DAOrayaki: Analysis of 0xhabitat Multisig being stolen
DAOrayaki DAO Research Bonus Pool:
Funding address: DAOrayaki.eth
DAOrayaki DAO Research Bonus Pool:
Funding address: DAOrayaki.eth
Voting progress: DAO Committee /7 passed
Total bounty: 90 USDC
Original Author: Lukas Schor
Original title: The 0xhabitat Multisig Got Drained: An Analysis
secondary title
Analysis: 0xhabitat Multisig was stolen
A Gnosis Safe user suffered a severe and sophisticated phishing attack that resulted in the project's Multisig being drained.
IMPORTANT: Our current analysis indicates that this was a targeted attack on a specific Gnosis Safe user, and we have no indication that this attack impacted any other users. The attack also did not exploit any smart contract vulnerabilities, but instead used phishing techniques to get Multisig owners to sign malicious transactions.
This blog post aims to shed light on the 0xhabitat incident and detail what has been learned from it. In order to make this incident report completely objective, we only included first-hand data that we collected on-chain and through our backend (transaction indexer). The views of the 0xhabitat team can be read here. First, let's start by analyzing what happened...
trojan horse
The main source of this incident is two malicious contracts that mimic the following official Gnosis Safe smart contracts:
Safe Singleton: This is the core logic contract. Each Safe is a proxy contract pointing to a specific Safe Singleton. Safes can be upgraded by their users to point to a new Singleton, for example to add functionality.
Safe Multisend: This is an intermediary smart contract that enables Safes to combine multiple transactions into one.
In this article, the malicious contracts will be referred to as Evil Singleton and Evil Multisend. The Evil Multisend contract was deployed at this address on November 23rd. The special thing about the contract is that it not only allows batch transactions, but also changes Safe's Singleton in the same transaction. On the same day, Evil Singleton was deployed at this address. Evil Singleton acts as a Trojan horse program that initially forwards all interactions to the original Singleton, but has a backdoor that enables third parties to access Safe.
It's a trap!
The 0xhabitat story begins a few hours after the Evil Multisend contract was deployed. A transaction was proposed in 0xhabitat Multisig interacting with the Evil Multisend contract. To all parties involved it will look like a regular bulk transaction using Transaction builder Safe App. However, this is an elaborate transaction, at first glance, it looks like a normal Multisend transaction, but in fact, it also updates Safe's Singleton to Evil Singleton.
More technical details on activating the Evil Singleton can be found here.
turning point
After Safe upgraded to Evil Singleton, nothing happened for 7 days. Meanwhile, the 0xhabitat vault gradually grew to $1 million worth of digital assets. It's clear that the attackers want the honeypot to get bigger before executing the actual attack, hoping that their backdoor hasn't been discovered before. On November 30, the attack began. The hacker created a transaction that activated the Evil Singleton, allowing the third-party account to take full control of the assets in the safe.
funds drained
Just 30 minutes after Evil Singleton was activated, the attackers were able to withdraw all funds to their accounts. Subsequently, the attacker converted all assets to ETH via Uniswap and Sushiswap. The generated ETH is then sent to the Tornado Cash contract in multiple transactions, which is the end of the path.
So, what exactly happened?
From what we have gathered so far, it is clear that one of the signer keys in Multisig was compromised. This is because the malicious transactions leading to the implementation of the backdoor were proposed by Multisig's signers based on our backend data. While it's impossible to say exactly how this came about, there are two broad categories of events that likely led to it.
Phishing
There are several ways that an owner could be misled into proposing a transaction that would compromise the security of 0xhabitat Multisig. Possible options include:
Rogue browser extensions: Browser extensions are convenient, but they can also be risky. Since extensions are free to modify any content of the web application. As such, a fraudulent browser extension may have been used to modify the Gnosis Safe web interface in order to trick users into making malicious transactions.
Malicious Interfaces: As stated here, the security of Gnosis Safe depends on the integrity of the interfaces used to interact with accounts. Affected 0xhabitat users may have interacted with an interface that mimicked the official Gnosis Safe interface, but effectively created malicious transactions by changing the destination address of regular transactions to the Evil Multisend contract.
Supply chain attack/compromised website: While the source of the issue may have been a hostile takeover of the official Gnosis Safe software, our current assessment suggests this is not the case (more details). All signals point to this being a targeted attack on 0xhabitat Multisig rather than a general issue with the official Gnosis Safe interface. However, we continue to investigate and observe the situation in this area.
malicious owner
The second hypothetical option is that the owner was not tricked into making a malicious transaction, but did so voluntarily. One of the two signers in Multisig tricked the other into signing a fraudulent transaction, causing Multisig to break. 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 as a plausible explanation of events.
Lessons learned from the Gnosis Safe team
Expose the multisend address
To be able to verify which multisend contract was used in the transaction, the Safe Web UI explicitly displays the multisend contract address. Read more.
image description
Transaction details show full Multisend contract address for verification
Prevent decoding unknown multisend transactions
flag unexpected delegate calls
We've added an explicit warning when transactions use delegates to invoke contracts with which we don't know. This is another way we make users aware that transactions require special attention.
image description
Delegate calls made via contracts unknown to Gnosis are flagged
Advice for Gnosis Safe Users
While our goal is to put in place safety mechanisms to prevent such situations from happening in the future, it is also important to remind Gnosis Safe users of operational security practices when interacting with Gnosis Safe.
Verifying Interface Integrity: Malicious interfaces can compromise the entire security of Multisig by tricking co-signers into signing malicious transactions. If you use the Gnosis Safe web application, make sure to bookmark the link to the official application and verify the URL and security certificate. Or better yet, start using the Gnosis Safe Desktop app.
Be careful with DelegateCall: DelegateCall is a powerful tool, for example, it allows Safes to batch transactions. But it also comes with huge risks. Therefore, Gnosis Safe users should take special care when identifying transactions using DelegateCall. When validating transaction data, please verify that the correct Multisend destination address is used. Gnosis-validated Multisend implementations can be found in this list.
image description
in conclusion
in conclusion
References
https://etherscan.io/address/0x3cb0652856d7eabe51f1e3cceda99c93b05d7cea
https://etherscan.io/address/0x09afae029d38b76a330a1bdee84f6e03a4979359
https://bafybeiat2xp7cicrlpq3h57wdnz4pzaoby2cx62c3lprh3lzgrworcitly.ipfs.infura-ipfs.io/Exploit_Info.pdf
https://blog.gnosis.pm/the-impact-of-phishing-on-web-3-0-a62385c81310
https://github.com/gnosis/safe-react/issues/3091
https://github.com/gnosis/safe-react/issues/3090
