Patch Thursday — Security risks due to exchange rate manipulation of ibToken

Summary

This article introduces the concept and principles of ibToken and sheds light on the security risks of ibToken exchange rate manipulation through various scenarios and the case of the Hundred Finance hack.

What is an Interest-bearing token (ibToken)?

ibToken, short for Interest-bearing token, refers to tokens issued to track the deposited underlying assets and the interest generated in the future. It is issued when providing liquidity with deposited assets to track both the deposited assets and the accrued interest. For example, in the case of providing liquidity to the Uniswap V2 USDC/USDT pair, the issued LP (Liquidity Provider) token can also be considered an ibToken.

ibToken is a common form of token found in Decentralized Finance (DeFi) and is used in services where interest is generated based on users’ assets, such as staking services and Decentralized Exchange (DEX) liquidity pools.

Due to the continuous accumulation of interest along with the assets deposited by users, the exchange rate between ibToken and the underlying assets starts at 1:1 initially, but the value of ibToken gradually increases compared to the underlying assets.

• There are exceptional situations where the value of ibToken may decrease. This can occur if the underlying assets held by the ibToken contract are stolen due to hacking or if the underlying assets of ibToken are used as borrowed assets in a lending protocol, resulting in a significant amount of bad debt that the protocol cannot handle.

If you want more detailed information about ibToken, please refer to the documentation of Alpaca Finance.

What is the exchange rate?

The exchange rate serves two purposes: it is used to issue ibTokens corresponding to the value of assets deposited by users while also ensuring that the value of existing ibTokens held by depositors remains intact. The exchange rate and the number of ibTokens to be issued are determined by the following formulas:

• Exchange rate = Issued ibTokens / (Deposited underlying assets + Accrued interest)
• Number of ibTokens to be issued = Quantity of underlying assets to be deposited * Exchange rate

The exchange rate involved in the conversion of underlying assets to ibTokens is calculated as Issued ibTokens / (Deposited underlying assets + Accrued interest). The value of the denominator, Deposited underlying assets + Accrued interest, can be applied in two ways:

1. By updating the state variable (stored in storage) in the contract whenever deposits or withdrawals of underlying assets occur or when interest is accrued. This allows tracking and applying the balance of underlying assets.
2. By querying the real-time balance of underlying assets held by the contract (token.balanceOf()) and applying it.

Updating the state variable every time can be costly in terms of gas fees or may pose implementation challenges. Therefore, it is common to query the real-time balance of underlying assets held by the contract and use that for calculations.

• Some contracts also provide functions like sync() that immediately updates the balance of underlying assets held by the contract in a variable. If real-time balance querying or immediate variable updates are supported, an attacker could exploit the exchange rate formula by sending tokens to the contract, significantly increasing the balance of underlying assets at that moment, artificially inflating the value of ibTokens, and facilitating a decrease in the exchange rate.

Principle of ibToken issuance

Based on the exchange rate mentioned above, the issuance of ibTokens is calculated. The issuance formula is Quantity of underlying assets deposited by users * Exchange rate. This formula allows for the issuance of ibTokens corresponding to the value of the underlying assets deposited by users without compromising the value of existing ibTokens.

The Scenario of ibToken Exchange Rate Manipulation

Manipulating the exchange rate of ibToken can lead to the following issues:

1. Issuance of undervalued ibTokens: When the exchange rate of ibToken is manipulated, it is possible for ibTokens with a lower value than the assets deposited by users to be issued. As a result, users may experience losses when trying to withdraw their underlying assets.
2. Denial-of-Service (DoS) attacks: Manipulating the exchange rate of ibToken can potentially lead to a denial-of-service attack where ibTokens cannot be issued. This can prevent users from interacting with the protocol.
3. Negative impact on on-chain oracles: If the manipulated exchange rate of ibToken is used in on-chain oracles, the consequences can be more severe. If the manipulated exchange rate propagates inaccurate information throughout the protocol via the oracle, it can affect various DApps (Decentralized Applications) and smart contracts that rely on accurate price data.

Let’s examine three scenarios for manipulating the exchange rate of ibToken:

ChainLight reported a vulnerability on March 21st where a DoS attack on governance token issuance was possible due to exchange rate manipulation. You can find detailed information here.

• Scenario 1: Manipulation when no ibTokens have been issued

1. The attacker deposits 1 wei of underlying assets and issues 1 wei of ibTokens.
2. The attacker transfers 100 ETH as the underlying asset to the ibToken issuance contract. In this case, the exchange rate becomes 1 to 1 / (1 + 100 ETH).
3. The victim deposits 10 ETH of underlying assets to issue ibTokens. The number of ibTokens to be issued can be calculated using the issuance formula as 10 ETH * 1 wei / (1 wei + 100 ETH). Due to round-down, even though the victim deposited 10 ETH of underlying assets, no ibTokens are issued.
4. The attacker burns the ibTokens and receives the underlying assets. The amount of received underlying assets is 110 ETH + 1 wei. The attacker seizes the victim’s 10 ETH of underlying assets.

• Scenario 2: Manipulation when ibTokens have been issued

1. (Assuming no accrued interest) When the issued ibToken is 10 ETH, the attacker deposits 10 ETH out of their 110 ETH of underlying assets and mints 10 ETH worth of ibToken.
2. The attacker transfers 100 ETH of underlying assets to the ibToken issuance contract. As a result, the exchange rate becomes 1 divided by (20 ETH + 100 ETH).
3. The victim deposits 10 ETH to issue ibTokens. Similar to the previous scenario, due to round-down, even though the victim deposited underlying assets, no ibTokens are issued.
4. The attacker burns the ibTokens and receives the underlying assets. The received underlying assets amount to 65 ETH.
5. The attacker seizes the victim’s 5 ETH of underlying assets, but the attacker loses 50 ETH out of the 100 ETH of underlying assets used as the attack cost.

This scenario occurs when the attacker holds a stake of 50% in ibTokens, not 100%, and transfers the underlying assets to the ibToken issuance contract. As a result, the attacker loses 50% of the attack cost of 100 ETH.

When the quantity of issued ibTokens is 0, there are contracts implemented to revert in such cases. While these contracts prevent the attacker from fully seizing the victim’s funds through the described attack, the attacker can still cause a DoS by preventing the issuance of ibTokens, and the attacker can potentially exploit MEV (Maximal Extractable Value) to capture a portion of the victim’s funds.

• Scenario 3: A scenario where a revert occurs when the ibToken to be issued is 0, leading to the victim’s funds being captured through MEV

1. The victim initiates a transaction depositing 10 ETH as the underlying asset when there are no issued ibTokens.
2. The attacker observes the victim’s transaction and deposits 1 wei as the underlying asset (issuing 1 wei of ibTokens) before the victim’s transaction. Then, the attacker executes a transaction transferring 5 ETH as the underlying asset. The exchange rate at this point is 1 wei / (5 ETH + 1 wei).
3. When the victim’s transaction is executed, the number of ibTokens issued is calculated as 10 ETH * 1 wei / (5 ETH + 1 wei), resulting in 1 wei being issued due to round-down.
4. The attacker, holding 50% of the issued ibTokens, receives (15 ETH + 1 wei) / 2 as the underlying asset.
5. The attacker seizes 25% of the underlying asset deposited by the victim.

This scenario demonstrates that even when a revert is triggered due to the number of issued ibTokens being 0, it does not prevent the attacker from capturing the user’s funds through exchange rate manipulation.

Exchange Rate Manipulation Hacking Case

The Hundred Finance hacking incident on April 25, 2023, resulting from exchange rate manipulation, involved the attacker inflating the value of ibTokens through rate manipulation, thereby overvaluing the collateral and seizing assets of higher value than their actual worth. This hacking incident resulted in a total of $7 million in assets being stolen by the attacker.

Hundred Finance is a lending protocol that forked Compound V2 and deployed it on Optimism. Users can deposit wBTC and mint hwBTC as the corresponding ibToken. Hundred Finance utilizes hwBTC as collateral to borrow other assets.

Cause and Analysis of the Hack

The attacker exploited the empty liquidity in the hwBTC pool, allowing them to manipulate the exchange rate at will. By leveraging the round-down issue during the conversion of ibTokens to underlying assets, the attacker was able to seize all the attack funds.

Here’s a breakdown of the steps taken by the attacker:

1. When no hwBTC was issued, the attacker minted hwBTC equivalent to 2 wei.
2. The attacker borrowed wBTC from the hwBTC pool using a flash loan, manipulated the exchange rate, and significantly increased the value of ibTokens.
3. The attacker borrows other underlying assets using 1 wei of inflated ibToken as collateral.
4. The attacker calls the redeemUnderlying function with a value of underlying assets to be received equal to the number of underlying assets existing in the hwBTC pool — 1. Due to rounding down, only 1 wei is burned instead of the intended amount of 1.9xxx… wei (calculated as the number of underlying assets existing in the hwBTC pool — 1 * exchange rate). The attacker exploits this to receive back the wBTC used in manipulating the exchange rate.

• Compound Finance’s cToken has two functions when it comes to liquidity removal: the redeemfunction, which inputs the number of ibTokens to be removed, and the redeemUnderlying function, which inputs the number of underlying assets to be received in return.

5. At this point, the exchange rate between hwBTC and wBTC returns to 1:1.

6. Subsequently, as the value of the collateral drastically drops compared to the borrowed amount, bad debt is incurred. The attacker liquidates this position and continues the attack, resulting in the theft of $7 million.

This case highlights the risks associated with exchange rate manipulation and emphasizes the importance of thoroughly understanding and utilizing all code when forking existing protocols that are already in use.

Solutions

Here are three practical examples of actual solutions to address the issue of exchange rate manipulation:

1. Compound V2: Although Compound V2 has the potential for attacks when there is no liquidity in the code, no exchange rate manipulation incidents have occurred thus far. It is believed that this was prevented by initially providing a small amount of liquidity during deployment. Projects that fork Compound V2 should be aware of this risk and either provide a small amount of liquidity during deployment or modify the code to prevent exchange rate manipulation.
2. UniswapV2: When you first add liquidity, a small amount of liquidity is sent to a dead address to ensure that there is always a minimum level of liquidity and ibToken (LP token) supply. This strategy makes it more difficult and less profitable for attackers to carry out their attacks, thus reducing their motivation to attack.
3. OpenZeppelin ERC-4626: The risks associated with manipulating the exchange rate of ibToken and the solution* to this problem are explicitly mentioned in OpenZeppelin’s official documentation. OpenZeppelin has adopted the solution proposed by YieldBox, and finally, in “OpenZeppelin Contracts v4.9”, the solution for ERC-4626 has been implemented. (Even before the implementation, the solution was already recommended in the official documentation.)

*The solution introduces the concept of Virtual Offset, which involves adding a Virtual Offset to the ibToken decimal to calculate the exchange rate. This approach ensures that even in the absence of liquidity, the effects of having liquidity are simulated, resulting in losses for attackers attempting to manipulate the exchange rate. By increasing the cost of attack and significantly reducing the likelihood of profit realization, the motivation for attackers to carry out such attacks is effectively diminished.

Conclusion

What we can learn from the security risks associated with ibToken exchange rate manipulation is that it is important to thoroughly examine whether there are any adverse effects that can occur in specific situations beyond simply recognizing this vulnerability. It also emphasizes the importance of understanding and implementing all the code when forking a protocol or using a library. Just because a target protocol to fork has had no past hacking incidents and maintains a high TVL (Total Value Locked), it does not guarantee that there will be no security issues when using the same code. There may be vulnerabilities that have not been discovered in the forked project, and as described in this article, there may be vulnerabilities triggered in specific situations, such as when liquidity is depleted.

References

• https://docs.alpacafinance.org/tokenomics/IBtokens
• https://docs.openzeppelin.com/contracts/4.x/erc4626
• https://github.com/SunWeb3Sec/DeFiHackLabs#20230415-hundredfinance---flashloan-exchangerate-manipulation--erc4626-inflation-attack
• https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3979
• https://mixbytes.io/blog/overview-of-the-inflation-attack

✨ We are ChainLight!

ChainLight explores new and effective blockchain security technologies with rich practical experience and deep technical understanding. Our innovative security audits built upon such research proactively identify and eliminate various security risks and vulnerabilities in the Web3 ecosystem. To ensure continuous security even after the audit, we provide a digital asset risk management solution using on-chain data monitoring and automated vulnerability detection services.

ChainLight serves to guide and protect all users of decentralized services, lighting the way for a safer Web3 ecosystem.

• Want to see more from the ChainLight team? 👉 Check out our Twitter account.

🌐 Website: chainlight.io | 📩 TG: @chainlight | 📧 chainlight@theori.io