From the Bybit theft incident, examining the systemic issues of the entire multi-signature mechanism process and the overall solution of New Fire MPC.

CN
6 hours ago

Source: SINOHOPE

Overview of the Bybit Theft Incident

On February 21, 2025, a Safe multi-signature wallet of the cryptocurrency exchange Bybit was hacked, resulting in the theft of approximately $1.5 billion worth of crypto assets, making it the largest theft in crypto history. In this attack, although the Safe multi-signature wallet contract itself was not compromised, the usage process was still attacked. The participants in the multi-signature process lacked sufficient security awareness and reliable independent verification mechanisms, allowing hackers to alter the signature content and completely deceive multiple (three) signers, ultimately gaining control of the multi-signature wallet through malicious transactions.

Similar attacks on Safe multi-signature wallets have occurred before the Bybit incident, including:

  • On July 18, 2024, the Safe multi-signature wallet of the Indian exchange WazirX was attacked, with the logic contract altered, resulting in stolen funds of approximately $230 million.

  • On October 16, 2024, the Safe multi-signature wallet of the lending protocol Radiant Capital was attacked, with approximately $50 million stolen.

Since the development of the crypto industry, security issues arising from smart contracts have received significant attention from industry practitioners. However, recent incidents of hacking and theft indicate that wallet security remains a concern. The Bybit theft incident and similar occurrences in the industry have highlighted significant vulnerabilities in wallet security: during the daily management of funds/permissions, there are systemic issues under the seemingly secure multi-signature wallet mechanism, and wallet security needs to be given sufficient attention across the industry.

Analysis of the Hacking Process

According to the latest investigation report, the process and key points of the Bybit attack are as follows:

  • The attacker deployed a malicious contract (0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516) in advance at UTC 2025-02-19 7:15:23;

  • A developer's computer device with system publishing permissions for Safe{Wallet} was compromised. The attacker uploaded a modified JavaScript code file containing malicious logic to Safe's AWS S3 bucket at UTC 2025-02-19 15:29:43, targeting Bybit's Ethereum Safe wallet and an unknown wallet (presumably for the attacker's testing and verification), thus completing the intrusion of the Safe{wallet} front-end interface.

  • On February 21, 2025, during a normal cold and hot fund allocation process, all Safe{wallet} users saw and used a front-end that had been implanted with malicious code. Therefore, Bybit multi-signature participants saw the Safe{Wallet} front-end interface displaying information that appeared completely normal (but the actual signature content did not match the front-end display);

  • Signers used Ledger hardware wallets, but the signing process with Ledger is blind signing, meaning signers could not verify whether the content to be signed matched the information displayed on the Safe{Wallet} front-end.

  • The attacker successfully deceived all signing participants, obtaining the required (three) signatures; the malicious transaction was constructed to call the malicious contract using DelegateCall, mimicking an ERC20 transfer function; this malicious function completed an "upgrade" of the wallet contract, changing the logic implementation contract to the attacker's pre-deployed malicious contract.

  • After the malicious transaction was completed, the attacker re-uploaded a normal script file within two minutes, clearing the malicious script file.

  • Subsequently, the attacker gained complete control of the multi-signature wallet, absconding with nearly $1.5 billion worth of crypto assets.

Remaining doubts in this process include:

  • What is the front-end system publishing process for Safe{wallet}?

  • Why could a single developer change the code file hosted in cloud storage without submitting it to the source code repository?

Weaknesses Exposed by the Bybit Theft Incident

Security Risks in DeFi System Front-Ends

All DeFi applications theoretically allow anyone to create transactions and interact directly with on-chain smart contracts. However, in reality, this is an impossible task for the vast majority of users! Therefore, all DeFi applications inevitably require front-end systems to construct transactions or EIP-712 data to be signed. If the same set of smart contracts does not have multiple independent front-end systems supporting them, then the front-end system of the DeFi application becomes a significant single point of risk.

Security Risks of Operating Devices

