Back to Blog

#2 Bybit 事件:Web2 漏洞引發史上最大規模加密貨幣駭客攻擊

Code Auditing
February 9, 2026
5 min read

2025 年 2 月 21 日,Bybit 因攻擊者透過社會工程學手段入侵了 Safe{Wallet} 開發人員的計算機,導致約 15 億美元的損失。攻擊者將惡意 JavaScript 注入 Safe{Wallet} 的 AWS S3 儲存桶中,專門針對 Bybit 的交易。注入的代碼在簽名過程中篡改了交易內容:Safe{Wallet} UI 顯示的是合法交易,但發送給簽名者 Ledger 設備的實際有效負載(payload)則是將 Bybit 的 Safe 合約升級為一個惡意實現,從而讓攻擊者獲得了完全控制權。一旦簽名並執行,攻擊者便耗盡了合約中的所有資產。關於此事件的詳細技術分析,請參閱我們之前的報告 [1]。

背景

Safe{Wallet}(即 GnosisSafe)是一種使用 n-of-m 模式的多重簽名錢包基礎設施:執行交易需要來自 m 個簽名者中的至少 n 個簽名。

每個 Safe 錢包都作為一個代理合約部署。兩個儲存變量是此事件的核心:

  • masterCopy插槽 0):實現合約的地址。該合約包含所有執行邏輯,包括簽名驗證和升級機制。代理透過 delegatecall 將所有調用委派給 masterCopy
  • threshold插槽 4):所需的最低簽名數(n)。對於 Bybit 的 Safe 錢包,該數值為 3

由於代理使用 delegatecall,任何在 masterCopy 上調用的函數都會在代理的儲存上下文中執行。這意味著 delegatecall 的目標可以直接覆蓋插槽 0 的 masterCopy,從而在單筆交易中替換整個實現。

漏洞分析

攻擊路徑跨越了系統的三個層級,每一層都存在攻擊者可利用的結構性條件:

前端服務模型。 Safe{Wallet} 的前端 JavaScript 是從 AWS S3 儲存桶中提供的。在這種架構下,任何對該儲存桶具有寫入權限的人都可以修改為簽名者構建交易的代碼。子資源完整性(SRI)哈希或代碼簽名等完整性驗證機制可以減輕這種風險,但這對於大多數 dApp 前端來說尚未成為標準做法。攻擊者透過被入侵的開發人員機器獲得了寫入權限,並靜默地修改了所提供的 JavaScript。

UI 顯示與簽名負載之間的差距。 注入的 JavaScript 在 Safe{Wallet} UI 上顯示了一筆看似合法的交易,同時向 Ledger 硬體錢包發送了一個不同的負載。Ledger 螢幕上顯示的交易詳細資訊與 UI 顯示的內容不同,但解讀硬體錢包螢幕上的原始交易數據並不直觀,特別是在處理複雜的多重簽名操作時。這種差距使得攻擊者能夠為惡意負載收集到三個有效的簽名。

代理升級模型。 如背景中所述,delegatecall 在代理的儲存上下文中執行目標代碼。Safe 代理架構透過插槽 0 的單一 masterCopy 指針路由所有調用。覆蓋此指針會將代理重定向到完全不同的實現(包括其簽名驗證邏輯),且僅需一筆交易即可完成。n-of-m 模式規定了誰可以發起交易,但一旦交易被批准並執行,它就可以改變實現本身。如果新的實現移除了簽名驗證,那麼隨後所有交易的多重簽名保護實際上就失效了。

攻擊分析

攻擊分為三個步驟:惡意代碼注入實現替換資產竊取

第 1 步:惡意代碼注入

攻擊者入侵了一台 Safe{Wallet} 開發人員的電腦,並將惡意 JavaScript 注入到儲存前端的 AWS S3 儲存桶中。注入的代碼專門針對來自 Bybit Safe 地址的交易。根據 Bybit 執行長 Ben Zhou 的說法 [2],Safe{Wallet} UI 顯示了合法交易,而發送到簽名者 Ledger 設備的卻是不同的負載。簽名者按照 UI 中的顯示批准了交易,從而為惡意負載提供了三個有效的簽名。

