Original Author: Moonbeam

Timeline

• February 21, 2025: Bybit multi-signature wallet is attacked, $1.5 billion flows out through "legitimate" signed transactions.

• On-chain tracking: Funds are transferred to anonymous addresses and mixed, with potential links between the attackers and some validation nodes.

• Post-incident analysis: Security audits reveal that the attackers exploited a supply chain vulnerability in the Safe frontend to implant malicious scripts.

Why the Attack Happened

The hacker used malicious frontend code to convince Bybit multi-signature wallet signers that this was a legitimate transaction (e.g., a routine token transfer), ultimately leading them to sign an illegal transaction. To prevent the signers from discovering issues with the transaction content through other means, the hacker even disguised the attack as a transfer transaction, making Bybit's signers less likely to check the transaction calldata through other methods. (The transaction content is usually referred to as calldata.)

In short, the attack method was as follows:

1. The hacker gained developer access to the Safe frontend, modified the frontend code, and implanted malicious scripts targeting Bybit;

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

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

4. What was actually being signed was: "Modify cold wallet logic"

This is akin to an ATM with a swapped display screen, showing a withdrawal of 100 yuan, while the actual operation is a withdrawal of 1 million yuan.

Official APP — User's Trust Blind Spot

The multi-signature transaction process in users' perception is very simple: See transaction → Sign → Submit on-chain, but in reality, it hides a critical layer of separation:

1. The transaction the user sees

2. The transaction that is actually signed

Using the official app significantly lowers users' vigilance, leading them to overlook this layer of separation. If the official app page is attacked, it will result in users' signatures being real; they just won't know what content they signed at that moment.

If there were an independent channel to verify the authenticity of the signed content, it could greatly mitigate the risks posed by frontend attacks. This is what blockchain advocates: Don't trust it, VERIFY it.

Theoretical Foundation of "Independent Channel Verification"

Let's first look at how the Safe contract works (as of now, the Safe contract is still sufficiently secure):

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

2. Sign this hash value with a private key

3. Once enough signatures are collected, submit the original transaction and these signatures on-chain

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

The security and difficulty of forgery of hashes and signatures are the two cornerstones of how blockchain works, without a doubt.

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

Thus, even if the frontend or backend is attacked, the worst-case scenario is just returning erroneous data, and erroneous data in the "independent channel" can lead to the following situations:

• Erroneous original transaction, erroneous signature — user refuses to send the transaction on-chain

• Erroneous original transaction, valid signature — user refuses to send the transaction on-chain

• Erroneous original transaction, erroneous signature — user refuses to send the transaction on-chain

We can see that the worst-case scenario is simply that this transaction will not be sent on-chain; beyond that, there will be no on-chain losses. Therefore, the best way to address such "display attacks" is through multi-channel verification, which also aligns with the spirit of blockchain: don't trust it, VERIFY it.

Existing Solutions

Mutual Verification of Multiple Multi-Signature Products

Currently, there are 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 a user signs a multi-signature transaction, they or subsequent signers can log into another multi-signature product's page to view the original transaction again. If different multi-signature products display exactly the same transaction content analysis, they can trust that "the transaction content they are about to sign" 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 the signature data they collect back to the {Safe} backend, which imposes very strict collaboration requirements between products. Moreover, Safe is not very user-friendly in parsing the original text of some unconventional transactions; even if multiple Safe frontends display the same calldata, if it is just a meaningless string like 0xabcdefsf, it may deter signers.

Note: The two independent alternative websites currently provided by Safe require users to provide their own RPC links:

Independent Safe Transaction Verification Tools

The community responded quickly to the Safe frontend attack incident. We found that someone had already provided an independent Safe transaction analysis tool in the official Safe Telegram group, which seems to be a simpler and more direct approach.

We also verified this tool. As shown, simply pasting the transaction share link from the Safe page allows it to automatically read Safe backend data and independently verify the correctness of the transaction's original hash value and signature. In short, if it is confirmed that the calldata analysis in the image is the transaction you want and both "SafeHash Check" and "Signature Check" pass, you can consider "this is the transaction you want to send" and "you have signed it correctly."

Of course, for safety's sake, you should also carefully check Safe Address, the signer's address derived from the signature, the interacting contract address, and the operation type (whether it is Call or Delegatecall). For example, the transaction that Bybit was attacked with involved both delegatecall and transfer, a combination that any slightly experienced developer would find very strange.

If you encounter unreadable transaction information:

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

This will display readable transaction information:

Stay Safe - VERIFY, not trust

The multi-signature attack on Bybit serves as a reminder that frontend trust does not equate to 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 sign.

Do not trust blindly; always verify (Don’t trust it, VERIFY it.) is the core principle of Web3 security. It is hoped that in the future, the Safe ecosystem and more multi-signature products will strengthen independent verification mechanisms to prevent similar attacks from happening again.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。