Analysis of Grim Finance Attacked
Grim Finance is an intelligent revenue optimization platform that allows users to stake LP-Tokens issued by AMMs (automatic market makers) in Grim Vaults. These LP-Tokens will be automatically harvested and their rewards will be staked on LP-Tokens again. Obtain compound effects and help users get more rewards.
The news was monitored by lunaray technology blockchain security intelligence platform. On December 19, 2021, Grim Finance officially tweeted that the platform was used by an external attacker. The attacker stolen coins worth more than 30 million U.S. dollars. Our security team promptly Perform a review analysis of the security incident.
0x2 Event analysis
Through preliminary tracking and analysis by our security team , the attack occurred on the Fantom chain. The main attack information is as follows:
Attack transaction one
Fantom Transaction Hash (Txhash) Details | FtmScan
0x19315e5b150d0a83e797203bb9c957ec1fa8a6f404f4f761d970cb29a74a5dd6 2 days 9 hrs ago (Dec-18-2021 05:39:15 PM +UTC)…
Attacker’s wallet address:
Address 0xdefc385d7038f391eb0063c2f7c238cfb55b206c | FtmScan
The Address 0xdefc385d7038f391eb0063c2f7c238cfb55b206c page allows users to view transactions, balances, token holdings…
Attacker contract address
Contract Address 0xb08ccb39741d746dd1818641900f182448eb5e41 | FtmScan
The Contract Address 0xb08ccb39741d746dd1818641900f182448eb5e41 page allows users to view the source code…
Contract Address 0x660184ce8af80e0b1e5a1172a16168b15f4136bf | FtmScan
The Contract Address 0x660184ce8af80e0b1e5a1172a16168b15f4136bf page allows users to view the source code…
The following will disassemble the attack transaction to facilitate readers to understand the attack process more clearly.
The first step: The attacker borrowed 30 BTC and 920,000 WFTM in a flash loan, and added liquidity to the loan through PancakePair to obtain 0.0476 Spirit LP.
Step 2: Pledge the acquired Spirit LP to obtain GB-BTC-FTM.
Step 3: Obtain GB-BTC-FTM through multiple pledge deposits (the main part of the attack is to continuously pledge through unverified Tokens to increase the difference in pledge rewards).
Step 4: Return the obtained GB-BTC-FTM and obtain 0.0663 Spirit LP (have been profited through multiple pledge differences).
Step 5: Release the liquidity to obtain 41 BTC and 1.28 million WFTM, and return the flash loan and commission , and then transfer the profitable 11 BTC and 360,000 WFTM to the attacker’s wallet address.
The attacker continued 8 attacks through the same attack technique.
The attackers obtained a total of 260,000 BTC, 18.65 million, 750,000 DAI, 750,000 USDC, and 130,000 BOO through 9 attack transactions, worth about 30 million U.S. dollars.
Here below we analysis the cause of the vulnerability through the contract code.
There are two main contract methods used in this attack can be found by querying transaction details:
In the GrimBoostVault.depositFor method, users pledge funds and return corresponding proof tokens.
With GrimBoostVault.withdrawAll method, the user returns the proof token to obtain the corresponding pledge funds.
Through transaction analysis, we can know that the third step of the attacker’s success is mainly caused by running the depositFor method multiple times. First, analyze the method and read through the depositFor method process. It is mainly to determine that the user transfers the pledge of funds into the contract and calculates the contract. The balance difference is then calculated and sent to the user’s corresponding pledge proof token. At first glance, there seems to be no security problem, but we can still find that there is no fixed restriction on the token address here. The token address is passed in by the user. Because the depositFor method will use the safeTransferFrom method in the token contract address, token After the contract address is controllable by the user, the safeTransferFrom method will be controllable.
The attack path of the attacker can now be clarified. First, create a Token contract, and write the logic of re-invoking the GrimBoostVault.depositFor method in the safeTransferFrom method in the contract, and finally pass in a normal Token after multiple reentries. Staking, although it will enter the normal process afterwards, due to multiple re-entries before, the difference between obtaining the contract balance is too large, and finally a large number of proof tokens are minted.
For example: the attacker performs 6 reentries, and the last time the incoming funds are 100, then the final difference is 100*6, and the calculated value at the time of minting is also 600.
After the reentry is successful, the attacker calls the withdrawAll method to return the large amount of proof tokens obtained by the reentry to obtain the corresponding pledge funds and complete the profit.
Currently, Grim Finance has officially suspended all vaults and reminded users to withdraw all their funds as soon as possible. The contract modification plan and compensation plan have not yet been declared.
According to this attack, the attacker mainly used the depositFor method of the GrimBoostVault contract without checking the Token address. After multiple reentries, the huge contract balance difference was caused, a large amount of funds were cast, and then the profitable funds were taken away through the withdrawAll method. There are many similar attacks in DeFi projects. Why do they happen frequently? For DeFi projects, the security of the contract code, the relative stability of the token price, the controllability of the method transfer parameters, and the timely update of the old version are all guarantee projects. Security is an extremely important part, any sloppy details may lead to the loss of the project and user funds. For this kind of lightning loan attacks, the security team of Zero Hour Technology gives the following suggestions:
•For contract code security, you can find multiple security audit companies to conduct audits
•For methods involving fund transfers, strict authority control should be implemented
• For sensitive code, it must be updated and improved in time.