1/8
6 hours ago, there was another attack using flash loan, this time @OriginProtocol was affected. This attack is similar to Akropolis hack, because the problem is in re-entrancy and use of a fake token. All of this was needed to manipulate rebasing. Let’s see how it happened:
2/8 1. Flash loan 70k ETH from dYdX 2. Swap 17.5k ETH for 7.86 mln USDT on Uniswap 3. Swap 52.5k ETH for 20.99 mln DAI on Uniswap 4. Allow to rebase the attack contract 5. Mint 7.5 mln OUSD with 7.5 mln USDT
3/8 6. Call MintMultiple() function with:
6.1 mint 20.5 mln OUSD with 20.5 mln DAI
6.2 mint 2k OUSD with 2k USDT with rebasing through re-entrancy because the second asset is a fake token 7. Swap 300k OUSD to 158.5k USDT on Uniswap 8. Swap 1 mln OUSD to 520.7k USDT on Sushiswap
4/8 9. Redeem 33.27 mln OUSD after rebasing for 19.5 mln DAI, 3.9 mln USDC and 9.4 mln USDT 10. Swap 10.4 mln USDT to 22.9k ETH on Uniswap 11. Swap 3.9 mln USDC to 8.3k ETH on Uniswap 12. Swap 19 mln DAI to 47.9k ETH on Uniswap 13. Payback flash loan 70k ETH to dYdX
5/8 After this manipulation attacker made:
- 7 transactions in which he redeemed his OUSD
- 2 transactions to swap 300k OUSD to USDT on Uniswap
- 4 transactions with profit collection (swap all USDT and USDC for ETH on Uniswap and withdraw DAI and ETH from attack contract)
6/8 Finally, he used SELFDESTRUCT for destroying the contract.
As a result, the attacker was able to get ~$7.7M:
- 2,249,821 DAI
- 11,804 ETH
Also, the attacker deposited 333 ETH to Tornado Cash and tried to wash money using: 1. Uniswap for swap ~4338 ETH to 120 WBTC
7/8 2. Curve for swap 120 WBTC to ~120 renBTC 3. REN for withdrawal ~120 BTC to four addresses:
- bc1qdky68q9uv24ah8mf8uykj8x437u2hlrz6k4vzg
- bc1q2atlthkh04hsnk76w08ek5stk28wxgzhh8xvnu
- bc1qr0v3zz5wl0wjt79hj7yq57f3tkswj79jmjaynh
- bc1q4f645352dsam42ag3uym8rt0qzxwd8qlqe336h
8/8 Fun fact: an unnecessary argument *address* was used in collect() function called by the attacker, which is the address of @value_defi hacker. Whether this address is an easter egg, whether one attacker belongs to two hacks, or just trolling, we probably won’t know for sure.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
1/11 Okay, MEV is coming
MEV is a consequence of the fact that miners (pool operators) have the right to choose the tx order in a block.
They can be the first to:
- execute arbitrage
- get access to token offerings
- perform liquidation
Plus, they may not pay a fee for this.
2/11 As far as I know before, this was mainly used only for free distribution of rewards to miners. In this case, at the beginning of the transaction block, transactions are made to the pool miners, and only then all transactions, in order of decreasing gas price.
3/11 However, the DeFi boom led to the fact that more often, txs with not the highest gas price began to be the first in blocks. In some Spark Pool blocks, the first places in the block were occupied by txs from some address, although the price for gas in them was ~1 gwei.
$ENM hacker used Tornado to fund his address a week ago. Right after that, he claimed $UNI tokens for one of arbitrage contracts and withdrew them to himself in another tx by simulating arb. In theory, this claim could be a hack, which is why a mixer might have been used.
But it was necessary to guess without source code that arb function would help to withdraw $UNI and then use it in a certain way. Because of this, I’m more confident that it was the creator of the arb contract himself - 0x2d033fe
My hypothesis based on on-chain data:
0x223034e = $ENM hacker
0x762bfbd = the contract from which the hacker withdrawn $UNI
0x2d033fe = address of creator of 0x762bfbd
0x2f14f72 = address which funded creator (very likely one owner)
Two random facts about the hack of @BalancerLabs pools:
- the hacker made five 0.1 ETH withdrawals from Tornado, in the first of them relayer was used and the rest using his own address. Consequently, the hacker had experience with Tornado and he made at least 5 deposits there.
Currently, there are 1312 unique addresses that deposited 0.1 ETH into Tornado. Of these, 112 made at least 5 deposits. In addition, the number of addresses can be reduced by using heuristics from this paper: arxiv.org/pdf/2005.14051…
It will be cool if someone takes a look at it.
- the contract that withdrew the money from the STA pool couldn't withdraw it from the STONK pool due to an "Out of gas" error. However, after 40 minutes, the hacker rewrote the code and drained funds from the second pool using a new contract.
A couple of hours ago, the sale of the $DMG tokens from @DMMDAO has been completed, due to which DMG has the largest 24hr volume on Uniswap v2. However, the project allows anyone to get personal data of some borrowers of the fintech company which apparently launched it. ⬇️
The project promises a fixed rate (currently 6.25% per annum) for DAI, USDC, ETH, which is obtained from loans with cars as collateral. DMM uploads edited car documents to IPFS, allowing anyone to check them: explorer.defimoneymarket.com
Despite the project’s attempts to remove all private info, 18 of documents still have the Verification Code through which you can find additional information. The purchaser of these vehicle records is @FinovaFinancial. One of DMM’s partners is the CEO of this company.
For about 16 hours now, a known @Bancor vulnerability allows transferring tokens from people that used contracts v0.6. To avoid this, those who traded on this DEX should revoke their token approvals. So, let’s look at those who are still at risk.
Currently, 95 addresses allow malfunctioned Bancor contracts to do transfers from them. This means that as soon as one of the addresses receives a token, it can be immediately transferred by attackers or the Bancor team.
Good news, 15 of them are contracts: arbitrage bots, @1inchExchange, @DEXAG_TokenWire, and @KyberNetwork which receive and send tokens atomically - within one transaction. Due to this, tokens do not remain on the balance sheet and are not available for a transfer to an attacker.
Probably after the second fail, the address operator noticed an error and made some changes. Just take a look at how transactions stopped for an hour and a half (a tx with a 0.000609 fee, sent by someone not from this system).
Okay, one more pause
New portion of facts. I think that it is definitely clear that this is some kind of service, which has deposit addresses. After a closer look, it is also clear that transactions to deposit addresses have begun recently.