背景

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個攻擊者地址的私鑰， 並歸還了所有資金 ，項目方也進行了救援交易，把受損合約的資金全部轉到多籤合約進行保管。