Most Common Smart Contract Attacks

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.

#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 circumstances 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.