Original Article Title: "SlowMist Analysis | Safe Paradox, Can Guard Reconstruct the Contract Babel Tower?"

Original Article Author: flush & kong, SlowMist Technology

Background

On February 21, 2025, the cryptocurrency industry experienced its most severe asset management crisis in history. The on-chain multisig wallet of the exchange platform Bybit was breached through a targeted attack, and nearly $1.5 billion in assets were quietly drained through a transaction with a "legitimate signature." Subsequent on-chain analysis revealed that the attacker, through sophisticated social engineering, obtained multisig permissions, exploited the delegatecall feature of the Safe contract to implant malicious logic, ultimately bypassing the multisig verification mechanism and transferring the funds to an anonymous address.

This event exposed a harsh reality: "multisig" does not equal "absolute security." Even a security mechanism like the Safe multisig wallet is still at risk of being breached if it lacks additional protective measures. This is not the first attack case targeting Safe multisig wallets. Last year, both WazirX (loss of $230 million) and Radiant Capital (loss of $50 million) fell victim to similar attack methods. As SlowMist analyzed in the article "The Hacker Techniques and Questions Behind the Theft of Nearly $1.5 Billion from Bybit," the attack on Bybit's nearly $1.5 billion theft shares the following technical similarity with other Safe multisig wallet attacks:

Overreliance on Signature Mechanism: Entrusting all security responsibilities to private key management.

Lack of Dynamic Defense: Absence of real-time risk scanning before transaction execution.

Coarse-Grained Permission Control: Failure to establish a whitelist mechanism for high-risk operations like delegatecall.

(Bybit Theft Process: Using Safe v1.1.1)

The core issue of this series of events lies not in the Safe contract itself, but in the security vulnerabilities in the entire system integration process, especially in the front-end validation phase. This prompts us to consider: How can we strengthen the protection capability of a multisig wallet through additional security measures in Safe?

Safe

Safe is a multi-signature (Multi-Sig) wallet mainly used for the secure storage and transfer of high-value assets and cryptocurrencies. As a decentralized asset management infrastructure, it ensures the security of fund operations through a multi-party collaborative verification mechanism, guarding against malicious operations by a single administrator or hacker exploiting a single point of failure. It is widely used in scenarios such as DAO governance, corporate fund custody, and decentralized fund pools. The contract is developed by the Safe (formerly Gnosis Safe) team and is the industry standard on-chain asset management solution. The contract adopts the EIP-712 standard to implement structured data signatures, thereby enhancing the security and verifiability of transaction data.

Core Use Cases

Fund Security Management: The contract requires multiple pre-set owners to jointly confirm transactions for execution, effectively preventing single-point errors or malicious operations and ensuring fund security.

Transaction Execution and Management: Through its built-in multisig verification mechanism, the contract can execute external transfers, call other contracts, or handle complex business logic when meeting the signature threshold conditions, supporting token and native coin payments and fee reimbursement.

Modular Extension: The contract adopts a modular design, inheriting and combining multiple management modules (such as OwnerManager, ModuleManager, GuardManager, FallbackManager, etc.), making its functionality flexible and easy to extend, providing custom support for different application scenarios.

Function Breakdown

The execTransaction function executes a multisig-validated transaction:

· Computes the unique hash of the transaction (combining transaction parameters, nonce, etc.);

· Validates the authenticity of all signatures, ensuring each signature comes from a legitimate owner or a pre-approved address;

· Calls the business logic of the target address and records the success or failure status through events after transaction execution;

· Supports flexible gas fee handling, ensuring accurate calculation of transaction costs during fee reimbursement.

The checkContractSignatures and checkNSignatures functions verify the signature data of a transaction or message:

· Handle EOA account signature, contract signature (EIP-1271), and pre-approved hash separately;

· Ensure that signatures are ordered by owner and each signature is from a valid address to prevent replay attacks and signature tampering.

The getTransactionHash function generates the transaction hash for signature verification and to prevent replay attacks:

· Structure hash of transaction data using the EIP-712 standard;

· Utilize inline assembly to optimize memory operations and improve computational efficiency;

· Include the current nonce value to ensure uniqueness of each transaction.

The handlePayment function manages gas compensation payment during transaction execution:

· Calculate the payment amount based on the actual gas consumed and the base fee;

· Support payment in ETH and other tokens to ensure accurate fee compensation.

The onBeforeExecTransaction is an internal pre-hook function called before the execution of the execTransaction function. The design purpose of this function is to allow subcontracts inheriting the Safe contract to perform custom logic before transaction execution. The received parameter set includes:

· to: Target Address - Address of the contract or account the transaction is to call

· value: Ether Value - Amount of Ether sent with the transaction

· data: Payload Data - Transaction data containing the function selector and parameters

· operation: Operation Type - Determines whether it is a CALL or DELEGATECALL

· safeTxGas: Transaction Gas Limit - Amount of gas reserved for transaction execution

· baseGas: Base Gas - Gas cost independent of transaction execution

· gasPrice: Gas Price - Price of gas used to calculate transaction fee compensation

· gasToken: Gas Token - The token address used to pay for transaction fees

· refundReceiver: Refund Receiver - The address that receives the transaction fee reimbursement

· signatures: Signatures - The collection of signatures from owners on the transaction

While multi-signature wallet contracts have provided an efficient and secure solution for digital asset management through their rigorous security design and flexible modular structure, offering end-to-end secure control from transaction initiation to final execution and becoming a key tool in blockchain security management, it is essential to note that most victims rely on hardware wallets for signing. However, some hardware devices may not display structured data signatures effectively, leading to users being unable to accurately identify transaction data within a short timeframe, resulting in a risk of "blind signing." To address this phenomenon, in addition to optimizing hardware and its data display, measures such as enhancing hardware wallets for structured data signatures, exploring increased multi-factor authentication, providing intelligent prompts, and improving signature verification tools can further mitigate the security risks associated with blind signing.

Safe Guard

The Safe contract introduced a critical security feature in version 1.3.0 called the Safe Guard mechanism. This mechanism aims to provide additional constraints to the standard n-out-of-m multisig scheme, further enhancing transaction security. The core value of Safe Guard lies in its ability to perform security checks at different stages of transaction execution:

· Pre-transaction check (checkTransaction): The Guard mechanism can programmatically check all transaction parameters before transaction execution to ensure the transaction complies with predefined security rules.

· Post-execution check (checkAfterExecution): After the transaction execution is completed, the Guard performs additional security validation to verify if the final state of the Safe wallet aligns with expectations.

Architecture Analysis

In Safe, multi-signature transactions are typically executed through the execTransaction function. When Safe Guard is enabled, during the execution of a multi-signature transaction by a user, the Safe contract will call the Guard contract's checkTransaction function to conduct a pre-transaction check on all transaction parameters. Additionally, after the completion of the multi-signature transaction, the Safe contract will invoke the Guard contract's checkAfterExecution function to examine the outcome of the transaction execution. The specific implementation is as follows:

When a Safe contract performs a multi-signature transaction pre-check through the Guard mechanism, its checkTransaction function will receive the complete transaction context data, including the target contract address, invocation method, execution data (such as delegatecall), owner signature information, Gas configuration, and payment information.

This mechanism allows developers to implement multi-dimensional risk control strategies, such as contract whitelist controls (restricting interactable addresses), function-level permission management (disabling high-risk function selectors), transaction rate limiting, and dynamic rules based on fund flow. By appropriately configuring Guard policies, attackers can effectively block attacks that occur outside the contract layer.

Against the backdrop of a series of recent security incidents, various parties are increasingly concerned about the security of multi-signature wallet contracts. Hardware wallet providers such as KeyStone, OneKey, RigSec, and others have called for enhancing the parsing and protection capabilities of Safe contracts to prevent similar risks from occurring again. After the Bybit incident, many projects have begun to focus on Safe contracts and explore upgrade and expansion solutions based on the Guard mechanism.

