10月6日，BNB Chain推特发文称,由于平台上的异常攻击, 现在BSC网络已经暂停服务. 攻击者利用跨链桥 BSC Token Hub (BSC Token Hub 是 BNB 信标链 和 BNB 链 之间的跨链桥) 的漏洞, 套利了大约 $70 billion - $80 billion 。
交易地址: Transaction Address
https://bscscan.com/tx/0xebf83628ba893d35b496121fb8201666b8e09f3cbadf0e269162baa72efe3b8b
钱包地址: Wallet Address
https://bscscan.com/address/0x489a8756c18c0b8b24ec2a2b9ff3d4d447f79bec
Hyperlab 安全实验室根据@samczsun的分析，此次攻击发生的要原因在于
BSC 跨链桥的验证方式存在 BUG，该 BUG 可能允许攻击者伪造任意消息；本次攻击中，攻击者伪造信息通过了 BSC 跨链桥的验证，使跨链桥向攻击者地址发送了 200 万枚 BNB。
幸运的是，攻击者显然没有足够快地将代币转移到链外，因为BNB Chain在大部分代币被转移之前就冻结了所有交易活动。
Hyperlab 安全实验室提醒: 当前区块链行业发展迅猛，跨链技术的发展使得用户对于不同区块链之间的互操作成为可能。跨链桥作为应用范围最广的跨链解决方案（大多数双向跨链桥使用 lock 和 mint 以及 burn 和 mint 模型的组合），同时成为了一个非常吸引力的目标（对于对黑客来说）。后端漏洞，多重签名隐患，智能合约漏洞是三种跨链桥常见的安全风险。此次BSC 跨链桥的攻击事件也是针对跨链合约协议漏洞（验证方式）而发起的。这让人不由地联想到了另一起跨链桥攻击事件：由于执行不善的智能合约更新未能正确验证交易输入，Nomad被盗窃了近$190M。总的来说，针对合约的攻击向量很难缓解。Hyperlab建议采取更强大的安全审计来应对这些风险。协议开发人员需培养足够的安全意识，充分了解跨链桥设计的攻击风险，并更加关注代码底层的逻辑细节。
附录
@samczsun的分析详情如下: (https://twitter.com/samczsun/status/1578175778314780673原文帖链接)
起初，以为 @VenusProtocol 又一次被黑了。然而, 后面证实攻击者将2亿多美元存入Venus。
攻击者向Binance Bridge发送100万BNB两次。
首先比较了攻击者的交易和合法提款的交易。注意到的一点是，攻击者使用的高度总是相同的 - 110217401。合法取款人使用的高度要大得多，如270822321
同时，攻击者的证明明显比合法提款的证明短。攻击者已经找到了一种方法来伪造该特定区块的证明--110217401。接下来须弄清楚这些证明是如何工作的
在Binance中，有一个特殊的预编译合约，用于验证IAVL树, 如下图所示
基本上，当你验证一个IAVL树时，你指定一个 "操作 "列表。Binance Bridge通常期望其中的两个：一个 "IAVL:V "操作和一个 "multistore "操作。以下是它们的实现方式
(https://github.com/cosmos/iavl/blob/de0740903a67b624d887f9055d4c60175dcfa758/proof_iavl_value.go#L61-L82)
为了伪造一个证明，我们需要两个操作都成功，而且我们需要最后一个操作（multistore）返回一个固定值（指定块的哈希值：110217401）。
根据下图的实现代码，要操纵根哈希值是不可能的，或者至少是非常困难的
"multistore "操作的输入值是 "iavl:v "操作的输出值。这意味着我们要在这里以某种方式控制根变量，同时还要传递验证值
根哈希值是通过COMPUTEHASH的函数金进行激素. 它递归到每个路径和叶子上，做了一堆散列，实际上实现细节并不重要
(https://github.com/cosmos/iavl/blob/de0740903a67b624d887f9055d4c60175dcfa758/proof_range.go#L237-L290)
重要的是，由于哈希函数的工作方式，我们基本上可以肯定地说，任何（路径，Nleaf）对都会产生一个唯一的哈希值。如果我们想伪造一个证明，这些就需要保持不变。
在合法交易中证明的布局方式中，我们看到它有一个很长的路径，没有内部节点，只有一个叶子节点。这个叶子节点包含了我们的恶意有效载荷的哈希值! 如果我们不能修改这个叶子节点，那么我们就需要添加一个新的叶子节点
如果我们让添加一个新的叶子节点, 那么我们也同样需要添加一个与之匹配的内部节点
我们怎样才能让COMPUTEHASH返回我们想要的根哈希值？请注意，最终我们需要一个路径包含一个非零的右边哈希值。当我们找到一个这样的路径时，我们断言它与中间的根哈希值相匹配
让我们对代码进行一下分析，以便弄清楚我们需要什么哈希值
剩下的就是把这一切放在一起。我们将采取一个合法的证明，并对其进行修改，以便。
1）我们为我们的伪造的有效载荷添加一个新的叶子
2) 我们添加一个空白的内部节点以满足验证者的要求
3) 我们对我们的叶子进行调整，使其提前退出正确的根哈希值
(https://gist.github.com/samczsun/8635f49fac0ec66a5a61080835cae3db)
(值得注意的是，这并不是攻击者使用的确切方法。他们的证明路径要短得多，我不确定他们到底是如何生成的。然而，该漏洞的其余部分是相同的，我相信展示如何从头开始构建它是有价值的)
总之，Binance Bridge验证证明的方式有一个错误，可能允许攻击者伪造任意信息。幸运的是，这里的攻击者只伪造了两条信息，但损失可能会更大。
APP 
