Try   HackMD

Technical Analysis Report: Bybit Exchange Security Breach - Principles, Process, and Recommendations

Introduction

On February 21, 2025, the cryptocurrency exchange Bybit experienced a security breach, resulting in the loss of approximately $1.5 billion in ETH, potentially making it the largest cryptocurrency theft in history. The attack compromised Bybit's ETH multi-signature cold wallet during a routine transfer, exploiting a front-end vulnerability in Safe Wallet (formerly Gnosis Safe). Malicious code altered transaction data, ultimately draining funds from the multi-signature cold wallet. This report analyzes the technical principles and process behind the attack and provides recommendations for improving system design and security.

Technical Principles and Process of the Attack

Multi-Signature Wallet

Safe Wallet is a widely adopted multi-signature wallet implementation, a smart contract design that requires multiple private key signatures to execute transactions. It enhances security through distributed authorization, supports various blockchain networks, and provides an intuitive front-end interface for user operations. The normal multi-signature transaction signing process is as follows:

  1. Transaction Proposal: A signer creates and proposes a transaction via the Safe Wallet front-end.
  2. Transaction Review: The transaction data is broadcast to all signers for review through the front-end.
  3. Signature Verification: Signers use their respective private keys (e.g., hot wallets such as Metamask or cold wallets such as Ledger) to sign the transaction.
  4. Transaction Execution: Once sufficient signatures are collected, the transaction is submitted to the blockchain for execution.

Attack Vector

The attack hinged on a combination of a supply chain attack and blind signing. The specific process unfolded as follows:

  1. Front-End Supply Chain Attack:

    • The attacker exploited a supply chain vulnerability in the Safe Wallet front-end, injecting malicious code through social engineering (e.g., phishing) or compromised third-party dependencies, thereby altering the displayed transaction data.
    • Signers, using the tampered front-end, saw falsified transaction details and signed what they believed to be legitimate operations. For example, they might have seen a valid "transfer 10 ETH to a hot wallet" transaction, while actually approving a "replace the contract implementation with a malicious contract" operation.

  2. Transaction Tampering and Blind Signing:

    • Malicious code altered the transaction data displayed on the Safe Wallet front-end while simultaneously transmitting the actual malicious data to the signers' hardware wallets.
    • Hardware wallets typically display simplified transaction data rather than full contract execution details, which leads signers to unknowingly approve malicious transactions. This was especially problematic with complex, encoded contract calls that hardware wallets could not fully interpret, thus deceiving the signers.

  3. Malicious Contract Deployment and Execution:

    Safe Wallet's smart contract employs an upgradeable architecture, consisting of a proxy contract and an implementation contract, which makes contract upgrades a prime target. The attacker manipulated the proxy contract using the delegatecall function, tampering with callData to replace the legitimate implementation with a malicious one. Specifically, the forged transaction data might have mimicked a transfer(address, uint256) interface while actually executing contract upgrade logic, updating the implementation to a malicious version. Once updated, the backdoor functions in the malicious contract (sweepETH() & sweepERC20()) were triggered, enabling the transfer of funds. Analysis indicates that callData tampering was the key factor in the attack's success, further aggravated by hardware wallets' inability to fully display callData, thereby worsening the blind signing issue.

The wallet accounts, smart contracts, and executed transactions involved in this incident are as follows:

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Irregular Contract Update

In Safe Wallet's design, the proxy contract uses a state variable named masterCopy to store the address of the implementation contract, as a key factor of the upgrade functionality. This means the contract logic can be replaced. Normally, updating masterCopy requires authorization from multiple signers and a formal process (e.g., calling upgradeTo(address)).

However, in the Bybit hack, the attacker circumvented this formal process. By exploiting a front-end supply chain attack and callData tampering, they manipulated transaction data to deceive signers into approving what appeared to be legitimate transfers or routine operations. In reality, the malicious callData contained a pre-deployed malicious contract address. This method bypassed Safe Wallet's standard upgrade process by directly modifying masterCopy, exploiting delegatecall to alter its storage slot during proxy contract execution.

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Transaction Signing Process

