Binance Bridge Forged Proof Exploit

Notice: This page is a new case study and some aspects have not been fully researched. Some sections may be incomplete or reflect inaccuracies present in initial sources. Please check the References at the bottom for further information and perform your own additional assessment. Please feel free to contribute by adding any missing information or sources you come across. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

BNB Chain

An attacker found a massive hole in the proof validation that Binance Smart Chain nodes were using to validate that payments had been made to their bridge. The attacker was able to extract $566m worth of BNB token. The nodes were shut down after $127m was taken off-chain, and the rest of the money was frozen.

This is a global/international case not involving a specific country.

About Binance Bridge

Binance Bridge 2.0 acts as a bridge between the platform and tokens not listed on the exchange. This new feature allows users to use their wrapped tokens with the Binance Smart Chain (BNB). Users can access decentralized finance (DeFi), metaverse, and blockchain games without needing third-party wallets. The cross-chain bridge aims to revitalize the DeFi space by offering users the ability to stake their Ethereum (ETH) and its tokens on the BNB Smart Chain, reducing high fees and transaction completion times. Binance Bridge 2.0 supports various Ethereum-native tokens and provides access to BNB Smart Chain dApps.

The Reality

The Binance Bridge contained an exploit in the proof mechanism.

What Happened

A hacker exploited a bug in the Binance Smart Chain (BSC) Token Hub, a cross-chain bridge, stealing at least $100 million in cryptocurrency. Independent observers estimate the hacker's gains to be around $586 million. Binance, the largest cryptocurrency exchange, suspended trading on the smart contract blockchain and requested validators to suspend BSC to address the issue. Changpeng Zhao, CEO of Binance, assured users that their funds were safe and the issue was being resolved. The cybersecurity firm PeckShield stated that the attack exploited the internal verification logic of the smart contract blockchain, resulting in a "huge reward claim." Cross-chain bridges, which facilitate the transfer of crypto assets across blockchains, have been increasingly targeted by hackers, with $2 billion stolen in 2022.

"an attacker stole 2 million BNB (~$566M USD) from the Binance Bridge." "the attack appears to have started at 2:30 PM EST [on October 6th, 2022], with the attacker's wallet receiving two transactions [1, 2], each consisting of 1,000,000 BNB."

Key Event Timeline - Binance Bridge Forged Proof Exploit

Date	Event	Description
March 29th, 2022 10:09:30 PM MDT	Binance Bridge 2.0 Launching	Watcher.guru reports on Binance launching Binance Bridge 2.0, which acts as a bridge between the platform and tokens not listed on the exchange. This new feature allows users to use their wrapped tokens with the Binance Smart Chain (BNB). Users can access decentralized finance (DeFi), metaverse, and blockchain games without needing third-party wallets. The cross-chain bridge aims to revitalize the DeFi space by offering users the ability to stake their Ethereum (ETH) and its tokens on the BNB Smart Chain, reducing high fees and transaction completion times. Binance Bridge 2.0 supports various Ethereum-native tokens and provides access to BNB Smart Chain dApps.
October 6th, 2022 5:35:00 PM MDT	Samczson Post	Samczsun starts posting a technical analysis.
October 7th, 2022 1:31:00 AM MDT	BankInfoSecurity Article Published	Rashmi Ramesh publishes a BankInfoSecurity article on the situation. "@Binance paused its #smartcontract platform after a hacker exploited an internal verification vulnerability to steal #cryptocurrency from its cross-chain bridge. Binance has acknowledged a theft of at least $100m; @peckshield says hackers stole $586m"
October 7th, 2022 12:20:00 PM MDT	BSC Token Hub Operations Restored	Binance has reportedly restored "restored operations on its BSC Token Hub smart contract".
October 10th, 2022 10:49:00 AM MDT	Analysis By Patrick Hillmann	Patrick Hillmann, Chief Communications Officer at Binance, discussed the recent $100 million hack on BNB Chain in an interview. He highlighted that the hack could have been worse if the validators had not taken quick action. The hack targeted BSC Token Hub, a bridge on the BNB Chain, to mint additional BNB tokens. The attack was compared to thieves printing their own money. BNB validators reacted swiftly to lock down the chain, preventing most of the fraudulently minted BNB from leaving the ecosystem. This action prevented a potential $570 million hack. Hillmann emphasized that the ability of a smaller community of 26 validators to work together quickly was crucial in preventing the worst-case scenario. Validators will now hold on-chain governance votes to decide on freezing hacked funds and implementing a bug bounty reward system to prevent future hacks.

Technical Details

"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"

“The bug itself lies in how Binance Bridge processes the proofs of transactions sending the money from one chain to another,” Adrian Hetman, tech lead of the Triaging Team at Immunefi, a web3 bug bounty program provider, told TechCrunch. “The logic checks the message proof, something a user submits, and proceeds with the payout if the proof is valid.”

“The hacker managed to forge such a message that it tricked the logic of the contract into thinking the message was indeed valid, even though the hacker didn’t have valid claims to the funds. BSC Token Hub then proceeded with the payout as everything was valid,” said Hetman.

SlowMist Technical Analysis

TBD

Samczsun Technical Analysis

Samczsun published a technical analysis of the exploit on Twitter.

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

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

(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

Total Amount Lost

Initial observations had the amount lost at least $100m.

Patrick Hillmann, Chief Communications Officer at Binance, discussed the recent $100 million hack on BNB Chain in an interview. He highlighted that the hack could have been worse if the validators had not taken quick action. The hack targeted BSC Token Hub, a bridge on the BNB Chain, to mint additional BNB tokens. The attack was compared to thieves printing their own money. BNB validators reacted swiftly to lock down the chain, preventing most of the fraudulently minted BNB from leaving the ecosystem. This action prevented a potential $570 million hack. Hillmann emphasized that the ability of a smaller community of 26 validators to work together quickly was crucial in preventing the worst-case scenario. Validators will now hold on-chain governance votes to decide on freezing hacked funds and implementing a bug bounty reward system to prevent future hacks.

The total amount lost has been estimated at $566,000,000 USD.

"an attacker stole 2 million BNB (~$566M USD) from the Binance Bridge." "the attack appears to have started at 2:30 PM EST [on October 6th, 2022], with the attacker's wallet receiving two transactions [1, 2], each consisting of 1,000,000 BNB."

"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"

Immediate Reactions

The Binance Bridge was paused and Binance immediately acknowledged the incident.

Pausing Of The Binance Bridge

"When hackers exploited a bug in the BSC Token Hub (a cross-chain bridge connecting the BNB Beacon Chain and BNB Chain) which allowed them to extract 2M BNB (~$570M), the entire chain was “paused” before the hacker could make off with his exploits. As a result, the hacker only managed to snag ~127M off chain."

"The Binance blockchain, also known as BNB Chain and Binance Smart Chain, took the rare step of suspending transactions and fund transfers after discovering a vulnerability affecting the BSC Token Hub cross-chain bridge. These bridges are designed to facilitate the transfer of assets from one independent blockchain to another."

"Simply put, Binance “asked” all its validators (real nicely) to temporarily suspend the chain."

"That’s easy for Binance to do because Binance is also a highly centralized chain with a total of 25 validators, all of whom were pre-approved by Binance themselves."

Binance Acknowledgement of Incident

"Binance acknowledged the security incident at 6:19 PM EST and paused the BNB Smart Chain while they investigated the incident.

At 7:51 PM EST, the CEO of Binance tweeted that an exploit was used in the BSC Token Hub to transfer the BNB to the attacker and that they had asked all validators to suspend the Binance Smart Chain."

Ultimate Outcome

Binance shared an incident summary. A vote was held regarding what should be done with the frozen funds from teh exploit. The Binance Smart Chain was ultimately hard-forked in the Moran hard fork to resolve the vulnerability.

Binance Blog Post Incident Summary

"In a blog post on Friday, the BNB Chain team said that a total of 2 million BNB — worth approximately $568 million — were initially withdrawn by the hacker. But blockchain security company SlowMist says the attacker only managed to take about $110 million because the majority of the stolen tokens, worth about $430 million, couldn’t be transferred following the suspension of the BNB Chain."

"Binance chief executive Changpeng Zhao said in a tweet that the company estimates the impact of the breach to be between $100 million and $110 million."

"When approached for comment, Binance spokesperson Ismael Garcia declined to comment beyond the blog posted by the BNB Chain team, which says that the BNB Chain is now back up and running. The blog post adds that a new on-chain governance mechanism will be introduced on the BNB Chain to fight and defend against future possible attacks."

Hacked Funds Frozen

"Moving forward, BNB Chain’s validators said they would hold a series of on-chain governance votes that would decide whether the hacked funds should be frozen, as well as whether a bug bounty reward system should be put in place to prevent future hacks."

Hard Fork of Binance Smart Chain

"The Moran hard fork seeks to amend several issues on the BNB Chain stemming from its $100 million hack last week."

Concerns About Centralization

Patrick Hillmann, Chief Communications Officer at Binance, discussed the recent $100 million hack on BNB Chain in an interview. He highlighted that the hack could have been worse if the validators had not taken quick action. The hack targeted BSC Token Hub, a bridge on the BNB Chain, to mint additional BNB tokens. The attack was compared to thieves printing their own money. BNB validators reacted swiftly to lock down the chain, preventing most of the fraudulently minted BNB from leaving the ecosystem. This action prevented a potential $570 million hack. Hillmann emphasized that the ability of a smaller community of 26 validators to work together quickly was crucial in preventing the worst-case scenario. Validators will now hold on-chain governance votes to decide on freezing hacked funds and implementing a bug bounty reward system to prevent future hacks.

Total Amount Recovered

The total amount frozen and redistributed has been estimated at $439,000,000 USD.

None of the funds which were bridged to other chains are reported as having been recovered. TBD - Confirm.

Ongoing Developments

TBD

Binance Smart Chain Concerns

Patrick Hillmann, Chief Communications Officer at Binance, discussed the recent $100 million hack on BNB Chain in an interview. He highlighted that the hack could have been worse if the validators had not taken quick action. The hack targeted BSC Token Hub, a bridge on the BNB Chain, to mint additional BNB tokens. The attack was compared to thieves printing their own money. BNB validators reacted swiftly to lock down the chain, preventing most of the fraudulently minted BNB from leaving the ecosystem. This action prevented a potential $570 million hack. Hillmann emphasized that the ability of a smaller community of 26 validators to work together quickly was crucial in preventing the worst-case scenario. Validators will now hold on-chain governance votes to decide on freezing hacked funds and implementing a bug bounty reward system to prevent future hacks.

Individual Prevention Policies

No specific policies for individual prevention have yet been identified in this case.

Avoid the use of smart contracts unless necessary. Minimize the level of exposure by removing or withdrawing assets whenever possible. Aim to choose smart contracts which have obtained third party security audits, preferably having been audited by at least three separate reputable firms. Pay attention to the audit reports, which smart contracts are covered, and whether the smart contract has been upgraded or modified since the report. Ensure that any administrative functions with the ability to remove funds from the smart contract are under the authority of a multi-signature wallet which is controlled by at least three separate and reputable entities.

Store the majority of funds offline. By offline, it means that the private key and/or seed phrase is exclusively held by you and not connected to any networked device. Examples of offline storage include paper wallets (seed phrase or key written down and deleted from all electronic media), hardware wallets, steel wallet devices, etc...

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

Policies for platforms to take to prevent this situation have not yet been selected in this case.

All wallets, minting functions, and critical infrastructure should be implemented with a multi-signature requirement, with a recommended minimum of 3 signatures required. This means that making important changes or approving spending will require the keys held by at least 3 separate individuals within the organization to approve. The multi-signature should be implemented at the lowest layer possible, all key holders should have security training, and all key holders should be empowered and encouraged to exercise diligence.

All aspects of any platform should undergo a regular validation/inspection by experts. This validation should include a security audit of any smart contracts, reporting any risks to the backing (of any customer assets, ensuring treasuries or minting functions are properly secured under the control of a multi-signature wallet, and finding any inadequacies in the level of training or integrity of the team. The recommended interval is twice prior to launch or significant system upgrade, once after 3 months, and every 6 months thereafter. It is recommended that the third party performing the inspection not be repeated within a 14 month period.

Work with other industry platforms to set up a multi-signature wallet with private keys held separately by delegate signatories from seven prominent platforms and services within the industry. Establish requirements for contributions by all platforms and services, designed to be affordable for small platforms yet large enough to cover anticipated breach events. Any breach event can be brought forth by a member platform or a petition of 100 signatures for consideration by the delegate signatories. A vote of 4 or more delegate signatures is required to release any funds, which could partially or fully restore lost funds based on their assessment.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

No specific regulatory policies have yet been identified in this case.

All platforms should undergo published security and risk assessments by independent third parties. Two assessments are required at founding or major upgrade, one after 3 months, and one every 6 months thereafter. The third parties must not repeat within the past 14 months. A risk assessment needs to include what assets back customer deposits and the risk of default from any third parties being lent to. The security assessment must include ensuring a proper multi-signature wallet, and that all signatories are properly trained. Assessments must be performed on social media, databases, and DNS security.

In general, blockchain-level exploits can be resolved by reverting the blockchain to a prior state, which restores all funds to their prior ownership and limits potential losses to those who are transacting between the time of the exploit and the time of the revert. Effort should be undertaken by node operators to switch to a branch that eliminates the exploit as soon as possible to minimize losses. Any remaining losses would be resolved through the industry insurance fund.

Set up a multi-signature wallet with private keys held separately by delegate signatories from seven prominent platforms and services within the industry. Establish requirements for contributions by all platforms and services within the country, designed to be affordable for small platforms yet large enough to cover anticipated breach events. Any breach event can be brought forth by a member platform or a petition of 100 signatures for consideration by the delegate signatories. A vote of 4 or more delegate signatures is required to release any funds, which could partially or fully restore lost funds based on their assessment.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.