2/ The attacker first created the attack contract 0xe167cdaac8718b90c03cf2cb75dc976e24ee86d3 to call the DaoModule 0x8f90 contract's executeProposalWithIndex() function to execute a proposal.
3/ The proposal is to call the mint() function to mint 100,000,000,000,000 $RNBW and transfer ownership to the attacker.
Finally the hacker swapped them to $xRNBW, which sit at the attacker's address 0x0f44f3489D17e42ab13A6beb76E57813081fc1E2.
• • •
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().