7 Most Common Smart Contract Attacks - Hacken (2024)

A smart contract is the most viable technology for exchanging digital assets in DeFi. However, errors that occur from time to time lead to catastrophic losses. In our audit practice, we face identical bugs over and over again. The most common representations of smart contract vulnerabilities are Unchecked External Calls, Suicidal and Greedy Contracts, and Block Info Dependency.

To stop the endless cycle of losses and avoid bad headlines for crypto, our auditors share findings with the community. Here we take a more detailed look at the list of the most prevalent smart contract attacks that can cost millions of dollars.

#1 Reentrancy attack

According to CWE Registry, a Reentrancy Attack is an example of Improper Enforcement of Behavioral Workflow.

One of the features of Ethereum smart contracts is the ability to call and utilize the code of other external contracts. Contracts in many cases send ether to various external user addresses. The operation of calling external contracts, or sending ether to an address, requires the contract to submit an external call. Cybercriminals steal those external calls and force the contract to execute and call back to itself (using a fallback function). The execution of the code “re-enters” the contract.

The attacker can carefully construct a contract at an external address that contains malicious code in the fallback function. Such contracts make a recursive call back to the original function in an attempt to drain funds. When the contract fails to update its state before sending funds, the attacker can continuously call the withdraw function to drain the contract funds.

Let's continue topic about the most common smart contracts vulnerabilities ?

Today we will look at the Re-Entrancy attack, which led projects to hundreds of millions dollars losses over the last years

Moreover, it led to Ethereum fork in 2016

?…

— Hacken?? (@hackenclub) November 2, 2022

From a historical perspective, the reentrancy attack is one of the most destructive attacks in the Solidity smart contract. The reentrancy attack led to hundreds of millions of dollars in losses over the last years, including the Ethereum fork in 2016.

Notable Reentry Attacks

1. Grim Finance (Dec 2021) $30 mln

Exploited Vulnerability: The attacker publishes a malicious contract whose callback function contains a call to the deposit function. Deposit function returns proof of investment to the user. It will call the callback function in the malicious contract again to obtain multiple proofs of investments. This allows the attacker to gain more additional revenue.

1. dForece (Apr 2020) $24 mln

Exploited Vulnerability: ERC-777 (a standard for token contracts interfaces and behaviors) allows transaction notifications to be sent to the recipient in the form of callbacks. This means that ERC-777 token indirectly results in the recipient having control of the execution

1. The DAO hack (2016) $60 mln

The DAO hack of 2016 still remains the most significant reentry attack in Ethereum because it lost 5.6% of all ETH in circulation at that time. On June 17th, 2016, The DAO was hacked and 3.6 million Ether ($60 million at that time) were stolen using the first reentrancy attack Ethereum Foundation issued a critical update to roll back the hack. This resulted in Ethereum being forked into Ethereum Classic and Ethereum.

Critical Reentrancy found by Hacken auditors

Where found: Smart Contract Code Review and Security Analysis Report for a client.

Issue: There is a possibility to re-enter the function for the message sender. If the transaction would be created from the contract which does have a fallback function it will be able to reenter the function again and again, until not drain all balance of the Colexion contract

Affected Functions: withdraw, end_auction

Recommendation: update the balance to zero before doing the transfer

So, the name “reentrancy” comes from the fact that the external malicious contract calls back a function on the vulnerable contract and “re-enters” code execution at an arbitrary location on the vulnerable contract. Reentrancy is an especially common error that could lead to catastrophic losses if left unchecked.

Detect and Fix Reentrancy Before It’s Too Late with Smart Contract Audit

See Also

Difference between BSC And BNB - Two Binance Terms ExplainedMalicious Insider | Malicious Insider TechniquesWhat Are the Differences Between Binance and BNB Chain?Malicious activity Definition | Law Insider

#3 Arithmetic Over / Under Flows

The fixed-size data types for integers are specified by the Ethereum Virtual Machine (EVM). What it means is that it can represent only a certain range of numbers. Without taking the proper measures the variables can be utilized in case if user input is unchecked which is the reason why numbers can be outside the range of data type they are stored at.

It usually happens during an operation requiring a fixed-size variable to store a piece of data or a number surpassing the variable’s data type range. Such smart contract vulnerabilities are utilized by cybercriminals in order to misuse the code and benefit from the process.

Example: Adding numbers that exceed the data type range is called Overflow. As soon as the uint (unsigned integer) reaches its maximum size, the next element added will overflow. For example, for uint8, the maximum number is 255, and if you add 1 more to it, then the variable will be overflowed and will equal 0 (if added 2, then the variable would be 1).

#4 Entropy Illusion

Every transaction on the Ethereum blockchain has a global impact on the entire Ethereum ecosystem in a calculable way. Basically, it means that any randomness or entropy is impossible inside the blockchain ecosystem. Therefore, ‘rand()’ function is absent in Solidity, and achieving decentralized entropy is a problem many experts address.

Some programmers are trying to write their own “random” functions, but as they are not well familiar with the ecosystem of the ETH – they mess up; as a result, vulnerabilities appear.

#5 Race Conditions / Front Running

The Ethereum blockchain nature implies the combination of external calls to other contracts and a large number of users which makes it possible for cybercriminals to determine Solidity vulnerabilities by racing code execution for their benefit.

Due to blockchain technology, Ethereum nodes form transactions into blocks that are considered valid as soon as a miner solves a consensus mechanism.

Before a transaction is added to the block, it goes to the mempool where everyone knows what will occur. Such circ*mstances can be troublesome for decentralized markets as a transaction to buy some tokens is seen, and a market order is implemented before the other transaction is included. It’s almost impossible to be protected against it, as front running is a specific feature of a contract itself. However, it would be better to implement batch auctions (also to stay protected against high-frequency trading issues) or to use a pre-commit scheme (“I’m going to submit the details later”).

#6 Denial of Service (DOS)

Being a very wide category, DOS attack implies leaving contracts dysfunctional for some time or even permanently. This attack can freeze ether contained in those contracts for an indefinite period or even forever. Moreover, DOS attacks can violate the logic of a smart contract.

#7 Constructors with Care

Being specific functions, constructors carry out the most important and special tasks during the contract initialization. In the earlier Solidity versions, constructors were named the same as the contract that has them. This way, when the contract name has been changed during the development, and the constructor name hasn’t, it turns out as a regular callable function. Therefore, the vulnerability became the reason for numerous cybercrimes. This type of vulnerability is rarely met nowadays, as the majority resorts to the constructor keyword.

#8 Tx.Origin Authentication

Ethereum blockchain has a global variable – tx.origin. It runs through the entire calling process and returns the address of the account that was sending the transaction. Utilizing the variable for smart contract authentication creates a serious vulnerability for a phishing cyber-attack.

We rarely come across this vulnerability. Developers with little experience in solidity cannot distinguish it from the variable msg.sender and therefore write contracts with vulnerabilities, using it where it is not advisable. So, never use tx.origin for authorization.

Summing Up

Regardless of how innovative blockchain is, even the best developer in the world can make an unintentional mistake that can cause serious problems. This is exactly why we decided to provide a list of the most common vulnerabilities we have found when auditing our clients’ smart contracts (there is also a separate class of logical mistakes which may have critical nature but we’ll describe them in further articles). Maybe, it will help someone to avoid facing devastating consequences and losing the company’s reputation. As they say, forewarned is forearmed.