Cobo Security Team: Analysis of the WazirX Stolen Coin Incident

The Cobo security team conducted a detailed analysis of the recent attack on the Indian cryptocurrency exchange WazirX, and shared how Cobo helps customers defend against cyber attacks from the aspects of risk control mechanisms and security systems.

1 Overview of the incident

On July 18, 2024, more than $230 million was stolen from a multi-signature wallet of the Indian cryptocurrency exchange WazirX. The multi-signature wallet was a Safe{Wallet} smart contract wallet. The attacker induced the multi-signature signer to sign a contract upgrade transaction. The attacker directly transferred the assets in the wallet through the upgraded contract, and eventually transferred out all the assets of more than $230 million.

2 Analysis of the attack process

Note: The following analysis is based on WazirX and Liminal post-event reports, on-chain data, and public information on the Internet. There may be incomplete information or errors, which may lead to deviations in the analysis conclusions. The analysis results are for reference only, and the specific results are subject to the subsequent investigation results of the manufacturers involved.

Original link:

• WazirX Blog：https://wazirx.com/blog/wazirx-cyber-attack-key-insights-and-learnings/

• Liminal Custody Blog：https://www.liminalcustody.com/blog/update-on-wazirx-incident/

2.1 Multi-signature wallet configuration and attack process

According to the information disclosed by both parties, WazirX uses Safe (formerly known as Gnosis Safe)  Funds are managed and co-managed by Liminal. The Safe wallet uses a 4/6 signature method, of which 5 private keys are managed by WazirX members through hardware wallets, and 1 private key is managed by Liminal through HSM.

Under normal procedures, WazirX initiates transaction transfers through the Liminal platform's webpage, and the transfer address is restricted by the address whitelist maintained by the Liminal platform. After 3 of the 5 signers of WazirX confirm that the transaction is correct, they sign with a hardware wallet. After the Liminal platform collects 3 signatures, it uses HSM to add the final signature and puts the transaction on the chain. From the on-chain attack transaction, it can be seen that the attack transaction does contain 3 legitimate signatures, and the 4th signature is the transaction initiator (ie Liminal), which is consistent with the disclosed wallet management architecture.

Combined with the reports from Liminal and WazirX, the process of initiating this malicious multi-signature transaction is as follows:

1. The attacker induced WazirX to sign the transaction through some unknown means (including but not limited to 0-day network attacks, social engineering attacks, etc.).

2. Three members of WazirX logged into the Liminal platform through bookmarks, etc., and after passing Google verification and MFA verification, they found that the transactions to be signed were 2 GALA and 1 USDT transfer transactions, and signed them using a hardware wallet. However, the content signed by the victim was not a token transfer transaction, but a contract upgrade transaction of a multi-signature wallet. Since the actual transaction content was inconsistent with the claimed transfer transaction, the Liminal platform rejected the three transactions respectively.

3. So far, the attacker has collected the signatures of 3 members for the contract upgrade transaction, and submitted a malicious contract upgrade transaction to the Liminal platform again, with 3 correct signatures.

4.  After the Liminal platform checked the signatures and found them to be correct, it initiated the transaction as the fourth signer. After the transaction was uploaded to the chain, the wallet contract was upgraded and the control was transferred to the attacker.

According to WazirX's description, the signers use hardware wallets to keep private keys. The attacker also collected the signatures of the 3 signers by forging transfer transactions. Therefore, it is inferred that the 3 WazirX managers did not have any private key leaks. Similarly, Liminal did not have any private key leaks, otherwise the attacker would not have to initiate the last transaction through the Liminal platform. On the other hand, according to WazirX's description, the signer accessed the correct Liminal platform through a bookmark and performed Google and MFA verification. The Liminal platform also recorded the logs of three abnormal transactions, so it can also be ruled out that WazirX logged into the fake Liminal platform phishing page and collected signatures. In addition, according to the preliminary forensics results of the device disclosed by WazirX, it is also believed that the devices of the three WazirX signatories were not attacked. In summary, one possible attack method is that the attacker hijacked the browser front-end page of the WazirX victim through a man-in-the-middle attack, XSS attack or other zero-day attack, and forged and displayed legitimate transaction content to the WazirX victim. After collecting the signatures of the three WazirX victims, the attacker submitted the final contract upgrade attack transaction to the Liminal platform through the existing session, and successfully uploaded it to the chain after passing the risk control of the Liminal platform.

