Web3 安全事件周報 | 2026年4月13日 – 4月19日

在過去的一週（2026/04/13 - 2026/04/19）中，BlockSec 檢測並分析了四起攻擊事件，總估計損失約為 3.1 億美元。下表總結了這些事件，後續章節則提供了每個案例的詳細分析。

每週焦點：KelpDAO

若要閱讀涵蓋漏洞利用後的連鎖反應、Arbitrum 鏈上恢復機制以及更廣泛的治理影響的專題報告，請參閱：去中心化的兩難：KelpDAO 危機中的連鎖風險與緊急權力

此事件之所以受到關注，是因為它採用了新穎的基礎設施級攻擊向量（針對唯一 DVN 的 RPC 中毒，而非智慧合約漏洞）、透過 DeFi 可組合性在多鏈上產生的連鎖影響，以及 Arbitrum 透過強制狀態轉換來追回被盜資金所引發的治理問題。

2026 年 4 月 18 日，KelpDAO 的 rsETH LayerZero OFT 橋遭到攻擊，約 2.9 億美元資產被竊，攻擊被認為是由國家級行為者（極有可能是北韓 Lazarus Group）所為 [1]。根本原因是 KelpDAO 的 1-of-1 DVN 配置將跨鏈訊息驗證簡化為單點故障。攻擊者對 LayerZero Labs DVN 所信任的 RPC 基礎設施進行了中毒攻擊，強制其證明一條偽造的跨鏈訊息，導致 116,500 枚 rsETH 在以太坊上被釋放，而 Unichain 上並無對應的來源端事件。

背景

LayerZero 是一種建立在模組化安全架構上的跨鏈訊息傳遞協議。其核心在於，跨鏈訊息的完整性由去中心化驗證者網路（DVNs）執行，這些鏈下實體負責獨立驗證來源鏈上發送的訊息在執行前確實發生。每個部署在 LayerZero 上的應用程式都會配置自己的 DVN 設置，包括信任哪些 DVN、需要多少驗證者以及必須達到何種共識閾值。這種模組化賦予了應用程式對其安全模型的完全控制權，但也帶來了全部責任：協議本身無法為薄弱的配置提供後盾。

KelpDAO 的 rsETH 作為 OFT（全鏈可同質化代幣）部署在 LayerZero 上，橋接路由連接 Unichain（來源）和以太坊主網（目的地）。OFT 標準允許代幣在來源鏈上銷毀，並在目標鏈上解鎖，以跨鏈訊息作為釋放的唯一授權。以太坊端的適配器 (0x85d456...e98ef3) 負責在驗證並傳送有效跨鏈訊息後，將 rsETH 釋放給收款人。關鍵在於，KelpDAO 將此路徑配置為 1-of-1 DVN 設置，指定 LayerZero Labs 為唯一驗證者。這意味著單一 DVN 的證明足以授權任何代幣釋放，無需第二意見。

為了執行驗證職責，LayerZero Labs DVN 會查詢多個 RPC 節點，以確認跨鏈發送事件確實發生在來源鏈上。這些 RPC 節點包括自營設施和外部供應商，DVN 在簽署證明前會依賴它們的集體回應。此過程的完整性取決於假設大多數被查詢的節點會回傳真實數據。

漏洞分析

該漏洞是基礎設施和配置層面的系統性故障，由三個複合弱點組成。

首先，KelpDAO 的 1-of-1 DVN 配置消除了驗證層的所有冗餘。LayerZero 推薦的安全態勢明確要求採用具有獨立驗證者的多 DVN 配置，使得單一 DVN 無法單方面授權訊息。透過僅依賴 LayerZero Labs DVN，KelpDAO 確保了該驗證者的任何受損都足以授權任意代幣釋放。

其次，DVN 的故障轉移（failover）機制會將驗證查詢轉發至仍可存取的 RPC 節點。這種設計假設節點不可用是意外而非蓄意的。然而，這創造了一種情況：攻擊者不需要破壞所有數據源，只需透過 DDoS 使正常節點離線，並準備好中毒節點作為唯一可用的替代品，攻擊者就能完全控制 DVN 接收到的數據。

