Poly Network攻击关键步骤深度解析_HAI:mvchain

北京时间2021年8月10日,跨链桥项目Poly Network遭遇攻击,损失超过6亿美金。虽然攻击者在后续偿还被盗数字货币,但是这仍然是区块链历史上涉及金额最大的一次攻击事件。由于整个攻击过程涉及到不同的区块链平台,并且存在合约以及Relayer之间的复杂交互,对于攻击的完整过程和漏洞的根本原因,现有分析报告并未能梳理清楚。

整个攻击分为两个主要阶段,包括修改keeper签名和最终提币。对于第二阶段,由于keeper签名已经被修改,因此攻击者可以直接构建恶意提币交易,具体可以参见我们之前的报告。然而对于修改keeper签名的交易是如何最终在目标链执行的,目前并没有详细的文章阐明。而这一步是攻击的最核心步骤。

本报告从修改keeper签名交易入手(Ontology链上交易0xf771ba610625d5a37b67d30bf2f8829703540c86ad76542802567caaffff280c),分析了背后的原理和漏洞的本质。我们发现以下几个原因是Keeper能被修改的原因:

源链上(Ontology)的relayer没有对上链的交易做语义校验,因此包含修改keeper恶意交易可以被打包到poly chain上

目标链上(以太坊)上的relayer虽然对交易做了校验,但是攻击者可以直接调用以太坊上的EthCrossChainManager合约最终调用EthCrossChainData合约完成签名修改

攻击者精心够着了能导致hash冲突的函数签名,从而调用putCurEpochConPubKeyBytes完成对签名的修改

整个过程中的交互流程如下:

PolyYeld Finance发布补偿登记表格和发布YELD V2的时间线:收益耕作协议PolyYeld Finance发布补偿登记表格和发布YELD V2的时间线。8月8日,新网站上线,PALADIN已开始审计POLYYELD V2合约,预计将在4-7天内完成。北京时间8月9日21:00后,补偿登记表格将不再接受新的提交。YELD V2 Farm将于8月16日至20日开始,具体日期和时间将在审计完成后公布。2000枚YELD V2将预先铸造。其中1000枚用于初始流动性,1000枚用于补偿。此外,占释放的1/10、铸造到开发者钱包的YELD也将用于补偿计划。

此前消息,PolyYeld Finance遭到攻击,YELD代币价格直线跳水归零。[2021/8/8 1:41:51]

Ontology交易 -> Ontology Relayer -> Poly Chain -> Ethereum Relayer -> Ethereum

以太坊

0x838bf9e95cb12dd76a54c9f9d2e3082eaf928270: EthCrossChainManager

0xcf2afe102057ba5c16f899271045a0a37fcb10f2: EthCrossChainData

0x250e76987d838a75310c34bf422ea9f1ac4cc906: LockProxy

0xb1f70464bd95b774c6ce60fc706eb5f9e35cb5f06e6cfe7c17dcda46ffd59581: 修改keeper的交易

Poloniex因意外问题暂时不可用 官方正在调查:Poloniex官方发推称,由于意外问题,Poloniex目前不可用。团队正在调查,并将在了解更多信息时随时提供最新信息。[2020/12/5 14:06:57]

Ontology

0xf771ba610625d5a37b67d30bf2f8829703540c86ad76542802567caaffff280c: 修改keeper的交易

Poly

0x1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80: 修改keeper的交易

整个攻击大致可以分为三个步骤。第一个步骤是在 Ontology 链生成一条恶意交易(0xf771ba610625d5a37b67d30bf2f8829703540c86ad76542802567caaffff280c),第二个步骤是修改以太坊EthCrossChainData合约中的keeper签名,第三个步骤构造恶意交易发起最终攻击和提币。

步骤一

攻击者首先在Ontology发起了一笔跨链交易(0xf771ba610625d5a37b67d30bf2f8829703540c86ad76542802567caaffff280c),里面包含了一个攻击payload:

可以看出交易包含了精心设计的函数名(图中以6631开头的数字,转换后即 f1121318093),目的在于通过造成哈希冲突(hash collision)的方式调用putCurEpochConPubKeyBytes函数(属于以太坊上的EthCrossChainData合约)。关于哈希函数冲突的细节在网络上已有很多讨论,可以参考.

2.8亿枚TRX从Poloniex交易所转出,价值1177.7万美元:据Whale Alert数据显示,北京时间09月04日15:19, 2.8亿枚TRX从Poloniex交易所转入TLoxh9开头地址,按当前价格计算,价值约1177.7万美元,交易哈希为:8d0dadb8e67b3aa8b0b7b1c3bda2a0425d1c17bb83022c904ff48200f557dc27。[2020/9/4]

随后,该笔交易被Ontology Relayer 接收,注意这里并没有很严格的校验。该交易会通过Relayer在Poly Chain成功上链(0x1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80)。Ethereum Relayer会感知到新区块的生成。

然而,这笔交易被Ethereum Relayer拒绝了。原因在于Ethereum Relayer对目标合约地址有校验,只允许LockProxy合约作为目标地址,而攻击者传入的是EthCrossChainData地址。

因此,攻击者攻击之路在此中断。但如前所述,包含恶意payload的攻击交易已经在Poly Chain成功上链,可被进一步利用。

步骤二

攻击者手动发起交易,调用EthCrossChainManager合约中的verifyHeaderAndExecuteTx函数,将之前一步保存在Ploy Chain区块中的攻击交易数据作为输入。由于该区块是poly chain上的合法区块,因此可以通过verifyHeaderAndExecuteTx中对于签名和merkle proof的校验。然后执行EthCrossChainData合约中的putCurEpochConPubKeyBytes函数,将原本的4个keeper修改为自己指定的地址(0xA87fB85A93Ca072Cd4e5F0D4f178Bc831Df8a00B)。

火币全球站将于2020年7月14日22:30支持DOT (Polkadot) 主网映射:据火币全球站公告,将于2020年7月14日22:30支持DOT (Polkadot) 主网映射,到时可将DOT通过映射上账到火币全球站。映射上账成功后,DOT主网资产将呈现在火币全球站币币账户,待DOT主网转账功能开启后,可以进行提币操作。[2020/7/15]

步骤三

在keeper被修改之后,攻击者直接调用目标链上的verifyHeaderAndExecuteTx函数(而不需要再通过poly chain -- 因为keeper已经被修改,攻击者可以任意签署在目标链看来合理的poly chain上的块),最终调用至Unlock函数(属于LockProxy合约),大量地转移资金,给项目方带来了严重的损失。具体的攻击细节可参考我们之前的报告。

在本攻击过程中,Ontology方和以太坊方均有Relayer负责将来自Ontology的交易在poly Chain上链,以及将poly chain上的交易放到以太坊。这两个Relayer是由Go语言实现的服务进程。

然而我们发现,这两个Relayer都缺乏有效的校验。这导致

攻击者可以在Ontology构造一条恶意的跨链交易,并且成功打包到poly chain上。

虽然在以太坊的Relayer具有校验功能,但是攻击者可以直接同以太坊上的链上合约进行交互,直接执行恶意的函数。

Ontology Relayer完全信任来自Ontology上的跨链交易

