A smart contract is a computer application or a transaction protocol that is designed to execute, control, or document legally significant events and activities in accordance with the conditions of a contract or agreement. The goals of smart contracts are to reduce the need for trusted intermediaries, arbitration and enforcement costs, fraud losses, and purposeful and inadvertent exceptions.
Smart contracts are an account type. This implies they have money and can send transactions throughout the network. They are not, however, managed by a user; rather, they are deployed to the network and run as intended. User accounts can then engage with a smart contract by submitting transactions that perform a smart contract-defined function. Smart contracts, like conventional contracts, may set rules and automatically enforce them through programming. They are inherently irreversible and cannot be erased by default.
Without a doubt, smart contracts offer several fantastic application cases. Despite their many advantages, smart contracts can still be vulnerable. For example, attacks may, unfortunately, occur during the development period. In this blog, we’ll focus on one specific threat: reentrancy smart contract attacks. First, we’ll go over the fundamentals by addressing the question, “What is reentrancy?” After we’ve mastered the fundamentals, we’ll look at an example and then discuss the mitigation.
The term “reentrancy” is defined as “the act of entering again (reentering).” However, the term is nearly entirely associated with computing. In this sense, reentrant software or subroutines allow several invocations/requests to execute safely concurrently (either on multiple processors or on a single processor system). A reentrant operation in such systems can be halted in the middle of its execution. Following the interruption, the process might be called again (“reentered”) before the prior invocations finish.
According to the criteria above, there are several cases where reentry is advantageous. Decentralized Autonomous Organizations (DAOs) have a set of rules that are formed and controlled by the members of the organization and are not affected by outside forces. However, it can be a significant weakness with smart contracts. So, in the instance of smart contracts, let us now address the question “what is reentrancy?” A reentrancy attack might occur whenever a smart contract makes an external call to another smart contract. Furthermore, when a smart contract makes an external call, the execution of EVM is transferred from calling a smart contract. As a result, there is a potential threat unless the smart contract making the call has a complete understanding of the called smart contract’s code. So, the called smart contract may have anything to do with them.
The called smart contract might, among other things, make a call back to the originating smart contract (a reenter call). Furthermore, if the first smart contract has any flaws, the reinsert call might take advantage of them. These flaws manifest themselves when the original smart contract is not correctly updated at the time of the call. With that considered, it stands to reason that these exploits are known as reentrancy smart contract attacks.
One of the most damaging attacks in the Solidity smart contract is the Reentrancy attack. When a function makes an external call to another untrusted contract, a reentrancy attack occurs. Then, in an attempt to drain money, the untrusted contract makes a recursive call back to the original function.
When the contract fails to update its status before delivering cash, the attacker can execute the withdraw method repeatedly to drain the contract’s funds.
Recent Decentralized Finance (DeFi) attacks involving reentrancy vulnerabilities include the following:
These aren’t the only DeFi hacks that took advantage of reentrancy flaws. Reentrancy vulnerabilities are still showing up in new smart contracts today, despite being an old and well-publicized problem.
Okay, but how can you detect reentrancy in code? The simple answer is to examine any functions that make external calls and determine whether or not they are secure based on their rationale. Consider the following example (a high severity vulnerability):
Assume a susceptible contract that has just two functions:
For this practical, we will use Smart Contract Security – Reentrancy attack. So, let’s get the attack scenario first.
4. Now, the withdraw function will check to see if it can be executed:
a) Are there 10 ETH in the attacker’s balance? Because of their deposit, yes.
b) 10 ETH should be sent to a malicious contract. (The attacker balance has not yet been changed).
c) When an ETH call is received, the fallback function withdraws the function once more.
5. Now, the withdraw function will check to see if it can be executed:
a) Are there 10 ETH in the attacker’s balance? Because the balance has not been adjusted, yes.
b) 10 ETH should be sent to a malicious contract.
c) Using the contract, attacker depletes all of the ETH from the user’s wallet.
d) Again, until the attacker has depleted all of the value on the contract.
The contract with the reentrancy vulnerability is shown below.
The flaw occurs when we deliver the user the amount of ETH they requested. Attackers in this situation use the withdraw() method. Even if they have previously received tokens, they are allowed to transfer them since the balance has not yet been reset to zero.
Consider the following contract, which was created by a malicious attacker.
The attack() function in the victim’s contract invokes the withdraw() function. The fallback function runs the withdraw method when the token is received. The contract provides the token to the attacker once the check is passed, triggering the fallback method.
Functions should be designed based on check-effects-interactions code patterns i.e. state updates are made prior to recording value transfers.
Use the ReentrancyGuard function from “ReentrancyGuard.sol“ module and add attach nonReentrant to protect against reentrancy.
With the previous example, we can use the ReentrancyGuard function and test it.
The CEI (check-effects-interactions) pattern will remove the majority of difficulties, thus attempt to base your contract logic on it as much as possible. Make all of your checks first, then update your balances and make any necessary modifications before calling another contract.
Understanding how reentrancy attacks work in smart contracts is an excellent place to start when it comes to securing them. We will be talking more about Blockchain security in upcoming blogs.
By partnering with Redfox Security, you’ll get the best security and technical skills required to execute an effective and thorough penetration test. Our offensive security experts have years of experience assisting organizations in protecting their digital assets through penetration testing services. To schedule a call with one of our technical specialists, call 1-800-917-0850 now.
Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. If you are looking to improve your organization’s security posture, contact us today to discuss your security testing needs. Our team of security professionals can help you identify vulnerabilities and weaknesses in your systems and provide recommendations to remediate them.
“Join us on our journey of growth and development by signing up for our comprehensive courses.“
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
info@redfoxsec.com
©️2024 Redfox Cyber Security Inc. All rights reserved.
