UXLINK Hack: Approximately $11.3 Million Stolen - Technical Analysis

Original Title: "UXLINK Theft of Approximately $11.3 Million - Technical Analysis"

Event Description

On September 23, the UXLINK project's multi-signature wallet private key was compromised, resulting in the theft of approximately $11.3 million worth of cryptocurrency assets, which were subsequently transferred to various centralized (CEX) and decentralized (DEX) exchanges. Immediately upon the attack, we collaborated with UXLINK to investigate and analyze the incident and monitored the fund flows. UXLINK promptly contacted major exchanges to request the freezing of suspicious funds, filed a report with law enforcement and relevant authorities to seek legal support and asset recovery. Most of the hacker's assets have been frozen by major exchanges, minimizing further risks to the community. The project team has committed to maintaining transparency with the community, and ExVul will continue to analyze and follow up on the incident.

Latest Developments

During the hacker's fund movement, the funds deposited into exchanges have been frozen. Through initial on-chain tracking, it was discovered that the hacker who previously stole UXLINK assets fell victim to an Inferno Drainer phishing attack. Upon verification, approximately 542 million $UXLINK tokens, illegally obtained by the hacker, were stolen using an "authorized phishing" technique.

Hacker's Phishing Transaction:

Unauthorized Mint of 1B $UXLINK:

Attack Analysis

1. The previous contract suffered from a malicious operation by a multi-sign Owner or a private key leak, leading to the addition of a malicious address as a multi-sign account. Simultaneously, the contract's signature threshold was reset to 1, requiring only a single account signature to execute contract operations. The hacker set a new Owner address to 0x2EF43c1D0c88C071d242B6c2D0430e1751607B87.

2. The attacker first calls the execTransaction function in the Gnosis Safe Proxy contract. This function serves as the entry point to maliciously remove a multisig member, and all subsequent malicious operations are executed within this transaction.

3. When calling execTransaction, the attacker specified a malicious operation in its data parameter: invoking the Safe: Multi Send Call Only 1.3.0 implementation contract via delegatecall.

4. In the multiSend function of Safe: Multi Send Call Only 1.3.0, the execution flow is routed back to the Gnosis Safe Proxy contract's removeOwner. The process is as follows: the attacker first invoked the MultiSend implementation contract via delegatecall on the proxy contract, causing it to run multiSend within the context of the proxy contract; subsequently, based on the parameters constructed by the attacker, multiSend callbacked to the Gnosis Safe Proxy contract itself via a call and triggered the removeOwner function, thus removing an existing Owner address.

5. The key to a successful call is to meet the condition msg.sender == address(this). In the removeOwner function, to prevent direct external calls, the contract has an authorized check, where the internal logic typically requires the caller to be the contract itself (msg.sender == address(this)). Therefore, the removeOwner function will only be executed successfully when the contract's internal process callback itself.

6. The hacker used the above method to systematically remove other Owners from the multisig, undermining the multisig mechanism and eventually taking over the contract.

7. At this point, the attacker, by continuously repeating the above steps, rendered the original multisig security mechanism completely ineffective. At this stage, solely with the signature of a single malicious Owner, the multisig validation could be bypassed, thereby gaining full control of the contract.

Summary

Due to malicious actions or private key compromises of multisig Owners, the attacker added a malicious address as a multisig member and set the signature threshold of the Gnosis Safe Proxy to 1, rendering the original multisig security design completely ineffective. Subsequently, a single malicious Owner could bypass the multisig validation. The attacker then gradually removed other Owners from the contract, eventually gaining full control of the contract, further transferring the contract's assets, and maliciously minting $UXLINK tokens on-chain.

This attack incident highlights the critical role of multisig management in blockchain security. Despite the project's use of the Safe multisig mechanism and configuration of multiple multisig accounts, due to flaws in the management approach, the multisig design was ultimately rendered moot. The ExVul team suggests that project teams should strive for decentralization in multisig management, such as having different members each safeguard a private key and adopting diversified private key storage methods to ensure that the multisig mechanism truly provides the intended security protection.

Appendix

The following are suspected hacker addresses tracked on-chain by the ExVul team: