background
Blast is an Ethereum Layer 2 network launched by Pacman (Tieshun Roquerre, aka. Tieshun), the founder of Blur. It launched the main network on February 29. Currently, approximately 19,500 ETH and 640,000 stETH are pledged on the Blast main network.
The attacked project Munchables is a high-quality project that won the Bigbang competition organized by Blast.
Blast official will issue ordinary points to users who pledge ETH on the Blast main network:
In order to encourage users to participate in DeFi projects in 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. 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 was launched, on March 21, 2024, an attack on SSS Token (Super Sushi Samurai) occurred. There was a transfer logic error in the Token contract, which allowed the attacker to increase the SSS Token balance of the designated account out of thin air. Ultimately, the project lost more than 1,310 ETH (about 4.6 million US dollars).
Less than a week after the SSS Token attack, another larger attack occurred on Blast. The Munchables project was swept away by the 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's contract was also stolen by the hacker to another address.
At this time, there are still 7276 WETH, 7758267 USDB, and 4 ETH on the project party’s contract address, which may 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 U.S. dollars. Exposed to risk.
Immediately after the incident, X (Twitter)’s well-known on-chain detective zachXBT 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 announced on X (Twitter) that it had been attacked.
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.
Through Blastscan we can see this attack transaction: https://blastscan.io/tx/0x9a7e4d16ed15b0367b8ad677eaf1db6a2a54663610696d69e1b4aa1a08f55c95
The damaged contract (0x 29..1 F) is a proxy contract that stores the user's 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 behavior similar to withdraw and took away most of the ETH on the damaged 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 in the process of verifying permissions, 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), has been 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), we can see that 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) to 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 have also been 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 the backdoor existed at the beginning, and the later 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 0x e 7..f 1 without backdoor , the changed slot in the contract (0x 16..A 0) will still not be restored.
Let's verify this:
It can be seen that the corresponding slot in the contract (0x 16....A 0) has a numerical 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, in the unlock process, a second check is also involved:
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) was 0x 91..11, and just four minutes later,
https://blastscan.io/tx/0xea1d9c0d8de4280b538b6fe6dbc3636602075184651dfeb837cb03f8a19ffc4f
Was upgraded to 0x f 5..cd.
We also compare the two contracts and we can find that the attacker did something in the initialize function just like before.
Partial implementation of 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 unlocking time of the ETH amount held by oneself, and then replaced it back with the normal contract to deceive others. When the project team and security researchers were debugging, All the logical contracts I saw were normal, and because the contracts were all unopened, it was even more difficult to see the core of the problem.
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)
In the attack transaction we found above, we only saw 0x 6 e..c 5 . What did the other two addresses do? And what secrets are hidden in address( 0), _dodoApproveAddress, and _uniswapV3Factorty?
Second scene
Let’s first take a look at attacker address 3 (0x bf..87), which stole 73.49 WETH through the same method:
https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233
It also attacks the source address of gas (0x 97..de), and provides transaction fees to 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).
After receiving the transaction fee, 0x c 5..0 d (attacker address 2) did not carry out any attack, but it actually carried out a hidden plan. Let’s continue to look at it.
In fact, according to the official post-rescue transaction, there were not only 73.49 WETH on the address of the damaged contract (0x 29..1 F). Until the end of the attack, there were still 7276.5 WETH 7758267 USDB.
Rescue Transaction:
https://blastscan.io/tx/0x1969f10af9d0d8f80ee3e3c88d358a6f668a7bf4da6e598e5be7a3407dc6d5bb
Originally the attacker 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.
Here _dodoApproveAddress is 0x0000000000000000000000000430000000000000000000000000000000000000000003
is the address of usdb
0x bf..87 (attacker address 3) This address is used to steal weth:
The _uniswap V3 Factory here is 0x000000000000000000000004300000000000000000000000000000000000004
the address for 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 didn't the attacker steal all the assets?
In theory he could steal all the assets, i.e. 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 on-chain detective to conduct an in-depth internal investigation.
https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233
Why didn’t the attacker transfer 17413 ETH to 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 have evaluated the current cross-chain bridges of Blast. 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 time (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, the attacker can continue to cross-chain and transfer a large amount of ETH across the chain before the manual intervention of the cross-chain bridge.
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. We do not know the reason. It seems that the "hacker from a certain country" did not make sufficient 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.