SlowMist: Can Safe Mode be bypassed, and can Guard contract Babeltower be refactored?

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

Original Article Authors: flush & kong, SlowMist Technology

Background

On February 21, 2025, the cryptocurrency industry experienced the most severe asset management crisis in history. The on-chain multi-signature wallet of the exchange Bybit was breached through a targeted attack, and nearly $1.5 billion worth of assets were quietly drained via a "legitimate signature" transaction. Subsequent on-chain analysis revealed that the attacker, through a sophisticated social engineering attack, acquired multi-signature permissions, exploited the delegatecall functionality of the Safe contract to implant malicious logic, ultimately bypassed the multi-signature verification mechanism, and transferred 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 multi-signature wallet, if lacking additional protective measures, still carries the risk of being breached. This is not the first attack case against a Safe multi-signature wallet. Last year, both WazirX (loss of $230 million) and Radiant Capital (loss of $50 million) encountered similar attack methods. As SlowMist pointed out in the analysis of the hacker tactics behind the nearly $1.5 billion theft from Bybit and the associated questions, the Safe multi-signature wallet attack event exhibits the following technical homogeneity:

Over-reliance on Signature Mechanism: Entrusting all security responsibilities to private key custody.

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 during the integration process of the entire system, especially at the front-end validation stage. This prompts us to consider: How can we strengthen the protection capability of multi-signature wallets through Safe's additional security measures?

Safe

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

Core Use Cases

Asset Security Management: The contract requires multiple pre-defined owners to collectively approve a transaction before it can be executed, effectively preventing single-point errors or malicious operations and ensuring fund security.

Transaction Execution and Management: Through its built-in multi-signature validation mechanism, the contract can execute external transfers, interact with other contracts, or handle complex business logic when the signature threshold conditions are met, supporting token and native coin transfers as well as fee compensation.

Modular Expansion: The contract is designed with a modular approach, inheriting and combining multiple management modules (such as OwnerManager, ModuleManager, GuardManager, FallbackManager, etc.), making its functionality flexible and easily extensible to provide customized support for various application scenarios.

Function Breakdown

The execTransaction function executes a transaction that has been verified through multiple signatures:

