在過去的一周裡，陸續發生了幾起安全事件，包括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 和relayer進行研究。我們通讀了Ontology 和relayer的代碼，發現原因是Ontology 的relayer對交易缺乏驗證。在團隊成員反复討論和互相challenge之後，我們認為這個發現是接近事實真相的。因此在12號凌晨2點41 Twitter上公佈我們的發現，並且在medium上公開我們的分析全文[3]。
自此我們的分析結束，其他安全廠商也陸續發布獨立的分析報告，比如派盾在12號早上也公佈了是由Ontology鏈發起了攻擊交易[4]。
0x2 經驗和教訓
本次事件對於整個DeFi社區是非常重要的一起安全事件，雖然攻擊者最終返還了被攻擊的數字貨幣，但就像餘弦所說”這種能力太過消耗，成本也非常高，也有運氣成分”。我們不能期待每一次的攻擊事件都會有好的結局。因此，社區如何做才能讓整個生態的安全變得更好？
要讓安全滲透到項目方的血液當中，包括安全的意識、設計、編碼、管理、運營、監控、事件處理等每一個方面。一個好的DeFi項目必須首先要是一個安全優先的項目，否則用戶將資產投入到項目裡面，他們的資產安全由誰來守護？很遺憾的是，從這個事件來看，項目方的安全設計意識是不足的。作者本人在講授本科生的軟件安全課程，我們在軟件安全第一堂課就會講威脅模型和攻擊面。很顯然，這一次的跨鏈設計並沒有對攻擊面做一個梳理，沒有在預防可能的攻擊面上有過深入思考。或者有過深入的分析，但是最後的實現並沒有完全能遵循設計。
項目方的上線合約代碼沒有經過驗證，雖然項目方在github開源了一些代碼，但是其在鏈上並沒有上傳經過驗證的代碼。去中心的基礎是信任，信任的基礎是透明。而這樣一個沒有驗證源代碼的黑盒項目居然有那麼大的鎖倉量，說明社區在繁榮的同時，用戶也缺乏必要的安全意識。如何在用戶安全意識上破局，需要新的解決方案。