“Trust but verify”(信任，但要核查)，不要做“事後諸葛亮”。最厲害的bug 都是燈下黑。
由於合約的不可變性， 項目會隱性依賴多年前編寫的代碼， 我們在修復bug 時，就更需要注意它的潛在影響。
這次的事情是這樣發生的。
時間線
在本文中，我會用“我們”來指代所有為這次事件努力的人。我覺得，雖然我最初對發現漏洞作出了一些貢獻，但在整個過程中，有無數人提供了更多的幫助。
13:10 UTC pETH/ETH 1100 萬美元[1] 流失。
13:19 UTC Michal 在ETHSecurity 上發布有關pETH 價格突然暴跌的消息。
Igor 首先註意到不對勁。多虧了他，我們開始深入調查。
但是機器人是如何在remove_liquidity()調用中重入add_liquidity()的呢？
14:01 UTC 就這個問題組建了一個應急小組。
14:07 UTC 我們用我們最喜歡的反編譯器[2]反編譯了JPEGd 合約，並註意到重入保護存儲槽有點不同。
// Dispatch table entry for add_liquidity(uint256[2],uint256)
label_0057:
if (storage[0x00]) { revert(memory[0x00:0x00]); }
storage[0x00] = 0x01;
// Dispatch table entry for remove_liquidity(uint256,uint256[2])
label_1AF3:
if (storage[0x02]) { revert(memory[0x00:0x00]); }
storage[0x02] = 0x01;
14:27 UTC 我們通過一個簡單的本地測試合約確認了這個問題。
@external
@nonreentrant(“lock”)
def test(addr: address) -> bool:
return True
@external
@nonreentrant(“lock”)
def test2(addr: address) -> bool:
return False
這不僅僅是另一個重入bug。
此時，我們意識到這將產生多大的影響。封鎖消息，我們刪除了有關該漏洞的公開消息。
14:37 UTC Wavey 幫助確認了存在漏洞的提交和受影響的版本。我和Charles 通過手動檢查Vyper 編譯器輸出也證實了這一點。
這是一場與黑客的競賽。
值得慶幸的是，人們還將其與只讀重入混淆。摘自“Web3 安全警報” 頻道-Alchemix 和Metronome DAO 也因只讀重入bug 遭到黑客攻擊[3]
Michael 發現運行0.2.15 版本的alETH 和msETH 池也存在潛在漏洞。
14:50 UTC msETH/ETH 被耗盡[4]。
15:34 UTC alETH/ETH 被耗盡[5]。
15:43 UTC 我們發現用Vyper 版本0.3.0 編譯的CRV/ETH 存在漏洞[6]。我們必須盡可能長時間保密受影響的合約，這一點至關重要。
16:11 UTC 我們開始研究白帽漏洞。
不幸的是，太多的組織在同時進行獨立研究，謠言四起。 16:44 UTC，我們決定針對受影響的版本發佈公開聲明[7]。
到18:32 UTC，我們有了一個可用於潛在白帽拯救的概念證明漏洞。 Chainlight 的bpak 也同時在研究一個漏洞，並於19:06 UTC 分享。
五分鐘後，19:11 UTC，有人盜走了資金[8]。
攻擊結構與我們的概念證明有很大不同，不太可能是我們團隊洩密。無論如何，這非常令人沮喪。
儘管如此，還有很多事情要做。
21:26 UTC Addison 提出了一個雄心勃勃的計劃，拯救CRVETH 池中的剩餘資產。
如果你將30k crv 發送到crv/eth 池，
你可以更新管理費（admin fee） 然後設置crv/eth 費率約為每個crv 0.15 eth
基本上可以全部提取走池中的數百K crv
21:52 UTC bpak 做了一個可行的概念證明，可以拯救3100 ETH。
十分鐘後，22:02 UTC，我們再次被擊敗。出乎意料的是，CRV 管理費用機器人[9]已被取走資金，並且池子已耗盡[10]。
責備
責備(Balme) 是一個很強烈的詞。指責是沒有用的。我認為思考一下哪些方面可以做得更好才是有用的。
競賽
白帽的努力都在不到半小時的時間內被擊敗。有時候，每一秒都非常重要。
也許可以有更好的準備和資源來執行這些攻擊。同時，這似乎是一把雙刃劍。把如何執行黑客攻擊的信息匯總起來真的是個好主意嗎？我們應該信任誰？
另一方面，我認為整個過程非常有效。我們在2 小時4 分鐘內從最初的懷疑到確認出誰易受攻擊。
信息洩露
我既是審計員又是白帽黑客。
審計行業有著特有的發布文化。我們因技術思想領先和對漏洞的深刻理解而獲得報酬。證明他們的領先與深刻的一種方法是發布[11]有關黑客行為的“獨家新聞”。研究人員花費巨大，而投資的回報就是宣傳。
另一方面，有一個令人信服的論點認為：受影響版本的早期披露會對白帽拯救產生重大影響。
如果再多半小時，就可以拯救1800 萬美元。
審計師不會為他們的報告所造成的影響付出代價。相反，他們會得到點贊、轉發和報導。這似乎是一個問題。
下一步
我不同意“我們需要形式化驗證來解決這個問題”之類的觀點。這個錯誤可以通過單元測試來捕獲。形式化驗證對於許多錯誤類型都非常有用，但我不相信它對於相對簡單的、未優化編譯器也同樣有用。
需要注意的是，這個錯誤在2021 年11 月已修復[12]。
我認為這個Vyper 漏洞不是Vyper 團隊的技術或語言本身的問題，更多是流程問題。這個錯誤在很久以前的版本已被修復，但在修復的時候並沒有意識到它的潛在影響。
不幸的是，公共物品很容易被忽略。由於合約不可變性，項目會隱性依賴多年前編寫的代碼。協議開發人員和安全專家應該了解整個執行堆棧的最新安全開發情況。