Full Report
HomoraBankv2 allows for the usage of a custom smart contract for providing logic called a spell. The only check performed is that the loan is greater than the borrowed amount for custom contracts. When this was exploited, the bank was prepped for an upcoming release, with no UI and nothing publicly announced. This fact meant that an attacker can fully manipulate the market, since there is no liquidity inside the contract yet. First, the attacker takes out a loan of 1,000e18 sUSD from the bank. When paying back the loan, the attacker should have to pay back 1000.000098548938710984 sUSD. However, a rounding error in the protocol only required them to pay back 1000.000098548938710983 sUSD. By doing this, the debt is now at 1 minisUSD and 1 debt share. Finally, by calling resolveReserve, the debt increases but the shares remains at 1. Because of the off by 1 error, the contract believes that NO money has been taken out! By exploiting this bug over and over again, they are able to take out loans with only a single share. This bug only occurs when you are the only owner of shares in the contract. Neat! The pre-release aspect of this attack was quite important then. After performing the attack above, they couple this with a flash loan attack to extract the sUSD from the contract to steal even more money. I don't understand this part of the attack though. To me, there are few takeaways. First, a single off by 1 error resulted in a horrible security bug. Second, having this functionality public prior to launch seems strange as well. Finally, this contract was audited twice and still fell victim to attack. This is the second largest heist of an audited smart contract platform, only behind Wormhole.
Analysis Summary
# Incident Report: Alpha Homora V2 Rounding Error & Flash Loan Exploitation
## Executive Summary
On February 13, 2021, the Alpha Homora V2 protocol was exploited for approximately $37.5 million. The attacker leveraged a rounding error in the protocol's debt calculation combined with the ability to use custom "spells" (smart contracts) on a pre-release version of the bank. This allowed the attacker to borrow massive amounts of assets from Cream’s Iron Bank without sufficient collateral, eventually laundering a portion of the funds through Tornado Cash.
## Incident Details
- **Discovery Date:** February 13, 2021
- **Incident Date:** February 13, 2021
- **Affected Organization:** Alpha Finance (Alpha Homora V2)
- **Sector:** Decentralized Finance (DeFi)
- **Geography:** Global / Decentralized
## Timeline of Events
### Initial Access
- **Date/Time:** Early morning, February 13, 2021
- **Vector:** Deployment of a malicious custom "spell" contract (Address: 0x560a8e3b79d23b0a525e15c6f3486c6a293ddad2).
- **Details:** The attacker took advantage of HomoraBankv2’s ability to accept custom smart contracts (“spells”) and the fact that the contract was live but not yet publicly announced or populated with liquidity.
### Lateral Movement
- **Debt Manipulation:** The attacker initiated a loan of 1,000 sUSD. By repaying an amount infinitesimally smaller than the actual debt (an off-by-one rounding error), the attacker manipulated the contract state to keep only 1 "debt share."
- **Share Dilution:** By calling `resolveReserve`, the attacker inflated the debt while keeping shares at 1. This allowed them to repeatedly borrow funds such that the protocol recorded "zero" new shares being issued, effectively granting interest-free, collateral-free loans.
### Data Exfiltration/Impact
- **Hoarding cySUSD:** The attacker used flash loans from Aave to move USDC through Alpha Homora and into Cream’s Iron Bank, accumulating a massive balance of cySUSD.
- **Asset Drainage:** Using the inflated cySUSD collateral, the attacker drained 13.2k WETH, 3.6M USDC, 5.6M USDT, and 4.2M DAI.
### Detection & Response
- **Detection:** The incident was identified following anomalous transactions and a sudden drain in liquidity.
- **Response Actions:** Alpha Finance collaborated with Cream Finance and exchanges to freeze stolen assets. The protocol was patched to restrict "spells" to a whitelist of four major tokens.
## Attack Methodology
- **Initial Access:** Execution of a malicious custom smart contract (spell).
- **Persistence:** Not applicable (Smart contract interaction).
- **Privilege Escalation:** Manipulation of the `resolveReserve` function to bypass debt accounting.
- **Defense Evasion:** Executing the attack on a pre-release contract with no UI or public announcement, ensuring the attacker was the sole liquidity provider/owner of shares.
- **Lateral Movement:** Moving liquidity between Alpha Homora, Cream Finance (Iron Bank), and Aave.
- **Exfiltration:** Assets were moved to Tornado Cash (320 ETH) and external EOA wallets.
- **Impact:** Draining of protocol liquidity pools.
## Impact Assessment
- **Financial:** Estimated $37.5 million loss.
- **Data Breach:** None (Public blockchain transaction data).
- **Operational:** Temporary suspension of Homora V2 features and emergency patch implementation.
- **Reputational:** High; the protocol had been audited twice and was considered a top-tier DeFi project.
## Indicators of Compromise
- **Attacker Wallet:** 0x905315602ed9a854e325f692ff82f58799beab57 (Defanged)
- **Malicious Spell:** 0x560a8e3b79d23b0a525e15c6f3486c6a293ddad2 (Defanged)
- **Behavioral:** Repetitive borrowing of 1 minisUSD less than total debt to trigger rounding errors; excessive calls to `resolveReserve`.
## Response Actions
- **Containment:** Interaction with the vulnerable "spell" logic was restricted.
- **Eradication:** Patches were deployed to fix the rounding error and the `resolveReserve` accessibility.
- **Recovery:** Funds were tracked to exchanges; Alpha Finance limited supported tokens to ETH, DAI, USDC, and USDT to reduce attack surface.
## Lessons Learned
- **The "Audit False Sense of Security":** Despite two audits, a single off-by-one rounding error caused a total collapse of the accounting logic.
- **Pre-release Exposure:** Deploying contracts to mainnet without a UI or public notice does not provide "security by obscurity"; attackers scan the mempool and blockchain for unannounced contracts.
- **Permissionless Risk:** Allowing users to submit custom logic (spells) without a whitelist is a high-risk architectural choice.
## Recommendations
- **Strict Debt Accounting:** Use math libraries that revert on rounding errors or ensure the protocol always rounds in favor of the bank.
- **Access Control:** Sensitive functions like `resolveReserve` should be restricted to authorized keepers or automated internal processes.
- **Whitelisting:** Require governance or multisig approval for any external smart contract integrations ("spells").