Written by: XY

Timeline

February 21, 2025: Bybit's multi-signed wallet was attacked, and 1.5 billion US dollars were leaked through "legal" signature transactions.

On-chain tracking: funds are transferred to anonymous addresses and split up the mixed coins, and the attacker has a potential relationship with some verification nodes.

Post-fact analysis: Security audit found that attackers exploited supply chain vulnerabilities in Safe's front-end to implant malicious scripts.

Why did the attack happen?

The hacker used evil front-end code to make the signatures of bybit signing wallets convinced that this was a legal transaction (such as a routine token transfer), and the result actually induces them to sign illegal transactions. In order to prevent the signers from discovering that there is something wrong with the transaction content through other means, the hacker even pretended to be a transfer transaction, so that the signers of bybit try not to check the transaction calldata through other methods. (The transaction content is usually called calldata)

In short, the attack method is as follows:

The hacker obtained the developer permissions of the Safe front-end, modified the front-end code, and implanted the target of bybit Malicious script for attack;

bybit Multi-signature members visited the contaminated web page and saw fake transaction information:

The page they saw: "Transfer 100 ETH to address A"

The actual signing is: "Modify the cold wallet logic"

This is like an ATM machine that has changed the display screen. The screen display is 100 yuan, but the actual operation is 1 million yuan.

Official APP - User trust blind spots

The multi-sign transaction process in user perception is very simple: see the transaction → sign → submit it to the chain, but in fact there is a key separation:

Transactions seen by users

Actually signed transactions

Using the official app will greatly reduce the user's vigilance, so that this layer of separation is ignored. If the official app page is attacked, the user's signature will be real, and they just don't know what they signed at this time.

At this time, if there can be independent channels to verify the authenticity of the signature content, the risks brought by front-end attacks can be greatly eliminated. This is what blockchain advocates: Don’t trust it, VERIFY it.

The theoretical cornerstone of “independent channel verification”

Let’s first look at the working principle of Safe contracts (as of now, Safe contracts are still safe enough):

First calculate a hash value from the transaction content (similar to the "fingerprint" that generates transactions)

Sign this hash value with a private key

When a sufficient number of signatures is collected, submit the original text of the transaction and these signatures to the chain

The hash value is calculated again on the chain based on the original text, and verify whether these signatures are valid. If sufficient valid transactions are collected, they will be executed, otherwise they will be rejected.

The security and difficult-to-forge properties of hashing and signatures are the two cornerstones of blockchain work, so there is no doubt.

So, if there is an independent channel that can obtain the original text and signature of the transaction before the transaction is submitted and put on the chain, you can verify "what is the transaction signed by the user" and "whether the user signed the transaction."

Therefore, even if the front-end or back-end is attacked, the worst case is to return the wrong data, and the wrong data will cause the following situations in the "independent channel":

Error transaction original text, wrong signature—the user refuses to send transaction on the chain

Error transaction original text, valid signature—the user refuses to send transaction on the chain

False transaction original text, wrong signature - the user refuses to send transactions to the chain

We can see that the worst case is that this transaction will not be sent to the chain, and in addition, it will not cause any on-chain losses. Therefore, the best way to target "display attacks" like this is multi-channel verification, which is in line with the spirit of blockchain: don't trust it, VERIFY it.

Existing solutions

Multiple multi-signature products are verified by each other

There are many safe-compatible multi-signature products on the market. For example, Safe has deployed two independent front-end pages by itself:

https://eternalsafe.vercel.app/welcome/

https://eternalsafe.eth.limo/welcome/

After signing a multi-signature transaction, the user logs in to the page of another multi-signature product and checks the original text of the transaction again. If the different multi-signature products show the exact same transaction content analysis, you can believe that "the transaction content you want to sign" is correct.

But this requires that different multi-signature products use the backend of {Safe} to store off-chain transactions and signature data and will also send the signature data they collect to the {Safe} backend, which is very strict for collaboration between products; and Safe is not friendly to the original text analysis of some unconventional transactions. Even if multiple Safe frontends show the same calldata, if it is just a string of meaningless 0xabcdefsf, it will discourage the signer.

Note: Currently, the two independent alternative websites provided by Safe need to provide their own RPC links:

Independent Safe transaction verification tool

The community responded very quickly to Safe front-end attack incidents. We found in the official Safe telegram groupSomeone has provided independent Safe transaction analysis tools, which seem simpler and more direct.

We also verify this tool. As shown in the figure, you only need to paste the transaction sharing link in the safe page to automatically read the Safe backend data and independently verify the hash value and signature of the transaction. In short, if you determine that the calldata parsing in the figure is the transaction you want, and the "SafeHash Check" and "Signature Check" are verified, you can think that "this is the transaction you want to send" and "has signed correctly".

Of course, to be on the safe side, we must also carefully check the Safe Address. The signature address, interaction contract address and operation type resolved through signatures are Call or Delegatecall. For example, bybit The transaction that was attacked this time is that delegatecall and transfer appear at the same time. A little experienced developer will know that such a combination is very strange.

If you encounter unreadable transaction information:

You can click Decode to provide the ABI of the transaction method, such as:

You can display readable transaction information:

Stay Safe - VERIFY, not trust

left;">Bybit's multi-signal attack reminds us again that front-end trust does not equal transaction security. Even if the official application is used, the transaction content may still be tampered with, and the signer must have an independent way to verify the content signed by himself.

Don't trust it, VERIFY it.) is the core principle of Web3 security. Hope the future Safe Ecosystem and moreMulti-sign products can strengthen the independent visa verification mechanism to avoid similar attacks from happening again.