Thread by @samczsun

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.

It all started when @zachxbt sent 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

@zachxbt At first, I thought that @VenusProtocol had 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