从安全研究视角看Poly Network事件

在过去的一周里，陆续发生了几起安全事件，包括PolyNetwork和DaoMaker等造成大额资金损失的安全事件。虽然后续损失资金大部分或者全部被追回，但仍然给DeFi的安全敲响了警钟。

PolyNetwork: 6亿美金

DaoMaker: 700万美金

Maze: 500万美金

Punk Protocol：800多万美金

在本文中，我们主要从安全研究的视角来分析一下Poly Network攻击事件，包括如何对安全事件进行分析和复盘以及如何能将整个生态的安全性做的更好。

0x1 Poly Network安全事件

事件发生在2021年8月10日傍晚，网上一些渠道传出Poly Network被攻击的消息，但是对于攻击的手段是什么，项目方的漏洞成因并没有准确的消息。对安全研究团队来说，第一时间需要能搞清楚问题的根本原因所在（对于项目来说，更重要的是如何能通过应急响应挽回损失）。在明白问题所在之后，才能对事情的性质做基本判断：是代码漏洞所致、还是人为因素造成、亦或者是虚假消息。

0x1.1 确定攻击交易

BlockSec团队首先从以太坊的攻击交易入手，这源于我们已经有一个比较好的交易trace分析系统(https://tx.blocksecteam.com)，能用可视化的方式将函数调用过程恢复。

因此，我们首先在分析系统中重放了以太坊上的一笔攻击交易，交易hash值是：0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a。

函数调用非常清晰和简单，这和之前利用价格操纵来进行攻击的情况有非常显著的区别。在价格操纵中，攻击的trace往往非常复杂，攻击者需要经过多次的trade才能完成攻击。而在本次攻击中，攻击者只进行了有限的操作，最后就完成了资金转账。

0x1.2 分析合约代码

在捋清楚调用序列后，我们需要研究攻击合约和被攻击合约的源代码。有意思的是，被攻击合约在etherscan上是没有提交源代码验证的。也就是说， 这样一个高TVL的项目方的合约居然未发布验证的源代码！

虽然etherscan上并没有源代码，但是我们通过项目方的github一些线索和函数签名，找到了可能的源代码。因此接下来的事情就是分析源代码了。

在分析源代码的过程中，我们仔细比对了代码逻辑，并没有发现明显的逻辑漏洞。我们将该攻击交易和其他正常交易的trace进行了比较，攻击的整个调用trace和一条正常合法的交易并没有本质区别。

0x1.3 恢复关键状态

自此，分析进入了死胡同，而时间也到了深夜。在从外围没办法打开局面的情况下，我们只能去对执行过程中的关键变量进行恢复。整个的攻击过程是从函数 VerifyHeaderAndExecuteTxEvent 开始，我们恢复出来了函数的调用参数和函数执行过程中关键变量的值。这就有了我们当时在blog [1] 中所提到的关键参数的值。

通过这个过程，我们发现验证的keeper只有一个(如上图）。由于这个值是从真实的攻击交易中恢复出来的，因此是准确的 。并且我们发现攻击者的交易确实在整个过程中都通过了签名校验。结合只有一个keeper的发现，当时我们的判断是唯一的keeper私钥泄露了或者服务端签名程序有bug[1]。

这里我们犯了一个错误，做攻击分析，要像剥洋葱一样一层一层深入进行，只有找到真正的“root root root cause”才能结束。 因此，虽然我们从当时的表象“一个keeper，签名校验也是通过的”得出了两个可能“私钥泄露或者服务端签名有bug”，但是没有并没有进一步去研究keeper是否被人修改过，而这正是整个攻击比较关键的一步。写完初步分析文章已经是凌晨3点，于是就各自回家休息。

0x1.4 新的线索

在早上醒来后，发现twitter上Kelvin和慢雾都分别给出了新的线索。新的线索表明，keeper曾经被修改过，并且修改keeper是通过hash 碰撞来完成的。

这个时候，我们意识到第一次的分析还不完整。 因此，根据新的线索，我们很快也确认了修改keeper的交易是0xb1f70464bd95b774c6ce60fc706eb5f9e35cb5f06e6cfe7c17dcda46ffd59581。

修改keeper的交易并没有复杂之处（除了Kevin在twitter上提到的hash碰撞[2]是一个非常巧的攻击技巧 -- CTF选手注意了，以后可能会有类似的CTF赛题）。

但是请注意，在这一次修改keeper的交易中，keeper还没有被修改，是4个keeper（见下图），而且这4个keeper和合法交易一样 -- 说明key是官方的 。这一笔恶意交易也完整地通过了签名校验。 那么攻击者是如何能让这一笔攻击交易上链并且能得到执行呢？也就是说，这个时候，最根本的原因还没有找到。

0x1.4 寻找源头交易

由于有了第一次的教训，我们并没有到此就结束分析，而是继续挖掘下去，并且在twitter上和社区交流。

既然从以太坊来看这是一条合法的交易，那么这个交易是怎么最初到以太坊上的呢？我们沿着这个思路，仔细研究了项目的白皮书和源代码。Poly是一个跨链的平台，用来在不同的链之间进行资产转移。因此在以太坊上的调用是目标链，那么必然存在一条源头链，用来发起交易。

我们通过以太坊上的交易进而找到了poly chain（中间链）上的交易。根据poly chain上的中间交易，进而找到了源头的Ontology链。

这里有一个非常隐蔽的点，曾经困扰了我们很久 。因为有了修改keeper的以太坊交易trace，我们已经能恢复出来关键的交易hash。 比如下图中的txHash。从ChainID，我们很容易知道Poly chain和 Ontology链上的交易hash，但是我们使用这个hash并没有在这两个链上找到完整的交易，难道是恢复出来的数据不对?

经过一番的努力，我们终于发现， 是因为参数中的hash和在链上的交易hash数据表达方式不同（类似大端和小端）。 比如图中的polychain的txHash是0x80cc978479eb082e1e656993c63dee7a5d08a00dc2b2aab88bc0e465cfa0721a。

但是在polychain浏览器中，hash是1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80（发现区别了吗？）。发现这个关键的点之后，我们找到了polychain上的交易以及源头本体链上的交易，于是在11号下午16：55我们在tg上向社区分享了我们的发现。

0x1.5 寻找根本原因

但是这个时候，仍然不能回答”为什么这个交易会被上链“？ 如果不能回答这个问题，对于漏洞仍然没有找到根本原因 。因此我们继续从 Ontology链入手，追踪整个交易流向。我们发现整个交易的流向如下：

Ontology transaction -> Ontology relayer -> Poly chain -> Ethereum relayer -> Ethereum

因此想要弄清楚问题的本质，还需要对Ontology 和 relayer进行研究。我们通读了Ontology 和 relayer的代码，发现原因是 Ontology 的relayer对交易缺乏验证。在团队成员反复讨论和互相challenge之后，我们认为这个发现是接近事实真相的。因此在12号凌晨2点41 Twitter上公布我们的发现，并且在medium上公开我们的分析全文[3]。

自此我们的分析结束，其他安全厂商也陆续发布独立的分析报告，比如派盾在12号早上也公布了是由Ontology链发起了攻击交易[4]。

0x2 经验和教训

本次事件对于整个DeFi社区是非常重要的一起安全事件，虽然攻击者最终返还了被攻击的数字货币，但就像余弦所说”这种能力太过消耗，成本也非常高，也有运气成分”。我们不能期待每一次的攻击事件都会有好的结局。因此，社区如何做才能让整个生态的安全变得更好？

要让安全渗透到项目方的血液当中，包括安全的意识、设计、编码、管理、运营、监控、事件处理等每一个方面。一个好的DeFi项目必须首先要是一个安全优先的项目，否则用户将资产投入到项目里面，他们的资产安全由谁来守护？很遗憾的是，从这个事件来看，项目方的安全设计意识是不足的。作者本人在讲授本科生的软件安全课程，我们在软件安全第一堂课就会讲威胁模型和攻击面。很显然，这一次的跨链设计并没有对攻击面做一个梳理，没有在预防可能的攻击面上有过深入思考。或者有过深入的分析，但是最后的实现并没有完全能遵循设计。

项目方的上线合约代码没有经过验证，虽然项目方在github开源了一些代码，但是其在链上并没有上传经过验证的代码。去中心的基础是信任，信任的基础是透明。而这样一个没有验证源代码的黑盒项目居然有那么大的锁仓量，说明社区在繁荣的同时，用户也缺乏必要的安全意识。如何在用户安全意识上破局，需要新的解决方案。