欧科云链：深扒BSC攻击始末，凭空增发200万BNB的“奥秘”在哪里？

事件背景

北京时间2022年10月7日凌晨，BNB Chian跨链桥BSC Token Hub遭遇攻击FChain。黑客利用跨链桥漏洞分两次共获取200万枚BNB，价值约5.66亿美元。

漏洞分析

BSCTokenHub是BNB信标链（BEP2）和BNB链（BEP20 或 BSC）之间的跨链桥FChain。BNB链使用预编译合约0x65验证BNB信标链提交的IAVL的Proof，但BNB链对提交的Proof边界情况处理不足，它仅考虑了Proof只有一个Leaf的场景，对多个Leaves的处理逻辑不够严谨。黑客构造了一个包含多Leaves的Proof数据，绕过BNBChain上的校验，从而在BNB链造成了BNB增发。

以其中一次攻击交易为例：0xebf83628ba893d35b496121fb8201666b8e09f3cbadf0e269162baa72efe3b8b

黑客构造输入数据payload和proof，输入参数通过validateMerkleProof校验，返回值为trueFChain。

在后续IApplication(handlerContract).handleSynPackage处理中，合约给黑客增发100万个BNBFChain。

展开全文

函数调用过程

交易首先调用CrossChain合约0x2000的handlePackage函数：

handlePackage会进一步调用MerkleProof.validateMerkleProof对输入的proof进行校验：

MerkleProof相关代码可以看到FChain，实际的验证逻辑是使用预编译合约0x65完成：

系统预编译合约0x65对应iavlMerkleProofValidate功能：

系统合约0x65实现代码如下FChain，主要逻辑为使用DecodeKeyValueMerkleProof解码输入参数，并调用Validate进行校验：

其中kvmp.Validate()实现代码如下：

DefaultProofRuntime构造函数使用IAVL库进行Proof的验证：

IAVL代码问题

IAVL的Proof校验过程中，Hash计算存在漏洞，导致黑客可以在Proof添加数据，但计算Hash时并没有用到添加的数据FChain。详细分析如下：

在len(pin.Left)不为0的分支中，计算Hash并没有使用pin.Right数据FChain。黑客利用该处漏洞构造数据，添加proof.LeftPath[1].Right数据，但是该数据并不参与Hash计算。

根据上述分析，正常数据组织结构如下，proof.LeftPath[1].Right为空值，计算得到正确的HashFChain。

proof.LeftPath = len(2)

proof.LeftPath[0]是一个正常数据FChain，proof.LeftPath[1].Left是一个正常数据，proof.LeftPath[1].Right空值

proof.InnerNodes = len(0)

proof.Leaves = len(1),proof.Leaves[0]是一个正常数据

黑客构造攻击数据结构如下，添加proof.LeftPath[1].Right数据，且该数据不参与Hash计算FChain。

proof.LeftPath = len(2)

proof.LeftPath[0]是一个正常数据FChain，proof.LeftPath[1].Left是一个正常数据，proof.LeftPath[1].Right是一个伪造数据

proof.InnerNodes = len(1), InnerNodes[0]=nil

proof.Leaves = len(2),proof.Leaves[0]是一个正常数据FChain，proof.Leaves[1]是一个伪造数据

且proof.LeftPath[1].Right = COMPUTEHASH(proof.Leaves[1])

IAVL的Proof校验代码如下，主体逻辑为COMPUTEHASH递归调用FChain。由于lpath.Right也为黑客输入数据，使得黑客构造的数据能够通过bytes.Equal(derivedRoot, lpath.Right)的校验，并返回上一轮COMPUTEHASH通过proof.Leaves[0]计算的结果，该结果为正常数值，从而绕过了IAVL的Proof校验。

黑客攻击构造的数据中，包括了IAVL:V和multistore相关数据，multistore数据也是基于IAVL进行操作，原理是一样的，不再进行详细分析FChain。

这次IAVL Proof暴露的问题在于，数据局部的变化无法反应到整体，使得校验发生错误FChain。在Cosmos生态中，IBC使用 ICS23来做数据的校验处理，ICS23与IAVL Proof校验不同点在于，ICS23会对所有的“叶子节点”的值进行数据校验，最后计算得出的根Hash再与链上数据进行校验，OKC采用的是ICS23的Prove，因此不存在BNBChain这次遇到的安全漏洞。

测试验证代码

利用黑客攻击交易数据，基于BNBChain单元测试代码，增加了基于黑客攻击交易的测试用例，可以完整复现黑客的攻击交易FChain。单元测试代码利用iavlMerkleProofValidate.Run接口验证输入数据，即相当于调用预编译合约。

利用黑客攻击交易数据，构造新的payload数据为value := []byte(“okc test hack”)，并对proof相应数据进行了修改，即修改proof.LeftPath[1].Right和proof.Leaves[1]对应的数据，新构造的数据可以通过okcIavlMerkleProofValidate校验，即修改了黑客数据也能通过校验FChain。另外，如下单元测试代码对原始黑客数据和修改后的数据两种case都进行了校验，且校验都能成功，从而说明如下测试代码利用本文所述漏洞成功进行了复现。

事件过程

1）北京时间2022年10月6日7点27分黑客使用ChangeNOW服务转入了100多个BNB到BSC链上FChain，作为起始攻击资金：

0xa84f85e1afc3e1b8ed5111ba16e11325f8fc5d6081cb6958becd6a333f6d0d1d

2）北京时间2022年10月7日0点55分黑客调用系统RelayerHub合约 0x1006 进行注册FChain，成为relayer：

0xe1fe5fef26e93e6389910545099303e4fee774427d9e628d2aab80f1b53396d6

3）黑客使用Bsc跨链桥的漏洞执行了两次FChain，总共从里面盗取了200万个BNB：

北京时间2022年10月7日2点26分：

北京时间2022年10月7日4点43分：

4）黑客使用Venus的借贷服务，抵押了90万个BNB，从里面借走了5000 万 USDT、6250万 BUSD和3500万USDCFChain。

5）黑客使用Stargate跨链桥，将资产转移到ETH，AVAX，FTM等网络上，总计转出资产约为9000万美金FChain。

6）北京时间2022年10月7日6点19分，币安暂停BNBChain链FChain。

目前，OKLink 多链浏览器已标记 BNB Chain 被盗案黑客地址（0x489A 开头），关于此次被盗后续，欧科云链链上卫士团队将进一步追踪案件细节并及时同步FChain。