Author: Moonbeam

Timeline

• February 21, 2025: Bybit's multi-signature wallet was attacked, and $1.5 billion was drained through "legitimate" signed transactions.

• On-chain Tracking: The funds were transferred to anonymous addresses and split for mixing, and the attacker was potentially associated with some validator nodes.

• Post-analysis: Security audits found that the attacker exploited a supply chain vulnerability in the Safe frontend to inject malicious scripts.

Why the Attack Happened

The hackers used malicious frontend code to make Bybit's multi-signature wallet signers believe that this was a legitimate transaction (e.g., a routine token transfer), but in reality, they were induced to sign an illegal transaction. To prevent the signers from discovering the problem through other means, the hackers even disguised the attack as a "transfer" transaction, so that Bybit's signers would be less likely to check the transaction calldata.

In summary, the attack method was as follows:

1. The hackers obtained developer access to the Safe frontend and modified the frontend code, injecting malicious scripts targeting Bybit;

2. Bybit's multi-signature members accessed the compromised webpage and saw the fake transaction information:

3. The page they saw: "Transfer 100 ETH to Address A"

4. What they were actually asked to sign: "Modify cold wallet logic"

This is like an ATM machine with a tampered display screen, where the screen shows a withdrawal of 100 units, but the actual operation is a withdrawal of 1 million units.

Official App — The Trust Blind Spot of Users

In the user's perception, the multi-signature transaction flow is simple: See the transaction → Sign → Submit on-chain, but in reality, there is a critical separation:

1. The transaction the user sees

2. The actual transaction being signed

Using the official app will greatly reduce the user's vigilance, to the point that they overlook this separation. If the official app's page is attacked, the user's signature will be genuine, but they will not know what they are actually signing.

If there is an independent channel to verify the authenticity of the signed content, the risk of frontend attacks can be greatly reduced. This is what blockchain advocates: Don't trust it, VERIFY it.

The Theoretical Foundation of "Independent Channel Verification"

Let's first look at the working principle of the Safe contract (as of now, the Safe contract is still secure enough):

1. First, calculate a hash value of the transaction content (similar to generating a "fingerprint" of the transaction)

2. Sign the hash value with a private key

3. When enough signatures are collected, submit the original transaction text and these signatures to the chain

4. The chain recalculates the hash value based on the original text and verifies whether the signatures are valid, and if enough valid transactions are collected, it executes, otherwise it rejects.

The security and non-forgery properties of hashing and signing are the two cornerstones of blockchain work, no need to doubt.

Therefore, if there is an independent channel that can obtain the original transaction text and signatures before the transaction is submitted to the chain, it can verify "what transaction the user actually signed" and "whether the user actually signed this transaction".

Therefore, even if the frontend or backend is attacked, the worst-case scenario is that it only returns erroneous data, and the erroneous data will result in the following situations in the "independent channel":

• Incorrect transaction text, incorrect signatures — the user refuses to send the transaction on-chain

• Incorrect transaction text, valid signatures — the user refuses to send the transaction on-chain

• Incorrect transaction text, incorrect signatures — the user refuses to send the transaction on-chain

We can see that the worst-case scenario is just that this transaction will not be sent on-chain, and apart from that, there will be no on-chain losses. So the best way to deal with this kind of "display attack" is multi-channel verification, which is also in line with the spirit of blockchain: don't trust it, VERIFY it.

Existing Solutions

Mutual Verification of Multiple Multi-signature Products

There are currently many Safe-compatible multi-signature products on the market, for example, Safe itself has deployed two independent frontend pages:

https://eternalsafe.vercel.app/welcome/
https://eternalsafe.eth.limo/welcome/
After signing a multi-signature transaction, the user or subsequent signers can log in to another multi-signature product's page and review the original transaction text again. If the two multi-signature products display the same transaction content, the user can trust that "the transaction content they are signing" is correct.

However, this requires that different multi-signature products all use Safe's backend to store off-chain transaction and signature data, and also send their collected signature data to Safe's backend, which places very demanding requirements on product collaboration. Moreover, Safe's parsing of some non-standard transactions is not user-friendly, and even if multiple Safe frontends display the same calldata, it may still be a meaningless 0x abcdefsf that will make the signer hesitant.

Note: The two independent alternative websites provided by Safe currently require the user to provide their own RPC link:

Independent Safe Transaction Verification Tool

For the Safe frontend attack incident, the community's response was also very quick. We found that someone in the Safe official Telegram group had already provided an independent Safe transaction parsing tool, which seems to be a simpler and more direct approach.

We also verified this tool. As shown in the image, you only need to paste the transaction sharing link from the Safe page, and it can automatically read the Safe backend data and independently verify the correctness of the transaction text hash and signatures. In short, if you are sure that the calldata parsing shown in the figure is the transaction you want to send, and the "SafeHash Check" and "Signature Check" verifications pass, you can believe that "this is the transaction you want to send" and "you have signed it correctly".

Of course, to be on the safe side, you also need to double-check the Safe Address, the signer addresses parsed from the signatures, the contract address being interacted with, and whether the operation type is Call or Delegatecall, as in the case of the Bybit attack, the combination of delegatecall and transfer was very strange.

If you encounter unreadable transaction information:

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

Then you can display the readable transaction information:

Stay Safe - VERIFY, not trust

Bybit's multi-signature attack once again reminds us that frontend trust does not equal transaction security. Even when using the official application, the transaction content may still be tampered with, and signers must have an independent way to verify the content they are signing.

Don't trust it, VERIFY it. is the core principle of Web3 security. It is hoped that the Safe ecosystem and more multi-signature products in the future can strengthen the independent verification mechanism to avoid similar attacks from happening again.