Beating Re-Entrancy Attacks – Part 5 of the Smart Contract Series

DeTaSECURE

• 5 min read
Beating Re-Entrancy Attacks – Part 5 of the Smart Contract Series

Hello all, hope you are doing good, Today, we’ll go over smart contract security, which is something that every developer should be aware of before creating a smart contract. Smart contracts are pieces of code that run on the blockchain and handle millions of dollars. A simple flaw could result in the loss of a million dollars. To avoid this, we will learn about security best practices today.

Smart contract security is one of the main barriers to the widespread use of the blockchain. In order to inform and advance public understanding in this area, we are pleased to publish this series of essays on Solidity smart contract security.

One of the attacks that can be most detrimental to a smart contract is the Re-Entrancy attack. When a function calls another untrusted contract externally, it is called a re-entrancy attack. The untrusted contract then attempts to drain cash by calling the original function repeatedly. Because of how Ethereum handles value transfers, smart contracts on the platform are susceptible to re-entrancy attacks it treats user and smart contract counts equally, either one can call a smart contract or accept an ether transfer. A smart contract is given the opportunity to execute some code if Ether is delivered to an address that contains smart contract code. This "fallback function" could be used to do other operations prompted by the deposit, such as updating the internal state based on the transfer (such as issuing some token in response).

Disclaimer

In this article, smart contracts are simply used to illustrate vulnerability problems. Some contracts contain dangerous code, some are streamlined to a minimum, and some are insecure.  As a result, avoid using the source code from this article in your creation.
Worried about attackers targeting your smart contracts? Contact DeTaSECURE for your smart contract audits.

Re-Entrancy Smart Contract Attacks

In the past several years, there have been a number of re-entrance smart contract attacks. While this kind of assault made headlines the most in 2016, it also happened quite a bit in 2021. The following are a few of the most popular re-entrancy smart contract example hacks:

  • The DAO Hack – The most well-known Ethereum hack from 2016 was this one. Unfortunately, the DAO's smart contract's transfer mechanism was configured to send ETH to an external address before altering its internal state. As a result, it did mention that the amount was swiftly transferred. The latter provided the attackers with a means to take advantage of re-entrancy and withdraw more ETH from the contract than they were entitled to.
  • Uniswap/Lendf.Me – Back in April 2020, this re-entrancy hack resulted in $25 million being snatched.
  • Cream Finance – In September 2021, this DeFi protocol suffered a hard blow. The hackers behind the re-entrancy attack took over $34 million worth of AMP and ETH.
  • BurgerSwap – This token swap protocol, based on Binance Smart Chain (BSC), was attacked in May 2021. Using a fake token address and a re-entrancy exploit, the attackers stole about $7.2 million worth of tokens.
  • SurgeBNB – This is another noticeable re-entrancy attack worth $4 million. It took place in August 2021.
  • Siren Protocol – Back in September 2021, attackers managed to take $3.5 million worth of tokens from AMM pools by exploiting the re-entrancy weakness.

A Closer Look at Re-Entrancy Attack

State change has to be done before external calls:

According to Consensys “If you are making a call to an untrusted external contract, avoid state changes after the call.” To understand it better, let's have a look at the vulnerable code.

Example:

The above contract has two functions namely deposit and withdraw. Imagine it as a bank. Users can deposit their money and can also withdraw it.

The problem here is there are no checks implemented on whether the user has enough money to withdraw or not.

Second one could be usage of .call() function. This could open up a possibility for a reentrancy attack. Note that .call() does nothing to mitigate reentrancy attacks, so other precautions must be taken.

The third flaw that could be balanced is getting updated after transferring the amount to the caller.

So How to fix this?

There are three main methods for preventing reentry:

  1. Checks, Effects, Interactions (CEI)
  2. Reentrancy Guard / Mutex
  3. Pull Payment

For this example, we need to use the checks-effects-interactions pattern.

What is the Checks-effects-interactions pattern?

The checks-effects-interactions pattern refers to the various checks that must be performed prior to transferring funds to an external contract. In this way, we can prevent the loss of funds.

Let’s have a look at the fixed code.

In the above contract, withdraw function has certain checks including

  1. whether the user has enough balance or not
  2. State change is getting done before transferring the funds
  3. Usage of .transfer() function instead of .call(). Note that the transfer() function has a gas limit of 2300, This way it will prevent reentrancy attacks.

In the above cases of re-entrancy, the attacker executed malicious code during a single transaction. The ability to readily manipulate the order of transactions itself (inside a block, for example) constitutes a different kind of attack that is built into blockchains.

Conclusion

It is critical to be aware of such weaknesses and put in place efficient measures because a successful reentrancy attack can be disastrous and potentially drain all the funds in the victim's contract.

Whether there is a vulnerability or not, the CEI pattern ought to be used by default; it's just good practice. Reentrancy guards and/or pull payments are two methods that can be used to increase security. Gas restrictions may prohibit reentry, but they shouldn't be thought of as a security measure.

Worried about attackers targeting your smart contracts? Contact us today to get your smart contracts audited for any security issues!

Yuvarajan

is working as a security engineer in Detasecure. He can able to perform memory forensics and can able to analyze malware. He has done B.E from Anna University. He is an active participant in capture the flag (CTF) competitions. You can reach out to him by Clicking Here.