UXLINK was stolen approximately 11.3 million dollars technical analysis

Event Description

On September 23, the private key of the UXLINK project's multi-signature wallet was leaked, resulting in the theft of approximately $11.3 million in cryptocurrency, which has been dispersed and transferred to multiple centralized (CEX) and decentralized (DEX) exchanges. At the moment of the attack, we collaborated with UXLINK to investigate and analyze the attack while monitoring 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 authorities 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. Preliminary on-chain tracking has revealed that the hacker who previously stole UXLINK assets is 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 an "authorized phishing" technique.

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

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

Attack Analysis

1. The previous contract had malicious operations or private key leaks among multi-signature Owners, resulting in a malicious address being added 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)

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.

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

3. 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)

4. 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 using call with parameters constructed by the attacker, triggering the removeOwner function and thus removing the existing Owner address.

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

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

6. The hacker used the above method to sequentially remove other Owners from the multi-signature, undermining the multi-signature mechanism and ultimately taking control of the contract.

7. At this point, the attacker repeatedly executed the above steps, causing the original multi-signature security mechanism to become completely ineffective. At this time, a single malicious Owner's signature was sufficient to pass the multi-signature verification, thus achieving complete control over the contract.

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

Conclusion

Due to malicious operations or private key leaks among multi-signature Owners, the attacker added a malicious address as a multi-signature member and set the signature threshold of 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 incident 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 the management approach 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 provides the intended security protection.

Appendix

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