2.2 Problems exposed by the attack incident

Based on the above analysis, both WazirX and Liminal exposed certain problems in the incident.

Liminal platform risk control is not strict:

• From the attack transaction on the final chain, it can be seen that the Liminal platform signed and uploaded the contract upgrade transaction. The platform's whitelist transfer risk control strategy did not play its due role.

• It can be seen from the logs disclosed by the Liminal platform that the platform has discovered and rejected three suspicious transactions, but did not immediately warn users or freeze wallet transfer transactions.

WazirX did not carefully check the signature content of the hardware wallet:

• The content displayed in the hardware wallet is the real transaction content to be signed. When signing the multi-signature transaction, the WazirX signer trusted the transaction displayed on the Liminal page, and did not carefully check whether the content to be signed by the hardware wallet was consistent with the transaction displayed on the Liminal page, and directly signed, providing the signature of the contract upgrade transaction required by the attacker.

3 How Cobo helps customers resist cyber attacks

3.1 Perfect risk control mechanism

Cobo provides a variety of risk control mechanisms to address the security challenges encountered in storing, managing and transferring digital assets. Depending on the type of wallet, Cobo's risk control engine allows customers to run independent risk control programs or on-chain risk control contracts. Even if Cobo suffers a security attack, the risk control checks on the client side and on the chain can still ensure the safety of user funds.

Customers can flexibly set up on-chain and off-chain transaction risk control, business risk control, user roles and permissions as needed, and configure the required risk control and permission rules for different business types:

1. Transaction risk control: Customers can easily create and edit on-chain and off-chain transaction risk control, and automatically process each transaction by setting approval actions (including automatic approval, automatic rejection and multi-person approval).

2. Business risk control: Customers can define approval rules for various platform management operations (such as deleting team members or freezing team accounts).

3. User Roles and Permissions: Customers can assign specific user roles to designated team members. Currently, Cobo Portal provides five preset roles - Observer, Withdrawer, Approver, Operator and Administrator. Customers can also create other roles based on their business needs.

3.1.1 Transaction Risk Control

Customers can easily set up and edit off-chain and on-chain transaction risk control.

• Off-chain transaction risk control is managed by Cobo Portal's back-end system. Cobo's risk control engine can perform fine-grained inspection and control of token transfers and contract calls according to user-configured rules to ensure that the transaction content meets the user's restrictions. It is worth mentioning that for MPC wallets, we support the deployment of custom risk control programs (called Callback) on MPC-TSS signer nodes. This risk control program is independent of Cobo and is deployed on the customer's own MPC-TSS node. Risk control at this location can provide customers with a last line of defense in the extreme case of Cobo being attacked. In the scenario in this case, if the WazirX signer is an MPC-TSS node with Callback protection, the attacker cannot collect signatures for unexpected transactions.

• On-chain transaction risk control is managed through smart contracts on the blockchain network. We support the configuration of risk control rules on smart contract wallets through the Cobo Safe framework, including the configuration of on-chain transfer whitelists, which makes it difficult for attackers to damage the on-chain whitelist mechanism. In the scenario in this case, if the Cobo Safe on-chain transfer whitelist mechanism is used, the attacker will not be able to initiate any transactions outside the whitelist.

3.1.2 Business Risk Control

Customers can set business risk control to define the number of team members required to approve certain actions (such as deleting team members, modifying member roles, freezing team accounts). Depending on the operation, the default requirement is at least 50% of the administrators to approve or only one of the administrators to approve. Customers can also manually edit rules to set automatic approval, automatic rejection, or approval thresholds.

For more information about business risk control, please see the business risk control introduction: https://cobo-6.mintlify.app/cn/portal/organization/governance-intro.

3.1.3 User roles and permissions

User roles consist of a predefined set of rules that can be used to assign specific permissions to designated members within a team. Cobo provides five preset roles, and customers can create other roles based on specific needs.

For more information about user roles and permissions, please see the User Roles and Permissions Introduction: https://cobo-6.mintlify.app/cn/portal/organization/roles-and-permissions.

3.2 Providing security technical support to customers

Cobo provides 24/7 customer service support. If you encounter any security issues, customers can give us feedback as soon as possible, and we will do our best to assist every customer in troubleshooting security risks.

