DeFi Attack | Our monitoring system reported that EGD_Finance was attacked (bscscan.com/tx/0x50da0b1b6…), and the loss is around 36,044 USDT.
This is a typical price manipulation attack. #DeFi#BSC#CryptoSecurity
2/ The process of attack:
1)Flashloan from
Pool1: 2,000 BUSD-T
Pool2: 424,456 BUSD-T
Pool1: Pancake Pool BUSD-T/WBNB
Pool2: Pancake Pool **EGD**/BUSD-T
3/ The process of attack: 2) EGD_Finance.claimAllReward()
=> EGD_Finance transfers --- 5,614,105 EGD ---> Mal Contract
Mal Contract: 0xC30808D9373093fBFCEc9e026457C6a9DaB706a7
EGD_Finance.claimAllReward depends on the balance ratio of Pool2.
The method of calculating the reward token EGD depends on the ratio of the balance in the pair of USDT and EGD, so the attacker can manipulate the amount of the reward by flashloan.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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.