慢霧:Safe困局,Guard能否重構契約巴別塔?

avatar
律動
02-28

背景

2025 年 2 月 21 日,加密貨幣行業遭遇史上最嚴重的資產管理危機。交易平臺 Bybit 的鏈上多籤錢包遭定向攻破,近 15 億美元資產通過一筆「合法簽名」的交易悄然流失。事後鏈上分析顯示,攻擊者通過精密的社會工程攻擊獲取了多籤權限,利用 Safe 合約的 delegatecall 功能植入惡意邏輯,最終繞過多重簽名驗證機制,將資金轉移至匿名地址。

此次事件暴露出一個殘酷現實:「多重簽名」不等於「絕對安全」,即便是 Safe 多籤錢包這樣的安全機制,如果缺乏額外的防護措施,仍然存在被攻破的風險。這也並非首個針對 Safe 多籤錢包的攻擊案例。去年 WazirX(損失 2.3 億美元)和 Radiant Capital(損失 5,000 萬美元)都遭遇了類似的攻擊手法。正如慢霧:Bybit 近 15 億美元被盜背後的黑客手法與疑問一文中的分析,Safe 多籤錢包攻擊事件呈現出以下技術同源性:

過度依賴簽名機制:將安全責任都交給私鑰保管。

動態防禦缺失:缺乏交易執行前的實時風險掃描。

權限控制粗粒度:未對 delegatecall 等高風險操作建立白名單機制。

這一系列事件的核心問題不在於 Safe 合約本身,而是在於整個系統的集成過程中的安全隱患,特別是在前端驗證環節。這促使我們需要思考:如何通過 Safe 的額外安全措施機制來強化多籤錢包的防護能力?

Safe

Safe 是一款多重簽名 (Multi-Sig) 錢包,主要用於管理高價值資產和數字貨幣的安全存儲與轉移。作為去中心化資產管理的基礎設施,它通過多方協同驗證機制確保資金操作的安全性,防止單一管理員或黑客利用單點故障進行惡意操作,廣泛應用於 DAO 治理、企業資金託管、去中心化基金池等場景。該合約由 Safe(原 Gnosis Safe)團隊開發,是當前行業標準的鏈上資產管理解決方案。合約採用 EIP-712 標準實現結構化數據簽名,從而提高交易數據的安全性和可驗證性。

核心用途

資金安全管理:合約要求多個預先設定的所有者 (Owners) 共同確認交易才能執行,從而有效防止單點失誤或惡意操作,確保資金安全。

交易執行與管理:通過內置的多籤驗證機制,合約能夠在滿足簽名閾值條件的情況下,執行對外轉賬、調用其他合約或處理複雜的業務邏輯,支持代幣和原生幣的支付和費用補償。

模塊化擴展:合約採用模塊化設計,通過繼承和組合多個管理模塊(如 OwnerManager、ModuleManager、GuardManager、FallbackManager 等),使其功能靈活且易於擴展,為不同應用場景提供定製化支持。

函數解析

execTransaction 函數執行經過多重簽名驗證的交易:

· 計算交易的唯一哈希值(結合交易參數、nonce 等);

· 驗證所有簽名的有效性,確保每個簽名均來自合法的所有者或預先批准的地址;

· 調用目標地址的業務邏輯,並在交易執行後通過事件記錄成功或失敗狀態;

· 支持靈活的 gas 費用處理,確保在支付補償時準確計算交易成本。

checkContractSignatures & checkNSignatures 函數驗證交易或消息的簽名數據:

· 分別處理 EOA 賬戶簽名、合約簽名 (EIP-1271)、以及預批准的哈希;

· 確保簽名按照所有者順序排列,並且每個簽名都來自有效地址,防止重放攻擊和簽名篡改。

getTransactionHash 函數生成交易哈希,用於簽名驗證和防止重放攻擊:

· 利用 EIP-712 標準對交易數據進行結構化哈希;

· 使用內聯彙編優化內存操作,提高計算效率;

· 結合當前的 nonce 值,確保每筆交易的唯一性。

handlePayment 函數處理執行交易過程中的 gas 補償支付:

