Akropolis Incident: Root Cause Analysis


This incident was due to a bug in the protocol without (1) validating the supported tokens and (2) enforcing reentrancy protection on the deposit logic. The exploitation leads to a large number of pooltokens minted without being backed by valuable assets. The redemption of these minted pooltokens is then exercised to drain about 2.0mn DAI from the affected YCurve and sUSD pools.


The Hack Walk-through

We started the analysis from the transaction behind the hack: 0xe1f…e04d. This hack is initialized from a malicious ERC20-like contract (located at 0xe230). This malicious contract implements a hook that will be invoked whenever the transferFrom() (function signature: 0x23b872dd) is being called.

The Reentrancy-Based Exploitation on Akropolis

The Deposit Logic

Next, we elaborate the vulnerable deposit logic. Any Akropolis user can deposit tokens to Delphi Savings Pools and the pool will mint corresponding pooltokens to the user. The core logic is written in SavingsModule::deposit() (line 1944) and outlined in the following figure.

The Vulnerable Deposit Logic in *SavingsModule*
  • Step 1: The attacker calls deposit() with the specified _tokens as the input. This function calculates the token balance before and after the deposit function depositToProtocol(_protocol, _tokens, _dnAmounts). Then it uses the balance change to mint the poolTokens (line 1970). Between the calculation of balance change, the depositToProtocol() function calls the safeTransferFrom() function on the target tokens to perform the actual token transfer (line 2004). However, there is no reentrancy check on the deposit() function and no validity check on the deposited tokens which might be crafted and malicious.
  • Step 2: The attacker re-entered the deposit() function again when its transferFrom() function is called to invoke the hook routine.
  • Step 3: Because of this second time deposit, the pool will mint poolTokens to the attacker since the real DAI assets are transferred into the protocol and changes the balance.
  • Step 4: When this second time deposit completes, it returns back to the first time deposit’s context in depositToProtocol() and then calculates the balance change again! It turns out the balance difference is exactly the same as the second deposit. Therefore, the same amount of poolTokens is minted to the attacker.

The Stolen Funds

The stolen funds from the above exploitations are currently held in this wallet: 0x9f26. We are actively monitoring this wallet for any movement.

About Us

PeckShield Inc. is an industry leading blockchain security company with the goal of elevating the security, privacy, and usability of current blockchain ecosystem. For any business or media inquiries (including the need for smart contract auditing), please contact us at telegram, twitter, or email.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store