Technical Analysis of UXLINK Theft Involving Approximately $11.3 Million

Original Title: "Technical Analysis of UXLINK Theft of Approximately $11.3 Million"
Original Source: ExVul Security

Event Description

On September 23, the private key of UXLINK project's multi-signature wallet was leaked, resulting in the theft of approximately $11.3 million worth of cryptocurrency assets, which have since been dispersed and transferred to multiple centralized (CEX) and decentralized (DEX) exchanges. Immediately after the attack, we worked with UXLINK to investigate and analyze the incident and monitored the flow of funds. UXLINK urgently contacted major exchanges to request the freezing of suspicious funds and has reported the case to the police and relevant authorities to seek legal support and asset recovery. Most of the hacker's assets have been marked and frozen by major exchanges, thereby minimizing further risks to the community. The project team has promised to maintain transparency with the community, and ExVul will continue to analyze and follow up on the progress of the incident.

()

Latest Developments

During the flow of hacker funds, assets transferred into exchanges have been frozen. Preliminary on-chain tracking revealed that the hacker who previously stole UXLINK assets appears to have fallen victim to an Inferno Drainer phishing attack. Upon verification, approximately 542 million $UXLINK tokens illegally obtained by the hacker have been stolen through an "authorization phishing" technique.

Attack Analysis

1. Previously, due to malicious operations or private key leakage by a multi-signature Owner, a malicious address was added as a multi-signature account, and the contract's signature threshold was reset to 1, meaning only a single account signature was required to execute contract operations. The hacker set a new Owner address as 0x2EF43c1D0c88C071d242B6c2D0430e1751607B87.

()

2. The attacker first called the execTransaction function in the Gnosis Safe Proxy contract. This function became the entry point for maliciously removing multi-signature members, and all subsequent malicious operations were executed internally 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 redirected to the removeOwner function of the Gnosis Safe Proxy contract. Specifically, the attacker first invoked the MultiSend implementation contract via delegatecall executed on the proxy contract, causing it to run multiSend in the context of the proxy contract; then, multiSend, according to parameters constructed by the attacker, calls back the Gnosis Safe Proxy contract itself via call and triggers the removeOwner function, thereby removing the existing Owner address.

()

5. The core of a successful call lies in satisfying the condition msg.sender == address(this). In the removeOwner function, to prevent direct external calls, the contract sets up authorized verification, whose internal logic usually requires the caller to be the contract itself (msg.sender == address(this)). Therefore, only when the contract's internal process calls itself can removeOwner be successfully executed.

6. The hacker used the above method to remove other Owners in the multi-signature one by one, breaking the multi-signature mechanism and ultimately taking over the contract.

7. At this point, the attacker repeatedly executed the above steps, causing the original multi-signature security mechanism to completely fail. Now, a single malicious Owner's signature alone could pass multi-signature verification, thus achieving full control over the contract.

()

Summary

Due to malicious operations or private key leakage by a multi-signature Owner, the attacker added a malicious address as a multi-signature member and set the signature threshold of the Gnosis Safe Proxy to 1, causing the original multi-signature security design to completely fail. After that, a single malicious Owner could pass multi-signature verification. The attacker then gradually removed other Owners from the contract, ultimately achieving full control over the contract and further transferring contract assets, as well as maliciously minting $UXLINK tokens on-chain.

This attack highlights the critical role of multi-signature management in blockchain security. Although the project adopted the Safe multi-signature mechanism and configured multiple multi-signature accounts, flaws in management ultimately rendered the multi-signature design ineffective. The ExVul team recommends that project teams strive for decentralization in multi-signature management, such as having different members separately hold private keys and adopting diversified private key storage methods, to ensure that the multi-signature mechanism truly provides the intended security protection.

Appendix

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