技術還原：朝鮮黑客竊取Bybit 15億美元加密貨幣全過程
責編：gltian ｜2025-03-24 13:48:092025 年 2 月 21 日，加密貨幣交易所 Bybit 遭遇了 Web3 領域有史以來損失最大的攻擊，其 Safe 多簽錢包中近 15 億美元資金被朝鮮黑客洗劫一空。
DARKNAVY 團隊長期關注 Web3 領域安全動態，并在Bybit安全事件后，從攻擊者、開發者、簽名者視角全方面還原了 Bybit 被攻擊的過程。
攻防解讀
Safe 錢包得益于多簽機制的安全性，被廣泛作為多簽冷錢包用于資產托管。Bybit 自 Gnosis Safe（ Safe{Wallet} 前身）時期即采用該方案管理巨額 ETH 資產，此次事件中被盜的15億美元資金正源于此 Safe 錢包。
Safe{Wallet} 是以太坊生態上熱門的資產管理工具，其最核心的部分 Safe{Core} 實現了支持多重簽名驗證的智能合約賬戶，即 Safe 錢包。它允許用戶設置多個簽名者（owner），以及執行交易所需的驗證的簽名數量。分散管理每個簽名者的私鑰，可以有效降低單點故障風險、實現更靈活的治理。
Safe{Wallet} 不僅僅是智能合約。它還包含一個配套的 off-chain 網頁平臺，為用戶提供直觀的界面，從而讓用戶可以方便地創建和管理 Safe 錢包，發起和批準多簽交易，與各種 dApp 交互等；在前端網頁的背后，有龐大的一套后端為管理交易隊列、聚合簽名、交易記錄等接口提供支持。
01
社工攻擊 → 供應鏈攻擊
整個事件中的最先遭受攻擊的并不是 Bybit，而是 Safe{Wallet} 團隊的開發人員。
黑客首先找到 Safe 團隊的開發人員，通過社會工程學的方式誘騙其執行包含木馬的惡意程序。黑客控制了開發人員的電腦后，搜集得到了 AWS 會話 token 等各類憑據，以及存放 Safe 網站前端資源文件的 S3 對象存儲的控制權。
黑客偽裝技術小白向開發人員求助（示意）
黑客真正的目標是竊取 Bybit 在 Safe{Wallet} 中的資金。于是，他們向 Safe 網站悄悄植入了針對性的惡意 JavaScript 代碼。
02
被篡改的例行交易
Bybit 的 Safe 錢包共設置了 6 位簽名者，每次交易需要其中 3 位進行批準。Bybit 還為錢包配置了提案人（proposer）的角色，經提案人簽名，可以向錢包提交新的交易請求，但提案人的簽名不計入交易需要的簽名總數。
提案人首先發起向溫錢包例行轉賬的請求，并通知簽名者處理。
簽名者在網頁內核實交易參數無誤后點擊簽名按鈕，惡意 JavaScript 卻向硬件錢包提交了篡改后的數據，但簽名者沒有注意核對，就確認了惡意請求。而Bybit的三位簽名者竟然都犯了同樣的錯誤。
篡改前后的交易參數對比（示意）
當三人均完成簽名后，錢包的所有資產在短時間內便被清空，刷新網頁后連錢包的基本信息都無法再加載。
03
鏈上攻擊分析
提案人原始的轉賬提案是調用代幣合約的?transfer(address,uint)?方法；篡改后的交易變成了向惡意合約發起調用，方法雖是看似無害的?transfer(address,uint)，但最重要的參數 Operation 字段由 0 變成 1，即調用方式了由普通調用（call）變成了 delegate call。
Delegate call 是以太坊智能合約中的一種特殊調用方式，它允許當前合約執行另一個合約的代碼，但使用的上下文仍然是調用者合約。任何對狀態的改動也都是對調用者合約進行的。
代理合約正是利用delegate call的這一特性，實現了智能合約的可升級性。代理合約負責存儲數據，而將邏輯處理委托給另一個邏輯合約。只需更新邏輯合約的地址，就能在不改變數據存儲的情況下，實現合約升級。
然而，如果delegate call的目標是惡意合約，由于它是在調用者合約的上下文中執行，可能導致資金被竊取、數據被修改等嚴重后果。
Safe 錢包實例在本質上是代理合約，所有代碼邏輯部署在 Safe MasterCopy 中，MasterCopy 的地址就保存在錢包實例的?storage[0]?位置。攻擊者利用惡意合約“升級”了 Safe 錢包，替換了錢包的邏輯實現地址，從而能夠利用新的邏輯進行任意提款操作。
惡意合約：在轉賬接口下，實現的邏輯卻是修改storage[0]
破綻百出的騙術
在整個事件中，”欺騙”是朝鮮黑客最主要的武器。如果他們針對 Safe 團隊的欺騙策略失敗，他們也許還有很多其他技術手段進行攻擊；但篡改前端代碼守株待 Bybit 的騙術，實際上存在諸多漏洞。根據 verichains 對簽名者電腦的取證分析報告，黑客篡改了兩個前端 JavaScript 文件。
在重現這一篡改過程時，我們發現該騙局并不完美，前端頁面存在多個可能暴露攻擊痕跡的地方：
- 在簽名完成時跳出的成功提示中，safe client gateway 會根據交易生成 “human description”，信息中會包含轉賬的數額、代幣名稱、收款地址信息，而這三要素在事件中沒有一個是匹配的：攻擊者把要替換的實現地址放在參數中，并將轉賬數額設置為 0，而惡意代幣合約本身沒有代幣名稱的收錄。
正常代幣轉賬及惡意合約“轉賬”消息示意對比
- 點擊成功提示中的 “View transaction”，能看到實際簽署的真實數據，以及對 delegate call 的顯著提示。
對異常 delegate call 的提示（示意）
- 在第一位簽名者完成簽名后，第二位簽名者的主頁會發生一些變化：隊列中的交易數由 1 個變成了 2 個；Pending transaction 從原本的例行轉賬變成了”Contract interaction”。從這個界面出發，如果他點擊了交易隊列或”Contract interaction”都可能會發現問題，但右上角通知指向的還是原始交易的確認頁面。
發生惡意簽名前后頁面對比（示意）
- 發送惡意簽名后，交易隊列會顯示 “Contract interaction” 與例行轉賬的 nonce 沖突，并且前者已有 1 個簽名，后者還停留在無確認的提案狀態。
Nonce沖突的兩個交易（示意）
- 由于所有簽名實際都是針對惡意請求的，每個簽名者在檢查原始的例行交易時，會看到它已確認的簽名數始終是 0。
- 攻擊完成后，Safe 頁面顯示余額清零、錢包損壞。
Bybit錢包目前已無法加載
要讓攻擊更難露餡，更縝密的攻擊者一方面會進一步修改前端界面，對各種 API 接口或前端組件繪制接口進行 Hook，確保各種界面和提示信息都與正常情況一致；另一方面最小化惡意交易和原始交易的參數差異、保持原始?data?字段完全不變、部署與真實代幣具有相同地址前后綴的惡意代幣合約。
當然事實證明，即使是這樣破綻百出的騙局，在毫無防備的受害者面前就是奏效了。
缺位的防御機制與安全意識
Safe 雖然所有代碼全部開源，但其 off-chain 部分的部署仍然沒那么公開透明。多簽機制本能排除單點故障，Safe 前端卻成為本次事件的單點故障源。
盡管 Bybit 的簽名人員在事件期間的不細心直接導致了損失，但其實也有不少可以預防的措施沒有落實。
01
過度依賴第三方
Bybit CEO Ben 在采訪中提到，許多交易所都使用內部解決方案保存資金，Bybit 也采用同樣的做法保存以太坊之外的資產。對于以太坊，他們過去沒有向智能合約方向投入足夠的資源，這也是 Ben 最大的遺憾之一。
不能過度依賴第三方不意味著需要完全獨立。事實上 Safe{Wallet} 公開透明的合約部分經過了長期的驗證，做得也足夠優秀，本次出問題的也是 off-chain 部分。就算 Bybit 不了解智能合約，也不打算重新寫一套 off-chain 平臺，哪怕僅是將 Safe 的開源平臺本地化部署一份，都能在受益于第三方能力的同時將自身的安全命運掌控在自己手中。
Safe{Wallet} 平臺實際上也集成了許多第三方工具。在交易簽名的界面上，有單獨一欄 Transaction checks 提供了 tenderly 的交易模擬功能，使用它可以方便地看到對所有資金流動記錄、事件日志、狀態改變的預測。如果用它對惡意交易進行一次模擬，隱匿的攻擊就無處遁形了。
tenderly 的交易模擬功能
02
缺少合約知識儲備
Bybit 和其他一些機構不僅缺乏獨立實現安全合約的能力，對 Safe 本身的合約執行邏輯也缺乏了解。攻擊發生后，Bybit 聯系 Safe{Wallet} 團隊臨時關閉了部分服務，這直接導致了后續其他機構向 Bybit 放款以及 Bybit 從另一 Safe 錢包提取 USDT 時遇到了“困難”。
然而，實際被暫停的僅是 off-chain 平臺服務，略懂智能合約的人查閱 Safe 的源代碼，便能明白如何在不依賴平臺的情況下，自行簽名并提交執行交易。
03
固步自封
正如前文所述，Bybit 是 Safe 的早期用戶，其遭受攻擊的合約仍停留在四年前部署的 1.1.1 版本。盡管該版本本身不存在漏洞，但卻無法享用新版本引入的 Guard 等安全特性。新版本 Safe 實現了模塊化的 Guard 機制，通過在交易執行前后增加調用 Guard 檢查函數的鉤子，Guard 能夠檢測到非預期行為，并將整個交易回滾。
Safe的亡羊補牢
在調查報告中，Safe 記錄了他們的舉措，包括完整的基礎設施重置、增強的惡意交易檢測、全面的監控系統、交易隊列重置、UI 改進等等。
Safe針對前端增加了許多關于二次確認的提示，在交易模擬檢查一節也加入了指向 OpenZeppelin 的 Safe Utils 的鏈接。
Safe前端新增警示
處理多簽交易的后端也對 delegate call 進行了嚴格的限制，只允許錢包向 MultiSend、SignMessageLib、SafeMigration 等白名單合約發起 delegate call。
safe-transaction-service 新增限制delegate call的commit
然而，一旦足夠精明的黑客再次發起攻擊，所有的 off-chain 機制都可能被繞過、甚至其他鏈上防御也能通過欺騙用戶進行解除。因此，最核心的安全防線仍然是牢牢守護密鑰 ——?Not Your Keys, Not Your Coins。
參 考：
[1] https://x.com/safe/status/1897663514975649938
[2] https://coinacademy.fr/wp-content/uploads/2025/02/Bybit-Incident-Investigation-Report.pdf
[3] https://followin.io/en/feed/16568414
[4] https://mp.weixin.qq.com/s/rB4XeIBATAb1zHZ9WVyxAg