In October 2022, the BSC Beacon cross-chain bridge was the victim of an attack. The attack exploited a vulnerability in the underlying code to extract approximately $566 million to accounts on other chains.
Merkle Trees and Merkle Proofs
The BSC Beacon bridge also known as Token Hub acts as a cross-chain bridge between the BNB Beacon Chain (BEP2) and BNB Chain (also known as BEP20 or BSC).
The way this attack worked was by forging a merkle proof for a specific block. This should be impossible. A merkle proof is a cryptographic proof confirming that specific data such as a transaction is valid and has been included in a block. Typically this data is stored on a merkle tree.
A merkle tree is a tree in which every leaf node is labeled with the cryptographic hash of a piece of data. The internal leaves of the tree contain the hash of their children. For example, H12 = H(1,2).
A Merkle proof is obtained by climbing up the tree until you arrive at the merkle root. The merkle root is a summary of all the transactions contained within a block. This Merkle root — along with the hash of the previous block and some other information — is contained within the block header. These previous block hashes are what chain the blocks of the blockchain together.
The cryptographic hash functions used in Merkle trees have a couple of properties that make them useful for integrity protection. These include:
- Determinism: Hashing the same input will always produce the same hash output. Hash functions are non-random.
- Collision-Resistance: It is computationally infeasible to find two values X and Y where H(X)=H(Y).
This combination of features means that, if you can trust that a particular value has a particular hash, you can verify that the value is unchanged. If calculating the hash of the value produces the same value as the stored hash, then no modifications have occurred.
In the case of Merkle trees, it should be infeasible to find two trees with the same root hash. By storing the root hash in the block header, we should be able to be confident that the data contained within the tree cannot be changed without detection.
Inside the Attack
The BSC Beacon Bridge is heavily reliant on Cosmos software, one of which is a core Cosmos code repository using a form of merkle tree proof called IAVL. This is code to create a customized, binary merkle tree and it was here that the bug was identified.
The data stored in this type of merkle tree are range proof objects – a range of data existing alongside each other. Range proofs can be used to prove that a value is in a IAVL tree or that it is not in the tree.
Ordinarily, to obtain the merkle proof, this range proof outlines a path from a leaf node to the root, including enough internal node values to calculate the root hash. From there, the root hash can be verified to match the root hash stored in the block header.
Since a proof traces a path through a tree, every internal node in the IAVL tree in a proof should only have a left or right child. However, an IAVL tree is a binary tree, which means that it can have a left and right child. The range proof validation code should have verified that no node has a right child, but it didn’t.
An attacker was able to place data into the right field of a node (in addition to the legitimate data in the left field). This tampering was not evident because it didn’t affect the path through the left fields or the root hash. However, the presence of the malicious data in the tree made it seem legitimate and validated.
The attacker was able to exploit this code bug to transfer 1million BNB twice (approximately $566 million) first from the Beacon Chain to the Binance Smart Chain and then to other chains via cross-chain bridges.
After the hack was identified, BNB Chain validators agreed to halt the operation of the blockchain, preventing additional tokens from being transferred to other chains. Additionally, Tether has blacklisted the attacker’s address, and approximately $7 million of the assets moved from the BNB Chain have been frozen.
The BNB Chain is back online with a hotfix release (v1.1.15). The hotfix mainly prevents the attacker from moving additional stolen BNB off-chain.
The Cosmos team as well as Cosmos ecosystem projects have also been swift to act and collaborate on finding a fix for the IAVL software bug referred to as ‘Dragonfruit’. A security advisory was issued and a patch released to reject exploit transactions. As a result of an extensive audit of Cosmos code, another software bug was identified (referred to as ‘Dragonberry’). This affected all Cosmos chains using Inter Blockchain capabilities (IBC). All affected chains have now been patched.
Lessons Learned From the Attack
Demand for cross-chain functionality presents ongoing challenges at an operational level due to the complexity involved in creating bridges. This was first highlighted by Vitalik Buterin here and continues to be relevant.
The best way to meet the demand for cross-chain functionality is for the community to collaborate resources and meaningfully contribute to improve standards and security. This is particularly important when there is so much dependence on open-source software such as Cosmos.
It is important to note that users of IBC, the Cosmos-SDK or the Cosmos Hub are unaffected by the IAVL bug.
Secure software development practices are a vital part of the software development lifecycle and should be an integral part of training for engineers and the release process.
The Binance Bridge (BSC Token Hub) is a critical component of the BNB Chain. A major attack against it was enough to have the chain shut down for damage control.
Cross-chain bridges continue to be a focus for potential exploitation. Learn about protecting your projects against exploitation by contacting Halborn’s Web3 security experts at halborn@protonmail.com.