On May 8th an attacker was able to drain approximately 2600 ETH from the Rari Capital Ethereum Pool by leveraging the functions of the ibETH pool (Bank contract) of Alpha Homora V1, which is integrated in Rari Capital V2. The attack was performed over a series of approximately 200 transactions. This write-up provides a description of the technical details that made the attack possible and provides a step-by-step description of the attack.

Why the Attack Was Possible

The issue that caused the hack of the Rari Capital protocol was known by Alpha Finance since it was raised during the PeckShield audit published on October 5th, 2020 (see issue 2.3, link). According to the report, this issue was not fixed.

The fallback() function implemented in the Alpha Finance Bank contract (also known as ibETH) allows any address to deposit Ether into the contract, which modifies the return value of the Bank.totalETH() function. However, any ETH sent to the contract directly will be lost (distributed between the LPs) since there will be no way to withdraw it back, meaning that attackers cannot use it normally to exploit the Bank contract, except for a single scenario, which is described below.

The aforementioned issue in the PeckShield audit was not assessed correctly, the way that Bank.work() was implemented allowed the attacker to modify the ibETH state by depositing ETH through the fallback() function and still withdrawing it from the Alpha Finance Bank contract.

To summarize the attacker exploited the following functions in Alpha Finance:

• Bank.fallback()
• Bank.totalETH()
• Bank.work()

By doing so the attacker was able to manipulate the Alpha Finance contract state in a way that impacted the Rari Capital Ethereum Pool contracts.

How Was the Rari Capital Ethereum Pool Manipulated?

​
Alpha Finance LP earnings rely on the Bank.totalETH() function to estimate the total interest accrued, anyone able to manipulate its return value will technically be able to attack any third party relying on it.

Alpha Finance themselves relies on the totalETH() function to calculate ETH holdings of their users. When a user calls Bank.withdraw(), share.mul(totalETH()).div(totalSupply()) is used to estimate the user share from the total ETH holdings of the Bank. Rari Capital relied on the same computation in AlphaPoolController.getBalance() and AlphaPoolController.withdraw().
​
The attacker was able to manipulate Bank.totalETH() by sending a significant amount of ETH to the Alpha Finance Bank contract using a direct transfer and still being able to withdraw it due to a flaw/feature in the Bank.work() function. It is important to note here that for the majority of contracts in DeFi, sending ETH directly to the contract without calling the designated deposit function will almost always lead to the sender losing their funds because they will not be able to withdraw it.
​

Exploit Description

The description below only includes the main steps that the attacker went through to execute the exploit. We deem the attack extremely complex, the attacker needed a high degree of knowledge over multiple DeFi protocols (i.e. Alpha Finance, SushiSwap, Rari Capital) especially Alpha Finance and SushiSwap.

1. The attacker deploys a malicious token contract to handle most of the attack logic.

2. The attacker creates a fake SushiSwap token pair (ETH/Malicous Token) and add liquidity to it.

3. The attacker calls the Bank.work() function using the SushiswapGoblin contract address and a special payload that contains the StrategyAddTwoSidesOptimal contract address and the malicious token contract address. Note that both of the SushiswapGoblin and StrategyAddTwoSidesOptimal contracts:

   • were deployed by AlphaFinance on November 27th, 2020 and
   • were never used until the Rari Ethereum Pool hack on May 8th, 2021.

4. The SushiswapGoblin contract calls execute() on the StrategyAddTwoSidesOptimal contract of Alpha Finance.

5. StrategyAddTwoSidesOptimal contract calls the malicious token approve() function that is the main trigger of the attack.

6. The malicious approve() function in the token contract deployed by the attacker makes a flash loan from dYdX, deposits it in the Rari Ethereum Pool contract and receives REPT in exchange for that deposit. This is done by calling RariFundManager.deposit(), which at one point down the call chain calls Bank.totalETH() from Alpha Finance to compute the amount of REPT minted, as shown in the following screenshot of the transaction trace:

7. Inside the same approve() function in the malicious contract, ETH is sent to the Alpha Finance Bank through the fallback() function. The key to the attack resides here, the funds sent will allow the attacker to modify the return value of Bank.totalETH() in a way that will allow them to withdraw more ETH than they initially deposited in the Rari Ethereum Pool contract.

8. The malicious contract calls RariFundManager.withdraw() to redeem the previously minted REPT tokens using the dYdX flash loan. Since the attacker deposited Ether in step 7, the Rari Ethereum Pool will calculate a higher total balance due to the Alpha Finance Bank.totalETH() returning a higher balance than the same call returned in step 6, when REPT was minted. This means that significantly less REPT is burned than the amount that was minted in step 6, which leaves the attacker with the difference in REPT while getting back the same amount of ETH.

9. All the remaining logic is executed, the goblin call returns and Bank.work() continues its execution. The amount sent in step 7 is sent back to the msg.sender (attacker) due to Bank.work()#L162.

10. The attacker calls the donate() function in the malicious contract which:

    • Burns the extra REPT gained in step 8 in exchange for ETH.
    • Deposits the received ETH in step 9 back to the malicious token contract.

11. The attacker re-executes steps 3-10 multiple times, withdrawing more ETH every time from the victim contract (the Rari Ethereum Pool contract).

Conclusion

Approximately 2600 ETH was stolen from Rari Capital on May 8th 2021. This was due to an exploit of a known bug reported on October 5th, 2020 in a public audit report and which was not fixed. In response to the report, Alpha Finance stated:

"The randomly received ether would not greatly interfere with the calculation. We leave it as is.”

It is debatable whose responsibility it is to check for such an ibETH pool exploit. We have considered several ibETH integration implementations and we have yet to find one where this kind of attack is prohibited. This means that any Dapp that integrates with the Alpha Finance V1 (ibETH pool) or is currently using it, runs the risk of a similar exploit.