2. Analysis 1) Borrow BSC-USD via flashloan, buy USDT, and swap to $Zoom @ZoomproFinance 2) Call 0x47391071824569f29381dfeaf2f1b47a4004933b "0x1e69fcc4" function and it will send 1M USDT to ZOOM/USDT Pair
2. Analysis 3) The price of Zoom/USDT will raise after calling the pair function sync 4) Swap Zoom to USDT, buy BSC-USD and return the flashloan.
3.Notes 1) The "USDT" we mentioned here is not the Tether USDT. It is not an open source address(0x62d51aacb079e882b1cb7877438de485cba0dd3f) . And it is not a standard BEP-20 token because it doesn't emit any transfer events when making transfers.
3. Notes 2) Only Pancake where the attacker borrowed the flashloan is open source among these AMMs. The ratio of BSC-USD to USDT is pegged at 1:1 in the AMM instead of a constant product.
• • •
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.