第三，更換 RPC 節點上的 op-geth 可執行檔需要對底層伺服器擁有作業系統級別的權限存取。具體的初始存取向量未被揭露，但破壞位於不同叢集上的兩個獨立節點，可能顯示在控制伺服器存取權限方面存在共同弱點。

這三個條件共同形成了一個完整的攻擊鏈：第一個弱點確保沒有獨立的 DVN 來交叉檢查被證明的訊息；第二個弱點確保攻擊者可以完全控制唯一 DVN 接收到的數據；第三個弱點提供初始立足點，使數據操作成為可能。單一弱點都不足以造成此後果。如果沒有 1-of-1 配置，第二個查詢獨立基礎設施的 DVN 將會拒絕偽造的訊息；如果沒有故障轉移行為，健康的節點將在投票中勝過中毒節點；如果沒有伺服器受損，攻擊者將無法注入偽造數據。

攻擊分析

以下分析基於交易 0x1ae232...4222 以及 LayerZero Labs 的官方事件聲明。

• 步驟 1：攻擊者獲得了 LayerZero Labs DVN 信任的特定 RPC 節點清單。這是一個高價值的情報目標，因為了解確切的節點允許攻擊者規劃外科手術式的操作，而不是進行大規模的基礎設施攻擊。

• 步驟 2：攻擊者獲得了兩個 RPC 節點的作業系統級別寫入權限，並將正在執行的 op-geth 二進位檔替換為惡意版本。這兩個節點被描述為運行在彼此沒有直接連接的獨立叢集上，表明初始存取向量涉及共享的上游依賴項（例如：洩露的部署憑證、CI/CD 管道，或對擁有兩者存取權限的操作員進行社交工程）。LayerZero Labs 未揭露確切的初始存取方法。這是所有後續數據操作的先決條件。

• 步驟 3：惡意 op-geth 二進位檔實作了目標回應邏輯：它僅向 DVN 的 IP 位址返回偽造的交易數據，同時向所有其他請求者（包括 LayerZero 自身的監控基礎設施、區塊瀏覽器和掃描服務）提供真實的區塊鏈狀態。這種選擇性中毒使得所有現有的可觀測性系統都無法發現此次攻擊；從每個外部視角來看，來源鏈看起來一切正常。

• 步驟 4：DVN 的內部共識要求在中毒的和未受損的 RPC 節點之間達成協議。為了解決這個衝突，攻擊者在攻擊視窗（太平洋時間上午 10:20 至 11:40）期間對剩餘的健康節點進行了 DDoS 攻擊，觸發了 DVN 的故障轉移邏輯，迫使其僅依賴中毒的基礎設施。此步驟是必要的，否則健康節點將返回與偽造回應相矛盾的真實數據。

• 步驟 5：在 DVN 現在僅接收到攻擊者控制的數據後，一條偽造的 LayerZero 跨鏈訊息被視為合法。DVN 在以太坊目的地端點上證明了 nonce 308，而該 nonce 在 Unichain 上並沒有對應的出站事件（來源端點確認最大出站 nonce 仍為 307）。

• 步驟 6：以太坊端的 rsETH 適配器收到一條合法證明的訊息後，將 116,500 枚 rsETH 釋放給攻擊者的收款位址 (0x8b1b6c...0d3b)，該位址早在幾小時前就已透過 Tornado Cash 預先充值。被盜代幣隨即分散到七個分支錢包，並透過 Aave 抵押品部位、直接 ETH 兌換以及跨鏈回 Arbitrum 進行清算，最終收益整合在以太坊上的 0x5d3919...7ccc 以及 Arbitrum 上的一個對應收集位址中。

• 步驟 7：惡意二進位檔在完成後執行了自我銷毀程序，刪除了自身以及所有本地日誌和設定檔。這顯著阻礙了事件後的取證恢復，並展示了攻擊者高超的操作技巧。