第 2 步:實現替換

攻擊者提交了帶有三個收集到的簽名的惡意交易。Safe 代理將呼叫委派給 masterCopy,其 execTransaction() 驗證了簽名並執行了交易負載:對攻擊者合約(0x962214...5c7242)的 delegatecall。由於此 delegatecall 在代理的儲存上下文中運行,攻擊者的 transfer() 函數將插槽 0 的 masterCopy 值覆蓋為惡意實現地址(0xbDd077...9516)。從這一刻起,所有對 Safe 合約的調用都將委派給攻擊者的代碼。

第 3 步:資產竊取

由於 masterCopy 現在指向攻擊者的實現,多重簽名要求不再適用。攻擊者直接在 Safe 合約上呼叫 SweepERC20()SweepETH()。這些函數定義在攻擊者的實現合約中,無需任何簽名驗證即可轉移所有持有的資產。共執行了五筆轉出交易,總計損失約 15 億美元。

相關合約與交易

類型 描述 地址 / 哈希
合約 Bybit 的 Safe 合約 0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4
合約 原始的 masterCopy 合約 0x34CfAC646f301356fAa8B21e94227e3583Fe3F5F
合約 惡意的 masterCopy 合約 0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516
合約 攻擊者的合約(即 transfer() 0x96221423681A6d52E184D440a8eFCEbB105C7242
交易 替換 masterCopy 合約的交易 0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882
交易 轉出 15,000 cmETH 的交易 0x847b8403e8a4816a4de1e63db321705cdb6f998fb01ab58f653b863fda988647
交易 轉出 90,375 stETH 的交易 0xa284a1bc4c7e0379c924c73fcea1067068635507254b03ebbbd3f4e222c1fae0
交易 轉出 8,000 mETH 的交易 0xbcf316f5835362b7f1586215173cc8b294f5499c60c029a3de6318bf25ca7b20
交易 轉出 401,346 ETH 的交易 0xb61413c495fdad6114a7aa863a00b2e3c28945979a10885b12b30316ea9f072c
交易 轉出 90 USDT 的交易 0x25800d105db4f21908d646a7a3db849343737c5fba0bc5701f782bf0e75217c9

總結

此次事件展示了鏈下基礎設施的妥協如何引發災難性的鏈上損失。攻擊者將 Web2 漏洞、前端操縱和代理升級串聯成一條攻擊路徑,在未利用任何鏈上漏洞的情況下繞過了多重簽名保護。

關鍵教訓:

  • 前端完整性與鏈上安全同樣重要。 攻擊鏈始於前端服務層。隨著 dApp 越來越多地處理高價值交易,透過完整性驗證(SRI、代碼簽名、可再現構建)和監控未經授權的變更來保護前端代碼已成為基本要求。
  • 硬體錢包驗證在實踐中仍有難度。 硬體錢包可以顯示實際的簽名負載,但在小螢幕上解讀複雜的多重簽名交易數據是一項眾所周知的易用性挑戰。提高設備上交易摘要的可讀性是錢包生態系統待解決的問題。
  • 代理升級機制是高槓桿目標。 Safe 代理架構透過單一可升級指針路由所有邏輯。任何允許一鍵式實現替換的機制都會集中風險。增加時間鎖(timelock)、二次確認步驟或為升級設置獨立守護者,可以減輕單筆交易被入侵造成的影響。

參考資料

  1. BlockSec: Bybit 15億美元駭客攻擊深度分析

  2. Bybit 執行長 Ben Zhou 的 X 直播


關於 BlockSec

BlockSec 是一家全端區塊鏈安全與加密合規服務提供者。我們構建產品和服務,協助客戶在協議和平台的整個生命週期中進行代碼審計(包括智能合約、區塊鏈和錢包)、即時攔截攻擊、分析事件、追蹤非法資金,並滿足 AML/CFT 合規要求。

BlockSec 已在知名會議上發表多篇區塊鏈安全論文,上報了多個 DeFi 應用的零日漏洞,攔截了多次駭客攻擊並挽回超過 2,000 萬美元的資金,並保障了價值數十億美元的加密資產。

Sign up for the latest updates

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit