According to a representative for Binance, the largest cryptocurrency exchange in the world, a $570 million hack has affected a blockchain connected to the company. This is the latest in a string of attacks that have hit the cryptocurrency industry this year.

In a tweet, Binance CEO Changpeng Zhao said that tokens had been stolen from a blockchain “bridge” utilized in the BNB Chain, formerly known as the Binance Smart Chain until February.

Utilizing blockchain bridges, cryptocurrency can be moved across other apps.

According to researcher Chainalysis, thieves are increasingly focusing on them, with about $2 billion stolen in 13 distinct hacks, largely this year.

According to Zhao’s post, the thieves made off with almost $100 million worth of cryptocurrency.

Later, according to a blog post by BNB Chain, the hacker withdrew a total of 2 million BNB coins, valued at about $570 million.

According to the email from the Binance representative, most of the BNB was still in the hacker’s digital wallet address, with about $100 million worth remaining “unrecovered.”

BNB Chain supports BNB, formerly known as Binance Coin, which, according to data provider CoinGecko, is the fifth-largest cryptocurrency in the world with a market value of over $45 billion.

Technical details on the Binance Hack — BY Samczsun

Five hours ago, an attacker stole 2 million BNB (~ $566M) 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

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

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

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