On October 6th, BNB Chain tweeted that due to an abnormal attack on the platform, BSC network services have been temporarily suspended. The attacker exploited a vulnerability in the BSC Token Hub, a cross-chain bridge between BNB Beacon Chain and BNB Chain, and made approximately $70 billion - $80 billion in arbitrage.
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
Transaction Address: [link]
Wallet Address: [link]
According to the analysis by Hyperlab Security Lab, the main reason for this attack is the existence of a bug in the verification method of the BSC cross-chain bridge. This bug may allow attackers to forge arbitrary messages. In this attack, the attacker forged information that passed the verification of the BSC cross-chain bridge, causing the bridge to send 2 million BNB to the attacker's address.
Fortunately, the attacker apparently did not transfer the tokens off-chain fast enough, as BNB Chain froze all transaction activities before most of the tokens were transferred.
Hyperlab Security Lab reminds that the blockchain industry is developing rapidly, and the development of cross-chain technology makes interoperability between different blockchains possible. Cross-chain bridges, as the most widely used cross-chain solution (most bi-directional cross-chain bridges use a combination of lock and mint, as well as burn and mint models), have also become attractive targets for hackers. Backend vulnerabilities, multi-signature vulnerabilities, and smart contract vulnerabilities are three common security risks for cross-chain bridges. This attack on the BSC cross-chain bridge also targeted the vulnerability of the cross-chain contract protocol (verification method). This reminds us of another cross-chain bridge attack: Nomad was stolen nearly $190M due to poorly executed smart contract updates that failed to correctly verify transaction inputs. Overall, attack vectors against contracts are difficult to mitigate. Hyperlab recommends adopting more powerful security audits to address these risks. Protocol developers need to cultivate sufficient security awareness, fully understand the attack risks in cross-chain bridge design, and pay more attention to the underlying logic details of the code.
Appendix
Details of @samczsun's analysis: [link]
Initially, it was thought that @VenusProtocol was hacked again. However, it was later confirmed that the attacker deposited over 200 million dollars into Venus.
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
The attacker sent 1 million BNB to Binance Bridge twice.
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
First, the attacker's transactions were compared with legitimate withdrawal transactions. One noticeable point was that the attacker always used the same height - 110217401. The height used by legitimate withdrawers was much larger, such as 270822321.
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
At the same time, the attacker's proof was significantly shorter than the proof of legitimate withdrawals. The attacker had found a way to forge the proof of that specific block - 110217401. The next step is to figure out how these proofs work.
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
In Binance, there is a special precompiled contract for verifying IAVL trees, as shown in the figure below.
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
Basically, when you verify an IAVL tree, you specify a list of "operations." Binance Bridge typically expects two of them: an "IAVL" operation and a "multistore" operation. Here is how they are implemented.
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
To forge a proof, we need both operations to succeed, and we need the last operation (multistore) to return a fixed value (the hash value of the specified block: 110217401).
Based on the implementation code below, manipulating the root hash value is impossible, or at least very difficult.
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
The input value of the "multistore" operation is the output value of the "IAVL" operation. This means that we need to somehow control the root variable here while passing the verification value.
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
The root hash value is calculated using the COMPUTEHASH function. It recursively hashes each path and leaf, and the actual implementation details are not important.
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
What is important is that, due to the way the hash function works, we can basically say that any (path, Nleaf) pair will produce a unique hash value. If we want to forge a proof, these need to remain unchanged.
In the layout of the proof in legitimate transactions, we see that it has a long path with no internal nodes, only one leaf node. This leaf node contains the hash value of our malicious payload! If we cannot modify this leaf node, then we need to add a new leaf node.
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
If we add a new leaf node, we also need to add a matching internal node.
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
How can we make COMPUTEHASH return the root hash value we want? Note that in the end, we need a path that contains a non-zero right hash value. When we find such a path, we assert that it matches the intermediate root hash value.
Let's analyze the code to understand what hash values we need.
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
Hyperlab: Comprehensive Analysis of the BNB Chain Attack Route
The remaining step is to put it all together. We will take a legitimate proof and modify it to:
- Add a new leaf for our forged payload
- Add a blank internal node to satisfy the validator
- Adjust our leaf to exit with the correct root hash value
(https://gist.github.com/samczsun/8635f49fac0ec66a5a61080835cae3db)
(It is worth noting that this is not the exact method used by the attacker. Their proof path was much shorter, and I'm not sure how they generated it. However, the rest of the vulnerability is the same, and I believe it is valuable to show how to build it from scratch.)
In conclusion, there is a flaw in the way Binance Bridge verifies proofs, which may allow attackers to forge arbitrary information. Fortunately, the attacker only forged two pieces of information here, but the losses could have been greater.
Author: HyperLab Security Lab
This article represents the views of the PANews columnist and does not represent the position of PANews or assume any legal responsibility. The article and opinions do not constitute investment advice.
Image source: HyperLab Security Lab. Please contact the author to delete if there is any infringement.