• 步驟 8：攻擊者隨後嘗試利用同一路徑再次竊取 40,000 枚 rsETH（約 9500 萬美元），但在 KelpDAO 偵測到異常並暫停以太坊主網及 L2 上的所有相關合約後被阻止 [2]。

更廣泛的影響

損害遠不止最初 2.9 億美元的橋樑漏洞。攻擊者在多個市場的 Aave 中存入了約 89,567 枚 rsETH（約 2.21 億美元），並以 E-Mode 的 93% LTV 借入了 WETH [4]。由於 Aave 無法分辨合法橋接的 rsETH 與透過偽造訊息釋放的代幣，這些「中毒」抵押品被視為完全合法。由此產生的 WETH 儲備凍結蔓延至以太坊、Arbitrum、Base、Mantle 和 Linea，影響了那些完全未持有 rsETH 的用戶。這種從單一橋樑配置缺陷到多鏈借貸市場中斷的連鎖傳播，說明了 DeFi 可組合性如何放大單點故障的範圍和成本。

事件過後，關於去中心化操作現實的問題也隨之而來。LayerZero Labs 宣布其 DVN 將不再為使用 1-of-1 配置的應用程式簽署訊息 [1]，這意味著協議層的去中心化本身無法彌補應用程式層的配置弱點。

在鏈層面，Arbitrum 安全委員會執行了一項緊急行動，凍結了攻擊者在 Arbitrum One 上持有的 30,766 枚 ETH。正如 BlockSec 所分析的 [5]，這是透過鏈層級的強制狀態轉換實現的：安全委員會暫時升級了以太坊收件箱合約，注入了一條模仿攻擊者位址的未簽署 L1 到 L2 訊息，並在無需持有者簽名的情況下恢復了原始實作 [3]。

這一行動是治理定義的緊急權力的一種合法行使，以透明方式並與執法部門協調進行。然而，它也證明了 L2 鏈在設計上保留了中心化干預能力：原則上，Arbitrum One 上的任何資產都可以透過相同的機制由安全委員會移動。正如這次事件在每一層所展示的，系統的理論信任模型與其實際信任邊界之間的差距，正是最嚴重風險存在的地方。

結論

這次事件證明，橋樑安全不能單純簡化為協議正確性。LayerZero 協議本身執行如預期，漏洞完全存在於其上方的操作層。核心教訓是，鏈下驗證基礎設施屬於信任邊界的一部分，其安全態勢必須與其所保護的資產價值相匹配。

以下三種緩解措施本可以單獨預防此結果：

• 多 DVN 配置：要求多個獨立 DVN 達成共識，將使得單一 DVN 受損不足以授權訊息，無論該 DVN 被欺騙得有多徹底。

• 具備故障轉移意識的 RPC 選擇：在主動驗證視窗期間，可到達節點數量的突然下降應被視為潛在的攻擊訊號，而非例行的可用性事件。DVN 實作應該在遇到此情況時停止或發出警報，而不是在節點減少的情況下繼續操作。

• RPC 基礎設施加固：更換生產環境 RPC 節點上正在運行的可執行檔的能力，表明底層伺服器的存取控制不足。DVN 用於確認來源鏈事實的基礎設施，應實施與 DVN 簽名實例相同的安全邊界。

更廣泛地說，任何依賴鏈下證明的橋樑或跨鏈協議，不僅應審計智慧合約層，還應審計從「來源鏈事件」到「目標鏈執行」的整個數據管道。當數億美元資產依賴 RPC 基礎設施時，預設其為完全可信已不再合適。

參考文獻

[1] LayerZero Labs, "KelpDAO Incident Statement," April 20, 2026. https://x.com/LayerZero_Core/status/2046081551574983137

[2] KelpDAO, "April 18 Incident: Additional Context," April 21, 2026. https://x.com/KelpDAO/status/2046332070277091807

[3] Arbitrum, "Security Council Emergency Action," April 21, 2026. https://x.com/arbitrum/status/2046435443680346189

