从安全研究的角度看多网络事件

最近一周，接连发生了几起安全事件，包括PolyNetwork、DaoMaker等安全事件，造成了较大的财务损失。虽然后来损失的资金大部分或全部被追回，但还是给德菲的安全性敲响了警钟。

Multi-network:600milliondollarsKnights:7milliondollarsMaze:5milliondollars

Punkagreement:morethan8milliondollars

本文主要从安全研究的角度对聚网攻击事件进行分析，包括如何对安全事件进行分析和恢复，如何让整个生态的安全性更好。

0x1保利网络安全事件发生在2021年8月10日晚。有网络渠道报道保利网被攻击，但没有准确的攻击手段和项目漏洞原因的信息。。对于安全研究团队来说，需要在第一时间找出问题的根源(对于项目来说，更重要的是如何通过应急响应挽回损失)。理解问题后才能对事情的性质做出一个基本的判断：是代码漏洞导致的，还是人为因素导致的，还是虚假消息导致的。

0x1.1确定攻击交易。BlockSec团队首先从以太坊的攻击交易入手。这是因为我们已经有了一个很好的事务痕迹分析系统(https://tx.blocksteam.com)，可以用可视化的方式还原函数调用过程。

因此，首先我们在分析系统中的以太坊上重放一个攻击交易，交易的哈希值为：0xd8C1f7424593ddba11a0e072b61082BF3d931583CB75f7843fc2a8685d20033a。

函数调用非常清晰简单，与之前的价格操纵攻击有非常显著的区别。在价格操纵中，攻击的痕迹往往非常复杂，攻击者需要经过多次交易才能完成攻击。在这次袭击中，攻击者只进行了有限的操作，最终完成了资金的转移。

0x1.2契约代码分析整理完调用序列后，我们需要研究被攻击契约的源代码和被攻击的契约。什么'；有趣的是被攻击的合同没有在etherscan上提交进行源代码验证。换句话说，这样一个高TVL项目方的合同并没有公布经过验证的源代码！

虽然以太扫描上没有源代码。但是，我们通过项目的一些线索和函数签名找到了可能的源代码'；sgithub。所以接下来的事情就是分析源代码了。

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

0x1.3恢复临界状态。从此分析进入死胡同，夜深了。。在这种情况下，我们可以'；不能从外围打开局面，只能还原执行过程中的关键变量。整个攻击过程从函数VerifyHeaderAndExecuteTxEvent开始在函数执行期间，我们恢复了函数的调用参数和关键变量的值。这里面有我们当时在博客[1]中提到的关键参数的值。

通过这个过程，我们发现只有一个验证过的保管员(如上图)。这个值是准确的，因为它是从真实的攻击事务中恢复的。我们发现攻击者'；的交易在整个过程中确实通过了签名验证。。结合发现只有一个keeper，我们当时的判断是唯一的keeper私钥泄露了或者是服务器签名程序出现了bug[1]。我们在这里犯了一个错误。我们应该像剥洋葱一样一层一层地做攻击分析。只有找到真正的根源根源"能结束吗？因此，尽管我们从"一个保管员，签名验证通过"那时，"私钥泄露或服务器上的签名有问题"但对于keeper是否被修改，并没有进一步的研究，这是整个攻击的关键一步。写完初步分析文章，已经凌晨3点了，回家休息。

0x1.4新线索早上醒来。发现twitter上的开尔文和慢雾分别给出了新的线索。新的线索显示，keeper被修改过，对keeper的修改是通过哈希碰撞完成的。此时

我们意识到第一次分析并不完整。因此，根据新的线索，我们很快确定了修改保管员的交易是0xB1f70464BD95b774ce60f706e5BF9e35CB5f06ECFe7c17dcda46ffd59581。

修改守护者并不复杂'；s交易(除了凯文在推特上提到哈希碰撞[2]是一个非常巧妙的攻击技能——CTF选手注意了，以后可能还有类似的CTF比赛)。

但是请注意，在这个修改保管员的交易中，保管员并没有被修改，而是有四个保管员(见下图)，而且这四个保管员和合法交易一样——表示钥匙是官方的。。这次恶意交易也完全通过了签名验证。那么攻击者如何在线获得这个攻击交易并被执行呢？换句话说，这个时候，还没有找到最根本的原因。

0x1.4查找源事务由于第一课的原因，我们没有'；我没有在这里结束分析，而是继续挖掘并在twitter上与社区交流。

既然从以太坊的角度来看这是一笔合法的交易，那么这笔交易最初是如何到达以太坊的呢？沿着这个思路，我们仔细研究了该项目的白皮书和源代码。保利是一个跨链平台，用于不同链之间的资产转移。。所以以太坊上的调用是目标链，所以必须有一个源链来发起交易。

我们通过以太坊上的交易找到了聚链上的交易。根据聚链上的中介交易然后找到了源头的本体链。

有一个非常隐蔽的点困扰了我们很久。因为门神的改装'；的以太坊交易痕迹，我们已经能够恢复关键的交易哈希。。比如下图中的txHash。从ChainID中，我们可以很容易地知道聚合链和本体链上的事务哈希，但是我们可以'；使用这个散列在这两个链上找不到完整的事务。

经过一番努力，我们终于发现，是因为参数中的哈希数据和链中的事务哈希数据的表达方式不同(类似于大端和小端)。。比如图中的多链的txHash是0x80cc978479EB082E1e656993c63dee7a5d08a00DC2b2aab88BC0e465CFA0721a.

但是在polychain浏览器中，hash是1a72a0cf654c08bb8aab2c20da085d7aee3c69369651e2e08EB798497cc80(你发现区别了吗？)。发现这个关键点后，我们发现了polychain上的事务和源本体链上的事务，于是在11日下午16:55，我们在tg上与社区分享了我们的发现。

0x1.5寻找根本原因，但此时，仍然可以'；t回答"为什么这项交易会被终止？如果可以'；不回答这个问题，你还是没有'；没有找到漏洞的根本原因。所以我们继续从本体链入手，跟踪整个交易流程。.Wefoundthattheflowofthewholetransactionisasfollows:

ontologytransaction-

ontologyrelay-

aggregationchain-

以太坊中继——

以太坊

因此，为了理解问题的本质，有必要对本体和中继进行研究。。我们通读了Ontology和relayer的代码，发现原因是Ontologyrelayer缺乏对事务的验证。经过团队成员反复讨论，互相挑战，我们认为这个发现接近真相。。于是我们于12日凌晨2:41在推特上公布了我们的发现，并在medium[3]上发表了我们分析的全文。

自我们的分析结束后，其他安全厂商也陆续发布了独立的分析报告。比如派顿也在12日上午宣布了一个本体链发起的攻击交易[4]。

0x2经验教训

该事件对于整个DeFi社区来说是一个非常重要的安全事件。虽然攻击者最终归还了被攻击的数字货币，正如余弦所说，"这个能力太贵了，成本很高，还有运气。"。我们可以'；不要指望每次攻击都有好结果。所以，社区怎么做才能让整个生态更安全？

让安全渗透到项目方的血液里。，包括安全意识、设计、编码、管理、操作、监控、事件处理等各个方面。一个好的DeFi项目首先必须是安全优先的项目，否则用户将自己的资产投入到项目中，谁来保护自己的资产？不幸的是，从这次事件来看，项目方的安全设计意识不足。作者本人是教本科软件安全课程的，我们会在软件安全第一节课讲威胁模型和攻击面。显然，这一次的跨链设计并没有梳理出攻击面。我还没有'；没有深入思考如何防止可能的攻击。或者有过深入的分析，但是最后的实现并没有完全按照设计来。

虽然项目方在github中开放了部分代码，但是项目方的在线合同代码并没有得到验证。但它没有'；不上传链上的验证码。去中心化的基础是信任，信任的基础是透明。但是，这样一个没有经过验证源代码的黑箱项目，锁的数量如此之大，说明在社区繁荣的同时，用户也缺乏必要的安全意识。

相关内容