Bybit Hack Onchain Analysis

[zlog-in]

Safe Hack

Safe is a smart contract that enables multisig transactions for EVM chains.

A Safe wallet is composed of a proxy contract and its implementation contract, usually named Singleton. A Singleton is shared by all generated Safe proxy contracts.

The implementation address is stored in the first storage slot of the Proxy contract, referred to as masterCopy in version v1.1.1, and its published address is 0x34CfAC646f301356fAa8B21e94227e3583Fe3F5F
The Safe wallet (0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4) hacked is version v1.1.1

A Safe wallet is controlled by the code implemented in the Singleton contract. The hacker has maliciously changed the masterCopy storage slot of the proxy contract to take over the Safe wallet.

Let's dive into how the hacker achieved this.

1. Hacker knew that Bybit will execute a safe transaction to transfer some kind of ERC20 token
2. Hacker deployed a malicious contract A (0x96221423681A6d52E184D440a8eFCEbB105C7242) with the interface transfer(address,uint256), which code can update the first storage slot to the value of address parameter
3. Hacker deployed a malicious contract B (0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516) with the ability to control the Safe proxy
4. Hacker gained access to tamper the Safe transaction data of the three signers
5. Hacker submitted the Safe transaction signed by the three signers and took over the Safe wallet
6. Hacker got the assets from the Safe wallet

Here, we need to know how the Safe transaction is defined

{
  "to": "0x96221423681A6d52E184D440a8eFCEbB105C7242",
  "value": "0",
  "method": "transfer(address,uint256)",
  "params": [
  "0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516",
  "0"
  ],
  "operation": 1
}

• to: the target contract that the Safe wallet will call
• method: the function signature will be called on the target contract
• params: the parameters that will be input to the called method
• operation: 0 is Call, 1 is DelegateCall, DelegateCall means that the to contract is able to change the storage of the Safe wallet!!!

First, hacker has replaced the to parameter with the address of the malicious contract A, so that the Safe wallet will call the transfer(address,uint256) function on the malicious contract A.

Then, hacker passed the address of the malicious contract B as the first parameter of the transfer(address,uint256) function.

And, the hacker changed the operation parameter to 1, so that the malicious contract A can change the storage of the Safe proxy!!!

Finally, the hacker submitted the Safe transaction signed by the three signers and took over the Safe wallet.

As the decoded transaction data (tx: 0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882) shows, the attack transaction was encoded with operation=1 and to=0x96221423681A6d52E184D440a8eFCEbB105C7242 and method=transfer(address,uint256) and params=["0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516","0"].

And we can see that the masterCopy storage slot of the Safe proxy contract was changed from 0x34CfAC646f301356fAa8B21e94227e3583Fe3F5F to 0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516 by the malicious contract A.

What happed on chain is clear now, the rest of the story is to find how the hacker compromised the Safe transaction of on three devices and how could we prevent this from happening again.

[zlog-in]

Hi all, I've opened an issue to explain how the Safe wallet of Bybit is hacked on chain. I want to confirm with the community that Safe wallet itself is safe! But the signing process has quite high risk.

[yanboishere]

agree

[aiacobelli2]

https://blog.openzeppelin.com/backdooring-gnosis-safe-multisig-wallets ?

[mmv08]

Thanks for your analysis. According to the initial investigation, there is no issue with the implementation of the smart contract. The investigation is still ongoing, and a detailed post-mortem will follow.