Hyperlab：BNB Chain攻击链路全面复盘解析

10月6日，BNB Chain推特发文称,由于平台上的异常攻击, 现在BSC网络已经暂停服务. 攻击者利用跨链桥 BSC Token Hub (BSC Token Hub 是 BNB 信标链 和 BNB 链 之间的跨链桥) 的漏洞, 套利了大约 $70 billion - $80 billion

On October 6, BNB Chain tweeted that the BSC network is now out of service due to an unusual attack on the platform. The attackers exploit a vulnerability in the cross-chain bridge BSC Token Hub (BSC Token Hub is a cross-chain bridge between the BNB beacon chain and the BNB chain) and profited about $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在大部分代币被转移之前就冻结了所有交易活动。

According to @samczsun's analysis, the main reason for this attack is

A bug in the authentication method of the BSC cross-chain bridge that could have allowed the attacker to forge arbitrary messages; in this attack, the attacker forged messages to pass the BSC cross-chain bridge's authentication, causing the cross-chain bridge to send 2 million BNBs to the attacker's address.

Fortunately, the attackers apparently did not move the tokens off-chain fast enough, as BNB Chain froze all transaction activity before most of the tokens were moved.

Hyperlab 安全实验室提醒: 当前区块链行业发展迅猛，跨链技术的发展使得用户对于不同区块链之间的互操作成为可能。跨链桥作为应用范围最广的跨链解决方案（大多数双向跨链桥使用 lock 和 mint 以及 burn 和 mint 模型的组合），同时成为了一个非常吸引力的目标（对于对黑客来说）。后端漏洞，多重签名隐患，智能合约漏洞是三种跨链桥常见的安全风险。此次BSC 跨链桥的攻击事件也是针对跨链合约协议漏洞（验证方式）而发起的。这让人不由地联想到了另一起跨链桥攻击事件：由于执行不善的智能合约更新未能正确验证交易输入，Nomad被盗窃了近$190M. 总的来说，针对合约的攻击向量很难缓解。Hyperlab建议采取更强大的安全审计来应对这些风险。协议开发人员需培养足够的安全意识，充分了解跨链桥设计的攻击风险，并更加关注代码底层的逻辑细节。

Hyperlab Security Lab reminds that the blockchain sector is undergoing tremendous growth, and the development of cross-chain technology enables users to interact between blockchains. As the most prevalent cross-chain solution, cross-chain bridges have attracted wide attention but also become a highly desirable target for hackers. Three common security hazards for cross-chain bridges are back-end vulnerabilities, multi-signature attack, and smart contract flaws. Today’s BSC cross-chain bridge attack was launched against the cross-chain contract protocol flaw (incomplete verification). This is reminiscent of another cross-chain bridge attack: Nomad bridge was stolen nearly $190M due to a poorly executed smart contract update that failed to properly validate transaction inputs. Overall, contract attack vectors are tough to defend against. Hyperlab suggests more stringent security checks to combat these threats. Protocol developers should cultivate adequate security awareness, fully comprehend the attack risk of cross-chain bridge design, and pay closer attention to the code's underlying logic.

附录

@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) 我们对我们的叶子进行调整，使其提前退出正确的根哈希值

(值得注意的是，这并不是攻击者使用的确切方法。他们的证明路径要短得多，我不确定他们到底是如何生成的。然而，该漏洞的其余部分是相同的，我相信展示如何从头开始构建它是有价值的)

总之，Binance Bridge验证证明的方式有一个错误，可能允许攻击者伪造任意信息。幸运的是，这里的攻击者只伪造了两条信息，但损失可能会更大。