从安全研究员的视角回顾Poly Network黑客事件

在这篇博客中，我们想要回顾Poly Network被黑客攻击的整个过程，并讨论由此吸取的教训。

我们知道Poly Network于2021年8月10日被黑客攻击（本博客使用+8时区）。然而，我们对攻击是如何发生的，以及攻击的根本原因一无所知。作为一个安全研究团队，我们开始了我们的调查。

第一步：找到攻击交易

我们在交易虚拟化系统（https://tx.blocksecteam.com）中回放了攻击交易 0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a。

交易追踪非常简单，这与其他操纵价格的攻击不同。那些攻击通常有非常复杂的函数调用（请参阅Popsicle黑客攻击）。

第二步：分析合约代码

获取攻击追踪后，我们需要审查合约的源代码。令人惊讶的是，Poly Network在Etherscan上没有经过验证的源代码。然而，我们设法在github上找到了发布的源代码。

在审查了源代码后，我们没有发现任何明显的代码漏洞。我们还将攻击追踪与合法交易追踪进行了比较，发现它们是相似的。

第三步：恢复关键状态

然后我们恢复了攻击期间的关键状态。由于攻击是从调用VerifyHeaderAndExecuteTxEvent发起的，我们恢复了几个关键变量的值，我们已经在第一次分析中分享了这些值 [1]。

在此过程中，我们发现只有一个 keeper（见上图）。由于该值是从攻击追踪中获取的，并且攻击交易已通过所有签名验证，因此我们认为潜在原因可能是私钥泄露或服务器签名过程中的错误 [1]。

然而，我们在这里犯了一个错误。分析一次攻击就像剥洋葱，一层一层地剥，直到找到真正的“根本根本”原因。当时，我们没有继续深挖，看看keeper是否被更改了！

第四步：新线索

几个小时后，Kelvin和slow mist在Twitter上提供了新线索，显示keeper已被更改。更改过程滥用了哈希碰撞来调用一个强大的函数——一个“智能”的黑客攻击。

现在我们意识到我们的第一次分析并不完整。基于最新信息，我们回放了更改keeper的交易。交易追踪仍然非常简单。

但请记住，在此交易过程中，有四个keeper（而不是一个）。所有这些密钥与其他合法交易的密钥相同——这意味着这些密钥是合法的。这里出现了一个问题：为什么更改keeper的交易可以被打包到链上并被执行呢？

第五步：定位源交易

然后我们尝试定位源交易，因为Poly Network是一个跨链桥。某个地方应该存在一个源交易。我们通过解码关键变量（如下所示）来做到这一点。它显示了源链和Poly链的交易哈希。

有一个技巧是其他地方没有提及的。变量中的tx哈希值与Poly链上的官方值表示不同。例如，图中Poly链的tx哈希是0x80cc978479eb082e1e656993c63dee7a5d08a00dc2b2aab88bc0e465cfa0721a。但在Poly链浏览器中，哈希值是1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80（你看到区别了吗？）。我们在8月11日16:55在EthereumSecurity tg群组分享了我们的发现。

第六步：定位根本原因

但我们仍然无法回答“为什么更改keeper的交易可以被打包到链上”的问题。为了回答这个问题，我们从Ontology链开始，找到了交易流程：

Ontology交易 -> Ontology中继器 -> Poly链 -> Ethereum中继器 -> Ethereum

然后我们阅读了Ontology链和中继器的源代码。经过几个小时，我们发现Ontology中继器对跨链交易的验证不足。这使得恶意交易可以被打包到Poly链上。之后，系统就被攻破了。

经过内部讨论和挑战，我们在8月12日02:41在Twitter和medium上发布了我们的发现[3]。

吸取的教训

设计即安全。 安全应该贯穿DeFi项目的整个过程。用户将资金委托给项目。反过来，项目应该值得信赖。不幸的是，我们看到了Poly Network在安全方面的疏忽。例如，缺乏验证是一个老式的安全漏洞，我在本科课程中讲过。
对于TVL超过6亿美元的DeFi项目，没有经过验证的源代码。 去中心化基础设施的基础是信任，而信任的基础是透明度。不幸的是，用户愿意将资金投入一个黑箱项目，这让我感到惊讶和担忧。如何提高用户的安全意识可能需要一个新的解决方案。