Back to all stories
Reports
Incident Analysis
Revisiting FEI Protocol Incident
6/27/2022
Revisiting FEI Protocol Incident

TL;DR

On 30 April 2022, Fei Protocol announced that they were aware of and looking into an exploit on various Rari Fuse pools, that turned out to be a common re-entrancy attack. The total loss reported was ~$80 Million.

Event Summary

On April 30 2022, at 09:01:35 AM +UTC Fei Protocol announced that they were aware of and looking into an exploit on various Rari Fuse pools. The total loss reported was at ~$80 Million. They paused all borrowing to minimize further loss and publicly offered the attacker $10 million to return the user funds. At ~$80 million this makes the FEI exploit one of the largest re-entrancy hacks ever.

The attack drained funds from the Rari pool whilst the Fei Pools (Tribe, Curve) remain unaffected. A Rari team member confirmed that only borrowable assets were vulnerable in the attack.

Initial reports indicate this exploit is likely due to a re-entrancy bug which has affected and been main culprit in MANY exploits, including the infamous DAO hack in 2016 and several major protocols in the past like:

  • Uniswap/Lendf.Me hacks (April 2020) – $25 million, attacked by a hacker using a reentrancy.
  • The BurgerSwap hack (May 2021) – $7.2 million because of a fake token contract and a reentrancy exploit.
  • The SURGEBNB hack (August 2021) – $4 million seems to be a reentrancy-based price manipulation attack.
  • CREAM FINANCE hack (August 2021) – $18.8 million, reentrancy vulnerability allowed the exploiter for the second borrow.
  • Siren protocol hack (September 2021) – $3.5 million, AMM pools were exploited through reentrancy attacks. (Ref:Hackernoon)

In December, Fei merged with Rari Capital. Rari enabled the creation of Fuse Pools— permissionless lending pools— that anyone with a wallet can access from anywhere to lend or borrow ERC-20 tokens. No minimum funds are required of users.

On 01 April 2022, Rari Capital released a Security Upgrade Report on Medium, stating they had patched a security issue relating to Fuse pools. This patch fixed known vulnerabilities in Compound by blocking re-entrancy on functions that required it. Although they protected many of their system's functions, they did not protect exitMarket(). When the exploiter received ETH, they could then call exitMarket() even though a global reentrancy lock is active.

Fei Protocol also previously suffered difficulties earlier this month when a bug that was discovered through their bug bounty program caused them to shut down their rebate program while they fixed a vulnerability. At that time, they were able to block an exploit before any happened, which sadly was not the case in this instance.

Reference to prior FEI incident:

Fei Protocol Vulnerability Postmortem

Fei Protocol struggles with a bug as holders are mostly unable to sell the token

Rari Capital: Fuse Security Upgrade Report

Explained: The Fei Protocol Bug (April 2021)

Re-entrancy: Hack Solidity: Reentrancy Attack | HackerNoon

What is a Reentrancy Attack.

Attack Technical Analysis

Take 0xab48... as an example:

XncTnC6vgaDdKqhYx1kwztiThW34WKYato -GhCcKeLwPsxfncG1jPHG4XuHuWsH-9AlXkQqZN1Nr6uc7jac9X6r4uRGEszARos1c-M2d-VIyQWW8KGlcIheQPFIpGx4qkiAJ sYRUXZ47S8mA

  1. Attacker flash loaned 150,000,000 USDC and 50,000 WETH
  2. Deposited 150,000,000 USDC as collateral into fUSDC-127 contract for loans, which is a fork of vulnerable smart contract of Compound protocol.
  3. The attacker borrows 1,977 ETH via the “borrow()” function
  4. However, the “borrow()” function does not follow the check-effect-interaction pattern and transfers ETH to the attacker’s contract before updating the attacker’s borrow records.

L6W77n06SjP4XrPY4Qcczx4EMjRTTyN1WUabcdGt Wsw8baspvwCmo8Ma5yvC31heT2n4RsXq2Ih00i7TBBsBazqpCJimH0MZmMq5Vv w2 xyJRnTGROy4Fymns0EgBd EnxuFJnxO9n7PNQiQ

  1. Therefore, with the attacker’s borrow record not updated, the attacker made a re-entrant call to “exitmarket()” that allows the attacker to withdraw his collateral (150M USDC)
  2. Attacker repeated the steps on multiple other tokens.
  3. Finally, the attacker repaid the flashloan and transferred the rest as profit.

Contract Vulnerability Analysis

This attack was due to a design flaw in the Fei Protocl that failed to follow the check-effect-interaction pattern and thus allow the attacker to make a re-entrant call before the borrow records are updated.

In the “borrow()” function, the following code is implemented:

A7fksW6vfugvd7ylon4 zlkQRQklC2XnLz6cjtMpnqMeL0dm2L3L1L445b5U A95tcmTpJAecZxLiNU7yUxKpRTM-OdKfMKzOPesMQtfb416VGr5ZIHderMYX8RWNikViPO-3gZ8aP jByny8g

As the code illustrates, the “doTransferOut()” is invoked before the borrow records (i.e., “accountBorrows[]” and “totalBorrows” ) are updated.

The “doTransferOut()” function transfers ETH to the receiver via a low-level call:

L6W77n06SjP4XrPY4Qcczx4EMjRTTyN1WUabcdGt Wsw8baspvwCmo8Ma5yvC31heT2n4RsXq2Ih00i7TBBsBazqpCJimH0MZmMq5Vv w2 xyJRnTGROy4Fymns0EgBd EnxuFJnxO9n7PNQiQ (1)

Therefore, the attacker is able to make a re-entrant call in the “fallback()” function to “makeExit()”.

Profit and Assets Tracing

How much does the attacker earn?

TokenTransfer to 0xe39f3c4
ETH6037.814
DAI14278990.68
USDC10055556.33
FRAX13101364.94
UST2765891.006
RAI31615.8714
FEI7119260.782
USDT132959.9008
LUSD1948952.179

Where are the stolen assets?

Claim process:

TX hashAttacker outAttacker in
0xa733e3,106.26 ETH
0x8ad7c11,924,074.79 FEI 3,184,115.06 DAI 1,948,952.18 LUSD
0x0d7125,000,000.00 FEI4,995,000.00 DAI
0xa5cc55,000,000.00 FEI1,766.06 WETH
0xd56281,924,074.79 FEI1,922,150.72 DAI
0x901af548,950.00 LUSD194.21 WETH
0x229f03,364,504.99 FRAX 1,691,470.42 FEI, 1,250,000.00 UST (Wormhole), 963,852.76 DAI, 487.74 ETH
0x1c387700,002.18 LUSD247.59 WETH
0x3305b1,691,470.42 FEI596.10 WETH
0x86c693,364,504.99 FRAX1,186.29 WETH
0xdb8381,250,000.00 UST (Wormhole)441.34 WETH
0x57be2700,000.00 LUSD247.86 ETH
0xdb87310,131,022.86 DAI, 10,055,556.33 USDC, 9,736,859.95 FRAX, 6,636,057.90 FEI, 1,515,891.01 UST (Wormhole), 132,959.90 USDT, 2,443.81 ETH
0x1003a31,615.87 RAI
0x5352e5,000,000.00 USDC1,766.17 WETH
0xd970c5,000,000.00 USDC 1,766.17 WETH
0x6ad1c55,556.33 USDC19.63 ETH
0x64a925,736,859.95 FRAX2,021.04 ETH
0x5ffd4132,959.90 USDT46.91 ETH
0x0cd681,515,891.01 UST (Wormhole)534.01 WETH
0x602386,636,057.90 FEI2,324.16 WETH
0x23c6d4,000,000.00 FRAX1,407.37 ETH
0x88b4931,615.87 RAI33.65 ETH
0xb78525,000,000.00 DAI1,759.31 WETH
0x515095,000,000.00 DAI1,752.73 WETH
0xb5e7b5,000,000.00 DAI1,753.31 WETH
0x0c7a65,000,000.00 DAI1,755.00 WETH
0x7b7791,196,141.40 DAI421.33 WETH
0xb61d118,261.46 WETH18,261.46 ETH

Would we spot the issue during the audit?

In this specific incident, a CertiK audit would pick up this particular vulnerability. Our highly skilled auditors would have spotted if the check-effect-interaction is strictly followed in the implementation of the code. Our auditors would then take their findings to the project and work with them to resolve this issue. You can read a project's audit on our website where you can check for yourself a tokens critical, major, medium, minor and informational vulnerabilities which will aid you in DYOR.