深入分析POLY NETWORK攻击关键步骤

北京时间2021年8月10日，跨链桥项目PO NETWORK遭到攻击，损失超过6亿美元。尽管攻击者随后偿还了被盗的数字货币，但这仍然是区块链历史上涉及金额**的攻击。由于整个攻击过程涉及不同的区块链平台，合约和中继之间存在复杂的交互，现有的分析报告未能梳理出攻击的完整过程和漏洞的根本原因。

整个攻击分为两个主要阶段，包括修改KEEPERS签名和最终取款。对于第二阶段，由于KEEPERS签名已被修改，攻击者可以直接构建恶意的货币取款交易。有关详细信息，请参阅我们之前的报告。但是，没有详细的文章介绍如何在目标链中最终执行修改KEEPERS签名的事务。这一步是攻击的核心。

本报告首先修改KEEPERS签名事务（本体链上的事务0xF771BA610625D5A37B67D30BF2F88297070340C86AD76542802567CAAFFFF280C），并分析该漏洞的基本原理和本质。我们发现以下原因是可以修改keeper的原因：

• 源链上的中继不对上游链上的事务进行语义验证，因此可以将包括修改的keeper在内的恶意事务打包到po链上
• 尽管目标链（以太坊）上的中继验证事务，但攻击者可以直接调用以太坊上的ETHcrosschainmanager契约，并最终调用ETHcrosschaindata契约来完成签名修改
• 攻击者小心地获取可能导致哈希冲突的函数签名，并调用putcurepochconpubkeybytes修改签名[2]

涉及的交易和合同

整个过程的互动过程如下：

Ontology交易 -gt; Ontology Relayer -gt; Po Chain -gt; ETHereum Relayer -gt; ETHereum

以太坊

0x838bf9e95cb12dd76a54c9f9d2e3082eaf928270:ETHCrossChainManager

0xcf2afe102057ba5c16f899271045a0a37fcb10f2:ETHCrossChainData

0x250e76987d838a75310c34bf422ea9f1ac4cc906:LockProxy

0xb1f70464bd95b774c6c6ce60fc706eb5f9e35cb5f06e6cfe7c17dcda46ffd59581:修改KEEPERS的交易记录

Ontology

0xF771BA610625D5A37B67D30BF2F8829703540C86AD76542802567CAAFFFF280C:修改KEEPERS的事务

Po

0x1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80:修改KEEPERS的交易记录

攻击过程

整个攻击大致可分为三个步骤。第一步是在Ontology链中生成恶意事务（0xf771ba610625d5a37b67d30bf2f8829703540c86ad76542802567caaff280c）。第二步是修改以太坊ETHcrosschaindata合同中的KEEPERS签名。第三步是构造恶意交易，以发起最终攻击并提取资金。

第一步

攻击者首先在Ontology（0xf771ba610625d5a37b67d30bf2f8829703540c86ad76542802567caaff280c）中启动了一个跨链事务，其中包含一个攻击负载：

可以看出，交易包含一个设计良好的函数名（图中以6631开头的数字，即F11121318093）通过引起哈希冲突来调用putcurepochconpubkeybytes函数（属于以太坊上的ETHcrosschaindata协定）。关于网络上哈希函数冲突的细节已经有很多讨论。请参阅[2]

然后，Ontology Relayer接收事务。请注意，注意这里并没有很严格的校验。该交易会通过Relayer在Po Chain成功上链（0x1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80），ETHereum Relayer会感知到新区块的生成。

但是，该事务被以太坊中继拒绝。原因是以太坊中继器检查目标合约地址，只允许lockproxy合约作为目标地址，而攻击者传入ETHcrosschaindata地址。

因此，攻击者的攻击路径在此中断。然而，如前所述，包含恶意负载的攻击事务已成功链接到po-chain中，并可进一步利用。

步骤2

攻击者手动启动事务，调用ETHcrosschainmanager契约中的VerifyHeaderAndexecutex函数，并将上一步中保存在策略链块中的攻击事务数据作为输入。由于此块是POLOGAN链上的合法块，因此可以在VerifyHeaderAndexecutex中验证签名和Merkle证明。然后，执行ETHcrosschaindata合约中的putcurepochconpubkeybytes函数，将原来的四个Keeper修改为它们指定的地址（0xa87fb85a93ca072cd4e5f0d4f178bc831df8a00b）。

