The attacker mainly exploits the vulnerability in the PLTD contract to reduce the balance of PLTDs in Case-LP (0x4397c7) to 1 via flashloan, and then uses the $PLTD to swap all the $BUSD into the attack contract.
Step 1: The attacker initiates 2 flashloans through DODO and borrows $666,000 BUSD.
Step 2: The attacker swaps all the 666,000 $BUSD into 1.57M $PLTDs, at which point the attacker already holds a large amount of PLTD tokens, which will subsequently be used for the purpose of manipulating the balance of PLTD tokens in Cake-LP.
Step 3: The attacker queries the current bron value and the PLTD balance of the Commite-LP, which is a check before the attack. Note that these two values are critical and relate to the success of the attack.
Step 4: The attacker sends 116,000 $PLTD tokens directly to Commite-LP (0x4397c7), note that this amount is just twice the balance of $PLTDs in Commite-LP in the previous step minus 1
Why this number? We can find answers from the code.
1) Call the transfer function. 2) The target address is uniswapV2Pair, we look at else if branch in line 344. The from address is the attack contract, takeFee is true, and the internal function _tokenTransferSell is called.
3) The internal code of the _tokenTransferSell function is as follows. In lines 423-426, this part of the code sets the _bron to half the number of this transfer, i.e. the balance of the Cake-LP minus 1.
Step 5: Let's back to the attack. Here the attacker uses skim to take back the PLTD transferred in step 4. As in the _transfer function, if the from address is uniswapV2Pair, then it will call _tokenTransferBuy.
(The function will not affect the value of _bron)
Step 6: All the previous operations are for this step. The attacker transfers 1 $PLTD to the address 0x16b9a82891338f9ba80e2d6970fdda79d1eb0dae, and since this address is not the address of Take-LP, the internal function _tokenTransfer is called for this transfer.
Look at line 451 to 456. In step 4, _bron is set to the balance of Cake-LP minus 1, and the fifth step restores the balance of Cake-LP. This step directly reduces the balance of Cake-LP to 1, and then calls the sync function of Cake-LP to synchronize the balance to reserve.
Step 7: The attacker swaps all the $PLTD tokens to $BUSD, almost draining the entire BUSD balance of Case-LP.
The attacker gains 690,000 $BUSD and repays the 666,000 BUSD flashloan. The remaining 24,497 $BUSD profit is sent to 0x083c057221e95D45655489Fb01b05C4806387C19
• • •
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().