The direct cause of the Bybit incident was the compromise of a developer's computer device with system publishing permissions for Safe{Wallet}, highlighting the eternal existence of traditional security risks. Since Web3 practitioners may directly involve the security of on-chain funds, the highest level of attention should be given to preventing traditional cybersecurity risks. All technical systems and management processes in the Web3 field should be considered and implemented according to financial-grade security levels.

Security Weaknesses of Safe Multi-Signature Contracts

Safe multi-signature contracts only provide one execution entry: execTransaction, which offers two execution methods: Call and DelegateCall. For batch transactions, the Safe contract itself does not directly open a batch execution entry but implements the logic for batch transactions using other contracts, such as the MultiSendCallOnly contract. Therefore, when constructing batch contracts, it is necessary to create a transaction that calls the external contract using DelegateCall, executing the transaction splitting and individual execution logic of the external contract.

In normal business scenarios, DelegateCall should only be executed when the target address (to address) is the MultiSendCallOnly contract.

However, this mechanism of Safe leaves security vulnerabilities in its daily use. Most users may lack sufficient knowledge, skills, and awareness to perform independent and complete verification during usage.

In fact, the three known large-scale attacks on Safe wallets have all exploited this mechanism, with attackers successfully using the DelegateCall execution method to make the Safe wallet execute malicious logic.

Systemic Issues of the Multi-Signature Mechanism from the Bybit Theft Incident and SINOHOPE's Overall Solution

WazirX:

https://etherscan.io/tx/0x48164d3adbab78c2cb9876f6e17f88e321097fcd14cadd57556866e4ef3e185d

Systemic Issues of the Multi-Signature Mechanism from the Bybit Theft Incident and SINOHOPE's Overall Solution

Bybit:

https://etherscan.io/tx/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882

Some Hardware Wallets Have Blind Signing Risks

The ability of wallet applications to decode transaction data to be signed is a very important capability. Some wallets focused on Web3 on-chain interactions have developed certain transaction parsing capabilities and are continuously enhancing them. However, currently, hardware wallets (such as the Ledger hardware wallet used by Bybit in this incident) generally lack this capability, leading users to only perform blind signing, losing the opportunity to verify transaction content one last time.

The transaction parsing capability of wallets requires substantial and timely updated data support (such as the ABI database in the EVM-compatible chain field) and the ability to recognize and customize common specific transaction types. This places high demands on the continuous updating and iteration of wallets.

Independent Verification Awareness of Multi-Signature Participants Needs Strengthening

To avoid the single point risk and private key leakage risk associated with single signatures, the industry has generally shifted towards the use of multi-signature wallets. However, if multi-signature participants lack independent verification awareness, capability, and necessary tools during usage, and primarily rely on the security and reliability of the transaction initiator, then the multi-signature wallet loses its intended purpose.

SINOHOPE's Security Practices

Principles of Crypto Fund Security

To ensure the security of crypto funds, a comprehensive and multi-dimensional mechanism must be established in terms of security awareness, security technology systems, and security standards. In response to the Bybit incident and similar events, SINOHOPE emphasizes that users need to enhance some basic security awareness.

(1) Traditional Security Reinforcement Recommendations

Web3 organizations and personnel should possess financial-grade security awareness and take practical measures to prevent traditional security risks.

Use Dedicated Devices:

  • Equip dedicated independent devices for important purposes, avoiding mixing with daily office equipment, and do not use them unless necessary.

  • Use operating systems with higher security, such as Linux or the latest versions of macOS/Windows, and remove unnecessary services and ports.