步骤3

修改keeper后，攻击者直接调用目标链上的VerifyHeaderAndexecutex函数（而不是通过POLOGAN链——因为keeper已被修改，攻击者可以在POLOGAN链上任意签署目标链中看似合理的块），**调用解锁功能（属于lockproxy合同）转移大量资金，给项目方带来了严重损失。有关具体攻击的详细信息，请参阅我们以前的报告[1]。

Relayer代码分析

在此攻击过程中，本体和以太坊都有一个中继，负责将来自本体的事务链接到聚合链中，并将事务放入以太坊的聚合链中。这两个继电器是由go语言实现的服务过程。

然而，我们发现两个继电器都缺乏有效的验证。这导致了

• 攻击者可以在本体中构造恶意跨链事务，并将其成功打包到多链中。
• 虽然以太坊中的中继具有验证功能，但攻击者可以直接与以太坊上的链上契约交互，并直接执行恶意功能。

本体中继完全信任来自本体的跨链事务

Po Network的发展；ont_uuyer（https://github.com/ponetwork/ont-relayer )监控本体链上的跨链事务，并将它们打包到传入的po链中

注:

1. 在本体中继中，侧指本体链；联盟意味着多链
2. Crosschaincontractaddress是本体链上本机编号为09的智能合约

在上图中，本体中继启动时打开三个goroutine，分别负责监控本体链和po链的跨链事务，检查po链上跨链事务的状态。在本报告中，我们只关注监听端的69行代码逻辑。

在上图中，本体中继调用本体链提供的RPC接口（第215行，调用SDK函数getartcontracteventbyblock），获取块中触发的智能合约事件；然后，第228行和第232行指示本体中继仅侦听由本体链上的crosschaincontractaddress触发的makefromontproof事件；

在上图中，当处理本体链上的跨链事务时，本体中继总共执行五次验证，包括发送到本体链的RPC请求的两次验证（检查1和检查4）和参数是否为空的三次验证（检查2、检查3和检查5）。这五种验证均为常规验证，本体链的跨链事务不进行语义验证；第167行和第171行取出在目标链上执行所需的事务参数信息（证明、审核路径）；第183行将交易发送给po chain；

在多链上构造事务之后，本体中继发起RPC请求以将事务发送到多链（第164行，函数调用sendtransaction）；

这个名为ProcessToAliianceCheckAndRetry的goroutine仅重新传输失败的事务，并且仍然不会对来自本体链的跨链事务执行任何语义验证。

到目前为止，我们可以看到ont中继侦听由本体链中的crosschaincontractaddress触发的所有makefromontproof事件，并将事务转发到po-chain，而无需任何语义验证。任何人发送到本体的任何跨链事务都将触发crosschaincontractaddress的makefromontproof事件，因此本体中继将所有跨链事务从本体转发到po-chain。

以太坊继电器中的签入无效

以太坊中继层；负责监听po chain并将目标链为以太坊的跨链交易转发至以太坊。

以太坊中继启动goroutine以监控聚合链；

以太坊中继监控以太坊作为po链上目标链的所有跨链交易（第275至278行）；以太坊中继将验证跨链交易的目标合约是否为config.targetcontracts中指定的合约之一。否则，跨链事务将不会发送到以太坊（第315行）。

尽管以太坊中继部分验证po-chain上的跨链事务，例如限制目标合约，但与po-chain不同，任何人都可以将事务发送到以太坊上的ETHcrosschainmanager合约。换句话说，以太坊继电器在此进行的验证没有实际意义。只要包含恶意负载的跨链事务成功打包到po链中（尽管它没有通过中继转发到以太坊链），任何人都可以直接使用打包的块数据将负载发送到以太坊ETHcrosschainmanager合同并执行它（在此过程中，它可以通过Merkle证明的验证，因为它是正常链接的POLOGAN链块数据。

攻击者利用上述两个缺陷完成攻击过程中的步骤1和步骤2。

写在末尾

通过对整个攻击过程的全面梳理和详细分析，我们认为中继验证不完整是攻击的根本原因。其他方面（如使用哈希冲突）属于更出色的攻击技术。总之，跨链验证和认证是跨链系统安全的关键，值得社会各界进一步努力。