· 根據實際消耗的 gas 費用和基礎費用計算支付金額;

· 支持 ETH 以及其他代幣的支付,確保費用補償準確無誤。

onBeforeExecTransaction 為內部虛擬鉤子函數,在 execTransaction 函數執行之前被調用。該函數的設計目的是允許繼承 Safe 合約的子合約在交易執行前進行自定義邏輯處理。接收的參數集包括:

· to:目標地址 - 交易要調用的合約或賬戶地址

· value:以太幣值 - 隨交易發送的以太幣數量

· data:數據載荷 - 包含函數選擇器和參數的調用數據

· operation:操作類型 - 確定是 CALL 還是 DELEGATECALL

· safeTxGas:交易 gas 限制 - 為交易執行預留的 gas 數量

· baseGas:基礎 gas - 獨立於交易執行的 gas 成本

· gasPrice:gas 價格 - 用於計算交易費用補償的 gas 價格

· gasToken:gas 代幣 - 用於支付交易費用的代幣地址

· refundReceiver:退款接收者 - 接收交易費用補償的地址

· signatures:簽名集合 - 所有者對交易的簽名數據

儘管多籤錢包合約憑藉其嚴謹的安全設計和靈活的模塊化結構,為數字資產管理提供了高效且安全的解決方案,實現了從交易初始化到最終執行的全流程安全管控,併成為區塊鏈安全管理的重要工具,但同樣需要注意的是,受害者大多依賴硬件錢包進行簽名,而部分硬件設備對結構化數據簽名的顯示效果欠佳,容易導致用戶在短時間內無法準確識別交易數據,從而有「盲籤」風險。針對這一現象,除了優化硬件及其數據展示效果之外,還可以探索增加多重確認、智能提示以及增強簽名驗證工具等措施,以進一步降低盲籤帶來的安全隱患。

Safe Guard

Safe 合約在 1.3.0 版本中引入的重要安全功能——Safe Guard 機制。這一機制旨在為標準的 n-out-of-m 多籤方案提供額外的限制條件,進一步增強交易安全性。Safe Guard 的核心價值在於能夠在交易執行的不同階段進行安全檢查:

· 交易前檢查 (checkTransaction):Guard 機制可以在交易執行前,對交易的所有參數進行程序化檢查,確保交易符合預設的安全規則。

· 交易後檢查 (checkAfterExecution):在交易執行完成後,Guard 還會進行額外的安全驗證,檢查交易執行後 Safe 錢包的最終狀態是否符合預期。

架構分析

在 Safe 中,多籤交易一般通過 execTransaction 函數進行執行。在 Safe Guard 啟用的情況下,當用戶執行多籤交易時,Safe 合約將調用 Guard 合約的 checkTransaction 函數執行交易前檢查,而當多籤交易執行完成後,Safe 合約將調用 Guard 合約的 checkAfterExecution 函數對交易的執行結果進行檢查。具體實現如下:

當 Safe 合約通過 Guard 機制執行多籤交易預檢時,其 checkTransaction 函數將接收完整的交易上下文數據,包括目標合約地址、調用方式、執行數據(如 delegatecall)、owner 簽名信息、Gas 配置及支付信息。

該機制使開發者能夠實現多維度的風控策略,例如合約白名單管控(限制可交互地址)、函數級權限管理(禁用高危函數選擇器)、交易頻率限制以及基於資金流向的動態規則等。通過合理配置 Guard 策略,可有效阻斷攻擊者利用非合約層面進行攻擊。

在近期不斷曝出安全事件的背景下,各方對多籤錢包合約的安全性日益關注,硬件錢包提供商如 KeyStone 、OneKey、RigSec 等紛紛呼籲增強 Safe 合約的解析和防護能力,以預防類似風險的再次發生。在 Bybit 事件後,許多項目方開始聚焦 Safe 合約,並探索基於 Guard 機制的升級與擴展方案。