[4] LlamaRisk, "rsETH Incident Report," April 20, 2026. https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[5] BlockSec, "Arbitrum Security Council Freeze Mechanism Analysis," April 21, 2026. https://x.com/Phalcon_xyz/status/2046467830498173088

本週更多事件

Rhea Finance

2026 年 4 月 16 日，Rhea Finance 生態中基於 NEAR 的借貸與槓桿交易協議 Burrowland，因其槓桿交易模組的業務邏輯缺陷遭到攻擊，造成約 1,840 萬美元的損失。協議在開設槓桿部位時，依賴 verify_token_out() 來驗證預期的交換輸出，然後才接受該部位。然而，此函式在代幣與最終輸出代幣匹配時，錯誤地累積了來自中間交換步驟的 token_out 金額，卻忽略了這些中間金額隨後被重複計算為 token_in 的事實。攻擊者部署了假代幣和資金池，隨後構造了一條循環交換路徑，虛增了感知的輸出金額並透過了償付能力檢查，從協議中抽走了約 1,840 萬美元。

背景

Burrowland 是一個基於 NEAR 的開源借貸與槓桿交易協議。除了標準的存借功能外，它還支援槓桿交易，並引入了三個關鍵變數來表示用戶的槓桿部位：token_c（抵押品）、token_d（債務資產）和 token_p（部位資產）。

對於「多頭部位」，用戶存入 token_c 作為抵押品，並以選定的槓桿倍數（例如 5 倍）借入 token_d。借入的 token_d 然後在 DEX 上交換為 token_p，即用戶想要建立曝險的資產。在正常情況下，收到的 token_p 價值大致等於花費的 token_d 價值。協議代表用戶保管 token_p，同時將借入的 token_d 記錄為債務。

對於「空頭部位」，用戶同樣以槓桿存入 token_c 並借入 token_d（他們想要做空的資產）。借入的 token_d 被交換成另一種資產（token_p），從而對 token_d 有效建立了空頭曝險。同樣，預期交換過程在正常市場條件下會保持價值。

在部位生命週期中，token_p 保管在協議內，用戶無法直接提取。必須平倉以實現獲利或虧損，此時 token_p 會交換回 token_d 以償還債務。

開設槓桿部位的操作由 internal_margin_open_position() 處理，該函式設置部位參數並將借貸請求分發給 DEX。

在協議接受新部位之前，它會依序評估四項保護措施：is_min_amount_out_reasonable() 會對比用戶宣告的 min_token_p_amount 與 Pyth 預言機暗示的交換輸出以限制滑點；is_open_position_liquidatable() 驗證預期的部位與抵押品價值是否符合清算邊緣；is_open_position_forcecloseable() 驗證帳戶在帳面上是否已經資不抵債；get_open_position_lr() 執行 token_d / token_c 價值不超過最大槓桿率的約束。

所有四項檢查都使用 min_token_p_amount 作為部位資產的價值，因為交換尚未執行且沒有實現金額可供使用。因此每項檢查的正確性皆取決於 min_token_p_amount 是否與 DEX 實際交付的數量綁定。這種綁定正是 verify_token_out()（透過 RefV1TokenReceiverMessage::get_token_out() 實作）應該對用戶提交的交換訊息執行的強制約束。

漏洞分析

缺陷存在於 verify_token_out() 內部。該函式獲取最後一個交換步驟的 token_out 作為最終輸出代幣，然後加總所有產生相同代幣的交換步驟的 min_amount_out，前提是這些步驟的輸出最終會構成最終輸出。這對於真正的多路徑（分割路由）交換是正確的，但它並沒有排除其 token_out 被立即當作下一步 token_in 的步驟。圓形交換路徑（如 A->B->A->B）導致每個 ->B 步驟都被計入總和，儘管其輸出在隨後的 B->A 步驟中被消耗，且永遠不會到達 Burrowland。verify_token_out() 所批准的加總後的 min_amount_out，再也不代表 DEX 實際會返回的數量。

一旦 verify_token_out() 被繞過，虛增的 min_token_p_amount 就會在整個 internal_margin_open_position() 中被當作真值。所有本應停止不安全部位開設的償付能力檢查，都是基於一個偽造數字進行計算，因此部位被接受，協議將借入的 token_d 連同循環交換訊息發送給 DEX。

攻擊分析

以下分析基於交易 GcXEKm...fnFT。

第一階段：假代幣與資金池部署

攻擊者部署了三個假代幣並創建了五個假資金池。

1. 假代幣 ID：

   1. Fake1: 31623e1d98275d2b0db4f50e102f6bf40877c1345e06e4ca6727f58c89564bb2

   2. Fake2: 6a28e3d3c7af1415ec22c6264013e1138bab00f85b8b6055d882d7d46afdf49b

   3. Fake3: e081e03daf58f5bb04cf95a03017e58449b76e704f1974771d7e3bd52835b6e5

2. 假資金池 ID：

   1. Zec-Fake1: 7509

   2. Fake1-Fake2: 7510

   3. USDC-Fake2: 7511

   4. Fake2-Fake3: 7512

   5. Fake3-USDC: 7513

第二階段：開設槓桿部位

• 步驟 1：利用 Burrowland 的槓桿交易功能，攻擊者以合法資產作為 token_c，並以真實儲備資產作為 token_d 開設了一個槓桿部位，並附加了交換訊息，其動作清單為一個完全經由第一階段中攻擊者控制的資金池所路由的 A->B->A->B 圓形路徑。

• 步驟 2：由於 verify_token_out() 會加總每個 token_out 與最終輸出相匹配的步驟的 min_amount_out，循環路徑讓攻擊者將聲明的 min_token_p_amount 增加到任意值。

• 步驟 3：虛增的 min_token_p_amount 通過了 internal_margin_open_position() 中的所有開倉健康狀態檢查，因此部位被接受，協議將 token_d 分發給 Ref-Finance。

• 步驟 4：圓形交換僅返回了極少量的 token_p；on_open_trade_return() 進行了入賬處理而無任何複核，導致該部位從建立之初即處於資不抵債狀態。

• 步驟 5：借入的 token_d 在路徑上的攻擊者控制資金池內結算；攻擊者隨後透過 remove_liquidity() 提取了這些資金。

• 步驟 6：由於借款有槓桿效果，提取出的 token_d 比存入的 token_c 價值更高。其中的差額是每輪循環的淨利潤，而無法收回的債務被強制平倉並劃歸為「協議債務」。攻擊者重複此構造操作，直到約 1,840 萬美元被抽走。

結論

此事件是由 Burrowland 槓桿開倉路徑中的業務邏輯缺陷所引起。函式 RefV1TokenReceiverMessage::get_token_out() 在中間輸出與最終代幣匹配時錯誤地進行了匯總，假設這些數量會保持為最終輸出。然而，圓形交換路徑破壞了這一假設，因為這些代幣可以在路徑中被重新使用和消耗。結果，計算出的 min_token_p_amount 可被人工虛增，導致所有後續的償付能力檢查皆基於不正確的數值，允許在不驗證實際接收數量的同時，根據構造出的虛假健全狀態來開設部位。

對於生產環境中的槓桿交易合約，開發者應：

• 將用戶聲明的 min_amount_out 視為未驗證輸入，並僅取最後一跳的 min_amount_out，或者明確拒絕那些重新消耗先前已產生 token_out 的交換路徑（不允許穿過目標的循環）。

• 對宣告的滑點設定相對於預言機暗示交換輸出的上限和下限範圍，以防攻擊者單方面虛增聲明價值，從而繞過償付能力判定條件。

Hyperbridge

2026 年 4 月 13 日，以太坊上的跨鏈訊息橋 Hyperbridge 遭到攻擊，約 24.2 萬美元資產被竊，原因是其 MMR（默克爾山脈）證明驗證邏輯中缺少輸入驗證。函式 MerkleMountainRange.VerifyProof() 未強制執行 leaf_index < leafCount 條件，導致攻擊者能夠偽造跨鏈證明並執行特權操作，包括鑄造 1,000,000,000 枚 DOT 代幣。

