Detailed Explanation of Akropolis Vulnerability: Hackers Reappear "Classic Reentrancy Attack" and Steal 2.03 Million DAI

Original title: "Detailed Explanation of DeFi Protocol Akropolis Vulnerabilities: Hackers Reappear "Classic Reentrancy Attack" and Steal 2.03 Million DAI"

Original Source: PeckShield

At 19:50 yesterday evening, the DeFi protocol Akropolis was hacked.

Blockchain security company PeckShield (PeckShield) security personnel quickly located the problem that the SavingsModule contract of the Akropolis project had some kind of flaw when processing user storage assets , Hackers used this flaw to carry out 17 consecutive re-entry attacks, resulting in the loss of 2.03 million DAI in their YCurve and sUSD fund pools.

Technical Summary

This time The reasons for the attack are as follows:

The contract does not perform whitelist verification on the Token stored by the user. The key deposit function is not protected against reentrancy attacks

To put it simply: Hackers use the storage asset verification flaw in the Akropolis project to launch multiple consecutive re-entry attacks on the contract, causing the Akropolis contract to fail without new asset injection. , issued a large number of pooltokens out of thin air, and then used these pooltokens to extract DAI from the YCurve and sUSD pools, resulting in a loss of 2.03 million DAI in the project contract.

Detailed attack process

Attack process reproduction:

< br>

We analyzed the transaction hash

（0xe1f375a47172b5612d96496a4599247049f07c9a7d518929fbe296b0c281e04d）

and found that the attack came from In a malicious ERC20 contract address

（0xe2307837524Db8961C4541f943598654240bd62f）

This malicious contract implements a hook function, making the function transferFrom() ( function signature: 0x23b872dd) will be executed when called.

The attacker first calls SavingsModule.sol , and use the malicious contract written by yourself at the beginning of 0xe230 as the token address to be stored incoming. When the transferFrom() function of its malicious token is called, its hook function will call the deposit() function again and deposit the real DAI assets.

Because the amount of additional issuance of pooltokens is calculated by the difference in balance before and after token deposit. So the real DAI assets of the second deposit will be counted twice for minting pooltokens. The first time is when the malicious contract 0xe230 is stored, and the second time is when DAI is stored. That is to say, if 25K DAI is deposited in the second storage, the total minted pooltokens will be doubled, which is 50K DAI, due to the reentrancy attack.

By analogy, the hacker launched a total of 17 reentrancy attacks and obtained a total of 2,030,841.0177 DAI assets.

It is worth noting that at the beginning of the attack, the attacker also used the  Flash loan function.

Detailed Explanation of Core Vulnerabilities

Next, we analyze the token storage logic with loopholes . Akropolis users can deposit tokens into Delphi Savings Pools, and the fund pool will mint corresponding pooltokens to users. The core logic is in SavingsModule::deposit() (line 1,944).

Step 1: The attacker calls the deposit() function and provides the _tokens parameter. This function calculates the token balance before and after further calls to depositToProtocol(_protocol,_tokens,_dnAmounts), and determines the number of poolTokens to be minted based on the change in the token balance (line 1,970). The depositToProtocol() function calls the safeTransferFrom() function of the target token to transfer the token (line 2,004). However, the deposit() function does not detect re-entry attacks, nor does it check whether the deposited tokens are malicious tokens;

The second step: in the malicious When the transferFrom() function of the token is called, the hook function is triggered to call the deposit() function again;

The third step: because the second call When the deposit() function is executed, the attacker deposits the real DAI token, which changes the token balance of the pool, so the attacker can obtain the poolTokens minted by the fund pool;

Step 4: When the second deposit() function call ends, the code execution flow will return to the context of the first deposit token call depositToProtocol() function. At this time, the token balance change will be calculated again. The change of the token balance at this time is the same as the change of the token balance of the second call to the deposit() function. So the attacker can get the corresponding number of poolTokens again.

Status of Stolen Assets

The stolen assets of this attack are currently stored in wallets  0x9f26  CoinHolmes, a digital asset tracking platform under PeckShield, is monitoring the address in an all-round way, and further locking, analyzing and tracking the flow of its funds in order to assist the project party in recovering the stolen assets.

Original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia