Binance Smart Chain Token Bridge Hack

Backstory

On October 6^th 2022, the BSC Token Hub bridge (hereinafter BSC), belonging to the largest cryptocurrency exchange, Binance, was hacked. This was one of the largest cryptocurrency hacks ever. BSC ensures the interaction between the Binance Beacon Chain blockchain used by Binance for decentralized management (stacking, voting) and Binance Smart Chain, an EVM-compatible blockchain used to create various decentralized applications. Hackers withdrew 2 million BNB (Binance’s cryptocurrency) from the bridge protocol, with 1 BNB worth $293 at the time. A total of $586 million was stolen.

The technical aspects

Blockchain bridges are used to transfer data and assets between heterogeneous blockchains. They act as intermediaries to send transactions, so whether you trust a transaction sent from blockchain A to blockchain B depends on the bridge between A and B. To trust a transaction provided by blockchain A, the bridge needs to validate it. Depending on the bridge logic, there are several ways to verify transactions, but they all depend on how data is recorded and stored in the blockchain, that is, the tree-like structure of data representation.

Each node of the binary tree is a concatenation of hashes from its two child nodes. The end nodes of the tree corresponding to the transactions added to the blockchain are called leaves, and the top root nodes are called roots. This tree-like structure of data representation is called a binary search tree and allows you to easily check the legitimacy (authorship) and integrity of data recorded in any of the tree nodes. Knowing the hash of the data being checked and the values of intermediate nodes used when calculating the root hash, you can perform the Merkle proof: starting at the bottom of the node, check that each successive hash is correct, up to the root. Any discrepancy will indicate that the data in the node has been tampered with.

How BSC transaction validation works

The BSC bridge uses a balanced AVL tree, a kind of a binary search tree, to validate transactions. For each node of this tree, the height of its two branches differs by no more than 1. The verification algorithm is called in the handlePackage function of the main CrossChain smart contract, which processes token transfers between blockchains.

This function also contains the onlyRelayer modifier, which means that only a relayer can call this function.

Structure of the transaction validation request

Relayers in bridges process specially formatted data packets coming from blockchain A, extract the necessary parameters from them, and translate them to the network for transmission to blockchain B. To register as a relayer, it is necessary to deposit 100 BNB tokens and configure the device connected to the blockchain in accordance with the configuration file. After registration, the relayer starts parsing the data in the endBlock event table of each network block and selecting from it all the IBCPackage events. 

The value parameter has four attributes separated by “::”:

• The first attribute is the destination chain name; in this example it is “bsc”.
• The second attribute is the CrossChainID of destination chain; in this example it is “2”.
• The third attribute is the channel id; in this example it is “8”.
• The fourth attribute is the sequence; in this example it is “19”.

After processing this event, the relayer processes the data packet with the transaction sended from blockchain A to blockchain B. The relayer extracts the following parameters from the packet:

Parameter name	Size	Value
prefix	1 byte	0x00
source chain CrossChainID	2 bytes	Transaction source blockchain ID
destination chain CrossChainID	2 bytes	Transaction destination blockchain ID
channelID	1 byte	IBCPackage event channel ID
sequence	8 bytes	IBCPackage event sequence number

Next, the relayer sends these parameters, transaction data, the transaction validation sign (prove), and block height to a special RPC request that calls the handlePackage function of the CrossChain contract:

Merkle proof

In the handlePackage function, the validateMerkleProof function of the MerkleProof library is called; using the staticcall method at 0x65, the precompiled iavlMerkleProofValidate contract is called. This contract is a library written in Go that has a number of dependencies (methods) of the Cosmos cross-chain framework that implement the Merkle proof functionality.

These dependencies are called in the Run function of the iavlMerkleProofValidate contract in strings 8, 9, and 16:

The called op.Proof.ComputeRootHash() method calculates the AVL tree root hash for the tree leaf that contains the transaction being checked. Next, the op.Proof.Verify(root) method compares the hash of the AVL tree root with the one calculated at the previous step. If the compared hashes differ, the op.Proof.Verify(root) method will return an error, and the transaction transfer from blockchain A to blockchain B will be canceled. If the hashes are the same, the op.Proof.VerifyItem(op.key, value) method is called, in which the presence of the transaction data hash in the AVL tree is checked. If the hash is found, the transaction is considered valid and is executed.

Transaction verification vulnerability

The vulnerability of the transaction verification process is related to the way the tree root hash for the transaction is calculated and checked. The ComputeRootHash function calls the pwl.Leaf.Hash() method:

The Hash function correctly calculates the root hash in case when the left leaf in the Merkle proof chain for the transaction being checked equals zero, that is, not defined. But if the left leaf is defined, the tree root hash is calculated without taking into account the right leaf. In other words, if the left leaf in the Merkle proof chain for the checked transaction is defined, the value of the tree root hash will not depend on the presence of the right leaf in the proof chain.

This flaw allows attackers to write a payload to the right leaf and successfully pass the tree root hash value check, provided that the payload hash is calculated correctly.

Attack scenario

Before starting the attack, criminals deposited 100 BNB to the Relayer Hub contract in order to register as a BSC bridge relayer.

They used a legitimate transaction that was used to transfer 0.05 BNB from the BSC bridge two years ago. They changed the payload by specifying the attacker address as the recipient and changed the amount to 1 mln BNB:

	Original transaction	Attacker transaction
payload	0x00000000000000000000000000000000000 00000000000000000038d7ea4c68000f86da0 424e420000000000000000000000000000000 0000000000000000000000000009400000000 0000000000000000000000000000000087b1a 2bc2ec50000944e656459ed25bf986eea1196 bc1b00665401645d94a10123c15a63135fe94 5a54232bae7fac8177056845fd12999	0x00000000000000000000000000000000000 0000000000000000000000000000000f870a0 424e420000000000000000000000000000000 0000000000000000000000000009400000000 000000000000000000000000000000008ad3c 21bcecceda100000094489a8756c18c0b8b24 ec2a2b9ff3d4d447f79bec94489a8756c18c0 b8b24ec2a2b9ff3d4d447f79bec846553f100

The payload content is a structure encoded in RLP format: 

Next, attackers modified the proof variable content by adding the right leaf with the payload hash to the AVL tree, and added an empty internal host to balance the AVL tree:

Original transaction proof structure

Attacker transaction proof structure

RangeProof{    LeftPath: PathToLeaf{       0:proofInnerNode{          Height:  1          Size:    3          Version: 110217392                     Left: 0C10F902D266C238A4CA9E26FA9BC36483CD3 EBEE4E263012F5E7F40C22EE4D2          Right:       }       1:proofInnerNode{          Height:  -1          Size:    2          Version: 110217392               Left: E4FD47BFFD1C06E67EDAD92B2BF9CA63631978676288A2AA99F95C459436EF63          Right:       }    }    InnerNodes:       Leaves:       proofLeafNode{          Key:          0000010038020000000000000002          ValueHash: 11056C6919F02D966991C10721684A8D1542E44003F9FFB47032C18995D4AC7F          Version:    110217392             }       (rootVerified): true       (rootHash): E09159530585455058CF1785F411EA44230F39334E6E0F6A3C54DBF069DF2B62       (treeEnd): true }

RangeProof{    LeftPath: PathToLeaf{       0:proofInnerNode{          Height:  1          Size:    3          Version: 110217392          Left: 0C10F902D266C238A4CA9E26FA9BC36483CD3 EBEE4E263012F5E7F40C22EE4D2          Right:       }       1:proofInnerNode{          Height:  -1          Size:    2          Version: 110217392                  Left: E4FD47BFFD1C06E67EDAD92B2BF9CA63631978676288A2AA99F95C459436EF63          Right: DA657C1FFB86C684EB3E265361EF0FA4F9DFA670B45F9F91C5EB6AD84B21A4D1       }    }    InnerNodes:       empty-PathToLeaf       Leaves:       proofLeafNode{          Key:          0000010038020000000000000002          ValueHash: 11056C6919F02D966991C10721684A8D1542E44003F9FFB47032C18995D4AC7F          Version:   110217392       }       proofLeafNode{          Key:          00000100380200000000010DD85C          ValueHash: 2C3A561458F8527B002B5EC3CAB2D308662798D6245D4588A4E6A80EBDFE30AC          Version:          1       }       (rootVerified): true             (rootHash): E09159530585455058CF1785F411EA44230F39334E6E0F6A3C54DBF069DF2B62       (treeEnd): true }

Due to the vulnerability, the content of the added right leaf did not affect the root hash, so the fraudulent transaction was successfully verified. After checking the transaction, the CrossChain contract called a function to transfer 1 mln BNB from BSC to the attacker address. Next, the attackers tried to repeat the transaction, but the next 15 attempts were unsuccessful because of the incorrect packageSequence value. On the 16^th attempt, however, they managed to find the correct packageSequence value and obtain another 1 mln BNB at their address.

Next, for fear of freezing and blocking of assets in BSC, the attackers began to withdraw money from the bridge. For laundering, they used the Venus Finance DeFi: they issued wrapped vBNB tokens in exchange for BNB, and used vBNB as a collateral to loan BUSD, Binance’s stablecoin. Next, using the Stargate and Anyswap bridges, the attackers converted BUSD to the USDT and USDC stablecoins in several blockchains: Ethereum, Avalanche, Fantom, Polygon, Arbitrum, and Optimism.

Reaction of Binance and the crypto community

After identifying the attack, Binance suspended and forked the BSC blockchain, preventing the attackers from withdrawing more than $400 million. Following that, Tether, the owner of the USDT stablecoin, blocked the attacker’s USDT address, preventing them from laundering part of the stolen funds. The attacker addresses were blacklisted:

Vulnerability elimination

Initially, the AVL tree verification method assumed that only the right or only the left leaf of the tree could be defined for a transaction to be verified. However, the check for the simultaneous presence of the right and left leaves in the AVL tree check algorithm was initially missing, and the attacker took advantage of it.

Shortly after the hack, a fix was introduced to the AVL proof method of the Cosmos cross-chain framework: 

In case of simultaneous presence of the left and right leaf of the AVL tree, the transaction verification will be rejected with a corresponding error.

Conclusion

The Binance Smart Chain Token Hub bridge hack is an example of exploiting a vulnerability in a third-party component that the bridge uses to determine whether a transaction can be trusted and executed or rejected. Although the vulnerability was in a third-party component, it caused great financial damage to the BSC bridge. Apparently, before it was fixed, this vulnerability was also present in other DeFi protocols using the AVL proof method of the Cosmos cross-chain framework. However, based on the amount of funds stolen from BSC, we can assume that the attackers were after the jackpot from the very beginning, knowing that after the vulnerability is fixed, they would not get a second chance.