背景

Hyperbridge 對跨鏈訊息採用「以太坊端驗證器與調度器」模型。在以太坊上，合約 HandlerV1 根據儲存的 overlayRoot 驗證提供的證據，如果證明被接受，則將訊息分發給目的地模組（如 TokenGateway 合約）。

TokenGateway 合約是一個具有特權的資產管理模組。除了常規的資產橋接外，它還支援資產創建、註銷及管理員管理等治理類操作。對於實作為 ERC6160Ext20 的橋接資產，管理員可以透過呼叫 changeAdmin() 直接移交鑄造權限，新管理員隨後可透過 mint() 函式鑄造任意數量的供應額。

這意味著整個資產橋的安全取決於 HandlerV1 中證明驗證路徑的正確性。如果偽造的訊息可以通過驗證，下游模組將把攻擊者控制的負載視為真實的跨鏈指令。

漏洞分析

核心問題在於 HandlerV1 合約中的 MMR 證明驗證流程 (0x6c84ed...6d64)。入口函式 handlePostRequests() 首先基於攻擊者提供的輸入建構 MmrLeaf(leaf.kIndex, leaf.index, commitment)。然後，呼叫 MerkleMountainRange.VerifyProof() 執行驗證。

MerkleMountainRange.VerifyProof(root, request.proof.multiproof, leaves, request.proof.leafCount)

然而，VerifyProof() 僅檢查 root == CalculateRoot(proof, leaves, mmrSize)，而未驗證每個 leaf.index 是否在有效範圍內（即 leaf.index < leafCount）。透過選擇 leafCount = 1 和 leaf_index = 1，攻擊者使得 CalculateRoot() 跳過了將偽造請求承諾折疊到計算根的過程，直接返回峰值根（peak root）。這打破了「訊息與證明之間的綁定」，並讓任意負載看起來像是針對歷史 overlayRoot 的有效訊息。

攻擊分析

以下分析基於交易 0x240aeb...1109 [1]。

• 步驟 1：攻擊者 EOA 0xC513...F8E7 在同一筆交易中部署了輔助合約 0x518A...8f26 和 0x31a1...ca9AB。

• 步驟 2：輔助合約 0x31a1...ca9AB 透過 HandlerV1 中的漏洞驗證路徑提交了偽造的請求。由於 VerifyProof() 未拒絕越界的 leaf_index，偽造的請求承諾未被包含在根計算中，但證明仍然與歷史上的 overlayRoot 匹配。

• 步驟 3：偽造訊息被接受後，HandlerV1 將其分發到 TokenGateway，執行了 ChangeAssetAdmin 操作。這將 DOT 代幣的管理員變更為攻擊者控制的輔助合約 0x31a1...ca9AB。

• 步驟 4：該輔助合約鑄造了 1,000,000,000e18 枚 DOT 代幣。

• 步驟 5：輔助合約透過 Odos Router V3 將新鑄造的 DOT 代幣兌換為 108.2 枚 ETH。

• 步驟 6：攻擊者將 108.2 枚 ETH 轉移到其 EOA 帳戶。

結論

此事件是由 Hyperbridge 的 MMR 驗證邏輯中不當的證明驗證所引起。由於未強制檢查 leaf_index < leafCount，攻擊者可以偽造一條其承諾從未被實際包含在計算根中的訊息，並通過相對於歷史狀態根的驗證。緩解措施應在驗證證明之前強制檢查嚴格的數值邊界，如 leaf_index < leafCount。

參考文獻

[1] BlockSec, "Hyperbridge Attack Analysis," April 13, 2026. https://x.com/Phalcon_xyz/status/2043601549893738970

Dango

2026 年 4 月 13 日，作為 Cosmos AppChain 構建的永續期貨 DEX Dango，因缺少簽名檢查而遭到攻擊，約 150 萬美元資產被竊。函式 replenish_insurance_fund() 使用 is_non_zero() 而非 is_positive() 來驗證輸入金額，攻擊者藉此輸入負值的 UsdValue，從而將保險基金耗盡到自己的保證金部位中。

