Table of Contents
- 1 Overview
- 2 About Alpha Finance’s Alpha Homora V2
- 3 Root Cause of the Exploit
- 3.1 Key elements contributing to the exploit include:
- 4 Attack Flow
- 5 Stolen Fund Details
- 6 Hack Aftermath
- 7 Mitigation Steps to Avoid Such Hacks
- 8 Conclusion
On February 13, 2023, at 5:37 AM UTC, Alpha Finance’s Alpha Homora V2, in partnership with CREAM’s Iron Bank, fell victim to a sophisticated exploit, resulting in a significant loss of approximately $38 million USD.
The attack was executed through a complex series of transactions involving flash loans, targeting Alpha Homora V2’s sUSD pool.
The attacker manipulated the pool by exploiting a rounding miscalculation in the borrowing function, allowing them to inflate the total debt amount without increasing the total debt share.
This incident affected the protocol-to-protocol lending between Alpha Homora V2 and Cream V2 (Iron Bank), but user funds remained secure.
About Alpha Finance’s Alpha Homora V2
Alpha Finance Lab’s Alpha Homora V2 is a prominent Decentralized Finance (DeFi) sector project specifically designed to facilitate leveraged lending and borrowing.
Launched as a part of the broader Alpha Finance Lab ecosystem, it aims to innovate in the DeFi space by providing users with advanced financial instruments. The platform is known for its integration with Cream V2 (Iron Bank), enabling a unique protocol-to-protocol lending model.
Root Cause of the Exploit
The root cause of the hack on Alpha Finance’s Alpha Homora V2, specifically targeting its integration with CREAM’s Iron Bank, can be traced to a series of vulnerabilities and design oversights in the smart contract system.
Key elements contributing to the exploit include:
Unannounced sUSD Pool
HomoraBankv2 had an sUSD pool at the contract level, prepared for an upcoming release. This pool was neither accessible via the user interface nor publicly announced. This obscurity played a role in the vulnerability being overlooked.
Lack of Liquidity in sUSD Lending Pool
There was no liquidity in the sUSD lending pool, allowing the attacker to fully manipulate and inflate the total debt amount and total debt share. This lack of liquidity was a critical factor that enabled the manipulation of the borrowing mechanism.
Rounding Miscalculation in Borrow Function
The borrow function of HomoraBankv2 contained a rounding error. This miscalculation only became significant when the attacker became the sole borrower in the pool, allowing them to exploit the system by inflating the debt without a corresponding increase in the debt share.
Vulnerability in the resolveReserve Function
The resolveReserve function in HomoraBankv2 was designed to collect revenue for the reserve pool. However, it was callable by anyone and could be exploited to increase the total debt without increasing the total debt share. This design flaw was a pivotal point in the exploit.
Custom Spell Acceptance
HomoraBankv2’s architecture allowed for any custom spell (similar to a strategy in Yearn Finance) as long as it satisfied the condition that the collateral was greater than the borrowed amount. This feature was exploited by the attacker, who created an ‘evil spell’ to manipulate the borrowing and debt mechanisms.
Smart Contract Interaction
The exploit was not a simple attack but a complex interaction of multiple vulnerabilities. It involved advanced understanding and manipulation of DeFi protocols and smart contracts, including flash loans and custom smart contracts (spells).
Contract Addresses Involved
HomoraBankv2 Contract: https://github.com/AlphaFinanceLab/alpha-homora-v2-contract
Evil Spell Contract: 0x560a8e3b79d23b0a525e15c6f3486c6a293ddad2
The attack on Alpha Homora V2 was a sophisticated and multi-step process involving over nine transactions.
Attacker address: 0x905315602ed9a854e325f692ff82f58799beab57
Attacker’s txn: https://etherscan.io/txs?a=0x905315602ed9a854e325f692ff82f58799beab57
Evil spell address: https://etherscan.io/address/0x560a8e3b79d23b0a525e15c6f3486c6a293ddad2
Here is a detailed breakdown:
The attack was meticulously orchestrated with multiple steps, each leveraging specific functionalities and vulnerabilities within the DeFi ecosystem. Here’s a comprehensive and logical explanation of the attack flow:
- Initial Setup: The attacker crafted a malicious strategy, analogous to Yearn’s strategy, to exploit vulnerabilities in various protocols. This was the foundation of the attack.
- Asset Swapping and Pooling: The attacker exchanged Ethereum (ETH) for Uniswap (UNI) tokens. They then supplied both ETH and UNI to a Uniswap liquidity pool, receiving ETH/UNI LP tokens in return. Simultaneously, they swapped ETH for sUSD on Uniswap and deposited the sUSD into Cream’s Iron Bank, obtaining cysUSD tokens.
- First HomoraBankV2 Interaction: Using the evil spell, the attacker executed a transaction with HomoraBankV2 to create position 883. This involved borrowing 1000e18 sUSD and depositing the UNI-WETH LP into WERC20, using it as collateral to bypass checks. This resulted in the attacker obtaining 1000e18 sUSD debt shares.
- Repaying Debt with a Twist: The attacker again used the evil spell on position 883. They repaid 1000000098548938710983 sUSD, slightly less than the actual debt (which was 1 sUSD higher). This resulted in the attacker having only 1 minisUSD of debt and 1 debt share.
- Manipulating sUSD Bank Reserves: The attacker then called
resolveReserveon the sUSD bank, which led to an accrual of 19709787742196 debt, while the total share count remained at 1. This made the total debt 19709787742197 sUSD, disproportionately high compared to the total share.
- Borrowing and Doubling Debt: The attacker executed a series of transactions (16 times), each time borrowing an amount just under the total debt and transferring it to themselves. The borrowed amount was doubled each time, exploiting the system to treat these as zero-debt borrowings. Finally, 19.54 sUSD was deposited back to Cream’s Iron Bank.
- Escalating the Borrowing Scheme: This process continued, repeated ten times, with each transaction doubling the borrowed amount. At the end of these transactions, the attacker deposited 1321 sUSD into Cream’s Iron Bank.
- Flashloan and Swapping: The attacker took a flash loan of 1,800,000 USDC from Aave, swapped it for sUSD, and deposited it into Cream to create sufficient liquidity. They continued doubling the sUSD borrow, ultimately swapping the sUSD back to USDC on Curve, and then borrowing additional USDC from Cream.
- Repeating with Higher Stakes: The attacker repeated the flashloan process with approximately 10 million USDC, but without borrowing USDC at the end.
- Further Replication: The same process as step 9 was executed again, involving another 10 million USDC flash loan.
- Diversified Borrowing and Pooling: The attacker borrowed a mix of cryptocurrencies (WETH, USDC, USDT, DAI), and supplied the stablecoins to Aave to receive aTokens. These aTokens were then supplied to Curve’s a3Crv pool.
- Liquidity Provision to Curve: The acquired a3Crv LP tokens were added to Curve’s liquidity gauge.
The final phase of the attack involved moving funds through Tornado Cash and GitCoin Grants, with 1,000 ETH being sent to the deployer addresses of Cream and Alpha as a diversion or possibly a form of repayment.
Stolen Fund Details
The detailed breakdown of the stolen funds in the Alpha Homora V2 exploit is as follows:
- USDC: A total of 3,997,921.01617 USDC and 426,659.27 USDC were illicitly acquired by the attacker.
- DAI: The attacker managed to siphon off 4,263,138.929122643119834654 DAI.
- USDT: A sum of 5,647,242.107646 USDT was taken.
- WETH: The attacker also grabbed 13,244.630331762545750401 WETH.
- Total Estimated Loss: The combined loss from these assets amounted to approximately $38,175,295.92, a near equivalent of $38M when considering the value of WETH at around $1,800 per ETH during the attack.
- Additional Movements: Post-exploit, the attacker distributed funds in various ways, including transferring 1,000 ETH each to the deployer addresses of Alpha and Iron Bank and making a donation to Gitcoin.
Immediate Response by Alpha Finance Lab
Alpha Finance Lab, audited by 3rd-party auditors, acknowledged the attack on Twitter. They informed the public that the loophole exploited in the attack was patched and announced having a prime suspect in the case.
C.R.E.A.M. Finance Team’s Actions
In response to the exploit, the C.R.E.A.M. team took several decisive steps:
- Paused supply and borrowing across all markets in the Iron Bank.
- Reduced the credit limit of Alpha Homora V2 to zero during the investigation phase.
- After ensuring the normal functioning of the Iron Bank smart contracts and markets, they re-enabled these markets.
- Announced plans to implement additional preventative measures, including automated monitoring for abnormal activities.
- Confirmed that other contracts, including C.R.E.A.M. V1 markets on Ethereum and Binance Smart Chain, were not impacted as they are separate from The Iron Bank liquidity pools.
The large drop in Total Value Locked (TVL) reported was partly due to the withdrawal of approximately $400 million worth of FTT tokens from C.R.E.A.M. V1 by the owner, separate from the exploit incident.
Movement of Capital by Large Players
- Sam Bankman-Fried (SBF) withdrew approximately $400 million worth of FTT tokens from Cream Finance.
- Three Arrows Capital transferred over $3 million of ALPHA tokens to Binance, presumably for selling purposes.
Decline in Value of Related Tokens
- The value of tokens associated with the attack experienced a significant decrease.
- ALPHA, the governance token of Alpha Homora, dropped from $2.25 to $1.78.
- CREAM, the governance token of the Iron Bank, fell from $288.32 to $193.51.
- AAVE, known for flash loans that have been implicated in similar attacks, decreased from $518 to a low of $492 within the same day.
Despite the attack, lending services on Alpha Homora V2 remained operational, with borrowers being able to repay debts, add collateral, and close positions.
Alpha Finance and C.R.E.A.M. teams are coordinating efforts to develop remedial actions and enhance security measures to prevent such incidents in the future.
Mitigation Steps to Avoid Such Hacks
Enhanced Monitoring of Protocol-to-Protocol Lending Activities
Given that the exploit involved a complex interplay between Alpha Homora V2 and Cream V2 (Iron Bank) in a protocol-to-protocol lending way, it’s crucial to implement advanced monitoring systems.
These systems should be capable of detecting anomalies in lending patterns, especially when new pools or financial instruments (like the sUSD pool in this case) are involved. Regular audits of such interactions can also prevent the exploitation of unforeseen vulnerabilities.
Stricter Validation of Custom Spells and Smart Contracts
The exploit was facilitated by the use of a custom, malicious spell. Alpha Homora V2 and similar platforms should implement stricter validation processes for custom spells or strategies to prevent similar incidents.
This includes rigorous testing and verification procedures before allowing any custom smart contract to interact with the main protocol, especially those that can significantly alter debt and collateral balances.
Refinement of Borrowing Function Calculations and Resolving Function Vulnerabilities
The hack capitalized on a rounding miscalculation in the borrowing function and the abuse of the resolveReserve function.
Moving forward, refining the mathematical logic within these functions is critical to prevent manipulation.
This could involve implementing additional checks and balances within the borrowing function to prevent rounding errors from being exploited and restricting the accessibility of functions like resolveReserve to authorized entities only, thus preventing their malicious use.
The Alpha Finance’s Alpha Homora V2 hack underscores the importance of rigorous security protocols in DeFi platforms. This incident demonstrates the complex nature of smart contract vulnerabilities and the need for continuous vigilance and improvement in blockchain security. Firms like ImmuneBytes, with its team of experienced smart contract auditors, could play a crucial role in preventing such exploits through thorough audits and security assessments.