Understanding the Threat of Read- Only Reentrancy Attacks on YourSmart Contracts
What is Read-only Reentancy Attack
Read-only reentrancy refers to a situation where a view function is reentered, typically without any protective measures, as it doesn’t modify the contract’s state. However, if the contract’s state is inconsistent, this could lead to incorrect values being reported. Additionally, this vulnerability can be exploited by attackers to deceive other protocols that rely on return values, causing them to read incorrect states and potentially execute undesired actions.
In the context of DeFi protocols, various integrations with other DeFi platforms are established to obtain token prices or read prices of wrapped tokens issued by specific protocols. This integration is possible when a lending protocol supports pool tokens from other protocols as collateral or allows staking. Such integrations frequently require the retrieval of pool token prices or wrapped token prices.
Attackers take advantage of these situations to execute read-only reentrancy attacks by manipulating token prices to their advantage.
The Importance of Caring About This Attack
The significance of the read-only reentrancy attack lies in its novelty, often overlooked by developers and auditors. As the interactions between different protocols in the DeFi space increase, the risk posed by this type of attack becomes more pronounced. Particularly concerning is its impact on DeFi protocols integrating with platforms like Curve.fi. These protocols frequently rely on reading token prices and wrapped token prices from other systems, making them susceptible to exploitation through price manipulation. To ensure the security and integrity of the decentralized finance ecosystem, it is crucial for developers, auditors, and the wider community to be vigilant about this threat and implement appropriate safeguards to mitigate its risks.
What is Reentrancy Attack
A reentrancy attack occurs when a function within a smart contract invokes an external contract that is not entirely trusted, and this external contract subsequently makes a recursive call back to the original function. As a consequence, the reentrancy attack can lead to the draining of funds or the initiation of malicious activities within the contract.
This type of attack can manifest in various forms, including Single-Function Reentrancy, Cross-Function Reentrancy, Cross-Contract Reentrancy, and Cross-Chain Reentrancy.
In this article, our focus will be on exploring Read-Only Reentrancy, delving into its specific characteristics and implications but let’s first give an example of Reentrancy Attack
Reentrancy Attack Senario
-
A user calls the withdrawAll() function of the “Reentrant” contract, intending to withdraw their balance.
-
The contract first checks the user’s balance in the userBalances mapping. If the balance is greater than 0, the function proceeds; otherwise, it throws an error message saying “Insufficient balance.”
-
The contract then deducts the user’s balance from the totalSupply variable without updating the user’s balance in the userBalances mapping.
-
The contract executes a msg.sender.call{value: balance}(“”) statement to transfer the user’s balance (in Ether) to the user’s address. This is where the vulnerability lies. The call function allows calling external contracts, and since it’s done before updating the user’s balance, the external contract can call the withdrawAll() function again before the balance is set to zero.
-
During the call to msg.sender, the external contract can call the withdrawAll() function again, effectively reentering the withdrawAll() function while the initial call is still in progress.
-
In the reentrant call, the function checks the user’s balance again, which is still the original value. Since the contract allows reentrancy without any guard, the same process repeats, and the external contract can execute the withdrawAll() function repeatedly, each time deducting the user’s balance from the totalSupply and executing the transfer of Ether.
-
This reentrancy loop continues until the totalSupply reaches zero, resulting in a scenario where the contract doesn’t have enough Ether to fulfill the balance transfer to the original caller.
-
Consequently, the contract will fail to send Ether (require(success, “Failed to send Ether”)) when the Ether balance is depleted, leaving the contract in an inconsistent state, and the user’s balance in the userBalances mapping will be zeroed out.
What is the method of operation or the attack strategy employed in Read-only Reentancy scenario?
-
In this scenario, an attacker deploys a contract capable of performing reentrancy and designates it as the “reentrant contract.” Multiple protocols, including the target DeFi protocol, rely on reading certain values from this contract, making it a crucial part of the attack.
-
When other protocols interact with the reentrant contract, it triggers a fallback method, causing the execution of specific logic defined within the attacker contract.
-
Seizing the opportunity, the attacker contract then proceeds to call the target DeFi protocol contract without any hindrance, exploiting its vulnerability.
-
As anticipated, the target protocol interacts with the compromised reentrant contract and unintentionally retrieves incorrect or manipulated values.
-
While the target contract remains oblivious to the attack, the attacker has successfully exploited it, completing the entire process as Steps 1 and 2 eventually conclude without interference.
Instances of Real-world Attacks
Numerous protocols have fallen victim to read-only attacks, resulting in the unlawful appropriation of substantial liquidity linked to these protocols, amounting to millions of dollars.
1- Sentiment Platform attack:
Analysis of the Attack
In a notable incident on April 4th, 2023, the Sentiment platform, operating on the widely adopted Layer 2 solution, Arbitrum, fell victim to an attack. The malicious act involved manipulating asset prices using read-only reentrancy, resulting in a significant loss of approximately one million dollars for the platform.
Protocols Involved
-
Sentiment Platform:
The Sentiment platform’s primary objective is to address capital inefficiencies by offering a primitive-based solution that enables permissionless undercollateralized on-chain credit. It tackles the challenge of widespread counterparty risk through on-chain hypothecation. Key to the Sentiment protocol is the concept of a “Sentiment Account,” which grants users access to higher leverage than traditional money markets. Borrowed assets from these accounts can be deployed across the DeFi ecosystem.
-
Balancer Protocol:
Balancer is a decentralized automated market maker (AMM) protocol built on Ethereum, providing a flexible building block for programmable liquidity. The core component of Balancer is the Vault, a smart contract responsible for managing and holding all tokens in each Balancer pool. Additionally, the Vault serves as the primary gateway for various Balancer operations, including swaps, joins, and exits.
-
Aave v3:
Aave Protocol is a decentralized liquidity protocol enabling users to participate as suppliers, borrowers, or liquidators. Users who supply liquidity to a market can earn interest on their provided crypto assets, while borrowers can overcollateralize and borrow assets. Aave also supports “flash loans,” which are one-block-borrow transactions that don’t require traditional overcollateralization.
Impact of the Attack:
The Sentiment platform integrates with Balancer pools, allowing users to open accounts with Balancer’s assets. To facilitate this integration, the Sentiment platform utilizes Balancer’s Vault contract and its getPrice(token) method. However, this introduces a vulnerability to read-only reentrancy attacks, potentially leading to asset price manipulation. This attack vector could have severe consequences for the Sentiment platform, potentially resulting in significant financial losses and undermining the trust of its users.
Positive Outcome Following the Attack
Fortunately, the Sentiment team managed to turn the situation around after the attack. They successfully recovered 90% of the stolen funds from the attacker and diligently worked to recoup the remaining portion. This positive resolution showcases the team’s swift response and effective recovery efforts, leading to a favorable outcome in the aftermath of the incident.
2- Check Our last Article About Eraland exploit
Mitigation
The approach to mitigating read-only reentrancy attacks varies depending on whether a new contract is being written or an already deployed contract is being read.
For new contracts, one effective mitigation method involves adding a read-only reentrancy guard. This guard operates by checking whether the reentrancy lock is active. If the lock is engaged, an error is triggered, preventing further execution. To ensure transparency, the lock can be made public, allowing calling contracts to verify whether the target contract is in lock mode before proceeding.
As for existing contracts, a reentrant modifier can be implemented and called as the first step in any function execution. If the modifier fails, indicating a potential reentrant attack, the contract will be placed in a locked mode, and any subsequent read operations should be avoided to prevent further vulnerabilities. By employing these mitigation methods, developers can enhance the security and robustness of their smart contracts against read-only reentrancy attacks.
