background
Blast is an Ethereum Layer 2 network launched by Pacman (Tieshun Roquerre, aka. Tieshun), the founder of Blur. It launched the mainnet on February 29. Currently, approximately 19,500 ETH and 640,000 stETH are pledged on the Blast mainnet.
The attacked project, Munchables, was a premium project that won the Bigbang competition hosted by Blast.
Blast officials will issue ordinary points to users who pledge ETH on the Blast mainnet:
In order to encourage users to participate in DeFi projects on the Blast ecosystem, Blast officials will select high-quality projects for recommendation and encourage users to pledge ETH a second time into DeFi to obtain faster points increase and gold points, so there are quite a few Users pledged the ETH pledged on the Blast main network to the newly created DeFi project.
The maturity and security of these DeFi projects have yet to be examined, and whether these contracts have sufficient security considerations to safeguard users’ tens of millions or even hundreds of millions of dollars.
Event overview
Less than a month after the Blast mainnet went online, an attack on SSS Token (Super Sushi Samurai) occurred on March 21, 2024. There was a transfer logic error in the Token contract, which allowed the attacker to increase the SSS Token of the specified account out of thin air. balance, the project ultimately lost more than 1,310 ETH (approximately $4.6 million).
Less than a week after the SSS Token attack, another larger attack occurred on Blast. The Munchables project was swept away by attackers with 17413.96 ETH, a total of approximately 62.5 million US dollars.
Half an hour after the attack transaction occurred, 73.49 WETH in the project contract was also stolen by another address by the hacker.
At this time, there are still 7276 WETH, 7758267 USDB, and 4 ETH stored in the contract address of the project party, which will fall into the hands of hackers at any time. The hacker has the authority to take away all the funds of the entire project, totaling approximately 97 million US dollars. Exposed to risk.
Immediately after the incident, zachXBT, a well-known on-chain detective of X (Twitter), pointed out that the root cause of this attack was the hiring of hackers from a certain country.
Let’s take a closer look at how a “hacker from a certain country” completed an attack worth nearly $100 million.
On-site restoration
Victims speak out
[UTC+ 0 ] At 21:37 on March 26, 2024 (5 minutes after the attack), Munchables officially posted on X (Twitter) stating that it was under attack.
According to the investigation of on-chain detective Zach The attacker came to do some game development work. He was very rough and really looked like a Chinese hacker. We fired him within a month. He also tried to get us to hire one of his friends, who was probably also a hacker. hacker.
Since this attack caused huge losses to users in the community, we immediately launched an on-chain investigation. Let’s take an in-depth look at the attack details of this “hacker from a certain country”.
First scene
[UTC+ 0 ] At 21:32 on March 26, 2024, an attack involving 17413.96 ETH occurred.
We can see this attack transaction through Blastscan: https://blastscan.io/tx/0x9a7e4d16ed15b0367b8ad677eaf1db6a2a54663610696d69e1b4aa1a08f55c95
The damaged contract (0x 29..1 F) is a proxy contract that stores the users pledged funds. We can see that the attacker called the unlock function of the pledge contract, passed all permission checks, and transferred it away. All ETH in the contract goes to attacker address 1 (0x 6 E..c 5).
It seems that the attacker called an unlock function with withdraw-like behavior and took away most of the ETH on the compromised contract (0x 29..1 F).
Did the project party forget to lock the vault?
There are two related checks for unlock in the damaged contract (0x 29..1 F). Let’s look at them one by one.
First, we found that during the permission verification process, the isRegistered method of the contract (0x 16..A 0) was called to check whether the current msg.sender, that is, the hacker address 1 (0x 6 E..c 5) Already registered:
The answer is: passed the verification.
This involves the contract (0x 16..A 0) and its corresponding latest logical contract (0x e 7..f 1)
[UTC+ 0 ] At 08:39 on March 24, 2024 (2 days before the attack), the logical contract corresponding to the contract (0x 16..A 0) was upgraded.
Logical contract upgrade transaction:
https://blastscan.io/tx/0x9c431e09a80d2942319853ccfdaae24c5de23cedfcef0022815fdae42a7e2ab6
The logic contract is updated to 0x e 7..f 1 .
The original logical contract address can be seen here, which is 0x 9 e..CD.
https://blastscan.io/tx/0x7ad050d84c89833aa1398fb8e5d179ddfae6d48e8ce964f6d5b71484cc06d003
At this time, we suspect that the hacker updated the logic implementation contract of the proxy contract and changed 0x 9 e..CD into a malicious 0x e 7..f 1 , completing the bypass of verification permissions.
Is it really?
In Web3.0, you never need to guess or listen to others. You only need to master the technology to get the answer yourself.
By comparing the two contracts (not open source contracts), there are some obvious differences between the original 0x 9 e..CD contract and the updated 0x e 7..f 1:
The initialize function part of 0x e 7..f 1 is implemented as follows:
The initialize function part of 0x 9 e..CD is implemented as follows:
It can be seen that the attacker set the attacker address (0x 6 e..c 5) as register in the original logical contract (0x 9 e..CD), and there are also two other attacker addresses 0x c 5 ..0 d, 0x bf..87 are also registered, and their field 0 is set to the block time during initialization. The use of field 0 will be explained later.
In fact, contrary to what we guessed, the real logic contract with a backdoor existed from the beginning, and the subsequent updates were normal!
Wait, this update appeared at 08:39 on March 24, 2024 [UTC+ 0] (2 days before the attack). That is, before this incident, the logic contract had become a contract without backdoors. Why? Can the attacker still complete the attack?
This is because of delegatecall, so the actual state storage update is in the contract (0x 16..A 0), which results in the fact that even if the logic contract is later updated to the logic contract without backdoor 0x e 7..f 1 , the changed slot in the contract (0x 16..A 0) will still not be restored.
Let’s verify it:
As you can see, the corresponding slot in the contract (0x 16....A 0) has a value.
This allows an attacker to pass the isRegistered method check:
The attacker later changes the backdoor contract to a normal contract to hide the fact that the backdoor has already been planted.
In addition, the unlock process also involves a second verification:
Regarding the lock time check, this part is to ensure that the locked assets will not be transferred before expiration.
The attacker needs to ensure that the block time when unlock is called is greater than the required lock expiration time (field 3).
This part of the verification involves the damaged contract (0x 29..1 F) and the corresponding logical contract 0x f 5..cd.
In a transaction at 11:54 on March 21, 2024 [UTC+ 0] (5 days before the attack),
https://blastscan.io/tx/0x3d08f2fcfe51cf5758f4e9ba057c51543b0ff386ba53e0b4f267850871b88170
We can see that the original logical contract of the damaged contract (0x 29..1 F) contract was 0x 91..11, and just four minutes later, at
https://blastscan.io/tx/0xea1d9c0d8de4280b538b6fe6dbc3636602075184651dfeb837cb03f8a19ffc4f
Upgraded to 0x f 5..cd.
We also compare the two contracts and we can find that the attacker also made tricks in the initialize function as before.
Partial implementation of the initialize function of 0x f 5..cd:
Partial implementation of the initialize function of 0x 91..11:
It can be seen that it is obvious that the same method was used again to tamper with the amount of ETH and the unlocking time, and then replaced it with the normal contract to deceive others. When the project team and security researchers were debugging , all the logical contracts seen are normal, and because the contracts are all non-open source contracts, it is even more difficult to see the core of the problem clearly.
So far, we understand this transaction involving 17413 ETH and how the attacker did it, but is there only this much information behind this incident?
In our above analysis, we actually saw that the hacker built 3 addresses into the contract:
0x 6 e..c 5 (attacker address 1)
0x c 5..0 d (attacker address 2)
0x bf..87 (attacker address 3)
However, we only saw 0x 6 e..c 5 in the attack transaction we found above. What did the other two addresses do? And what secrets are hidden in address(0), _dodoApproveAddress, and _uniswapV3Factorty?
Second scene
Let’s first look at attacker address 3 (0x bf..87), which stole 73.49 WETH through the same method:
https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233
And attack the source address of gas (0x 97..de), and provide handling fees to both 0x c 5..0 d (attacker address 2) and 0x bf..87 (attacker address 3).
The source of the 0.1 ETH that attacks the gas source address (0x 97..de) comes from owlto.finance (cross-chain bridge).
0x c 5..0 d (attacker address 2) did not carry out any attack after receiving the handling fee, but it actually shouldered a hidden plan. Let’s continue to look at it.
In fact, according to the official rescue transaction, the original address of the damaged contract (0x 29..1 F) was not just 73.49 WETH. Until the end of the attack, there were still 7276.5 WETH 7758267 USDB.
Rescue deal:
https://blastscan.io/tx/0x1969f10af9d0d8f80ee3e3c88d358a6f668a7bf4da6e598e5be7a3407dc6d5bb
The attacker originally planned to steal these assets. You can see that the address 0x c 5..0 d (attacker address 2) was originally used to steal USDB.
The _dodoApproveAddress here is 0x0000000000000000000000004300000000000000000000000000000000000003
is the address of usdb
0x bf..87 (attacker address 3) This address is used to steal weth:
The _uniswap V3 Factory here is 0x00000000000000000000000043000000000000000000000000000000000000004
is the address of weth
And 0x 6 e..c 5 (attacker address 1) is responsible for stealing address(0), which is the native asset ETH.
By setting field 0, the attacker can steal the corresponding assets through the following logic:
question
Why didnt the attacker steal all the assets?
In theory he could steal all the assets, which is the remaining WETH and USDB.
0x bf..87 (attacker address 3) only stole 73.49 WETH. 0x bf..87 (attacker address 3) can actually take away all 7350 WETH, or you can use 0x c 5..0 d (Attacker address 2) took away all 7758267 USDB. Why it stopped after only taking a little WETH? We don’t know. It may require a well-known chain detective to conduct an in-depth internal investigation.
https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233
Why didn’t the attacker transfer 17413 ETH to the Ethereum mainnet?
As we all know, it is possible for the Blast main network to intercept these ETH through a centralized method and let it stay here permanently without causing substantial user losses. However, once these ETH enter the Ethereum main network, there is no way to intercept it.
We evaluated the current Blast cross-chain bridges. There is no limit on the number of official cross-chain bridges, but they require 14 days to exit, which is enough for Blast officials to prepare an interception plan.
The third-party cross-chain bridge can be credited in near real-time, just like the attacker’s source of fees, and can quickly complete the cross-chain. Why did the attacker not cross-chain immediately?
In fact, the attacker carried out cross-chain at the first moment (within 2 minutes of the attack):
https://blastscan.io/tx/0x10cf2f2b884549979a3a1dd912287256229458ef40d56df61738d6ea7d9d198f
Moreover, it took 20 seconds for the funds to arrive on the Ethereum main network. In theory, an attacker can continue to cross-chain and transfer a large amount of ETH across chains before the cross-chain bridge can manually intervene.
As for why it can only be 3 ETH at a time, the reason is the liquidity limit of the cross-chain bridge, from Blast to ETH:
Another cross-chain bridge that supports Blast supports even less:
After this cross-chain transaction, the attacker did not continue other cross-chain operations. The reason is unknown to us. It seems that the hacker from a certain country did not make adequate preparations for the withdrawal of funds from Blast.
What happened after the attack
Based on feedback from community user Nearisbuilding, he found more identity information of the attacker and found ways to prompt the attacker to return the funds.
https://twitter.com/Nearisbuilding/status/1772812190673756548
In the end, with the attention and efforts of the encryption community, the hacker from a certain country, perhaps because he was afraid of exposing his identity, provided the private keys of the above three attacker addresses to the project party and returned all funds. The project party also conducted a rescue transaction. Transfer all funds from the damaged contract to the multi-signature contract for safekeeping.
