Front-running attacks take advantage of the process by which transactions are added to the blockchain’s distributed ledger. A user that takes advantage of how the system works can make a near-guaranteed profit trading DeFi.
Transactions are not added immediately to the blockchain’s distributed ledger. They are collected into blocks and only added to the ledger as a part of these blocks.
The nodes in the blockchain network need to know about a transaction before it can be added to a block. Since the block creation process is decentralized, this means that the entire blockchain network needs to know about these transactions.
Once a blockchain user has created a transaction, they broadcast that transaction to the entire blockchain network. When nodes receive a copy of a transaction, they add it to a pool of unused transactions.
When a new block is being built, the block creator draws from the current pool of unused transactions. The order in which transactions are added to blocks is typically determined based upon the transaction fees.
While blockchains often have a minimum fee, blockchain users can set their own fees. This means that a user can pay for priority, putting a higher fee on a particular transaction.
The block creator – who receives these fees and is trying to maximize their profits – will add transactions to blocks based on fees, not the order in which they are received.
Front-running attacks take advantage of this process of adding transactions to blocks based on transaction fees. An attacker has the ability to ensure that their transaction is processed before any other transaction by including a higher transaction fee with it. This is called a front-running attack.
As decentralized finance (DeFi) becomes more common, this ability can make a user a significant profit. On cryptocurrency exchanges, the prices of buys and sells are dependent on supply and demand.
By front-running a buy that they see about to happen (because all transactions are publicly broadcast), a user can:
By front-running actions on an exchange (either buys or sells of a token), it is possible to make a profit. This is why bots are performing front-running attacks on DEXs. These bots net a near-guaranteed profit on transactions with minimal risk.
Front-running can also allow an attacker to cheat in contests where the first correct answer wins. The DODO DEX hack is an ironic example of this. In this case, front-running bots actually decreased the impact of the hack because they frontrunned some of the attacker’s attempts to exploit the vulnerabilities. After the hack was discovered, the owners of the bots returned the tokens that the bots drained from the DEX.
Front-running is a “feature” of how the blockchain is designed. Transaction fees are an intentional part of the blockchain environment, so the ability to pay for priority (and frontrun transactions) is not a design or implementation error.
The simplest way to escape front-running is to always pay transaction fees high enough that front-running is no longer profitable. However, this is an expensive and unsustainable way to beat front-running.
The other way is to cheat. This is how samczsun and a team managed to protect a major smart contract vulnerability from exploitation. Instead of publicly broadcasting a transaction, they secretly sent it to a mining pool that added it to a block without revealing it. This way, the transaction was only publicly visible once it was a part of the digital ledger.
While blockchains were called “unhackable” by some in the past, this isn’t actually true. Blockchains can be attacked in a number of different ways.
Blockchains can be targeted through a variety of different attack vectors. In some cases, the problem is a failure by blockchain users to follow security best practices. In others, the “vulnerability” lies in the design of the blockchain itself.
Here are the five most common ways in which blockchain systems are attacked:
One of the most common types of blockchain hacks is for a user to lose control of their blockchain account because the secret keys associated with that account are compromised.
On the blockchain, public key cryptography is used for identity management, so one of the main criteria for a transaction to be considered “valid” is for it to carry a valid digital signature. A compromised private key allows an attacker to perform transactions with a user’s account.
Security best practices for private key management say that users should manage their own private keys and store them offline when not in use. However, many users entrust their keys to cryptocurrency exchanges. This makes it possible for their keys to be compromised if an attacker guesses their account password, performs a SIM swapping attack to steal multi-factor authentication (MFA) codes, etc.
On the blockchain, transactions are not immediately added to the digital ledger. Instead, when transactions are broadcast to the blockchain network, they are stored by nodes in pools of unspent transactions. When future blocks are created, the contents of these blocks are composed of the current contents of the unspent transaction pool.
This delay between the initial publication of a transaction and its inclusion in the digital ledger leaves the door open to frontrunning attacks. In these attacks, an attacker observes a broadcast transaction and then submits their own version of that transaction (often with a higher transaction fee to increase the probability that it is processed first).
In a successful frontrunning attack, the attacker’s transaction is processed before the original one, often providing a profit to the attacker. Ironically, frontrunning bots actually saved the day in one case, where they frontrun an attacker’s transactions to exploit a vulnerability in the DODO DEX smart contract. By exploiting the vulnerability first and later returning the stolen value, the owners of these bots decreased the impact of this attack.
51% attacks are a built-in “vulnerability” of the Proof of Work consensus algorithm. In a Proof of Work system, the creator of the next block on the blockchain is selected by majority vote (with hashpower counting as votes). A 51% attack occurs when the attacker controls the majority of the votes. This provides them with complete control over the contents of the blockchain because they can build a version of the blockchain faster than the rest of the network put together.
The best protection against 51% attacks is to have enough hashpower in a blockchain network that it is infeasible for an attacker to control the majority of it (Polkadot has an interesting approach to this).
However, many smaller blockchains are trivially attackable using 51% attacks because the cost of a majority of the hashpower is so low.
Smart contracts are programs that run on top of the blockchain. Smart contract platforms implement virtual machines (VMs) that run smart contract code in an emulated, deterministic environment. This makes a decentralized computer possible because different nodes running the same code on identical VMs will always reach the same result.
Like any program, smart contracts can contain errors, and some of these errors will be exploitable vulnerabilities. Many of the recent exploits of decentralized finance (DeFi) projects - such as the Fei and ForceDAO hacks - have exploited smart contract vulnerabilities.
The blockchain is a concept, but it’s implemented as software. The blockchain works because each node in the network runs a program that follows set protocols to make the blockchain network work together despite being decentralized.
These programs - like smart contracts - can contain vulnerabilities that can be exploited by attackers. Most major blockchains have had at least one software vulnerability that either led to a hack or was detected and remediated before it could be exploited.
While, in many cases, the design of the blockchain is secure, an imperfect implementation can make it attackable.
Blockchain systems can be hacked in a variety of different ways, and the responsibility for protecting them lies with different parties in different cases. In some instances, such as frontrunning and 51% attacks, the “vulnerability” is the design of the protocol. In others, like compromised private keys, it is the responsibility of the blockchain user to follow security best practices.
However, in the case of software vulnerabilities - such as the ones that make smart contract and blockchain software exploits possible - the problem lies with the creator of the software. A failure to undergo a comprehensive security audit (covering both the design and implementation of the system) before release can leave the project and its users vulnerable to attack.
To schedule a security audit of your blockchain project, get in touch with Halborn by emailing [email protected].
Blockchains come in a variety of different flavors, including public vs. private and permissionless vs. permissioned. These choices not only affect the blockchain’s ability to meet business needs but also the security of the blockchain system.
Blockchain systems can be classified in a couple of different ways. The original blockchains, like Bitcoin, were public, permissionless networks. However over time, the concepts of private and permissioned blockchains have emerged as well.
The choice between a public and a private blockchain impacts who has the ability to create an account on the blockchain network and use it. Public blockchains, like BItcoin, allow anyone to use them, while other networks restrict access to particular users.
Structurally, public and private blockchains are largely the same. Often, a private blockchain is simply an instance of a public blockchain that is set up within a controlled environment.
However, some blockchains are specifically designed to be deployed as private networks.
Blockchains can also be classified as permissioned or permissionless. A permissionless blockchain, like Bitcoin, allows anyone to perform any role within the blockchain network.
Permissioned blockchains, on the other hand, restrict certain functionality to particular users.
Permissioning can be implemented within a blockchain in a few different ways. In some cases, blockchains use a “pay to play” model to implement permissioning, where any user with a certain minimum amount of cryptocurrency is a masternode with special privileges. Under this model, the assumption is that privileged nodes will not misbehave because of the potential risk of losing their investments.
Other permissioned blockchains have privileged nodes selected by the creators of the network. While these parties may be “trusted”, this model increases the centralization of the network.
The various types of blockchains create very different security environments. With the choices between public and private, permissioned and permissionless digital ledgers come a wide range of security considerations.
Some of the major security pros and cons of different blockchain types include:
These are only some of the implications of the various blockchain models for blockchain security. The precise security impacts and tradeoffs depend on the details of the blockchain’s design. For this reason, a third-party security audit - designed to identify design flaws or oversights - is a crucial component of the design process for a blockchain system. Identify the different security risks your blockchain company may be exposed to by contacting Halborn at [email protected].
Blockchains are high-value targets for cybercriminals. These systems are designed to store and process cryptocurrency and valuable information. As demonstrated by numerous incidents, hacking a blockchain can net a significant financial gain for an attacker.
Blockchains can be “hacked” in a variety of different ways. Some blockchain attacks take advantage of poor protection of private keys, either by the owner of a blockchain account or a cryptocurrency exchange. Others target vulnerabilities in the blockchain protocol, like a 51% attack that takes advantage of the fact that Proof of Work consensus is based upon majority vote.
In some cases, cyberattackers take advantage of vulnerabilities within blockchain protocols or their implementations. These code exploitation attacks leverage design or programming errors to break the blockchain system.
Exploitable vulnerabilities in blockchain code can be classified in a few different ways. One is based on the “type” of vulnerability that exists. The other is where the issue is located in the blockchain stack.
Blockchain is commonly (and incorrectly) called “unhackable” because many of its security assumptions are based on cryptographic algorithms believed to be secure against modern systems.
However, blockchain systems can “go wrong” in a couple of different ways:
The blockchain is a complex, multi-layered ecosystem. This means that design and implementation errors can exist at multiple different levels:
Attacks against blockchain systems are increasingly taking advantage of design or implementation protocols in blockchain-related software. As the functionality built into and on the blockchain becomes more sophisticated and complex, the opportunities for exploitation increase.
Minimizing the threat of code exploitation requires a comprehensive security audit before releasing new code. This should include all levels of the blockchain ecosystem and consider both potential design and implementation issues.
On the blockchain, your identity is managed using public key cryptography. Instead of having a blockchain account tied to a real-world identity, it’s linked to a particular public/private keypair.
The private key is used to generate digital signatures for transactions, while the public key can be used to verify them.
Under this model, access to a private key is equivalent to control over a particular blockchain account. Anyone who knows an account’s private key can perform transactions on its behalf, and blockchain immutability makes it impossible to reverse these malicious transactions. As a result, protecting the secrecy of a private key is essential for blockchain security.
Private key security may seem simple, but compromised private keys are the most common way in which blockchain accounts are hacked and people lose their cryptocurrency. Avoiding three common mistakes does a lot towards protecting the security of a blockchain account.
In order to use your blockchain account, you need to be able to remember the private key (or have something remember it for you). The use of mnemonic phrases to simplify key recall is designed to make this easier.
With mnemonic phrases or private keys, it may be tempting to create something that is easy to remember. Some common choices are a simple mnemonic phrase or a private key that is the hash of a common word.
While these seem like a good idea, other people have had the same idea already and look for these weak keys. If they guess correctly, they can take over a blockchain account and steal the crypto inside. For this reason, it is essential to use a completely random private key for blockchain accounts.
Some of the primary selling points of blockchain are decentralization and control over your own money. However, many cryptocurrency users immediately give up this control to a centralized exchange, trusting them to manage and secure the user’s private keys.
When using a cryptocurrency exchange, your security is only as good as that of the exchange.
In some cases, exchanges have been hacked. In others, users have traded the security of their private keys (long, random numbers) for that of passwords (often short and reused). As a result, exchange-related hacks are much more common than any other.
Putting private keys on a cryptocurrency exchange leaves them vulnerable. Private key security requires maintaining control of your own private keys.
Almost all software has vulnerabilities that can leave it exposed to attack. This is also true of software-based cryptocurrency wallets.
If private keys are on Internet-accessible systems, they may be vulnerable to attack. A better way to protect these private keys is to use a hardware wallet or other offline system to store private keys and generate digital signatures.
By ensuring that keys are never accessible to or stored on an Internet-connected device, these systems reduce their probability of exposure.
Control over a blockchain account is based on access to the corresponding private key. Anyone with the key can generate digital signatures and transactions for that account. This means that protecting your private keys is an essential part of securing a blockchain account and the smart contracts associated with it.
Blockchains can be targeted by a variety of different attacks. A Sybil attack - named after the subject of the 1973 book Sybil, a case study of a woman diagnosed with dissociative identity disorder - is when attackers take advantage of the blockchain’s anonymity to create multiple different malicious accounts. While these accounts can’t be used to break consensus, they can be used to attack the blockchain in other ways.
The blockchain protocol is designed to be pseudonymous. Instead of using real-world identities on the blockchain, users are identified by a blockchain address, which is derived from their private key.
Since a private key is just a random number, there is nothing tying it to an individual’s real-world identity. This fact also means that blockchain users can create multiple blockchain accounts, which can be used for benign or malicious purposes.
In a Sybil attack, the attacker creates a massive number of blockchain accounts. While this can’t be used to break blockchain consensus (blockchain consensus algorithms count hash power, staked cryptocurrency, etc. as “votes” instead of individual accounts), it can be employed in a few different attacks.
In a Sybil attack, the attackers have control of a number of different accounts on the blockchain network. While these accounts can’t be used to affect consensus, they may be useful for network-level attacks.
In an eclipse or routing attack, the attacker tries to isolate a blockchain node from the rest of the blockchain network or split the blockchain network into multiple, isolated pieces. Doing so makes it possible to perform double-spend attacks against the network.
In blockchain, nodes randomly select their direct neighbors in the blockchain’s peer-to-peer network. If an attacker performs a Sybil attack, a disproportionate number of the available nodes are under the control of the attacker. This increases the probability that a node will select only nodes belonging to the attacker as their peers or that all links between two parts of the blockchain network will pass through attacker-controlled nodes.
If this is the case, the attacker has control over the communications within the blockchain network. While they can’t create fake transactions on behalf of other users (since transactions are digitally signed), they can filter the transactions and blocks that each part of the network sees and send mutually conflicting versions of their own transactions to each part.
Using a Sybil attack in an eclipse or routing attack forces the isolated network parts into building different, conflicting versions of the digital ledger. This can be used in a Denial of Service attack or to increase the attacker’s probability of success within a 51% attack.
The design of the blockchain makes it impossible to use a Sybil attack to corrupt consensus. However, a Sybil attacker may still be able to impact the blockchain’s operations by performing a network-level attack.
Blockchain networks can mitigate the impacts of these attacks by adopting certain strategies.
To learn more about securing a blockchain against Sybil and other types of attacks, reach out to Halborn at [email protected]
51% attacks are one of the oldest and most famous attacks against the blockchain. They were described in the Bitcoin whitepaper because 51% attacks arise from how Proof of Work consensus works.
The Proof of Work consensus algorithm is designed to use a majority vote to decide the current state of the distributed ledger. However, instead of a “one account, one vote” approach to voting, Proof of Work bases the number of votes a user has on the computational power (or “hashrate”) at their disposal.
The reason for this is that it is easy to create additional blockchain accounts, which could allow an attacker to cheat the vote. Computational power, on the other hand, is harder and more expensive to acquire.
Proof of Work (PoW) implements its majority vote through the mining process. Each block in the blockchain needs to meet certain validity criteria, and one of these is that the hash of the block header must be less than a given threshold (the difficulty target).
The only way to find a valid version of a block header is through a guess-and-check process, testing different values for a nonce to see if they produce a valid header. This means that the more computational power that you have, the higher your probability of finding a valid block first.
This fact - combined with the longest chain rule - makes majority rule work in Proof of Work.
If there are two competing versions of the blockchain, the longest chain rule says that the “longer” of the two should be accepted, which means that whichever version grows faster has the advantage.
If a version of the blockchain has more hashrate supporting it (i.e. the majority vote), then it should grow more quickly and overcome other versions under the longest chain rule.
The design of Proof of Work is intended to make it difficult and expensive for an attacker to replace the original version of the blockchain with their own version. However, difficult does not mean impossible.
A 51% attack is a built-in vulnerability of the Proof of Work consensus algorithm. It states that, if an attacker gains control over 51% of the blockchain network’s hashrate, then the attacker gains control over the blockchain.
Looking at the Proof of Work protocol, this makes perfect sense. Proof of Work works on majority vote, and, if an attacker is the majority, then they win the vote and control the blockchain.
51% attacks are an inconvenient but unavoidable fact in a decentralized system. If a system works on majority vote, then an attacker with the majority of the vote controls the system. Any measure to block 51% attacks starts introducing centralization into the system.
The best way to fight 51% attacks is by making them too expensive and difficult to perform. This requires building up enough hashrate on a Proof of Work network so that it is infeasible for an attacker to purchase a majority of the network’s computational power.
Blockchains can be attacked in a variety of different ways. However, the most famous potential blockchain attack is the 51% attack against Proof of Work (PoW) blockchains. This attack takes advantage of the fact that PoW consensus is based on majority vote (with votes expressed as hashrate). If an attacker controls the majority of the vote, then they control the blockchain.
To protect themselves against 51% attacks, PoW blockchain networks try to attract as much hashrate as they can. However, hashrate is a finite resource, because computational power (and especially computational power that its owners are willing to devote to mining) is limited.
As a result, some blockchains have a lot of hashrate and protection and others do not.
As blockchain becomes more popular, these security limitations stand in the way of growth and scalability. Some blockchains are using sidechains to tap into the security of secure, stable blockchains, but the Polkadot Network is taking a different approach.
Cross-chain functionality has become common in an attempt to expand the functionality and scalability of a blockchain. Using sidechains “pegged” to a particular blockchain, it is possible to combine the stability of one blockchain (like Bitcoin) with the features of another (like support for smart contracts).
Sidechains also enable a blockchain to scale because - in most cases - the transactions performed on a sidechain are not recorded on the mainchain.
While sidechains have their benefits, security is a major limitation. Two sidechains that are pegged together are each responsible for their own security. If one of the networks is the victim of a 51% attack, the value of the associated cryptocurrency can fall, and the terms of the peg can change or fail entirely.
The Polkadot network consists of up to one hundred parallel chains or “parachains”. This design allows the network to achieve the same scalability and functionality benefits as sidechains because Polkadot puts minimal constraints on how a parachain works.
The main requirement that Polkadot places on a parachain is that any state transitions performed on a parachain must be communicated to and verified by the Polkadot Relay Chain.
Under this model, the responsibility for securing all of the parachains in the Polkadot Network is transferred to the validators of the Polkadot Relay Chain. In fact, most parachains do not even need to implement their own security.
By centralizing the responsibility for validation with a single group of validators, Polkadot removes the need for different blockchains to compete for limited hashrate. Anyone with an investment in a parachain (creators, users, etc.) has incentive to join the group of Polkadot Relay Chain validators by acquiring and staking DOT tokens. By doing so, they further diversify the set of block creators, making it more difficult for an attacker to gain control over the consensus process.
Blockchain networks are designed to be decentralized, meaning that much of blockchain security is based on incentives. As long as it is in the best interests of the blockchain’s users to behave correctly, the blockchain can remain stable and relatively secure against attack.
Polkadot has built a system where different blockchains are incentivized to pool their resources to secure the system as a whole. This enables the network to scale securely in a way that isn’t possible using sidechains.
The blockchain ecosystem is tightly intertwined with the web. Many blockchain-related applications (such as cryptocurrency exchanges, DApps, etc.) have websites, and attacks against these sites are often reported as blockchain hacks and proof that the blockchain is not as secure as many claim.
However, blockchain security is not the same as web security. Understanding the line between the blockchain and the web (and their relative security protections) is essential to understanding and evaluating blockchain-based applications.
Blockchain and the web are very similar. In fact, all but one of the current OWASP top ten list of web application vulnerabilities also apply to the blockchain.
However, the blockchain and the web differ in several significant ways. These differences have a dramatic impact on their security.
Blockchain-based solutions and smart contracts are hosted on very different infrastructure than websites. All data hosted on the blockchain is stored on the distributed and decentralized digital ledger. Websites, on the other hand, are hosted on centralized webservers.
These infrastructure differences make blockchain and web security very different. On the one hand, the design of the blockchain provides it with the advantages of anti-censorship and resiliency. On the other, the web’s centralization makes it easier to correct and update to patch a vulnerability or remediate a website cyberattack.
The blockchain and the web approach user authentication and access control in different ways.
One of the most common types of blockchain-related websites, online wallets, is designed to replace blockchain’s authentication mechanism with a web-based one.
On the blockchain, all authentication and access control is performed via public key cryptography. A user has a private key that they use to authorize transactions, and the corresponding public key is used to verify them. As long as the private key remains secure, only the legitimate owner of an account can perform transactions using it.
Websites can use a variety of different authentication mechanisms, but the most common is a password potentially backed up with two-factor authentication (2FA). Password security is notoriously poor, and the security of 2FA depends on the particular implementation. SMS-based 2FA - the most commonly used type - can be defeated via SMS interception, SIM swapping, phishing, and other attacks.
The decision to hand over private keys to websites is the most common source of hacks in the blockchain ecosystem. Website authentication is much more breakable, and attackers take advantage of this to gain access to the blockchain users that have entrusted their account security to these sites.
The World Wide Web was invented in 1989. The first blockchain (Bitcoin) was launched in 2009, and smart contract platforms came along even more recently.
The difference in age between the web and the blockchain has a significant impact on their relative security. Web developers are more familiar with their languages and the infrastructure than blockchain developers, and the web has received more security inspection than many blockchain platforms. As a result, when working on the blockchain, developers are much more likely to make mistakes that undermine the security of their systems and put users at risk.
The security of the blockchain and the web can be very different. However, they are both part of the blockchain ecosystem, and an effective blockchain security strategy should include both of them.
When designing or evaluating a blockchain-based solution, it is important to go further than a smart contract audit. Halborn offers in-depth, comprehensive security audits of blockchain-based solutions. Reach out to us at [email protected] for a consultation.
