Five hours ago, an attacker stole 2 million BNB (~$566M USD) from the Binance Bridge. During that time, I've been working closely with multiple parties to triage and resolve this issue. Here's how it all went down.
Post
Post
samczsun on X: "In summary, there was a bug in the way that the Binance Bridge verified proofs which could have allowed attackers to forge arbitrary messages. Fortunately, the attacker here only forged two messages, but the damage could have been far worse"
It all started when
@zachxbtsent me the attacker's address out of the blue. When I clicked into it, I saw an account worth hundreds of millions of dollars. Either someone had pulled off a huge rug, or there was a massive hack underway
At first, I thought that
@VenusProtocolhad been hacked yet again. However, it only took a couple seconds to determine that the attacker *really did* deposit over $200M USD into Venus Instead, I needed to figure out where those funds came from
The answer was that the attacker had somehow convinced the Binance Bridge to simply send them 1,000,000 BNB. Twice.
Either Binance was finally running the biggest giveaway that Web3 had ever seen, or the attacker had found a critical bug
I started by comparing the attacker's transactions with legitimate withdrawals. The first thing I noticed was that the height used by the attacker was always the same - 110217401. The heights used by legitimate withdrawals were much bigger, such as 270822321
I also noticed that the attacker's proof was significantly shorter than the legitimate withdrawal's proof. These two facts led me to believe that the attacker had found a way to forge a proof for that specific block - 110217401. Now I had to figure out how these proofs worked
On Binance, there's a special precompile contract used to verify IAVL trees. If you don't know anything about IAVL trees, don't worry. I still don't understand about 95% of it. Fortunately, all you and I need to reproduce the hack is the remaining 5%
Ok, so basically, when you verify an IAVL tree, you specify a list of "operations". The Binance Bridge typically expects two of them: an "iavl:v" operation, and a "multistore" operation. Here are their implementations github.com/cosmos/iavl/bl… github.com/bnb-chain/bsc/…
In order to forge a proof, we need both operations to succeed, and we need to last operation (the multistore) to return a fixed value (the hash of the specified block: 110217401)
Looking at the implementation, we can convince ourselves with some effort that it's impossible, or at least very difficult, to manipulate the root hash. Or you can just take my word for it. This means that we need our input value to be equal to one of the commit IDs
The input value of the "multistore" operation is the output value of the "iavl:v" operation. This means that we want to somehow control the root variable here, while still passing the value verification
So how is the root hash computed? Well, it happens in this monster of a function called COMPUTEHASH. At a very very high level, it recursively goes over each path and leaf and does a bunch of hashing and really the implementation details don't matter github.com/cosmos/iavl/bl…
What does matter is that due to the way that hash functions are intended to work, we can basically say with certainty that any (path, nleaf) pair will produce a unique hash. If we want to forge a proof, those will need to stay the same
Looking at the way that the proof is laid out in a legitimate transaction, we see it has a very long path, no inner nodes, and only one leaf node. This leaf node contains the hash of our malicious payload! If we can't modify this leaf node, then we'll need to add a new one
Of course, if we add a new leaf node, we'll also need to add a new inner node to match
Now we just have one last obstacle to face. How do we actually get COMPUTEHASH to return the root hash we want? Well, notice that eventually we'll need a path to contain a non-zero right hash. When we find one that does, we assert it matches the intermediate root hash
Let's just instrument the code a bit so we can figure out what hash we need and....
All that's left is to put it all together. We'll take a legitimate proof and modify it so that: 1) we add a new leaf for our forged payload 2) we add a blank inner node to satisfy the prover 3) we tweak our leaf to exit early with the correct root hash gist.github.com/samczsun/8635f…
(It's worth noting that this wasn't the exact method the attacker used. Their proof path is much shorter, and I'm not sure how exactly they generated that. However, the rest of the exploit is identical, and I believe showing how to build it from the ground up is valuable)
In summary, there was a bug in the way that the Binance Bridge verified proofs which could have allowed attackers to forge arbitrary messages. Fortunately, the attacker here only forged two messages, but the damage could have been far worse
Proof verifier bug. That’s scary af.
This is incredibly too detailed in such a short period of time. You are either a genius, or.. the guy, lmao.
Getting away with $100M isn't all that bad. Binance survives another day and crypto along with it. Does this impact other chains? Cosmos?