Normal Signing Process

The normal multi-signature signing process highlights the secure operation of a multi-signature wallet. The proposer (Proposer) creates a transaction and broadcasts its data to multiple signers (Signer1, Signer2, Signer3) via the front-end. Each signer reviews and signs the transaction using their hardware wallet (e.g., Ledger). Once enough signatures are collected (e.g., three required), the system submits them to the wallet contract (WalletContract) for transaction execution. This ensures multi-layer authorization and transparency, preventing unilateral actions.

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Compromised Signing Process

The compromised signing process reveals the attack's operations. The attacker injects malicious code into the wallet front-end (WalletFrontend), altering the displayed transaction data. The proposer (Proposer) creates a legitimate transaction and broadcasts it, but the signers (Signer1, Signer2, Signer3) see tampered data that appears valid. Due to hardware wallets' blind signing limitations (inability to display full callData), signers approve the transaction unknowingly. Once submitted, the wallet contract (WalletContract) executes the malicious transaction. This exposes the severe risks of supply chain attacks and UI deception.

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

System Design Recommendations

To prevent such attacks, developers and operators should integrate the following measures into multi-signature wallet systems:

1. Secure Software Development and Distribution

  • Supply Chain Security: Regularly audit front-end and third-party dependencies, using content integrity checks to prevent code tampering.
  • Version Control: Ensure all signers use the latest official front-end versions, and avoid unverified mirror sites.

2. Multi-Layer Verification Mechanisms

  • Pre-Execution Checks: Simulate transaction effects in a local sandbox, compare state changes, generate readable reports, and integrate threat detection engines for pattern recognition.
  • Independent Verifications: Signers should verify transaction details using blockchain explorers (e.g., Etherscan) or independent tools (e.g., transaction simulators) to ensure independent review before execution and prevent unauthorized upgrades.
  • Execution Delay Mechanism: Implement a timelock in smart contracts (e.g., a 72-hour delay) to allow teams sufficient time to review transactions and detect anomalies.
  • Detailed Transaction Display: Use hardware wallets that support full transaction data and details to avoid blind signing.

3. HSM and FIDO2 Integration

  • Hardware Security Module (HSM):

    • An HSM is a dedicated cryptographic device designed for secure private key storage and signing, which is commonly used in enterprise environments. Enterprise-level multi-signature systems can integrate an HSM to ensure private keys never leave the device.
    • In multi-signature wallets, signers can use HSM to store private keys and sign transactions, reducing the risk of approving malicious operations.

  • Fast Identity Online (FIDO):

    • FIDO2 provides passwordless authentication using security keys or biometrics, which restricts signing interface access. Only FIDO2-authenticated users can operate the front-end, which prevents unauthorized access.
    • Combining HSM and FIDO2 creates a dual-layer security framework, thereby enhancing protection.

4. Signing Policies and Restrictions

  • Policy Enforcement: Implement back-end signing policies (e.g., limiting single transfer amounts or prohibiting upgrades) to block malicious transactions, even if the front-end is compromised.
  • Real-Time Monitoring: Deploy anomaly detection systems to monitor signing behavior and transaction patterns, which can promptly intercept suspicious operations.

5. Regular Security Assessments and Training

  • Penetration Testing: Conduct regular audits, assessments, and simulated attacks to identify potential vulnerabilities.
  • Staff Training: Educate signers on phishing risks and emphasize the importance of verifying transaction data.

Institutional-Level Security Recommendations

To strengthen the security of institutional multi-signature wallet systems — especially in light of the Bybit hack, which exposed vulnerabilities such as front-end supply chain attacks, blind signing, and unauthorized contract upgrades — the following advanced techniques and strategies are recommended:

1. Enhance Physical Isolation (HSM and FIDO2 Integration)

  • Offline Signing Environment: Perform transaction signing in physically isolated environments to avoid network-based remote attacks (e.g., front-end UI infiltration). Use dedicated HSM devices for key storage and signing, ensuring keys remain offline.
  • FIDO2 Authentication: Combine FIDO2 passwordless authentication with security keys or biometrics to ensure that only authorized users access the signing interface. The FIDO2 challenge-response mechanism prevents replay attacks, thereby enhancing access security.

2. Enhance Technical Architecture (Multi-Signature Mechanism Design)

  • Sharded Private Key Management: Adopt sharded key management (Shamir Secret Sharing) by splitting a single key into multiple fragments (e.g., n fragments, requiring k to sign, where k ≤ n) and storing them in HSM devices across different locations to prevent single-point failures or physical breaches.
  • Context-Aware Signing: Implement context-aware signing to account for transaction context (e.g., callData integrity) and prevent the accidental approval of malicious transactions. Back-end validation of callData against formal interfaces ensures consistency. Embed contextual parameters like timestamps, asset types, and whitelisted addresses, making signatures valid only under predefined conditions.

3. Enhance Monitoring System (On-Chain Detection and Analysis)

  • AI Monitoring and Anomaly Detection: Use AI to monitor transaction patterns in real-time and identify anomalies such as unusual callData, frequent upgrades, large asset transfers, or interactions with high-risk addresses.
  • On-Chain Behavior Analysis Engine: Deploy an on-chain analysis engine with threat intelligence databases and address scoring to assess transaction risks and trigger alerts (e.g., to pre-detect malicious contract deployments).

4. Enhance Operational Workflow (Improved Signing Verification)

  • Semantic Visualization: Develop tools to convert callData into natural language descriptions, highlighting key parameters such as contract address changes or permission modifications to aid signers in understanding transactions and avoiding UI deception.
  • Cross-Chain Feature Matching: Automatically compare current transactions with historical patterns to detect anomalies (e.g., new cross-chain bridge addresses or unauthorized contracts) and to prevent attacks involving newly deployed malicious contracts.
  • Environmental Risk Scoring: Integrate global threat intelligence to dynamically adjust signing risk levels based on network conditions and trigger additional precautions in high-risk scenarios.

5. Enhance Verification Architecture (Hybrid-Layered Verification)

  • Application Layer:

    • Conduct formal verification of smart contracts to ensure that the logic is secure and perform semantic analysis of callData to prevent upgrade manipulations.
    • Deploy detection engine to identify supply chain attacks and UI deception.

  • Physical Layer:

    • Use HSM hardware signing to ensure device integrity through regular checks and tamper-proof encapsulation, thereby preventing physical attacks.
    • Leverage FIDO2 device authentication and challenge-response mechanisms for multi-layer verification, blocking unauthorized access.
    • Integrate HSM with FIDO2 to require dual-layer authentication, reducing social engineering risks.

Conclusion

The Bybit hack exposed the fragility of multi-signature wallet systems to supply chain attacks and blind signing, making digital asset security an industry priority. By adopting multi-layer verification, HSM and FIDO2 integration, and robust software security practices, developers and operators can significantly mitigate such risks. The blockchain industry must learn from this incident and advance secure system designs and operational standards to counter evolving threats. Moreover, adopting advanced prevention techniques — shifting assumptions from "preventing key leaks" to "assuming signing processes are susceptible to compromise" — is crucial to addressing complex attacks.

SecuX, a Web3 security solutions provider, is dedicated to developing and delivering advanced HSM solutions and FIDO2 authentication technologies, offering enterprise-level cryptographic solutions to help clients counter these threats. SecuX's HSM products provide secure key storage and management, while its FIDO2 solution leverages security key technology for passwordless authentication, ensuring Web3 security and operational integrity for digital asset management.

References

Last changed by 
 
Alison Lin
0
150
Published on HackMD