Poly Network 的 ont_relayer(https://github.com/polynetwork/ont-relayer) 负责监听 Ontology 链上的跨链交易并将其打包入传入Poly Chain.

动态 | Poloniex已重新启用PASC钱包:据Poloniex官方消息,此前遭禁用的Pascal Coin (PASC)钱包已重新启用。9月4日消息,由于PASC存取款存在问题,Poloniex暂时禁用PASC钱包。[2019/9/5]

注:

在Ontology Relayer中,Side 指 Ontology Chain; Alliance 指 Poly Chain.

CrossChainContractAddress 是 Ontology 链上原生编号为 09 的智能合约.

上图中,Ontology Relayer启动时开启三个 Goroutines 分别负责监听 Ontology Chain 和 Poly Chain 的跨链交易,以及对 Poly Chain 上的跨链交易做状态检查。在本报告中,我们只关注69行的监听Side的代码逻辑。

在上图中,Ontology Relayer 调用 Ontology 链提供的 RPC 接口(第 215 行,调用SDK函数 GetSmartContractEventByBlock) 获取区块中触发的智能合约事件;然后在第 228 和 232 行表明 Ontology Relayer 只监听 Ontology Chain 上由 CrossChainContractAddress 触发的 makeFromOntProof 事件;

上图中,在处理 Ontology Chain 上的跨链交易时,Ontology Relayer 总共做了五次校验,分别是两次向 Ontology Chain 发送的 RPC 请求校验(check 1 和 check 4), 以及三次参数是否为空的校验(check2, check3, 和check5)。这五次校验都属于常规校验,并未对来自 Ontology Chain 上的跨链交易做语义上的校验; 第 167 和 171 行取出了在目标链上执行所需要的交易参数信息(proof, auditPath);第 183 行向 Poly Chain 发送交易;

Ontology Relayer 在构造了 Poly Chain 上的交易后便向 Poly Chain 发起 RPC 请求发送交易(第 164 行,函数调用 SendTransaction);

这个名为 ProcessToAliianceCheckAndRetry 的 Goroutine 也仅仅是做了重发失败交易的工作,仍然未对来自 Ontology Chain 上的跨链交易做任何语义上的校验。

至此,我们可以看出 ont-relayer 监听所有来自 Ontology Chain 由 CrossChainContractAddress 触发的 makeFromOntProof 事件,并未对其做任何语义上的校验,便向 Poly Chain 转发了交易。而任何人向 Ontology 发送的任何跨链交易都会触发 CrossChainContractAddress 的 makeFromOntProof 事件,所以 Ontology Relayer 会将所有来自 Ontology 上的跨链交易都转发到 Poly chain 上。

Ethereum Relayer中的无效校验

Ethereum Relayer 负责监听 Poly Chain 并将目标链为 Ethereum 的跨链交易转发到 Ethereum 上。

Ethereum Relayer 启动一个 Goroutine 来监控 Poly Chain;

Ethereum Relayer监听所有 Poly Chain 上目标链为 Ethereum 的跨链交易 (第 275 至 278 行); Ethereum Relayer会校验跨链交易的目标合约是否为 config.TargetContracts中指定的合约之一,如果不是则不会发送这笔跨链交易到 Ethereum 上(第 315 行)。

虽然 Ethereum Relayer 对 Poly Chain 上的跨链交易做了部分校验,比如限制了目标合约,但是与 Poly Chain 不同,任何人都可以向 Ethereum 上的EthCrossChainManager合约发送交易。换句话说,Ethereum Relayer 在这里做的校验没有实际的意义,只要包含恶意payload的跨链交易被成功打包进了 Poly Chain(虽然没有被relay转发到以太坊链上), 那么任何人都可以直接使用已经打包好的区块数据将payload发送到以太坊EthCrossChainManager合约并执行(这个过程中,可以通过merkle proof的校验,因为是已经正常上链的poly chain区块数据)。

攻击者正是利用了上述两个缺陷,完成了攻击流程中的步骤一和步骤二。

通过对整个攻击流程的完整梳理和详尽分析,我们认为Relayer的不完整校验是攻击得以发生的根本原因。其它(诸如利用hash冲突等)方面则更多地属于比较精彩的攻击技巧。总而言之,跨链的校验和鉴权是跨链系统安全的关键所在,值得社区付出更多的努力。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

水星链

Fil区块链技术如何帮助企业加速数字转型?_区块链:B2B

近年来,商业世界出现了新的发展趋势。在一个广泛数字化转型的时代,企业要想生存下去,关于如何安排业务流程并将其整合到有效的商业模式中的战略决策至关重要,因此管理团队必须认识到数字技术为自己企业带来.

[0:46ms0-1:49ms