其中,不乏有基於 Guard 機制的創新應用,構建一種建立在 Safe 多籤錢包之上的中間層安全解決方案,為底層資產與用戶資產之間提供了額外的安全保障。其核心作用在於,通過將 Safe 多籤交易涉及的目標合約、調用方式、執行數據、owner 簽名信息、付款信息以及 gas 信息傳入 checkTransaction 函數,實現對交易的極細粒度檢查,包括白名單合約調用、白名單函數操作、白名單轉賬目標、交易頻次等權限控制。

值得注意的是,Safe 本身只提供 Guard 管理和回調功能,實際的多籤交易檢查邏輯由用戶自行實現,其安全性取決於 Guard 實現的質量。如:Solv Guardian 拓展了這一思路,在每個 Vault 配置專門的 Guardian 來指定允許的目標地址和操作權限,實現了指定允許合約、定義允許函數操作和 ACL 驗證需求三大權限控制要素。

同時,採用分離的治理機制,由 Vault Guardian 負責執行,而 Governor 控制治理權限,確保即便 Guardian 出現問題,也能及時採取補救措施保護用戶資產。類似的設計理念也在 Elytro 的 SecurityControlModule 中得到應用,該模塊通過 preExecute 函數攔截關鍵操作,並藉助白名單機制對模塊安裝、鉤子設置和驗證器管理等高風險操作進行精細管控,從而確保只有經過信任的合約才能被添加到系統中,為錢包提供了持久的安全保障。

在 Bybit 事件攻擊鏈中,若 Safe 合約部署了合理配置的 Guard 機制,攻擊者通過 execTransaction 發起的惡意 delegatecall 將在預檢階段被多重策略攔截:Guard 的 checkTransaction 函數首先識別到 delegatecall 操作類型並觸發禁用規則(如強制限定 operation 僅為普通調用),隨後解析 data 字段檢測到非常規合約地址(0x4622...7242)及高危函數選擇器,通過預設的合約白名單與函數黑名單策略直接回滾交易,最終形成「策略攔截 → 邏輯阻斷」的防禦體系,徹底阻斷存儲篡改與資金轉移路徑。

總的來說,Safe 僅在 1.3.0 版本之後才提供 Guard 功能,儘管 Guard 可以提供極為細粒度的多籤交易檢查,但用戶在使用 Guard 功能時有較大的門檻。他們需要自行實現 Guard 檢查邏輯,粗略的或者有缺陷的 Guard 實現可能無法幫助用戶提升其 Safe 錢包的安全性,因此對 Guard 實現進行安全審計是必要的。毫無疑問的是,安全且適當的 Guard 實現可以極大提升 Safe 錢包的安全性。

結論與展望

Bybit 被攻擊事件凸顯了及時更新安全基礎設施的重要性,Bybit 使用的是 v1.1.1 (<1.3.0) 版本的 Safe 合約,這意味著他們無法使用 Guard 機制這一關鍵安全特性。如果 Bybit 升級到 1.3.0 或更高版本的 Safe 合約,並實現了合適的 Guard 機制,例如指定唯一接收資金的白名單地址,並進行嚴格的合約函數 ACL 驗證,可能就能避免這次的損失。儘管這只是假設,但它為未來的資產安全管理提供了重要思路。

Safe Guard 機制就像給數字資產保險箱加裝的智能安檢系統,其效能取決於規則設計的嚴謹性和實施質量。面對日益精密的攻擊手段,我們需要:

· 自動化驗證:建立自動化的交易驗證機制

· 動態策略調整:根據威脅情報實時調整安全策略

· 多層防禦:結合多種安全機制構建深度防禦體系

· 持續審計:對 Guard 實現進行定期安全審計

未來的數字資產管理,將是智能合約安全機制與持續攻防演進的共同進化過程。只有將安全理念融入每一個環節,才能在黑客的"矛"與守護者的"盾"的博弈中構築真正的安全壁壘。

原文鏈接

歡迎加入律動 BlockBeats 官方社群:

Telegram 訂閱群:https://t.me/theblockbeats

Telegram 交流群:https://t.me/BlockBeats_App

Twitter 官方賬號:https://twitter.com/BlockBeatsAsia

來源
免責聲明:以上內容僅為作者觀點,不代表Followin的任何立場,不構成與Followin相關的任何投資建議。
喜歡
收藏
評論
Followin logo