Among them, there are innovative applications based on the Guard mechanism, building a security solution layer on top of the Safe multi-signature wallet, providing additional security for underlying assets and user assets. Its core function lies in passing the target contract, invocation method, execution data, owner signature information, payment information, and gas information involved in a Safe multi-signature transaction into the checkTransaction function to achieve extremely granular transaction checks, including whitelist contract calls, whitelist function operations, whitelist transfer targets, transaction frequency permissions, and more.

It is worth noting that Safe itself only provides Guard management and callback functions, and the actual multi-signature transaction check logic is implemented by the user. Its security depends on the quality of the Guard implementation. For example, Solv Guardian extends this idea by configuring a specific Guardian for each Vault to specify allowed target addresses and operation permissions, achieving the three main elements of permission control: specifying allowed contracts, defining allowed function operations, and ACL verification requirements.

Additionally, using a separate governance mechanism, managed by the Vault Guardian for execution and Governor for governing permissions, ensures that even if the Guardian encounters issues, remedial measures can be promptly taken to protect user assets. A similar design philosophy is also applied in Elytro's SecurityControlModule, where the module intercepts critical operations through the preExecute function and finely controls high-risk operations such as module installation, hook setting, and validator management using a whitelist mechanism, ensuring that only trusted contracts can be added to the system, providing long-lasting security for wallets.

In the Bybit exploit chain event, if the Safe contract has deployed a properly configured Guard mechanism, the malicious delegatecall initiated by the attacker through execTransaction will be intercepted by a multi-step policy in the pre-check stage: The Guard's checkTransaction function first identifies the delegatecall operation type and triggers disable rules (such as enforcing the operation to be a regular call only), then parses the data field to detect unconventional contract addresses (0x4622...7242) and high-risk function selectors, rolling back the transaction directly through preset contract whitelisting and function blacklisting policies, ultimately forming a "Policy Interception → Logic Blockade" defense system, completely blocking storage tampering and fund transfer paths.

(When using Safe version ≥ v1.3.0  Safe Guard module verification operation https://excalidraw.com/#room=fd1df67dd09b3dab6bd8,Q1jeb1MZW7vwbY4NuxaV5A)

Overall, Safe only provides Guard functionality after version 1.3.0. Although Guard can offer a very granular multisig transaction check, users face a significant barrier when using the Guard feature. They need to implement Guard check logic themselves, and a rough or flawed Guard implementation may not help users enhance the security of their Safe wallets. Therefore, it is necessary to conduct a security audit of Guard implementations. Undoubtedly, a secure and adequate Guard implementation can greatly enhance the security of Safe wallets.

Conclusion and Outlook

The Bybit attack incident highlighted the importance of timely updating security infrastructure. Bybit was using a v1.1.1 (<1.3.0) version of the Safe contract, which means they were unable to utilize the Guard mechanism, a key security feature. If Bybit upgrades to a 1.3.0 or higher version of the Safe contract and implements a proper Guard mechanism, such as specifying a whitelist address that can receive funds and conducting strict contract function ACL verification, they may be able to avoid this kind of loss. Although this is only a hypothesis, it provides an important insight for future asset security management.

The Safe Guard mechanism is like a smart security screening system added to a digital asset safe, and its effectiveness depends on the precision of rule design and implementation quality. Faced with increasingly sophisticated attack methods, we need:

· Automated Verification: Establish an automated transaction verification mechanism

· Dynamic Policy Adjustment: Real-time adjustment of security policies based on threat intelligence

· Multi-layer Defense: Combine multiple security mechanisms to build a defense-in-depth system

· Continuous Audit: Regular security audits of the Guard implementation

The future of digital asset management will be a joint evolution of smart contract security mechanisms and continuous attack and defense evolution. Only by integrating security concepts into every aspect can we build a truly secure defense in the battle between hackers' "spear" and guardians' "shield".

Original Article Link