#Flashloan
On July 10, @OMNI_xyz OMNI protocol suffered a reentrancy attack. The hacker made a profit of ~496 $ETH and deposited into Tornado.cash.
We take one of the attack Txs (0x05d65e0adddc5d9ccfe6cd65be4a7899ebcb6e5ec7a39787971bcc3d6ba73996) as an example:
2/ The attacker first borrowed 1,000 $WETH and 20 #Doodles via flashloan and staked NFTs with ids 720, 5251 and 7425, obtained the corresponding digital receipts and then borrowed 12.15 WETH.
3/ Then call the withdrawERC721 function to withdraw the NFTs with ids 720 and 5251. This will call Ntoken contract’s burn function, which internally calls the safeTransferFrom function to send the NFTs to the attack contract and calls back the onERC721Received function.
4/ In the onERC721Received function, the victim's liquidationERC721 function is re-entered to liquidate the NFT with id 7425. During liquidation, the _burnCollateralNTokens function is called to burn the digital receipts of the attack contract and repay the staked NFT.
5/ So the safeTransferFrom function is called again to trigger the onERC721Received function of the attack contract. The attacker again used callback to stake all borrowed 20 NFTs from flashloan and borrowed 81 $WETH.
6/ Finally the hacker returned to the liquidationERC721 function and set the borrowing status to false, and successfully withdrew all staked NFTs.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
2/ The total loss from hacks in Web3 has significantly decreased compared to last year.
In H1 2022, the total loss from attacks was ~$1.91 billion, and in H2 2022, it was about $1.69 billion, while in H1 2023, this value dropped to $470 million.
3/ Distribution of loss amount in hacks:
Loss exceeding $100 million: 1 incident
$10 million to $100 million: 7 incidents
$1 million to $10 million: 23 incidents
Last month, Beosin security researchers have discovered a high-risk vulnerability CVE-2023–33252 in the library of SnarkJS (version 0.6.11 and earlier).
The high-risk vulnerability that allowing double-spending has now been fixed by Circom. It has a severity score of 7.5 in the… twitter.com/i/web/status/1…
2/ Circom is a zero-knowledge proof circuit compiler developed in Rust. The team behind Circom has also developed the SnarkJS library, which supports various functionalities, including trusted setups, generation and verification of zero-knowledge proofs.
3/ In versions of SnarkJS <= 0.6.11, the library fails to perform comprehensive validation checks on the parameters during proof verification. This allows attackers to forge multiple proofs that pass the verification process, enabling double-spending attacks.
3/ The backdoor function add() will transfer LP tokens from the contract to the _devadd address. By querying the _devadd address, it will return the ‘Swaprum:Deployer’ address.
On Apr 15th, @HundredFinance was exploited for over $7M on #Optimism.
Hundred Finance was also a victim of a reentrancy attack on Mar 2022.
Txs:
0x15096dc6a59cff26e0bd22eaf7e3a60125dcec687580383488b7b5dd2aceea93
0x6e9ebcdebbabda04fa9f2e3bc21ea8b2e4fb4bf4f4670cb8483e2f0b2604f451
2/ The root cause is that the attacker can manipulate the exchangeRate by donating a large amount of WBTC to the hWBTC contract.
In the getAccountSnapshot function, the value of exchangeRateMantissa relies on the amount of WBTC in the contract.
3/ The attacker flashloaned 500 $WBTC, then called the redeem function to redeem the previously staked 0.3 WBTC.
Next, the attack contract 1 sent 500.3 WBTC to attack contract 2. Contract 2 used 4 BTC to mint 200 hWBTC. The redeem function was then called to redeem the 4 BTC.
Root cause: The reset of lastCalledPool is before the check. This results in an invalid check on Pool, allowing attackers to specify malicious Pool to transfer users’ funds that have approved when swap.
1) The attacker created the malicious pool contract 30 days ago. 2) The swap is performed by calling SushiSwap's router function processRoute, specifying the malicious contract as the pool contract.
3) After the swap, the malicious contract calls the uniswapV3SwapCallback, specifying the tokenIn as WETH and the from address as the victim's address (@0xSifu sifuvision.eth), thus using the victim's approval to router contract to transfer the funds.
2/ The attacker first calls the "joinPool" function of Balancer Vault to make a deposit. Then he calls "exitPool" to withdraw, during which Balancer Vault sends eth to the attacker to call the fallback function of the attack contract.
3/ In the fallback function, the attacker calls the 0x62c5 contract's borrow function, which does a price calculation based on the return data from Balancer Vault.getPoolTokens().