Author: flush & kong

Background

On February 21, 2025, the cryptocurrency industry suffered the worst in history asset management crisis. The multi-signed wallet on the chain of the trading platform Bybit was targeted, and nearly US$1.5 billion of assets were quietly lost through a "legitimate signature" transaction. Post-chain analysis shows that the attacker obtained multi-signature permissions through sophisticated social engineering attacks, and used the delegatecall function of the Safe contract to implant malicious logic, and finally bypassed the multi-signature verification mechanism and transferred funds to anonymous addresses.

This incident exposed a cruel reality: "multi-signature" does not mean "absolute "Safe's security mechanism like the multiple-sign wallet, if there is a lack of additional protection measures, there is still a risk of being broken. This is not the first attack case against Safe's multiple sign-up wallets. WazirX (loss $230 million) and Radiant Capital (loss $50 million) both encountered similar attacks last year. Just like the analysis of the Hackers and Questions behind the stolen $1.5 billion by Bybit, the Safe multi-signment wallet attack showed the following technical homology:

Overdependence on signature mechanism: hand over security responsibilities to the private key for custody.

Disappearance of dynamic defense: lack of real-time risk scanning before transaction execution.

Permission control coarse-grained size: no whitelisting mechanism is established for high-risk operations such as delegatecall.

(Bybit Theft Process: Use Safe v1. 1.1)

The core problem of this series of events is not the Safe contract itself, but the security risks in the integration process of the entire system, especially in front-end verification link. This prompts us to think about: How to strengthen the protection capabilities of multi-signment wallets through Safe's additional security measures mechanism?

Safe

Safe is a multi-signature (Multi-Sig) wallet, mainly used to manage the secure storage and transfer of high-value assets and digital currencies. As the infrastructure for decentralized asset management, it collaborates through multiple parties The verification mechanism ensures the security of fund operations and prevents a single administrator or hacker from using a single point of failure to perform malicious operations. It is widely used in DAO governance, enterprise fund custody, decentralized fund pool and other scenarios. This contract is made by Safe (formerly Gnosis Safe) Team development is the current industry standard on-chain asset management solution. The contract uses the EIP-712 standard to implement structured data signatures, thereby improving the security and verifiability of transaction data.

Core uses

Fund Security Management: The contract requires multiple pre-set owners (Owners) Only by jointly confirming the transaction can it be executed, thereby effectively preventing single-point errors or malicious operations and ensuring the safety of funds.

Transaction execution and management: Through the built-in multi-sign verification mechanism, A contract can perform external transfers, call other contracts or handle complex business logic when the signature threshold condition is met, and supports payment and fee compensation for tokens and native coins.

Modular expansion: The contract adopts a modular design, and by inheriting and combining multiple management modules (such as OwnerManager, ModuleManager, GuardManager, FallbackManager, etc.), it makes its functions flexible and easy to expand, providing customized support for different application scenarios. .

Function parsing

execTransaction function executes transactions that have been verified by multiple signatures:

calculates the unique hash value of the transaction (combined with transaction parameters, nonce, etc.);

Verify the validity of all signatures to ensure that each signature comes from a legal owner or a pre-approved address;

Call the business logic of the target address and record the successful or failed status through the event after the transaction is executed;

< p style="text-align: left;">Supports flexible gas fee processing to ensure accurate calculation of transaction costs when compensation is paid.

checkContractSignatures & checkNSignatures function verify the signature data of transactions or messages:

process EOA account signatures, contract signatures (EIP-1271), and Pre-approved hash;

Ensure that signatures are arranged in owner order and that each signature comes from a valid address to prevent replay Attack and signature tampering.

getTransactionHash function generates transaction hash for signature verification and preventing replay attacks:

Use the EIP-712 standard to structured hash transaction data;

Use inline assembly to optimize memory operations, Improve computing efficiency;

Combining the current nonce value, ensure the uniqueness of each transaction.

< /p>

handlePayment function handles gas compensation payment during the execution of transactions:

according to actual consumption of gas Calculate payment amounts for fees and basic expenses;

Supports payment of ETH and other tokens to ensure accurate fee compensation.

onBeforeExecTransaction is an internal virtual hook function. Called before the execTransaction function is executed. This function is designed to allow subcontracts inheriting Safe contracts to be customized logical processing before the transaction is executed. The received parameter set includes:

to: target address - the contract or account address to be called for the transaction

value: ether value - sent with the transaction Ether Coins Number

data: Data load - Call data containing function selector and parameters

operation: Operation type - OK is CALL or DELEGATECALL

safeTxGas: Transaction gas limit - the number of gas reserved for transaction execution

baseGas: base gas - gas cost independent of transaction execution

gasPrice: gas price - gas used to calculate transaction fee compensation Price

gasToken: gas token - the token address used to pay transaction fees

refundReceiver: Refund Receiver - Address to receive transaction fee compensation

signatures: Signature set - owner's signature data for transactions

Although the multiple wallet contracts rely on their rigorous security design and flexible modular structure, they provide an efficient and secure solution for digital asset management, realizing the full process of security control from transaction initialization to final execution, and It has become an important tool for blockchain security management, but it should also be noted that most victims rely on hardware wallets for signatures, while some hardware devices have poor display of structured data signatures, which can easily lead to users being unable to accurately in a short period of time. Identify transaction data, thus posing a risk of "blind signing". In view of this phenomenon, in addition to optimizing the hardware and its data display effect, measures such as adding multiple confirmations, smart prompts, and enhancing signature verification tools can also be explored to further reduce blind signing The security risks brought about.