· Computes the unique hash of the transaction (based on 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 target address's business logic and records the success or failure status through events after transaction execution;

· Supports flexible gas fee handling to accurately calculate transaction costs during fee compensation.

The checkContractSignatures & checkNSignatures functions validate the signature data of a transaction or message:

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

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

The getTransactionHash function generates the transaction hash for signature verification and prevention of replay attacks:

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

· Optimize memory operations using inline assembly to improve computational efficiency;

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

The handlePayment function handles gas reimbursement payment during transaction execution:

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

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

The onBeforeExecTransaction is an internal virtual 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 - Call 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 the transaction execution

· gasPrice: Gas Price - Price used to calculate transaction fee reimbursement gas price

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

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

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

Despite its rigorous security design and flexible modular structure, a multi-signature wallet contract provides an efficient and secure solution for digital asset management, covering end-to-end security control from transaction initialization to final execution. It has become an essential tool for blockchain security management. However, it is also important to note that many victims rely on hardware wallets for signing, and some hardware devices may not display structured data signatures effectively, potentially leading to users being unable to accurately identify transaction data within a short timeframe, thus introducing the risk of "blind signing." To address this issue, in addition to optimizing hardware and its data display, one can explore measures such as increasing multi-factor verification, providing smart prompts, and enhancing signature verification tools to further mitigate the security risks associated with blind signing.

Safe Guard

The Safe contract introduced an important security feature in version 1.3.0 - the Safe Guard mechanism. This mechanism aims to provide additional constraints for the standard n-out-of-m multi-signature scheme to further enhance transaction security. The core value of Safe Guard lies in its ability to perform security checks at different stages of transaction execution:

· Transaction Pre-check (checkTransaction): The Guard mechanism can programmatically inspect all parameters of a transaction before execution to ensure compliance with preset security rules.

· Transaction Post-check (checkAfterExecution): After transaction execution is completed, Guard also conducts additional security validation to verify whether the final state of the Safe wallet after transaction execution meets expectations.

Architecture Analysis

In Safe, multi-signature transactions are typically executed through the execTransaction function. With Safe Guard enabled, when a user executes a multi-signature transaction, the Safe contract will invoke the Guard contract's checkTransaction function to perform a pre-transaction check. After the multi-signature transaction is executed, the Safe contract will call the Guard contract's checkAfterExecution function to examine the transaction's execution result. The specific implementation is as follows:

When a Safe contract performs a multisig transaction pre-check through the Guard mechanism, its checkTransaction function will receive the complete transaction context data, including the target contract address, call 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 control (restricting interactable addresses), function-level permission management (disabling high-risk function selectors), transaction frequency limits, and dynamic rules based on fund flow. By properly configuring Guard policies, attackers can effectively prevent attackers from exploiting non-contract-layer attacks.

Against the backdrop of a series of recent security incidents, various parties are paying increasing attention to the security of multisig wallet contracts. Hardware wallet providers such as KeyStone, OneKey, and RigSec have called for enhancing the resolution and protection capabilities of Safe contracts to prevent similar risks from reoccurring. 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 middleware security solution on top of the Safe multisig wallet, providing additional security for the underlying assets and user assets. Its core function lies in passing the target contract, call method, execution data, owner signature information, payment information, and gas information involved in Safe multisig transactions to the checkTransaction function to achieve ultra-fine-grained transaction checks, including whitelist contract calls, whitelist function operations, whitelist transfer targets, transaction frequency, and other permission controls.

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

Furthermore, by adopting a separate governance mechanism, where the Vault Guardian is responsible for execution and the Governor controls governance permissions, ensures that even if the Guardian encounters issues, remedial measures can be promptly taken to protect user assets. Similar design principles are 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 settings, and validator management through a whitelist mechanism, ensuring that only trusted contracts can be added to the system, providing long-lasting security for wallets.

In the Bybit attack chain, if the Safe contract has deployed a properly configured Guard mechanism, malicious delegatecall initiated by the attacker through execTransaction will be intercepted by a multi-layered defense during the pre-check phase: 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 non-standard contract address (0x4622...7242) and high-risk function selectors. It directly rolls back the transaction through preset contract whitelisting and function blacklisting policies, ultimately forming a "Policy Interception → Logic Block" defense system, thoroughly preventing storage tampering and fund transfer paths.

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

Overall, Safe only provides Guard functionality after version 1.3.0. Although Guard can offer very granular multi-signature transaction checks, users face a significant threshold when using Guard functionality. They need to implement Guard check logic themselves. Rough or flawed Guard implementations may not help users enhance the security of their Safe wallets; hence, a security audit of Guard implementation is necessary. Undoubtedly, a secure and proper Guard implementation can significantly enhance the security of a Safe wallet.

Conclusion and Prospects

The Bybit attack incident highlights the importance of timely updating security infrastructure. Bybit was using the v1.1.1 (<1.3.0) version of the Safe contract, which means they could not utilize the Guard mechanism, a key security feature. If Bybit upgrades to the 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 such losses. Although this is only a hypothesis, it provides important insights for future asset security management.

The Safe Guard mechanism is like an intelligent security check 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: Adjust security policies in real-time based on threat intelligence

· Multi-Layer Defense: Combine various security mechanisms to build a defense-in-depth system

· Continuous Audit: Regularly audit the Guard implementation for security

The future of digital asset management will be a joint evolution of smart contract security mechanisms and continuous offensive and defensive evolution. Only by integrating security principles into every aspect can we build a truly secure defense in the game between the hacker's "spear" and the guardian's "shield."

References

[1] https://github.com/safe-global/safe-smart-account/blob/v1.3.0/CHANGELOG.md

[2] https://docs.safe.global/advanced/smart-account-guards

[3] https://docs.solv.finance/security/solv-guard

[4] https://github.com/safe-global/safe-smart-account/tree/main/contracts/examples/guards

[5] https://github.com/Elytro-eth/soul-wallet-contract/blob/v0.6/contracts/modules/securityControlModule/SecurityControlModule.sol

Original Article Link