約1130萬美元損失：Multicall Router、Nostra｜BlockSec Weekly

在過去一週(2026/09/14 - 2026/09/20),我們觀察到 2 起安全事件,估計總損失約為 1,130 萬美元。

本週焦點:Unknown Multicall Router

選擇此事件的原因是,在巢狀路由呼叫中一個細微的呼叫者身份變化,擊敗了運行自訂模組的 Safe 錢包的授權機制,並使得大量資產得以被提取。

2026 年 9 月 15 日,一個名為 Yoink 的 MEV 機器人搶先執行了一次針對 Safe 錢包的漏洞利用嘗試,該錢包透過自訂策略模組管理其資產,導致估計損失約 780 萬美元 [1]。請求透過一個 multicall 路由器到達這些模組,其中一個巢狀呼叫的授權錯誤使得未受信任的指令得以傳遞至模組鏈中,同時一個可重複使用的權限為此未授權操作提供了額外支持。

背景

Safe 錢包可以啟用一個 Safe 模組。一旦啟用,該模組即可呼叫 execTransactionFromModule() 來指示錢包執行操作,而無需多簽核准,因此一個已啟用的模組即代表對錢包資產的常設權限。受害的 Safe 錢包已啟用了兩個策略元件:Gateway 模組和 LP 模組。

Gateway 模組定義了可重複使用的指令範本,每個範本描述受害 Safe 錢包被允許執行的操作,具體數值在執行時填入。它僅接受來自其自身授權呼叫者名單中的呼叫者所發出的指令。每次執行還必須攜帶一個 Merkle 證明,該證明會與儲存的根值進行核對,以驗證所調用的指令範本。部分範本指示錢包呼叫 LP 模組,該模組使用錢包的資產執行 Uniswap v4 流動性操作。因此,控制流是透過錢包本身返回,而不是直接從一個模組傳遞到下一個模組:

Authorized Caller
       |
       v
Gateway module -- verify(command, Merkle proof, root)
       |
       | execTransactionFromModule(...)
       v
Safe wallet context
       |
       v
   LP module --> mintPosition(...)

本次事件中的操作者並未直接呼叫 Gateway 模組。請求是透過一個 multicall 路由器到達的,該路由器代表他們調度批次呼叫。由於路由器每次轉發合法請求時都是直接呼叫者,因此 Gateway 模組的授權呼叫者名單中包含了路由器本身。

透過此路徑,受害 Safe 錢包可以將 aEthrsETH(Aave 為存入的 rsETH 所發行的收據代幣)存入 Uniswap v4 資金池,並將部位 NFT 鑄造回錢包。任何持有 aEthrsETH 的人都可以透過 Aave 銷毀它以提取底層的 rsETH。

受害 Safe 錢包也曾以該 Aave 抵押品借款。因此 Aave 會為其追蹤健康係數,即其抵押品價值與債務的比率,並拒絕任何會使該係數低於 1 的抵押品轉移。

漏洞分析

位於 0x4f00...8ebC 的路由器未經過原始碼驗證。因此以下說明依賴於其已部署的位元組碼、反編譯邏輯、交易追蹤記錄以及一份公開的分叉測試重建,而非權威的原始碼層級命名。

路由器的調度邏輯接受一個目標地址,該地址可以是其白名單中的地址,也可以是路由器自身的地址,然後根據當前呼叫的 msg.sender 檢查該目標的授權呼叫者名單。在路由器對自身進行呼叫的過程中,沒有任何機制保留原始外部呼叫者的身份。

當路由器呼叫自身時,內部呼叫觀察到的 msg.sender 是路由器本身。授權輔助函式在自我目標的情況下會接受路由器,否則會檢查當前的 msg.sender 是否出現在下一個目標的授權呼叫者名單中。因此,一個以 Gateway 模組為目標的內部呼叫,會被判定為源自已獲授權的路由器,而非外部呼叫者。這使得來自不受信任來源的指令得以透過此巢狀路徑滿足 Gateway 的呼叫者授權檢查。

第二個缺陷存在於證明檢查本身。該證明驗證的是指令範本,但沒有任何檢查將其與所附帶的執行時參數綁定。因此,一個先前為合法指令核發的有效證明,在其具體執行數值被更改後仍然可以繼續使用。這個被重複使用的證明提供了一個可用的權限,但正是巢狀授權繞過使得未受信任的呼叫者得以首先到達 Gateway 模組。

攻擊分析

一個先前針對相同指令範本核發的 Merkle 證明,即使搭配不同的執行時數值,仍然可以繼續使用。此特性本身並不能獨立繞過 Gateway 的呼叫者授權,但在巢狀路由路徑滿足該授權檢查之後,它提供了一個可用的權限。

以下分析基於交易 0x0e7680...a8705。

在成功交易發生之前,原始攻擊者部署了一個攻擊合約、一個受攻擊者控制的 PAT 代幣,以及一個稍後將用於執行 PAT 交換的第二個合約。

在下一個區塊中,攻擊者呼叫了 prepare() 來建立並初始化一個 PAT/aEthrsETH 的 Uniswap v4 資金池。

Yoink MEV 機器人偵測到了這個待處理的漏洞利用,並透過呼叫已備妥的攻擊合約搶先於原始攻擊者執行。由此產生的呼叫進入路由器,導致路由器呼叫自身,然後以路由器作為 msg.sender 到達 Gateway 模組。由於 Gateway 是一個已啟用的模組,它便可以讓受害 Safe 錢包執行所提供的操作,而無需多簽核准。

該指令使受害 Safe 錢包在 tick 範圍 [10, 20] 內,向受攻擊者控制的 PAT/aEthrsETH 資金池提供約 2,900 枚 aEthrsETH 作為流動性。該交易同時將相關的 Uniswap v4 部位 NFT 鑄造給該錢包,使此操作看起來符合預期的流動性流程。這並未動用錢包全部的 aEthrsETH 餘額:數額被限制在能使 Aave 的健康係數檢查仍能通過的範圍內,使該錢包的健康係數維持在 1.001182484056805114。

攻擊合約隨後透過該第二個合約,用受攻擊者控制的 PAT 換取了幾乎全部已存入的 aEthrsETH。它透過 Aave 銷毀了取得的收據代幣,並提取了相應數額的 rsETH。在到達 Yoink 機器人的約 2,900 枚 rsETH 中,約有 2,882.37 枚 rsETH 轉入了其獲利接收地址,而約 17.63 枚 rsETH 被兌換為 ETH,且所產生的 ETH 幾乎全數支付給了區塊建造者。

結論

根本原因在於附加於單一 Safe 錢包的自訂基礎設施中存在授權缺陷,並因一項未能綁定所有執行參數的權限而加劇。此問題不應歸咎於 Safe、Aave、Uniswap v4 或 Kelp 的核心合約。

一個代表他人轉發呼叫的元件,應根據原始外部呼叫者來決定授權,而不是根據呼叫鏈在傳遞過程中所獲取的身份,且該元件不應能以其自身作為目標而被觸及。同樣地,權限應綁定操作將要執行的具體數值,而不僅僅是該操作所屬的範本。

本週更多事件

Nostra Finance

2026 年 9 月 17 日,Nostra 在 Starknet 上的貨幣市場遭受了利用一個被拉高的 NSTR 預言機價格所發動的攻擊,使得攻擊者得以用被高估的抵押品借出約 350 萬美元的資產。根本原因在於預言機整合配置所接受的定價來源數量過少,使得一個被操縱的淺池報價得以顯著影響聚合後的價格。Nostra 已暫停其市場運作 [2],而 Pragma 則表示攻擊者的地址已被凍結,追討工作正在進行中 [3]。最終損失及可能的資金追回情況目前仍屬未知。

背景

Nostra 在 Starknet 上運營一個貨幣市場,使用者可以存入受支援的抵押品,並根據該抵押品的預言機衍生價值借出其他資產。

Nostra 透過其自有的價格饋送合約獲取 NSTR 定價,該合約會委託給一個主要預言機合約,後者從 Pragma(一個在 Starknet 上發布聚合價格的預言機)讀取資料。發布者以指定名稱的來源向 Pragma 提交觀測數據,包括 AVNU 和 GECKOTERMINAL,而其記載的 NSTR 配置說明採用其中三個來源的中位數 [4][5]。每個預言機回應都包含價格、小數精度、時間戳記以及貢獻來源數量 [6]。主要預言機合約儲存了 MinAggregatedSources,即一個可配置的最低貢獻來源數量。

已部署的聚合實作並未被直接讀取。儘管如此,有兩項獨立跡象指向相同結論:Pragma 的開源程式碼在條目數為偶數時,回傳的是中間兩個條目的平均值 [6];而本次事件中觀察到的 MEDIAN 回應值,恰好等於其兩個貢獻觀測值的算術平均數。

這些來源背後的數值來自市場本身。GECKOTERMINAL 的觀測值可由鏈上資金池推導而來,而 Starknet 上其中一個此類場所是 Ekubo,一個採用集中流動性機制的去中心化交易所,類似於 Uniswap v3。流動性提供者可將資產置於選定的 tick 範圍內,而交易會使資金池價格在活躍範圍內移動,同時沒有活躍流動性的缺口可能會將置於明顯不同價格的部位分隔開來。

Nostra 使用透過此預言機路徑取得的 NSTR 價格來評估存入的抵押品價值,並計算該帳戶的借款能力。

漏洞分析

Nostra 的貨幣市場從 0x6838...5bf0 讀取 NSTR 價格,該合約在其文件中被列為 NSTR 價格饋送 [7]。該合約委託給其指定的主要預言機 0x7b05...f0ab,而該預言機的 MinAggregatedSources 被配置為 1。Pragma 建議至少採用三個定價來源,並在事件發生後表示,若強制執行三個來源的最低要求,則此次被接受的回應本應被拒絕 [3]。

因此,一個僅包含兩個有效觀測值的回應便已超過了所配置的門檻。由於針對兩個觀測值的 MEDIAN 計算結果為其算術平均數,即使另一個觀測值仍接近當時的市場價格,單一極端報價也足以大幅扭曲最終結果。

這是一個整合配置上的弱點,而非小數位縮放或中位數計算實作上的錯誤。Pragma 在其計算邏輯中並未發現任何缺陷 [3]。正是因來源門檻不足,才使得由一組多樣性不足的輸入所正確計算出的結果,得以決定抵押品價值和借款能力。

攻擊分析

此次攻擊依賴於一個新建立、資金稀少的集中流動性資金池易於被操縱的特性。現有證據顯示,攻擊者的資金池注入行為及重複活動,可能影響了被用於 GECKOTERMINAL 觀測值的資金池,不過確切的資金池選擇因果關係尚未被證實。

以下分析基於交易 0x2460fd...cdf00e。

攻擊者首先建立了一個 Ekubo 的 NSTR/SolvBTC 資金池,並在一個較低、非活躍的價格範圍內以單邊流動性形式提供了 1.5 枚 SolvBTC。攻擊者接著在接近正常市場價格的範圍內加入約 1,900 枚 NSTR 和 0.0001514751 枚 SolvBTC,並在該資金池中進行了多次交易。

接下來,攻擊者在遠高於正常價格的一個狹窄範圍內,以單邊流動性形式放置了 190 枚 NSTR。在移除接近正常市場價格範圍內的流動性後,攻擊者在此高價部位之前留下了一個空流動性的缺口。

一筆僅包含 0.00000001 枚 SolvBTC 的交易穿越了這個空範圍,將資金池推移至 tick -6645400,即該高價部位的邊界。這個被操縱的資金池價值隨後被提交作為 GECKOTERMINAL 的 NSTR/USD 觀測值,金額為 $99.02439975。

另一個貢獻觀測值以 AVNU 名義提交,將 NSTR 的價值定為 $0.00596118。在該回應中並未出現來自第三個配置來源的觀測值,因此僅有這兩個數值進入了聚合計算 [4]。

在僅有兩個數值的情況下,MEDIAN 回應即為其算術平均數,約為每枚 NSTR $49.51518046。Nostra 接受了由此得出的估值,並將攻擊者存入的 NSTR 視為足以支撐大額借款的抵押品。

在首次識別出的提取行動中,攻擊者使用一個持有 NSTR 抵押品的獨立帳戶,以被拉高的估值借出約 939.386010 枚 ETH [4]。Nostra 表示,完整的借款過程還涉及 STRK、USDC、USDT、WBTC 和 DAIv1,借出資產的總價值約為 350 萬美元 [2]。

結論

此次事件源於 Nostra 整合配置中預言機來源門檻不足,而非 Pragma 在小數位處理或聚合計算上的錯誤。即使其中一個觀測值來自一個極易被操縱的資金池,一個僅有兩個來源的回應仍然被視為有效。

Nostra 應強制要求至少三個貢獻定價來源,並在使用價格進行抵押品估值或借款之前,拒絕任何來源數量低於此門檻的預言機回應。抵押品資格及風險敞口限制,也應反映可用的市場流動性,以及操縱各資產底層價格來源所需的深度。

參考資料

[1] https://x.com/Phalcon_xyz/status/2099741447776096270

[2] https://x.com/nostrafinance/status/2100577538053493076

[3] https://www.pragma.build/updates/nostra-nstr-incident

[4] https://x.com/Phalcon_xyz/status/2100818035082952751

[5] https://www.pragma.build/asset/NSTR-USD?network=mainnet

[6] https://github.com/Astraly-Labs/pragma-oracle

[7] https://docs.nostra.finance/lend-and-borrow/deployed-contracts/money-market-mainnet

關於 BlockSec

BlockSec 是一家全端區塊鏈安全與加密貨幣合規服務提供商。我們打造各種產品與服務,協助客戶執行程式碼審計(涵蓋智慧合約、區塊鏈及錢包)、即時攔截攻擊、分析事件、追蹤不法資金,並在協議與平台的整個生命週期中滿足反洗錢/打擊資助恐怖主義(AML/CFT)的合規要求。

BlockSec 已在多場知名學術會議上發表區塊鏈安全論文,揭露多起 DeFi 應用程式的零日攻擊,成功阻止多起駭客攻擊事件,挽回超過 2,000 萬美元的損失,並為數十億美元的加密貨幣資產提供安全保障。

• 官方網站: https://blocksec.com/

• 官方 Twitter 帳號: https://twitter.com/BlockSecTeam

• 🔗 BlockSec 審計服務 : 提交申請

• 🔗 Phalcon Security 應用程式: 預約展示

• 🔗 Phalcon Compliance