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

Event Description

On September 23, the private key of the multi-signature wallet of the UXLINK project was leaked, resulting in the theft of approximately $11.3 million in cryptocurrency assets, which have been dispersed and transferred to multiple centralized (CEX) and decentralized (DEX) exchanges. At the first moment of the attack, we investigated and analyzed the attack together with UXLINK and monitored the flow of funds. UXLINK urgently contacted major exchanges to request the freezing of suspicious funds and has reported the incident to the police and relevant agencies for legal support and asset recovery. Most of the hacker's assets have been marked and frozen by major exchanges, thereby minimizing the further risks faced by the community. The project team has committed to maintaining transparency with the community, and ExVul will continue to analyze and follow up on the progress of the incident.

(https://x.com/UXLINKofficial/status/1970181382107476362)

Latest Developments

During the flow of the hacker's funds, the funds entering the exchanges have been frozen. Through preliminary on-chain tracking, it was discovered that the hacker who previously stole UXLINK assets was suspected to have fallen victim to an Inferno Drainer phishing attack. Upon verification, approximately 542 million $UXLINK tokens that were illegally obtained have been stolen using "authorized phishing" techniques.

Phishing transaction by the hacker: https://arbiscan.io/tx/0xa70674ccc9caa17d6efaf3f6fcbd5dec40011744c18a1057f391a822f11986ee

Unauthorized minting of 1B $UXLINK: https://arbiscan.io/tx/0x2466caf408248d1b6fc6fd9d7ec8eb8d8e70cab52dacff1f94b056c10f253bc2

Attack Analysis

The previous contract had issues with malicious operations or private key leaks from multi-signature owners, leading to the addition of a malicious address as a multi-signature account, while the contract's signature threshold was reset to 1, meaning that only a single account signature was needed to execute contract operations. The hacker set a new owner address to 0x2EF43c1D0c88C071d242B6c2D0430e1751607B87.

(https://arbiscan.io/tx/0x8504a830e7a7a1ca0308a71130efdebddd78b90a1dcc8a64d7c1d86261754689)

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.

(https://arbiscan.io/address/0x7715200141cfd94570bc9d97260ec974ee747972#code)

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

(https://arbiscan.io/address/0x40a2accbd92bca938b02010e17a5b8929b49130d)

In the multiSend function of Safe: Multi Send Call Only 1.3.0, the execution flow callback returned to the removeOwner function of the Gnosis Safe Proxy contract. The specific process was as follows: the attacker first called the MultiSend implementation contract through a delegatecall to the proxy contract, causing it to run multiSend in the context of the proxy contract; subsequently, multiSend called back to the Gnosis Safe Proxy contract itself via call and triggered the removeOwner function, thereby removing the existing owner address.

(https://arbiscan.io/address/0x40a2accbd92bca938b02010e17a5b8929b49130d#code)

The core of the successful call lies in meeting the condition msg.sender== address(this). In the removeOwner function, to prevent external direct calls, the contract sets an authorized verification, which typically requires the caller to be the contract itself (msg.sender == address(this)). Therefore, the removeOwner function will only be successfully executed when the internal process of the contract calls back to itself.

The hacker used the above method to sequentially remove other owners from the multi-signature, undermining the multi-signature mechanism and ultimately taking over the contract.

At this point, the attacker repeatedly executed the above steps, leading to the complete failure of the original multi-signature security mechanism. At this time, a single malicious owner's signature could pass the multi-signature verification, thereby achieving complete control over the contract.

(https://arbiscan.io/txs?a=0x2ef43c1d0c88c071d242b6c2d0430e1751607b87&p=2)

Conclusion

Due to malicious operations or private key leaks from multi-signature owners, the attacker added a malicious address as a multi-signature member and set the signature threshold of the Gnosis Safe Proxy to 1, rendering the original multi-signature security design completely ineffective. Subsequently, a single malicious owner could pass the multi-signature verification. The attacker then gradually removed other owners from the contract, ultimately achieving complete control over the contract and further transferring the contract's assets, maliciously minting $UXLINK tokens on-chain.

This attack event highlights the critical role of multi-signature management in blockchain security. Although the project adopted a Safe multi-signature mechanism and configured multiple multi-signature accounts, the flaws in management ultimately rendered the multi-signature design ineffective. The ExVul team recommends that the project team 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 plays its intended security protective role.