On March 16, 2022, the SlowMist Intelligent Zone received a notification regarding a vulnerability in the Hundred Finance protocol that cost over 2363 ETH. We immediately looked into the incident and will now be sharing our findings.
Relevant information
Hundred Fiance is a decentralized lending and borrowing protocol across various blockchains.
Address involved
Attacker contract:
https://blockscout.com/xdai/mainnet/address/0xdbf225e3d626ec31f502d435b0f72d82b08e1bdd
Attacker address:
https://blockscout.com/xdai/mainnet/address/0xD041Ad9aaE5Cf96b21c3ffcB303a0Cb80779E358
Attack Transaction: https://blockscout.com/xdai/mainnet/tx/0x534b84f657883ddc1b66a314e8b392feb35024afdec61dfe8e7c510cfac1a098
Attacker contract:
https://blockscout.com/xdai/mainnet/address/0xdbf225e3d626ec31f502d435b0f72d82b08e1bdd
https://blockscout.com/xdai/mainnet/address/0xbE8fe2aE087aeCcB1E46EF206368421c9212637B
https://blockscout.com/xdai/mainnet/address/0x09b4f2551e9f39fa021a99463e21d6044656a7b9
https://blockscout.com/xdai/mainnet/address/0xf07ac43678b408ff0c86efff99b8d21af3d38c51
https://blockscout.com/xdai/mainnet/address/0x9c4e6edbc45b16e4378b53cd3e261727e103f633
Attacked contract:
https://blockscout.com/xdai/mainnet/address/0x243E33aa7f6787154a8E59d3C27a66db3F8818ee husdc
https://blockscout.com/xdai/mainnet/address/0xe4e43864ea18d5e5211352a4b810383460ab7fcc hwbtc
https://blockscout.com/xdai/mainnet/address/0x8e15a22853a0a60a0fbb0d875055a8e66cff0235 heth
https://blockscout.com/xdai/mainnet/address/0x090a00a2de0ea83def700b5e216f87a5d4f394fe hxdai
Cause of incident
The borrowFresh function within the Hundred Finance contract checks the funds after they’ve been transferred. Since USDC, wBTC, and wETH use the ERC677 token protocol, it means they are compatible with the ERC20 protocol. Once the funds have been transferred, the ERC677 protocol can call the onTokenTransfer function in the target contract, allowing the hacker to perform reentrancy attacks using a malicious contract.
Detailed Analysis
1.The hacker borrowed millions via flash-loans to be used collateral. Details below.
2.Using malicious contracts, the hacker deposited millions in USDC as collateral and exchanged it for 59,999,789.075 (hUDSC).
Since the loan contract records the funds after the transfer, the hacker is able to start their attack simultaneously with the transfer.
On the XDai chain, USDC, WBTC, and WETH contain post-transfer callback procedures. This allows malicious contracts to re-enter the WBTC loan contract after USDC has been transferred. Since there’s no record of borrowing USDC yet, the contract borrowed 16.17030715 in WBTC , re-entered the WETH loan contract and borrow additional 24.715930916595319168 WETH.
3.The contract then transferred 1,964,607 USDC to the USDC loan contract as collateral for 98,230,019.558 in hUSDC. Next, it borrowed 1,748,500.495 USDC from the pool, and re-entered it into the xDai loan contract.
The xDai was then transferred and exchanged for 234,304,737.048 in hxDAI. The malicious contract continued to borrow xDai and 4,128,044.631 USDC from the USDC loan contract. The attacker then transferred 1,358,759.278 USDC to the USDC loan contract again, and obtained 67,937,725.081 in hUSDC this time. They repeated this step again and borrowed 1,209,295.758 USDC from the USDC loan contract.
4.Finally, the contract returned all the borrowed funds from the flashloan to SushiSwap, and then transferred the remaining funds to the hackers address.
MistTrack
According to our MistTrack analysis, the initial funds were transferred in from Tornado.Cash. Once the stolen funds were deposited into their account, it was converted to ETH and bridge to the Ethereum network.
In total, more than 2,363 ETH was converted from the stolen funds. It was then deposited into Tornado.Cash in 32 separate transactions to avoid tracking.
Summary
This attack was caused by the borrowFresh function in the loan contract. It does not verify token transfers before the funds are transferred. This allows malicious contracts to re-enter other loan contracts after the transfer.
The SlowMist security team recommends that when using non-ERC20 token contracts, projects should pay more attention to see if they’re compatible. Contract amounts should be recorded before token transfers, and the Checks-Effects-Interactions rules should be followed to avoid issues like this in the future.
