Smart Contract Attacks and Bugs: What Should We Know?

The first smart contract quickly broke into the blockchain world and brought many benefits for businesses. However, they are, at the same time, quite complex and not 100% resistant to attacks. Therefore, it was expected that the new virtual technology could not be forever invulnerable, especially only at the beginning of writing smart contracts.

Therefore, it is worth analyzing the most common vulnerabilities so that developers can work on them even before the launch of a contract. Otherwise, it is not profitable for investors to invest even in the most promising project because of the risk of losing their savings. Today we will analyze how dangerous bugs are, what they are, and discuss the top examples of successful attacks on a smart contract.

Why Are Attacks and Bugs on a Smart Contract so Dangerous?

Safety matters in a smart contract are quite serious because almost everyone is concerned about financial assets. Also, threats and bugs are dangerous for the following reasons:

• Due to the immutability of the blockchain, an error in a contract cannot be corrected after it has been published;
• Erroneous or fraudulent contract transactions cannot be canceled, resulting in the Blockchain state changes.
• The main reason for the existence of a vulnerable smart contract can be explained by a lack of understanding of the limiting cases associated with the implemented logic of the platform.

Thus, even one vulnerable function can cause serious problems.

Top-6 Vulnerabilities of Smart Contract Technology

Browse the most popular vulnerabilities encountered by security experts in blockchain technology. They are also found on the Ethereum platform as the most common smart contract environment.

Reentrancy Attack

Reentrancy attack occurs between two contracts, and calls to other smart contract functions happen synchronously. Thus, the calling code waits for the execution of the outer method to complete before continuing. Therefore, it can lead to the use of an intermediate contract state. This scenario of a reentrancy attack is not always obvious during development.

The fraudulent behavior of the invoked contract is not considered, if possible. During each next call, the contract checks if the balance has been replenished to this address, in which case a new deposit will not occur. The reentrancy attack simply re-enters the pay function before writing the address to the variable. In such cases, it will be.

Since the call function is operated for deposits, re-entry by everyone can be done by writing the suitable sense in the fallback function of the fraudulent contract. For reentrancy attacks, such a vulnerable contract must be placed on the network and wi5h the payment function.

Unknown Contract Code

Due to the fallback function in multiple contracts, indirect execution is possible. This function can be called for several reasons:

• Use an ABI to call a function of another Ethereum smart contract.
• Inserting into another contract causes its fallback function to be called.
• Calling a function of another contract by the API.

Regardless of the attack’s reason and an incorrect function in solidity code, it is worth paying special attention to these artificial bugs. They are often included in the lists of the most popular hazards from the Decentralized Autonomous Organization (DAO).

Cross-Function Race Condition

The DAO contract failed to properly update the state of the contract, resulting in the theft of funds. Part of the problem with DAOs and external functions (calls) is the possibility of cross-functional race conditions. While each transaction is continuous, external calls can be a recipe for disaster if not managed properly. In an ideal world, they would avoid it completely.

Due to function transfer, the user’s balance is not set to 0, but attackers can also transfer funds even though they have been withdrawn. In this case, the contract allows the attacker to double the funds, which is one of the concerns that blockchain technology is created to solve. So, function transfer makes external calls when sending funds to the recipient address.

Similarly, the function withdraw also uses the callback function to pass a one-time reward, which is not trustworthy. Therefore, it is also important for the contract to initially do all the internal work during function withdrawal.

Underflow Attack

The Ethereum virtual machine is developed to use 256 bits as the word size, or the number of bits the computer’s CPU can process at one time. Understatement occurs when someone subtracts a number greater than zero from zero, resulting in a new allocated integer 2²⁵⁶. Now, if the attacker’s balance is insufficient, the balance will be updated so that all funds can be stolen.

To avoid falling victim to an underflow attack, it’s best to review if the edited integer stays within the byte range. Developers can add parameter fitting to the code as a last line of defense. The first line of the function deposit or withdraw checks for sufficient funds, the second – overflow, and the third – insufficient.

Faulty Work with ERC20 Token

ERC-20 tokens are overused in modern protocols. In most cases, it is suitable and functional enough for proper financial work. So it creates room for contention between the new tokens and the actual ERC20 standard ​​in transfer functions. However, such a small change can result in a non-functional contract method because it doesn’t recognize the interface. It is a very small bug that is barely noticeable during testing, but it causes funds to stop and a contract to get blocked in production.

Most Known Attacks

Over the years of successful functioning of the blockchain, quite dangerous and unpleasant situations have shown more and more vulnerabilities in internal and external contracts. Among them:

• DAO attack. About $60 million was stolen. The Ethereum blockchain was later forked to recover stolen funds from the DAO balance, which were returned to investors.
• Rubix Bugs. It is ​​a Ponzi game where its owners can transfer the rewards accumulated in the financial pyramid. The contract was renamed from Dynamic Pyramid to Rubix. Still, the developer forgot to change the constructor’s name, so anyone who calls its function could become the contract owner, steal the accumulated funds and make a transaction.

There were attempts to implement other hazards, but they were not so successful. However, this does not exclude their risk in the future. In general, 2016 is considered the most successful year for scammers and important for developers, as all the main vulnerabilities and errors were shown, including the function withdrawal imperfection.

Summary

This new technology allows users to create decentralized digital agreements without a third party. As a result, it attracts many industries, including healthcare, business management, shareholder agreements, and insurance. However, the more this technique scales, the more it will attract the attention of potential attackers, leading to new vulnerabilities.

Therefore, it is important to understand what exactly threatens our funds and transactions. Otherwise, it will lead to their loss. For example, incorrectly acting contract functions lead to code errors or completely change the path to the recipient address. And as a result, the balance of the real investor is empty, and the scammer is full of other people’s money. So, be attentive and initiate an audit of functions before launching the contract.

FAQ