Verichains

Share this post

Binance Chain Bridge Exploitation Writeup - Part 2

blog.verichains.io

Discover more from Verichains

Leading web3 security firm in APAC. Trusted by top blockchain customers such as BNBChain (Binance), Klaytn (Kakao Talk), Wemix (Wemade), Solana, Axie Infinity/Ronin Network (Sky Mavis)
Continue reading
Sign in

Binance Chain Bridge Exploitation Writeup - Part 2

This is the second part of our analysis on Binance Chain's bridge hack, focus on hacker transactions and exploitation payloads.

Thanh Nguyen
Oct 8, 2022
3
Share this post

Binance Chain Bridge Exploitation Writeup - Part 2

blog.verichains.io
Share

by Verichains Team 

This is the second part of our analysis on Binance Chain’s bridge hack, focus on hacker transactions and exploitation payloads. This analysis also answers @samczsun's questions in his early tweets, in which he wondered how the attacker's payload was much shorter than his me.

Verichains Lab
Binance Chain Bridge Exploitation Writeup - Part 1
by Verichains Team On October 7th 2022, Binance Chain was hacked with almost $600M of asset value with roughly $90M being moved out of the Binance ecosystem. The hack was triggered in a transaction where the Binance Bridge sends out a large portion of BNB native…
Read more
a year ago · 4 likes · Thanh

Transaction details

The hacker transaction is at https://bscscan.com/tx/0xebf83628ba893d35b496121fb8201666b8e09f3cbadf0e269162baa72efe3b8b. Decoding the transaction data, we got the following arguments that will be passed to the function handlePackage of CrossChain.sol smart contract (link):

0	payload	bytes	0x000000000000000000000000000000000000000000000000000000000000000000f870a0424e4200000000000000000000000000000000000000000000000000000000009400000000000000000000000000000000000000008ad3c21bcecceda100000094489a8756c18c0b8b24ec2a2b9ff3d4d447f79bec94489a8756c18c0b8b24ec2a2b9ff3d4d447f79bec846553f100
1	proof	bytes	0x0a8d020a066961766c3a76120e00000100380200000000010dd85c1af201f0010aed010a2b0802100318b091c73422200c10f902d266c238a4ca9e26fa9bc36483cd3ebee4e263012f5e7f40c22ee4d20a4d0801100218b091c7342220e4fd47bffd1c06e67edad92b2bf9ca63631978676288a2aa99f95c459436ef632a20da657c1ffb86c684eb3e265361ef0fa4f9dfa670b45f9f91c5eb6ad84b21a4d112001a370a0e0000010038020000000000000002122011056c6919f02d966991c10721684a8d1542e44003f9ffb47032c18995d4ac7f18b091c7341a340a0e00000100380200000000010dd85c12202c3a561458f8527b002b5ec3cab2d308662798d6245d4588a4e6a80ebdfe30ac18010ad4050a0a6d756c746973746f726512036962631ac005be050abb050a110a066f7261636c6512070a0508b891c7340a0f0a046d61696e12070a0508b891c7340a350a08736c617368696e6712290a2708b891c7341220c8ccf341e6e695e7e1cb0ce4bf347eea0cc16947d8b4e934ec400b57c59d6f860a380a0b61746f6d69635f7377617012290a2708b891c734122042d4ecc9468f71a70288a95d46564bfcaf2c9f811051dcc5593dbef152976b010a110a0662726964676512070a0508b891c7340a300a0364657812290a2708b891c73412201773be443c27f61075cecdc050ce22eb4990c54679089e90afdc4e0e88182a230a2f0a02736312290a2708b891c7341220df7a0484b7244f76861b1642cfb7a61d923794bd2e076c8dbd05fc4ee29f3a670a330a06746f6b656e7312290a2708b891c734122064958c2f76fec1fa5d1828296e51264c259fa264f499724795a740f48fc4731b0a320a057374616b6512290a2708b891c734122015d2c302143bdf029d58fe381cc3b54cedf77ecb8834dfc5dc3e1555d68f19ab0a330a06706172616d7312290a2708b891c734122050abddcb7c115123a5a4247613ab39e6ba935a3d4f4b9123c4fedfa0895c040a0a300a0361636312290a2708b891c734122079fb5aecc4a9b87e56231103affa5e515a1bdf3d0366490a73e087980b7f1f260a0e0a0376616c12070a0508b891c7340a300a0369626312290a2708b891c7341220e09159530585455058cf1785f411ea44230f39334e6e0f6a3c54dbf069df2b620a300a03676f7612290a2708b891c7341220db85ddd37470983b14186e975a175dfb0bf301b43de685ced0aef18d28b4e0420a320a05706169727312290a2708b891c7341220a78b556bc9e73d86b4c63ceaf146db71b12ac80e4c10dd0ce6eb09c99b0c7cfe0a360a0974696d655f6c6f636b12290a2708b891c73412204775dbe01d41cab018c21ba5c2af94720e4d7119baf693670e70a40ba2a52143
2	height	uint64	110217401
3	packageSequence	uint64	17684572
4	channelId	uint8	2