Enhance the Security of Office Network Devices and Implement Traditional Security Measures:

  • Terminal/office environment security remains a top priority in defending against APT groups like Lazurus. Ensure that terminals have EDR tools installed (traditional antivirus software is limited in dealing with APTs);

  • Strengthen access control and defense in depth for internal systems. Access to sensitive internal systems and important operations must undergo additional two-factor authentication, such as for internal code repository management and cloud platform management;

  • Manage permissions for cloud service providers like CDN/AWS effectively. Ensure that console logins minimize the number of personnel, minimize permissions, and minimize access time. Avoid using root accounts and admin privilege accounts by default. Prioritize using IAM roles and avoid using ak/sk access methods. If necessary, enable key rotation and add access address whitelists;

  • Conduct integrity checks on publicly accessible resources, such as public SDKs, client installation packages, and static resources cached by CDNs (CloudFront-S3/CloudFlare-R2, etc.), simulating user scenarios for regular checks;

  • Perform additional integrity checks for each code release to ensure that the online environment code matches the internally security-reviewed code;

  • Strengthen monitoring of access to internal/vendor systems to promptly detect abnormal access behaviors at unusual times and investigate and confirm them in a timely manner;

Ensure comprehensive security capabilities for key personnel's terminal devices.

(2) Basic Principles for Wallet Usage

Isolation Principle

  • Cold and hot isolation

  • Purpose isolation: Strictly separate fund wallets from permission wallets. Fund wallets should only hold funds and have transfer functionality. It is strongly recommended to use dedicated fund wallet solutions rather than multi-signature contracts like Safe for purely fund wallets. Only consider multi-signature contract wallets when the wallet needs to serve as management permissions for on-chain contracts or participate in DeFi applications.

  • Device isolation: Key asset devices should be isolated separately, avoiding the use of daily computers/work computers, and should not be activated unless necessary.

Avoid single point risks, independent verification by multiple parties

Independent Risk Control System

  • Whitelist control

  • Independent risk control review

  • Transaction simulation execution

Sufficient capability principle, minimum permissions principle: Minimize risk exposure as much as possible

Cold Wallet Solution Recommendations

(1) Enterprise-level Fund Management Solution Based on MPC Technology

For wallets that only require fund management, using a multi-signature wallet solution with the potential risk of "executing arbitrary logic" in smart contracts may not be the optimal choice.

For "cold wallets" that only require fund management (without the need to participate in DeFi interactions), the SINOHOPE enterprise-level MPC wallet solution can be adopted, serving as an alternative to Safe multi-signature. For institutional clients with specific needs, SINOHOPE can also provide technical solutions to support clients in achieving private deployment of the MPC solution.

MPC-TSS (Multi-Party Computation-Threshold Signature Scheme) technology supports distributed management of private key shards and collaborative signing, addressing single point risks of private keys and enabling secure self-custody.

Compared to multi-signature smart contract solutions available only on EVM-compatible chains, the MPC-based solution retains all the advantages of the Safe multi-signature solution while also offering additional benefits not present in Safe multi-signature, such as multi-chain compatibility, better independent auditing, and elimination of the potential risk of "executing arbitrary logic." The characteristics of the SINOHOPE MPC solution are summarized as follows:

More autonomy than centralized custody

  • Autonomous control of assets, free from "misappropriation" and "runaway"

  • Supports T-N multi-signature, avoiding single point risks

  • Supports multi-level asset management for enterprises

Safer and more comprehensive than decentralized wallets

  • Multi-party management of private key shards, eliminating traditional private key custody risks

  • No need to manage "invisible" private keys, avoiding mnemonic phrases

  • Multi-level disaster recovery plans and multi-scenario shard recovery mechanisms

More convenient and user-friendly than hardware wallets

  • Shards can be networked, "0" storage difficulty

  • Web2 product form, easy to master

Cheaper and more versatile than contract wallets

  • Address creation incurs no gas costs, low transaction fees

  • Supports most mainstream blockchains

  • Multi-chain multi-signature, protecting privacy

For pure fund management needs, it can better achieve business auditing and risk control, eliminating the potential risk of "executing arbitrary logic."

Can be enhanced with dedicated mobile device measures, with devices online only during transaction audits, further strengthening security.

