Reentrancy attack in smart contracts

Smart contracts have taken the blockchain world by storm, enabling trustless and automated transactions on platforms, but reentrancy attack in smart contracts pose a serious threat. As with any new technology, there are security challenges that must be addressed in smart contracts too.

Smart contract reentrancy attacks can lead to significant losses. Join us in this article as we explore what reentrancy attacks are, how they work, examples of them, and, most importantly, how to protect smart contracts from them.

What is a reentrancy attack?

A reentrancy attack, also known as the call-after-call attack, is one of the most common exploits in smart contracts. It occurs when a contract is called recursively before the first call has finished executing all its functions.

This happens because, unlike traditional programs, smart contracts do not deactivate their code when they call another contract; the called contract immediately executes, and then control returns to the first one.

As we describe in the first paragraph, a reentrancy attack exploits this by recursively calling a smart contract while still inside another contract's code block.

The attacker can then divert the intended flow of execution and make unauthorized state changes, such as stealing funds. In 2021, nearly 30% of all cryptocurrency thefts involved reentrancy attacks on dApps and DeFi protocols.

How does the reentrancy attack work?

Let's break down the steps of a reentrancy attack:

• The attacker contract calls the victim contract and transfers Ether to it.
• Before the victim contract finishes executing all its functions, it calls an external contract, which happens to be the attacker contract.
• The attacker contract calls the victim contract again, recursively, before the first call finishes.
• The attacker modifies the victim contract's state during the second call, such as withdrawing Ether from the contract since the first call is still on the stack.
• The attacker essentially "reenters" the victim's contract before the first call finishes, circumventing checks and stealing funds. The victim incorrectly assumes state changes from the first call were executed, but they were overwritten by the attacker.

In essence, the attacker abuses the fact that smart contracts can call other contracts and manipulate states during that process before the intended execution is complete. As a result, it jeopardizes the security of smart contract-protected crypto exchanges.

What are the different types of reentrancy attacks?

There are a few variations on how types of reentrancy attacks can be implemented:

• Call-After-Call: As described above, this is the most common type where an external contract is called recursively before the first call finishes.
• Call-After-Send: Here, the attacker sends Ether to the victim contract to trigger a call, then calls recursively before the funds transfer finishes.
• Delegatecall: Some fallback functions allow delegatecall, which executes code in the context of the calling contract. Attackers abuse this to re-access storage from the calling scope.
• Pull Attack: By pulling funds rather than pushing, via call.value(), the attacker contract initiates transactions without requiring a call first.

Any way an external contract can be invoked recursively from within another contract's scope presents a reentrancy risk if state changes or callbacks are not properly protected. Let’s explore an example of a reentrancy attack in smart contract to understand how it works.

What is an example of a reentrancy attack in a smart contract?

One of the most infamous examples of reentrancy attack in smart contracts was on The DAO in 2016, which led to $150 million being stolen from its Ethereum funds.

As a brief background, the DAO was a venture capital fund crowdsourced from Ether contributions. It contained a vulnerable splitDAO function that allowed splitting Ether.

Each investor's total investment in the DAO is kept track of in the smart contract as a state variable named Balances. By posing as an "investor" and deploying a smart contract, the hacker gained access to the DAO's ETH and then withdrew it by invoking the withdraw() method.

The attacker called splitDAO recursively over and over before the contract's state had been updated, gradually emptying its funds with each reentrant call. However, it did not take into account the possibility of reentrant calls. This left its balance unchanged each time until it was fully depleted.

The DAO transferred ETH to the hacker, but the hacker's smart contract was missing the receive() method on purpose, which caused the contract to execute malicious code in its fallback mode.

This line of code repeatedly invoked the DAO's withdraw() method, resulting in a never-ending cycle of exchanges between the hacker contract and the DAO's smart contract. The DAO continued to drain its funds as it sent the hacker additional ETH without reducing the hacker's balance.

A group of "whitehat" hackers tried to withdraw money from The DAO as quickly as the attacker did, using the same exploit to save money and return it to investors. Members of the DAO received several refunds, but many investors left the protocol via so-called "escape pods" to withdraw their assets.

This attack exposed major issues like a lack of reentrancy protection and over-reliance on asynchronous state change assumptions in smart contract design at the time. It highlighted the risk of recursive calls compromising financial transaction processing.

What does a reentrancy guard do?

The most common way smart contracts defend against reentrancy is by using a reentrancy guard. This basically disables external calls and prevents reentrancy until all post-call state changes are executed.

A typical reentrancy guard disables external calls by setting a "locked" boolean flag before entering a state-changing function. Before any funds move, it also clears the call stack by transferring all Ether owed to the recipient. Then it unlocks external calls at the end only if all other operations succeed.

This ensures the smart contract's state and funds are never accessible to an externally called contract until the function is fully executed.

Reentrant calls cannot disturb the intended execution flow or manipulate the state. Additionally, you can trust Cryptobunq, as it is an audit-secure crypto service provider. CBQ's transparent transactions guarantee security.

How do you protect smart contracts against a reentrancy attack?

Here are some effective ways developers can help secure smart contracts in blockchain:

• Use pull-over push payments where possible to avoid reentrancy issues with call.value().
• Implement a reentrancy guard by disabling external calls during state changes.
• Check call stack depth before allowing external calls from within a function.
• Use mutex locking patterns to prevent reentrant functional access.
• Keep fallback functions empty if not needed to avoid additional entry points.
• Perform input validation and limit external access to critical functions.
• Thoroughly test contracts for reentrancy, particularly after any state changes.
• Gradually update to more secure standards.

Staying vigilant about reentrancy attacks is crucial as the value and adoption of decentralized applications increase. With care and testing, smart contracts can provide secure and trustless transactions on exchange platforms.

Studies show that more than 15% of people around the world who don't have bank accounts could possibly get access to new financial systems through platforms powered by reliable stablecoins like EURK.

This is because EURK's architecture is securely audited, and its transactions are clear and designed to be efficient and reliable. With proper security measures in place, decentralized applications can truly expand access.

Additionally, EURK has reserves both in Switzerland and the Dominican Republic. These reserves show that EURK is a secure stablecoin that is 1:1 pegged to the euro. As a euro stablecoin, EURK offers fast, secure, and easy transaction options for individuals and businesses.

The bottom line: eliminating reentrancy vulnerabilities before funds vanish

Reentrancy attacks pose a serious threat to smart contract security due to the unique characteristics of blockchain technology execution environments. The costs of not properly preventing this attack can be enormous, as seen with past incidents involving millions of dollars stolen.

While reentrancy is a complex problem, using community defenses like reentrancy guards, limited external access, and input validation offers strong protection for contracts and their users. Responsible security practices are needed to ensure the continued development of this new technology.

Additionally, you can use a reliable type of cryptocurrency, such as EURK, and an expert crypto service provider, such as CBQ, to eliminate these risks and make secure transactions.

The Cryptobunq-approved transparent and secure architecture of EURK, an emerging euro stablecoin, aims to combine the benefits of both transparency and security. If you want to learn more about EURK advantages, contact us. Secure transactions are possible with EURK!