Where:

  • payload contains information about the cross-chain transfer (of course it did not actually happen) including BSC recipient address and token amount which the attacker has set to his/her own address and 1 million BNB respectively.

  • proof is an IAVL/Merkle proof that asserts the integrity of payload.

  • height is (at least) the BC (not BSC) block height at which the transfer occurred. The appHash of BC corresponding to height will be retrieved for verifying proof.

  • packageSequence acts like a TCP sequence number to assure that packages relayed to BSC can not be replayed and arrive in order.

  • channelId is routing information that is used to select the next appropriate contract to handle the package payload after its verification succeeds. Here, channelId == 2 indicates a cross-transfer (BC to BSC) package which should be handled by the TokenHub.sol contract (link).

The way BC to BSC cross-chain communication works is that every-time a package needs to be sent to BSC, a key will be constructed from packageSequence and channelId, and its associated value, which is essentially the package payload, will be stored in the verifiable key-value store of BC and thus, updating BC appHash. Later on, the package is relayed to BSC together with proof that proves the correctness of the corresponding key-value pair in BC store. This is basically the light-client technique for cross-chain communication.

Next, we will analyze proof.

Proof details

proof essentially contains 2 parts.

The first part regards to the multistore architecture of BC. Basically, BC appHash is the hash of all its sub-store root hashes, including the one named ibc (short for Inter-Blockchain Communication) in which the key-value pair mentioned earlier is actually stored. proof carries all the sub-store hashes so ibc root hash could be verified against appHash. Compared with a valid proof, the attacker did not change this part.

first-part
First part of proof

The second part is about proving that a leaf containing key-value does actually exist in ibc IAVL tree given its root hash. The technique used to forge this part has been described earlier. Please notice that both Left and Right fields of Proof.LeftPath[1] are filled:

second-part
Second part of proof

Based on LeftPath, we deduce that the ibc tree snapshot at BC block height 110217401 looks like this:

tree-at-BC-height-110217401
ibc IAVL tree at BC height 110217401

And the malicious second part is as follows:

malicious-2nd-part
Malicious IAVL range proof for proving the correctness of package with sequence number 17684572

So, the BC block height 110217401 chosen by the attacker is likely for minimizing the proof size as the ibc tree at that time had only a few nodes. Maybe it helped reduce some gas cost when submitting the malicious transaction, or the attacker just prefers a concise proof over longer ones.

This analysis also answers @samczsun's questions in his early tweets, in which he wondered how the attacker's payload was much shorter. As long as the IAVL tree contains at least 2 leafs, the attack is already feasible. Therefore, the proof could be made short, and the attacker chose to do so.

Thanks for reading Verichains Lab! Subscribe for free to receive new posts and support my work.

3
Share this post

Binance Chain Bridge Exploitation Writeup - Part 2

blog.verichains.io
Share
Previous
Next
Comments
Top
New
Community

No posts

Ready for more?

© 2023 Verichains
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing