Comment by rkagerer
4 months ago
There's some info and speculation in these two (distinct) articles, but I'd love to know technical details of where the gaffs were.
eg. Was client software compromised? Did the multisig keyholders succumb to social engineering? Were the signers using airgapped machines / hardware devices?
https://blockworks.co/news/bybit-hack-raises-security-questi...
Here is what the CEO wrote on X:
"Bybit ETH multisig cold wallet just made a transfer to our warm wallet about 1 hr ago. It appears that this specific transaction was musked, all the signers saw the musked UI which showed the correct address and the URL was from @safe . However the signing message was to change the smart contract logic of our ETH cold wallet. This resulted Hacker took control of the specific ETH cold wallet we signed and transfered all ETH in the cold wallet to this unidentified address."
[yes, it says 'musked', assuming they meant masked. @safe is https://safe.global/wallet]
Unfortunately most hardware wallets can't interpret EVM smart contract transactions and asks you to sign a big binary blob that is supposed to match what you see on your computer screen (it's literally called blind signing). He said in the tweet and later on a live stream that they verified that the URL was correct, and there were several signers in different locations on different machines.
Logically the UI must have been manipulated for all of them, which I can think of a few different ways to do:
- The signing link was replaced somehow over whatever medium they sent it to each other, pointing to something that either looks like the original UI (perhaps IDN homograph domain) or is the actual site if it has some weakness that allows script injection to manipulate the page
- The server side was exploited to serve a manipulated page
- Client side malware that injects something in the browser to manipulate the page
- Some kind of network/DNS attack combined with mis-issued TLS certificate (or injected CA)
It points to some level of sophistication and long-term observation of their internal systems to know what the process looks like and devising an attack.
Will be interesting to read when/if they release a full analysis.
They could have used a hardware wallet like the Lattice1 from GridPlus, which actually shows the function parameters on a big screen instead of blind signing.
Oh, when I read this yesterday I assumed "musked" was a clever play on the idea that someone is tricked into agreeing to things against their interests.
Is it possible that this was an inside job?
One of the links says the following:
> According to crypto security firm Groom Lake, a Safe multisig wallet was deployed on Ethereum in 2019 and on the Base layer-2 in 2024 with identical transaction hashes. Ethereum’s alphanumeric transaction hashes are 64 characters long, so deploying the same smart contract transaction hash twice should be mathematically impossible.
> The same transaction hash appearing on both Ethereum and Base indicates an attacker could have found a way to make a single transaction valid on more than one network or could be reusing crypto wallet signatures or transaction data across networks, pseudonymous Groom Lake researcher Apollo said.
The quote is incorrect. If I deploy the same smart contract to two different EVM chains, from the same wallet, with the same nonce (pretend it's the first transactions I'm doing with this wallet on each chain, so nonce 0), then the transaction hash will be the same on both chains. That's not odd.
1 reply →
Are we sure he didn't mean the transaction got DOGEd?
A huge problem with signing EVM transactions using hardware wallets is that is common to be blind signing messages. The device has no knowledge of the SAFE EVM contract functions or any other context, it just asks you to sign an gobblygook opaque binary message so you may have no idea what's being signed, is my experience using multiple different vendor HW wallets. Not sure if that's what happened, but possible this type of problem contributed to the exploit. BTC TXs are simple enough that all HW wallets can basically display what's happening, but with turing-complete arbitrary computations in EVM this becomes very difficult.
In almost all cases EVM smart contract interaction looks like a function call which can be easily decoded into JSON if you know ABI.
HW wallet doesn't need to understand the contract logic, it just needs ABI, which is generally a simpler task. Also it can show the name of function you're calling as selector is a hash of a name.
Safe is a bit more complex as it also wraps it in EIP-712 message, but that can also be decoded in a systematic way.
> with turing-complete arbitrary computations in EVM this becomes very difficult.
I have very limited knowledge about EVM, but those computations are bounded by gas, right? Evaluating them is a finite process.
Yes, each opcode has a gas cost. Some are quite expensive, like writing storage (changing network state). Each block has a target gas limit. Say 30 million. A single transaction cannot exceed that. Additionally, a transaction specifies a bid on how much they are willing to spend, in ether, per gas. That said, transferring funds does not typically require significant gas.
What you suggest is possible (evaluate the side effects of the transaction and present that information to the prospective signer). But at present they don't do that. I'm not sure about this specific case but often it's just a supplied text string (that can say anything) that's displayed. Basically the system depends on trust in whatever came up with the transaction payload.
1 reply →
But the space of their effects on the Blockchain state is vast. You need software to translate those effects to a form human can interpret as "what I want"/"not what I want".
Ie. engineering work needs to happen in the UI they used to confirm the tx
Thanks for spelling this out, the explanation makes a lot of sense.
You'd think they could at least show a blockie representing the contract, or reputational party who cryptographically vouched for it.
Sometimes you have the right contract, but an attacker is making you pass in different parameters than you think. The most popular hardware wallets don't help you with this; the Ledger Nano S for example just alerts you that you're passing some kind of data to the contract, so you're relying on your computer to show the details. This is a problem when, for example, you're interacting with a token or wallet contract, and you think you're telling it to transfer $ to Alice, but actually it's $$$$ to Bob.
But there are better options with larger screens, which actually display contract parameters on the secure device.
https://x.com/tayvano_/status/1847877011462901915 This thread has some info about very similar past attacks, should give some insights into the level of sophistication that goes into something like that.
This was interesting, thanks!