4 Cobo Security System

In response to the two possible causes of this theft: phishing and system vulnerabilities, Cobo has set up comprehensive security protection measures in multiple dimensions such as the company's overall network construction, employee terminals, and transaction processes to deal with various forms of attacks and prevent similar security incidents from happening.

4.1 Secure and Diversified Wallet Technology

Cobo Portal integrates four wallet technologies into a single platform, providing the most advanced security architecture, and its chain and token coverage is the widest in the industry (refer to the fully managed wallet and MPC wallet to understand the tokens and chains supported by Cobo Portal).

• Fully Custodial Wallet: https://manuals.cobo.com/cn/portal/supported-tokens-custodial

• MPC Wallet: https://manuals.cobo.com/cn/portal/supported-tokens-mpc

• Fully Custodial Wallet: The fully custodial wallet uses advanced encryption technology and risk control engines to protect customers' funds from unauthorized access and potential attacks. It adopts a robust three-tier (hot-warm-cold) private key storage architecture, with 95% of funds securely stored in cold wallets and only 5% of funds stored in hot and warm wallets.

• MPC Wallet: Multi-party computation (MPC) is an advanced cryptographic technology for blockchain private key management. Cobo Portal provides two types of MPC wallets: institutional wallets, which allow institutions to have full control over their own funds or the assets of their end users; and end-user wallets, which allow end users to have full control over their digital assets.

• Smart Contract Wallet: This type of wallet supports a variety of smart contract wallets, mainly including Safe{Wallet} and other account abstraction smart wallets. It also supports the flexibility of delegating external account (EOA) wallets to seamlessly interact with the smart contract ecosystem.

• Exchange Wallet: The Exchange Wallet is a one-stop solution for easily managing multiple exchange accounts. It centralizes all exchange accounts in a single user-friendly interface, allowing for seamless viewing, monitoring and management of assets across exchanges.

4.2 Cobo Guard - Multi-functional iOS security application

Cobo Guard is a multi-functional iOS security application independently developed by Cobo, designed to enhance the transmission security of digital assets. It uses asymmetric encryption technology to protect assets and can act as a transaction approval tool and MPC private key sharding manager. At the same time, Cobo Guard supports multi-factor authentication (MFA) as Cobo Accounts and provides a password-free login mechanism.

• Cobo Guard generates a unique public and private key pair for each user, ensuring that your bound applications have a strong security infrastructure.

• The user's public key is shared with Cobo, while the private key is securely stored in the native Secure Enclave of your iPhone. This setup ensures that all operation approvals are signed with your private key and authenticated using the public key you share with Cobo.

• Easily authorize requests using state-of-the-art biometric authentication technologies such as fingerprint scanning, Face ID, or device PIN code, thereby enhancing the integrity of the authentication process.

• After binding Cobo Guard, each withdrawal and payment transaction requires a second confirmation within Cobo Guard. This additional layer of security significantly improves transaction protection and reduces the risk of unauthorized access.

• Cobo Guard can display user-friendly transaction analysis content during the transaction review process to facilitate auditors' judgment.

4.3 Phishing

Phishing has become one of the common means used by attackers due to its low cost, easy implementation, and the ability to obtain significant benefits at a relatively low cost. Cobo is well aware of the dangers of phishing and has taken the following measures to address this threat:

• Use leading terminal security protection products to monitor and respond to potential threats in real time

• Use hardware keys to protect terminal security

• Detailed division of permissions, any permission requires application

• Conduct internal phishing drills regularly to enhance employees' security awareness

4.4 Targeting network attacks

Cobo always remains highly vigilant against network attacks and implements comprehensive security measures to ensure the efficient resilience of the system and comprehensive protection against potential threats. Based on comprehensive protection measures, we have maintained a perfect record of "zero security incidents" since we started operations in 2017, and our security system is indestructible.

• Implement 7×24 monitoring and maintenance to ensure the system runs stably around the clock

• Regularly conduct full penetration testing and code audits for business systems

• Regularly conduct internal and external attack and defense drills

• Perform penetration testing every six months through well-known security vendors, and no security issues have been found

• Cobo infrastructure currently has 200+ security policies and conducts regular security inspections

• Has the ability to resist DDOS and block common security vulnerabilities

• ISO-27001 and SOC 2 type 2 compliant