The 0xhabitat Multisig Got Drained: An Analysis
A Gnosis Safe user experienced a severe and sophisticated phishing attack that resulted in the project’s Multisig being drained.
Important: Our current analysis shows that this is a targeted attack on one specific Gnosis Safe user and we have no indication that this attack also affects any other users. The attack also does not make use of any smart contract exploits, but rather used phishing techniques to get Multisig owners to sign malicious transactions.
This blog post aims to shed light on the 0xhabitat incident and elaborate on the learnings. In order for this incidence report to be completely objective, we only included first-hand data we gathered on-chain and via our backend (transaction indexer). The perspective from the 0xhabitat team can be read here. First, let’s start with an analysis of what happened…
The trojan horse
The main source of this incident is two malicious contracts imitating the following official Gnosis Safe smart contracts:
- Safe Singleton: This is the core logic contract. Every Safe is a proxy contract pointing to a specific Safe Singleton. Safes can be upgraded by its users to point to a new Singleton to e.g. add functionality.
- Safe Multisend: This is an intermediary smart contract that enables Safes to batch multiple transactions into one.
For the sake of this article the malicious contracts will be called Evil Singleton and Evil Multisend. The Evil Multisend contract was deployed on November 23rd at this address. The specialty of the contract is that it not only allows to batch transactions, but also changes the Singleton of a Safe in the same transaction. On the same day, the Evil Singleton was deployed at this address. The Evil Singleton acts as a trojan horse, initially forwarding all interactions to the original singleton, but having a backdoor which enables a third-party to gain access to the Safe.
It’s a trap!
The 0xhabitat story begins just a few hours after the Evil Multisend contract was deployed. A transaction was proposed in the 0xhabitat Multisig that interacted with the Evil Multisend contract. To all involved parties it looked just like a regular batched transaction made with the Transaction builder Safe App. However, it was a carefully crafted transaction that, on first sight, looked like a regular Multisend transaction, but in fact, also updated the Safe’s Singleton to the Evil Singleton.
More technical details on the activation of the Evil Singleton can be found here.
Turning point
After the Safe was updated to the Evil Singleton, nothing happened for 7 days. In the meantime, the 0xhabitat treasury gradually grew to $1M worth of digital assets. It is evident that the attacker expected the honeypot to become bigger before they executed the actual attack, hoping that their backdoor was not discovered before. On November 30th, the attack was initiated. A transaction was created by the hacker that activated the Evil Singleton allowing the third-party account to have full control over the assets in the Safe.
Funds are drained
Just 30 minutes after the malicious singleton had been activated, the attacker was able to withdraw all funds to their account. Subsequently, the attacker converted all assets to ETH via Uniswap and Sushiswap. The resulting ETH was then sent via multiple transactions to Tornado Cash contracts, which is where the trail ends.
So, what actually happened?
From the information we have gathered so far, it is evident that one of the signer keys in the Multisig was compromised. This is because the malicious transaction that led to the backdoor implementation was proposed by a signer of the Multisig based on our backend data. While it is not possible to determine exactly how this was achieved, there are two general categories of events that might have led to this.
Phishing
There are several ways the owner could have been misled into proposing the transactions that led to compromising the security of the 0xhabitat Multisig. Possible options include:
- Rogue browser extension: Browser extensions are convenient, but they are also risky. As extensions can freely modify any content of a web application. A fraudulent browser extension could have therefore been used to modify the Gnosis Safe web interface to trick the user into proposing the malicious transactions.
- Malicious interface: As elaborated in this article, the security of Gnosis Safe depends on the integrity of the interface used to interact with the account. The affected 0xhabitat user could have interacted with an interface imitating the official Gnosis Safe interface but effectively creating malicious transactions by changing the target address of a regular transaction to the Evil Multisend contract.
- Supply chain attack / compromised website: While it’s possible that the source of the issue could have been a hostile takeover of official Gnosis Safe software, our current evaluation shows that this was not the case (more details on this). All signals indicate that this was a targeted attack on the 0xhabitat Multisig rather than a widespread issue with the official Gnosis Safe interface. However, we are continuing to investigate and observe the situation in this regard as well.
Malicious owner
The second hypothetical option is that the owner was not tricked into proposing the malicious transactions but rather did so willingly. One of the two signers in the Multisig tricked the other party into signing fraudulent transactions that led to the Multisig being compromised. We have no reason to doubt the integrity of the 0xhabitat team. But to be thorough in our analysis, we still have to consider this being a viable explanation for the incident.
Learnings for the Gnosis Safe team
While we are still analysing this incident, we already took some immediate actions to mitigate similar attacks in the future. All of these changes were implemented as a hotfix.
Expose multisend address
In order to be able to verify which multisend contract is used in a transaction, the Safe Web UI explicitly shows the multisend contract address. See details.
Prevent decoding unknown multisend transactions
We made changes in our decoding mechanism to only decode multisend transactions triggered via the official multisend implementations. This makes it clear when a transaction is interacting with an unknown contract.
Mark unexpected delegate calls
We added an explicit warning when a transaction uses a delegate call with a contract that is unknown to us. This is another way we make users aware that a transaction requires special attention.
Recommendations for Gnosis Safe users
While we aim to build in security mechanisms to prevent such cases from happening in the future, it is also important to remind Gnosis Safe users of the best practices in terms of operational security when interacting with Gnosis Safe.
- Validate the interface integrity: A malicious interface can compromise the entire security of a Multisig by tricking co-signers into signing malicious transactions. If you use the Gnosis Safe web application, make sure to bookmark the link of the official app and validate the URL and security certificates. Or even better, start using the Gnosis Safe Desktop application.
- Don’t just trust one information-source: We strongly recommend using an additional independent client/interface to check every transaction in detail. For example, use the Gnosis Safe mobile application to double-check transactions before signing. This can prevent a single compromised interface to trick users into signing malicious transactions.
- Be careful with DelegateCall: DelegateCall is a powerful tool, which allows Safes to batch transactions, for example. But this also comes with significant risks. So when identifying a transaction that makes use of DelegateCall, Gnosis Safe users should be especially attentive. When validating transaction data, verify the correct Multisend target address is used. The Gnosis-verified Multisend implementations can be found in this list.
- Reduce the use of browser extensions: While convenient, browser extensions can become critical attack vectors that can even trick the most advanced users. We generally recommend not using any browser extensions with the browser used to interact with the Gnosis Safe web application.
Conclusion
It is core to our mission to build the right tools for individuals and organisations to stay safe in Web3. This is why we were sorry to hear about the 0xhabitat team funds being compromised. We wish the team and community all the best recovering from this unfortunate situation and hope the attacker will eventually be identified and funds being returned.