The capabilities and advantages of MPC-TSS technology, combined with years of accumulated online account systems, multi-factor authentication systems, and biometric technologies, can effectively help users eliminate private key mnemonics, preventing theft, loss, and malicious actions, ensuring users maintain control over their assets.

(2) SINOHOPE's Signature Verification Solution for Safe{wallet} Multi-Signature

In the Web3 field, in addition to cold wallets for pure fund management needs, there are also needs for on-chain permission management and participation in DeFi interactions. For such needs, on-chain multi-signature solutions represented by Safe{wallet} are undoubtedly still one of the optimal solutions available today. However, the Bybit incident has also exposed multiple weaknesses in the usage of Safe{Wallet} multi-signature, particularly the reliance on a single front-end system and the blind signing risks associated with hardware wallets.

To address the potential risks present in the usage of Safe{wallet}, SINOHOPE has launched a signature verification solution for Safe{Wallet} multi-signature, introducing an independent signature content verification mechanism combined with enterprise-level approval flows and risk control mechanisms to fill the security gaps in the hardware wallet + Safe{Wallet} multi-signature solution.

The independent verification solution of SINOHOPE's MPC wallet includes:

  • For signature requests to Safe{Wallet}, enable independent risk control verification strategies; based on the industry ABI database and targeted processing of Safe contracts, independently parse the content to be signed and its execution intent, providing timely warnings for risky operations (such as unexpected DelegateCall calls).

  • Integrate transaction simulation execution capabilities, allowing for simulated transaction execution before signing, identifying operational intent, and presenting operational intent and potential risks in a user-friendly manner to avoid blind signing risks.

  • Can integrate enterprise-level approval flows, establishing dedicated approval flows and risk control strategies for multi-signature wallets participating in the management of MPC wallet accounts, meeting more flexible and diverse fund management needs.

Systemic Issues of the Multi-Signature Mechanism from the Bybit Theft Incident and SINOHOPE's Overall Solution

By using SINOHOPE's MPC wallet as part of the Signer members for Safe{Wallet}, an independent security enhancement layer can be introduced into the current Safe{Wallet} multi-signature wallet application system, providing a beneficial supplement to the existing usage solution. Since the SINOHOPE MPC wallet itself is a self-custody wallet and can hold a single signing authority solely by the SINOHOPE MPC wallet, clients always maintain ultimate control over their Safe wallet/assets.

Through the signature verification service of the SINOHOPE MPC wallet, the security of clients using Safe{Wallet} can be significantly enhanced, effectively reducing the independent verification skill requirements for users and lowering the independent verification burden on users. This is more conducive to institutional clients to closely align with business needs and reasonably allocate multi-signature participant roles (such as boss, business, finance, security, etc.) while ensuring that each participant has the conditions to implement independent audit verification, truly achieving the purpose of Safe{Wallet} to "prevent single point risks and achieve multi-party verification."

Conclusion: Wallet Security Initiative in the Web3 Industry

Promote Unified Security Standards in the Industry and Build a Trustworthy Web3 Ecosystem Together

In today's rapidly developing Web3 ecosystem, wallets serve as the core and entry point for user asset management, making their security crucial. However, the lack of unified security standards in the industry leads to users facing different security risks when using different wallets.

SINOHOPE advocates:

  • Establishing industry-wide security standards—building an industry security forum to collaboratively develop best security practice norms covering industry R&D, daily management, user usage, etc., and creating interoperability standards for ecological applications/security components to jointly ensure the long-term security of the industry.

  • Enhancing user security awareness—improving industry users' risk awareness and prevention capabilities through standardized security education.

  • Strengthening cross-ecosystem collaboration—promoting information sharing and emergency response mechanisms among industries to jointly address security threats.

Security is the cornerstone for the stable and long-term development of the cryptocurrency industry. We call on developers, wallet service providers, auditing institutions, and communities to work together to promote the construction of security standardization and create a safer trading environment for users!

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

Share To
APP

X

Telegram

Facebook

Reddit

CopyLink