Safe Guard

The important security function introduced by the Safe contract in version 1.3.0 - Safe Guard mechanism. This mechanism is designed to provide additional restrictions for the standard n-out-of-m multi-sign scheme to further enhance transaction security. The core value of Safe Guard is the ability to perform security checks at different stages of transaction execution.Check:

checkTransaction: The Guard mechanism can programmatically check all parameters of the transaction before the transaction is executed to ensure that the transaction complies with the preset Safety rules.

checkAfterExecution: After the transaction is executed, Guard will perform additional security verification to check the transaction execution. Whether the final status of the Safe wallet is as expected.

Structure Analysis

In Safe, multiple transactions are generally Execute through the execTransaction function. When Safe Guard is enabled, when the user executes a multi-sign transaction, the Safe contract will call the checkTransaction function of the Guard contract to perform a pre-transaction check. When the multi-sign transaction execution is completed, the Safe contract will call the checkAfterExecution function of the Guard contract to perform a transaction. Check the execution results. The specific implementation is as follows:

When the Safe contract performs a multi-sign transaction pre-check through the Guard mechanism , its checkTransaction function will receive 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 enables developers to implement multi-dimensional risk control strategies, such as contract whitelist control (restriction of interactive addresses), function-level permission management (disable high-risk function selectors), transaction frequency restrictions, and dynamic rules based on capital flow. By rationally configuring Guard policies, attackers can be effectively blocked from attacking at the non-contract level.

In the context of recent constant exposure of security incidents, all parties are increasingly concerned about the security of multiple wallet contracts, hardware wallet providers such as KeyStone, OneKey, RigSec and others have called for enhanced analysis and protection capabilities of Safe contracts to prevent similar risks from happening again. After the Bybit incident, many project parties began to focus on Safe contracts and explore upgrades and expansion solutions based on the Guard mechanism. Among them, there are many basicBased on the innovative application of the Guard mechanism, an intermediate layer security solution built on Safe multi-signment wallet is built, providing additional security guarantees between the underlying assets and user assets. Its core function is to pass the target contract, call method, execution data, owner signature information, payment information and gas information involved in Safe multi-sign transactions into the checkTransaction function, which can achieve extremely fine-grained checks on transactions, including whitelist contract calls. , whitelist function operation, whitelist transfer target, transaction frequency and other permission control.

It is worth noting that Safe itself only provides Guard management and callback functions. The actual multi-sign transaction checking logic is implemented by the user, and its security depends on Guard Quality of achievement. For example: Solv Guardian has expanded this idea and configured a special Guardian in each Vault to specify the allowed target address and operation permissions, realizing three permission control elements: specifying the allow contract, defining the allowable function operation, and ACL verification requirements. At the same time, a separate governance mechanism is adopted, and Vault Guardian is responsible for the implementation, while Governor controls governance authority to ensure that even if Guardian has problems, remedial measures can be taken to protect user assets in a timely manner. Similar design concepts are also applied in Elytro's SecurityControlModule, which intercepts key operations through the preExecute function and uses the whitelisting mechanism to finely control high-risk operations such as module installation, hook settings, and validator management, so as to ensure that only trust is done. The contract can be added to the system, providing lasting security for the wallet.

In the Bybit event attack chain, if the Safe contract deploys a reasonably configured Guard mechanism, the malicious delegatecall initiated by the attacker through execTransaction will be multiple times during the pre-flight stage. Policy Intercept: Guard's checkTransaction function first recognizes the delegatecall operation type and triggers the disable rule (such as forcing operation to be a normal call only), and then parsing the data field to detect the unconventional contract address (0x4622...7242) and the high-risk function selector , directly roll back the transaction through the preset contract whitelist and function blacklist strategy, and finally form a defense system of "strategy interception → logic blocking", completely blocking the storage tampering and fund transfer paths.

/p>

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

In general, Safe only provides Guard functionality after version 1.3.0. Although Guard can provide extremely fine-grained multi-sign transaction checks, users are using it Guard has a large threshold when it comes to functioning. They need to implement Guard check logic by themselves. A rough or flawed Guard implementation may not help users improve the security of their Safe wallets, so it is necessary to conduct a security audit of Guard implementations. There is no doubt that a secure and proper Guard implementation can greatly improve the security of your Safe wallet.

Conclusion and Outlook

Bybit's attacks highlight the importance of timely updates of security infrastructure. Bybit uses v1.1.1 (<1.3.0) version Safe contracts, which means they cannot use the key security feature of the Guard mechanism. If Bybit is upgraded to a Safe contract of 1.3.0 or later and implements a suitable Guard mechanism, such as specifying a whitelist address that receives funds and performing strict contract function ACL verification, this loss may be avoided. . Although this is just a hypothesis, it provides important ideas for future asset security management.

Safe Guard mechanism is like an intelligent security inspection system installed on digital asset safes. Its effectiveness depends on the rigor of rule design and the quality of implementation. 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: Combining multiple security mechanisms to build a deep defense system

Continuous audit: conduct regular security audits on Guard implementation

The future digital asset management will be a co-evolution process of smart contract security mechanism and continuous offensive and defense evolution. Only by integrating security concepts into every link can we build a real security barrier in the game between the "spear" of the hacker and the "shield" of the guardian.