背景

Dango 是一個構建在 Cosmos AppChain 上的永續期貨 DEX。用戶將 USDC 存入永續合約作為抵押品，並透過鏈上訂單簿（CLOB）對 BTC、ETH 和 SOL 等資產開設槓桿多頭或空頭部位。用戶的每個抵押品餘額以保證金帳戶的形式在永續合約中追蹤。

為了保護流動性提供者（LPs）免受壞債損失，協議維護了一項保險基金：保存在永續合約內部的一筆 USDC 儲備，用於彌補被清算部位抵押品不足以償還債務時的缺口。若無此基金，缺口將直接由 LPs 分攤。任何用戶都可以從其期貨交易帳戶中貢獻保證金至保險基金中。

漏洞分析

根本原因在於 0x90bc84...bea4f 合約中的 replenish_insurance_fund() 函式，該函式未能拒絕負數金額。該函式雖有兩道檢查機制，但都無法阻止負數 amount：

1. ensure!(amount.is_non_zero()) 檢查金額是否不為零，但未檢查其是否為正數。
2. ensure!(user_state.margin >= amount) 檢查用戶是否有足夠的保證金，但任何為正數的保證金都滿足 >= 負數 的條件。

兩道檢查皆通過後，函式執行 user_state.margin.checked_sub_assign(amount) 和 state.insurance_fund.checked_add_assign(amount)。當 amount 為負時，對保證金進行減去負數的操作等於增加保證金，而對保險基金進行加上負數的操作等於從基金減少，完全反轉了預期的資金流向。

攻擊分析

交易資訊：

第一階段：

在交易 1 中，攻擊者執行了以下步驟從 Dango 的保險基金中抽走資產：

• 步驟 1：攻擊者存入 1e6 USDC 開設了一個保證金部位。這是調用 replenish_insurance_fund() 的先決條件。

• 步驟 2：攻擊者調用 replenish_insurance_fund() 並傳入負數 amount（即 -1500000）。由於驗證邏輯缺失，負數 amount 被接受，導致資產從保險基金轉入攻擊者的保證金部位。

• 步驟 3：攻擊者從保證金部位提款，獲取了 1,500,000 美元的 USDC。

第二階段：

在交易 2-8 中，攻擊者調用 transfer_remote() 將被盜資產跨鏈至以太坊。最終，共計 41 萬美元的 USDC 被跨鏈至以太坊。

結論

此攻擊的核心在於在未經符號檢查的上下文中使用了有符號整數類型。UsdValue 類型在設計上是有符號的（期貨盈虧可能是負數），但保險基金捐贈的路徑僅對正數貢獻有意義。使用 is_non_zero() 代替 is_positive() 留下了一個關鍵漏洞，允許任何呼叫者反轉資金流動方向，從保險基金中抽走 USDC 到他們自己的帳戶內。攻擊者在單筆交易中完成了從存入 $1 到抽走 $150 萬再到提款 $150 萬的過程，隨後緩慢跨鏈轉移資金。限流機制是唯一能減少損害的措施：若無此限制，全部約 150 萬美元都會被不可逆地跨鏈轉移至以太坊。

關於 BlockSec

BlockSec 是一家全棧區塊鏈安全與加密合規服務供應商。我們構建各類產品與服務，協助客戶在協議與平台的完整生命週期內執行程式碼審計（包括智慧合約、區塊鏈與錢包）、即時攔截攻擊、分析事件、追蹤非法資金，並滿足 AML/CFT 合規義務。

BlockSec 已在知名學術會議上發表多篇區塊鏈安全論文，通報過多起 DeFi 應用的零日漏洞，阻止多次駭客攻擊並挽救超過 2,000 萬美元資產，確保了數十億美元密碼資產的安全。

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

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

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

• 🔗 Phalcon Security APP: 預約演示

• 🔗 Phalcon Compliance