Review of Blast Chain’s $97 million battle, are hackers from a certain country unfamiliar?

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 is a high-quality project that won the Bigbang competition organized by Blast.

Blast will issue regular 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 a hacker from another address.

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, 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 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.

Through Blastscan we can see this attack transaction:

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 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 logic contract corresponding to the contract (0x 16..A 0) was upgraded.

Logical contract upgrade transaction:

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.

At this time, we suspect that the hacker updated the logic implementation contract of the agent contract, which will be 0x 9 e.. CD becomes 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 of 0x e 7..f 1 is partially 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 initial logic contract (0x 9 e..CD). At the same time, two other attacker addresses 0x c 5..0 d and 0x bf..87 were also registered, and their field 0 was set to the block time at the time of initialization. The purpose 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 the delegatecall, so the actual state storage update is in the contract (0x 16..A 0), which means that even if the logic contract is later updated to the logic contract 0x e 7..f 1 without a backdoor, the changed slot in the contract (0x 16..A 0) will not be restored.

Let's verify this:

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:

The lock time check is to ensure that the locked assets will not be transferred before the expiration date.

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 [UTC+ 0] March 21, 2024 (5 days before the attack),

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

Upgraded to 0x f 5..cd.

We also compare the two contracts and find that the attacker has also tampered with 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 held and the unlocking time, and then replaced it back to the normal contract to cover up the truth. When the project party and security researchers were debugging, they saw that the logical contracts were all normal, and because the contracts were not open source contracts, 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 look at the attacker’s address 3 (0x bf..87), which stole 73.49 WETH using the same method:

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 handling fee, 0x c 5..0 d (attacker address 2) did not carry out any attacks, but it actually carried out 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 Transaction:

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 0x00000000000000000000000043000000000000000000000000000000000000003

is the address of usdb

0x bf..87 (attacker address 3) This address is used to steal weth:

The _uniswap V3 Factory here is 0x0000000000000000000000004300000000000000000000000000000000000004

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 didn't the attacker steal all the assets?

Theoretically he can steal all the assets, namely 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.

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 cross-chain bridges of Blast. There is no limit on the number of official cross-chain bridges, but it requires 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):

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.

Events 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.

Finally, with the attention and efforts of the crypto community, the "hacker from a certain country" may have provided the private keys of the above three attacker addresses to the project party for fear of exposing his identity, and returned all the funds. The project party also carried out a rescue transaction and transferred all the funds of the damaged contract to a multi-signature contract for safekeeping.