Blast 鏈 9700 萬美元爭奪戰，某國黑客生疏了？

撰文：CertiK

背景

Blast 是由 Blur 的創始人 Pacman(Tieshun Roquerre、aka.鐵順 ) 推出的 Ethereum Layer2 網絡，在 2 月 29 日啟動主網，目前約有 19500 ETH 和 640000 stETH 質押在 Blast 主網。

被攻擊的項目 Munchables 是 Blast 舉辦的 Bigbang 競賽勝出的優質項目。

Blast 官方對質押 ETH 在 Blast 主網的用戶會發放普通積分：

為了鼓勵用戶參與 Blast 生態上的 DeFi 項目，Blast 官方會挑選出優質項目進行推薦，並鼓勵用戶將 ETH 二次質押到 DeFi 裡，可以獲得更快的積分增加速度以及黃金積分，因此有相當多的用戶將質押在 Blast 主網的 ETH 質押到了新創建的 DeFi 項目。

而這些 DeFi 項目的成熟度、安全性還有待考察，這些合約是否具有足夠的安全考慮來保管用戶的數千萬、甚至上億美元。

事件概述

Blast 主網上線不到一個月，在 2024 年 3 月 21 日就發生了針對 SSS Token（Super Sushi Samurai）的攻擊，Token 合約中存在一個轉賬邏輯錯誤，導致攻擊者可以憑空增加指定賬戶的 SSS Token 餘額，最終項目損失了超過 1310 ETH（約 460 萬美元）。

而在 SSS Token 攻擊事件過去不到一週的時間，Blast 上又發生了一起更大的攻擊事件，Munchables 項目被攻擊者一把卷走了 17413.96 ETH，共約 6250 萬美元。

在這筆攻擊交易發生的半小時後，項目方合約裡的 73.49 WETH 也被黑客盜取到的另外一個地址。

此時項目方的合約地址上，還存著 7276 個 WETH、7758267 個 USDB、4 個 ETH，隨時會落入黑客手裡，而黑客擁有拿走整個項目的所有資金的權限，共計約 9700 萬美元暴露於風險之中。

在事件後發生的第一時間，X（Twitter）的知名鏈上偵探 zachXBT 指出本次攻擊的根本原因是由於僱傭了某國黑客所致。

讓我們深入看看，「某國黑客」是如何完成一次接近一億美元的攻擊。

現場還原

受害者發聲

[UTC+0]2024 年 3 月 26 日 21 點 37 分（攻擊發生 5 分鐘後），Munchables 官方在 X（Twitter）發文表示遭到攻擊。

按鏈上偵探 ZachXBT 的調查，是因為他們有一位開發者是「某國黑客」，aavegotchi 的創始人 coderdannn 也在 X（Twitter）上表示：「Aavegotchi 的開發團隊 Pixelcraft Studios 在 2022 時曾短期僱用過 Munchables 攻擊者來進行一些遊戲開發工作，他技術很糙，感覺確實像一名某國黑客，我們在一個月內解僱了他。他還試圖讓我們僱用他的一位朋友，那個人很可能也是一名黑客。」

由於這次攻擊讓社區的用戶損失巨大，我們立即啟動了鏈上調查，讓我們深入看看這個「某國黑客」的攻擊細節。

第一現場

[UTC+0]2024 年 3 月 26 日 21 點 32 分，涉及 17413.96 ETH 的攻擊發生了。

通過 Blastscan 我們可以看到這筆攻擊交易：https://blastscan.io/tx/0x9a7e4d16ed15b0367b8ad677eaf1db6a2a54663610696d69e1b4aa1a08f55c95

受損合約（0x29..1F）是一個代理合約，存放了用戶質押的資金，我們可以看到，攻擊者調用了質押合約的 unlock 函數，並通過了所有的權限校驗，轉走了合約中所有的 ETH 到攻擊者地址 1（0x6E..c5）。

看上去攻擊者調用了一個類似 withdraw 行為的 unlock 函數，取走了受損合約（0x29..1F）上大部分 ETH。

是項目方的金庫忘了上鎖嗎？

受損合約（0x29..1F）中的 unlock 存在兩個相關校驗，我們一個一個來看。

首先，我們發現在校驗權限的流程中，調用了合約（0x16..A0）的 isRegistered 方法來查看當前的 msg.sender，也即是黑客地址 1（0x6E..c5）是否已經被註冊過：

答案是：通過了驗證。

這裡涉及到了合約（0x16..A0）以及其對應的最新的邏輯合約（0xe7..f1）

[UTC+0]2024 年 3 月 24 日 08 點 39 分（攻擊發生的 2 天前），合約（0x16..A0）對應的邏輯合約被升級了。

邏輯合約升級交易：

https://blastscan.io/tx/0x9c431e09a80d2942319853ccfdaae24c5de23cedfcef0022815fdae42a7e2ab6

邏輯合約被更新至 0xe7..f1。

最初的邏輯合約地址在這裡能看到，為 0x9e..CD。

https://blastscan.io/tx/0x7ad050d84c89833aa1398fb8e5d179ddfae6d48e8ce964f6d5b71484cc06d003

此時，我們懷疑黑客是更新代理合約的邏輯實現合約，將為 0x9e..CD 變成惡意的 0xe7..f1，完成了驗證權限的繞過。

真的是這樣嗎？

在 Web3.0 從來不需要猜測和聽信別人，你只需要掌握技術就能自己得到答案。

我們通過對比兩份合約（未開源合約），最初的 0x9e..CD 合約與更新後 0xe7..f1 存在一些明顯的區別:

0xe7..f1 的 initialize 函數部分實現如下：

0x9e..CD 的 initialize 函數部分實現如下：

可以看到，攻擊者在最初的邏輯合約（0x9e..CD）中，將攻擊者地址（0x6e..c5）設置為 register，同時還有其他兩個攻擊者地址 0xc5..0d、0xbf..87 也被 register 了，並且它們的 field0 被設置為初始化時的區塊時間，field0 後面會解釋用處。

實際上，和我們猜測的恰好相反，真正的藏有後門的邏輯合約，反而是最初就存在，而後面更新的反而是正常的！

等等，這個更新出現在[UTC+0]2024 年 3 月 24 日 08 點 39 分（攻擊發生的 2 天前），也就是在這個事件之前，邏輯合約已經變成沒有後門的合約了，為什麼後面攻擊者還可以完成攻擊？

這是因為 delegatecall 的原因，所以實際的狀態存儲更新是在合約（0x16..A0）中，這也就導致了即使之後邏輯合約被更新至沒有後門的邏輯合約 0xe7..f1，合約（0x16..A0）中被更改的 slot 依然不會恢復。

我們來驗證一下：

可以看到，合約（0x16.....A0）中對應的 slot 是有數值的。

這使得攻擊者能夠通過 isRegistered 方法的校驗：

攻擊者之後再將後門合約更換為正常合約掩人耳目，其實此時後門早已種下。

另外，在 unlock 的流程中，還涉及到第二個校驗：

對於 lock 時間的檢查，這一部分是保證鎖定的資產不會在未到期就被轉走。

攻擊者需要保證當 unlock 被調用時的區塊時間大於要求的鎖定過期時間 (field3)。

這一部分校驗就涉及到受損合約 (0x29..1F) 以及對應的邏輯合約 0xf5..cd。

在[UTC+0]2024 年 3 月 21 日 11 點 54 分（攻擊發生的 5 天前）的交易中，

https://blastscan.io/tx/0x3d08f2fcfe51cf5758f4e9ba057c51543b0ff386ba53e0b4f267850871b88170

我們可以看到受損合約 (0x29..1F) 合約最初的邏輯合約是 0x91..11，而在僅僅四分鐘後，就在

https://blastscan.io/tx/0xea1d9c0d8de4280b538b6fe6dbc3636602075184651dfeb837cb03f8a19ffc4f

被升級為了 0xf5..cd。

我們同樣來對比兩份合約，可以發現攻擊者和之前一樣，也在 initialize 函數做了手腳，

0xf5..cd 的 initialize 函數部分實現：

0x91..11 的 initialize 函數部分實現：

可以看到，很明顯的，又是運用了同樣的手法，將自己持有的 ETH 數量&解鎖時間都進行了篡改，之後再替換回正常合約掩人耳目，當項目方和安全研究人員在 Debug 的時候，看到的邏輯合約全是正常的，而且由於合約均為未開源合約，更難以看清問題的核心。

至此，我們瞭解了這筆涉及 17413 ETH 的交易，攻擊者是如何做到的，但是這個事件背後的信息，只有這麼多嗎？

我們上面的分析中，其實看到黑客在合約內部內置了 3 個地址：

0x6e..c5（攻擊者地址 1）

0xc5..0d（攻擊者地址 2）

0xbf..87（攻擊者地址 3）

而我們上面發現的攻擊交易中只看到 0x6e..c5，其他兩個地址都做了什麼？而且裡面的 address(0)、_dodoApproveAddress、_uniswapV3Factorty 到底還隱藏著什麼秘密？

第二現場

我們先來看看攻擊者地址 3（0xbf..87），通過同樣的手法盜取了 73.49 WETH：

https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233

並且攻擊 gas 的來源地址（0x97..de），同時給 0xc5..0d（攻擊者地址 2）和 0xbf..87（攻擊者地址 3）都提供了手續費。

而攻擊 gas 來源地址（0x97..de）的 0.1 ETH 的資金源頭來自 owlto.finance（跨鏈橋）。

0xc5..0d（攻擊者地址 2）收到手續費後，並未進行任何攻擊，但它其實肩負了一個隱藏的計劃，我們繼續看下去。

實際上，根據官方的事後救援交易，原來受損合約 (0x29..1F) 地址上並不止 73.49 枚 weth，直到攻擊結束，也仍有 7276.5 WETH & 7758267 USDB。

救援交易：

https://blastscan.io/tx/0x1969f10af9d0d8f80ee3e3c88d358a6f668a7bf4da6e598e5be7a3407dc6d5bb

原本攻擊者是打算盜取這些資產的，可以看到 0xc5..0d（攻擊者地址 2）這個地址原本是用來偷取 USDB 的。

這裡的_dodoApproveAddress 為 0x0000000000000000000000004300000000000000000000000000000000000003

為 usdb 的 address

0xbf..87（攻擊者地址 3）這個地址是用來偷取 weth 的：

這裡的_uniswapV3Factory 為 0x0000000000000000000000004300000000000000000000000000000000000004

為 weth 的 address

而 0x6e..c5（攻擊者地址 1）負責盜取的是 address(0)，即是原生資產 ETH。

攻擊者通過設置 field0，即可通過如下邏輯對對應資產進行盜取：

問題

為什麼攻擊者沒有盜走所有資產？

理論上他可以盜取所有的資產，即剩下的 WETH 和 USDB。

0xbf..87（攻擊者地址 3）只盜取了 73.49 WETH，0xbf..87（攻擊者地址 3）其實完全可以把所有的 7350 WETH 拿走，也可以藉助 0xc5..0d（攻擊者地址 2）把 7758267 USDB 全部拿走，為什麼只拿了一點點 WETH 就停下來了，我們不得而知，可能需要知名鏈上偵探深入內部的調查了。

https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233

為什麼攻擊者沒有把 17413ETH 轉到 Ethereum 主網？

眾所周知，Blast 主網是有可能通過中心化的方式攔截這些 ETH，讓它永久停留在這裡，從而不會造成實質上的用戶損失，但是一旦這些 ETH 進入 Ethereum 主網，就沒有辦法攔截了。

我們評估了當前 Blast 的跨鏈橋，官方跨鏈橋沒有限制數量，但是需要 14 天的退出時間，因此足以讓 Blast 官方來準備攔截的計劃。

而第三方的跨鏈橋是可以接近實時到賬的，就像攻擊者的手續費來源一樣，很快完成跨鏈，為什麼攻擊者沒有第一時間進行跨鏈？

實際上攻擊者在第一時間（攻擊的 2 分鐘內）進行了跨鏈：

https://blastscan.io/tx/0x10cf2f2b884549979a3a1dd912287256229458ef40d56df61738d6ea7d9d198f

而且資金花了 20 秒就在 Ethereum 主網到賬了，理論上攻擊者可以持續不斷進行跨鏈，可以在跨鏈橋人工干預之前，將大量 ETH 跨鏈轉走。

至於為什麼只能每次 3 ETH，原因是跨鏈橋的流動性限制，從 Blast 上跨到 ETH 上：

另一家支持 Blast 的跨鏈橋則支持的更少：

而在這一筆跨鏈交易後，攻擊者沒有繼續其他的跨鏈操作，原因我們不得而知，看上去「某國黑客」似乎是沒有為資金退出 Blast 進行充足的準備。

攻擊後的事件發展

根據社區用戶 Nearisbuilding 的反饋，他找到了攻擊者的更多身份信息，並且想辦法促使攻擊者歸還資金。

https://twitter.com/Nearisbuilding/status/1772812190673756548

最終，在加密社區的關注和努力下，「某國黑客」也許因為害怕暴露身份，向項目方提供了以上 3 個攻擊者地址的私鑰，並歸還了所有資金，項目方也進行了救援交易，把受損合約的資金全部轉到多籤合約進行保管。