2.1/ The Attack Process
Attacker: 0x334f3606886456537d0eb616497e770cbd2fbe5d
Mal Contract: 0x4fbb8840d37a21e38c8e438db27aae7bb91af052
Pool1: UniswapV2 WETH/USDT
Pool2: UniswapV2 WETH/XST
2.2/
1)Flashloan
from Pool1: 77.99 WETH
2)Swap in Pool2
77.99 WETH for 403,258 XST
3)Transfer 92,415 XST -> Pool2
4)Pool2.skim(Pool2)
Pool2 -> Pool2: 92.415 XST
..skims
5)Pool2.skim(Attacker)
6)Swap in Pool2:
3,413,549 XST for 105.35 WETH
Profit: 27.13 WETH
3/ The Vulnerability
$XST encourage users to purchase XST in the pool, users who purchase XST will be additionally rewarded with some XST. However, it has a logic problem of identifying "purchasing XST": when the sender is SupportedPool, it is considered "purchasing XST".
4/ This judgment method ignores that the sender of the transfer caused by the skim function of the Uniswap Pool is also the Uniswap Pool.
1/ @iearnfinance was hacked with two consecutive attack transactions. The root cause is due to an (on-purpose?) misconfiguration which makes the rebalance of the pools rely on an incorrect underlying token. This misconfiguration has been there for more than three years.
Specifically, one of the strategy pools of yUSDT/ycUSDT, Fulcrum, had its address incorrectly configured. The underlying token of the misconfigured pool is USDC.
3/ The attacker took advantage of this by emptying the interest rate of Aave V1 (in Tx1) and directly transferring Fulcrum USDC to yUSDT/ycUSDT, triggering a rebalance. This caused yUSDT/ycUSDT to retrieve a large amount of USDC, mistakenly thinking that its own balance was 0.
1/ @samczsun explained that the attacker exploited the vulnerability in mev-boost-relay to drain MEV bots. After digging into the attack, we have two more findings. First, the attacker used a honeypot tx to lure MEV bots. Second, the honeypot tx has a self-protected mechanism.
2/ The attacker is a validator with a pre-knowledge that he/she will be selected to be the miner of block 16964664. Besides, a vulnerability in the mev-boost-relay will reveal the private transaction in flashbots.
3/ But how to lure the MEV bot to issue sandwich txs? We find the attacker leveraged eight honeypot txs for this purpose. Let's use one of them as an example, which swapped 0.35 Eth to 158 STG in a pair with less liquidity. This transaction is broadcasted to the mem pool.
2/ Here is the key steps
a. Attacker flashloaned 30M DAI in AAVE
b. Attacker deposited 20M DAI and got back 20M eDAI
c. Since Euler Finance provides the capability of leverage borrow (docs.euler.finance/app/ui/mint), the attacker can mint 195M eDAI and 200M dDAI.
3/ Continued above
d. 10M debt is repaid so that the attacker can mint more eDAI. Now the attacker holds 215M eDAI and 190M dDAI
e. step b is repeated. Now the attacker holds 410M eDAI and 390M dDAI
f. Attacker invoked the function donateToReserve() to donate 100M eDAI.
1/ We have received queries about whether BlockSec is the “whitehat” behind the Jump "counter exploit". We are NOT involved in the Jump case, and the way of the Jump case is fundamentally different from the Platypus counter exploit we were involved in.
2/ The high-level idea for the Jump counter exploit is as follows.
The Exploiter’s Maker Vaults can be managed by Oasis AutomationBot smart contract since the Exploiter enables the automation sell and buy services offered by Oasis.
3/ The AutomationBot can only be operated by the address with the role AUTOMATION_EXECUTOR. This address is a configuration in the Oasis Service Registry contract, which can be updated by the Oasis multisig wallet.
2/ Specifically, users could deposit $DYNA and claim rewards, while the interest will be calculated as follows:
duration = now - lastProcessAt
interest = k * (stakeAmount * duration)
However, the user's lastProcessAt is only recorded for the first deposit/stake.
3/ Thus, attackers could: 1) open a new vault and deposit a few $DYNA at time A; 2) after a while (at time B), borrow a large amount of $DYNA by flashloan and deposit them; 3) redeem the deposit, the profit is calculated as k * (borrowAmount * (B - A)); 4) repay the flashloan.
1/ We have analyzed the recent @Platypusdefi attack and found that the attacker made a mistake in the first attack transaction, which prevented the attacker from withdrawing the profits. Here is the full story.
Thanks, @spreekaway for pointing out this direction.
3/ Our analysis of the decompiled code showed that the first contract did not have a transfer function signature, and the approve function signature only appeared in the attack flow logic. This means the attacker did not reserve any interface to transfer the profits.