BlockSec Profile picture
Aug 10, 2022 6 tweets 2 min read Read on X
DeFi Attack | Our monitoring system reported that XSTABLE.PROTOCOL was attacked (etherscan.io/tx/0x873f7c77d…), and the loss is around 27.13 WETH.

This is a Logic Vulnerability.
#DeFi #ETH #CryptoSecurity
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". Image
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.
The correct hash:
etherscan.io/tx/0x873f7c77d…

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with BlockSec

BlockSec Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @BlockSecTeam

Apr 13, 2023
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. ImageImage
2/
Attack Tx1: explorer.phalcon.xyz/tx/eth/0xd55e4…
Attack Tx2: explorer.phalcon.xyz/tx/eth/0x8db0e…

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. Image
Read 4 tweets
Apr 3, 2023
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.
Read 8 tweets
Mar 13, 2023
1/ @eulerfinance is attacked. The root cause is due to the lack of liquidity check in the function donateToReserves()
phalcon.xyz/tx/eth/0xc310a…

See the detailed attack steps below. Image
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.
Read 4 tweets
Mar 1, 2023
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.

blocksecteam.medium.com/blocksecs-pers…
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.

kb.oasis.app/help/what-is-a…
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.
Read 7 tweets
Feb 22, 2023
1/ @fi_dynamic $DYNA on #BSC was hacked (bscscan.com/tx/0xc09678fec…) and the loss is ~73 BNB.

The root cause is that the StakingDYNA contract (bscscan.com/address/0xa7B5…) does not handle the deposit time correctly. ImageImage
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.
Read 4 tweets
Feb 17, 2023
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.
2/ We identified two attack transactions, with the first one (phalcon.blocksec.com/tx/avax/0x1266…) leaving the profits in the attack contract and the second one (phalcon.blocksec.com/tx/avax/0x997b…) transferring the profits to the attacker.
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.
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(