後Safe時代:每個Safe使用者都該掌握的多簽安全新範式

本文約1814字,閱讀全文需要約3分鐘
「不要輕信,務必驗證」是Web3安全的核心原則。

原文作者:Moonbeam

時間軸

  • 2025 年 2 月 21 日: Bybit 多簽錢包被攻擊, 15 億美金透過「合法」簽名交易流出。

  • 鏈上追蹤:資金轉入匿名地址並分拆混幣,攻擊者與部分驗證節點有潛在關聯。

  • 事後分析:安全稽核發現攻擊者利用Safe 前端的供應鏈漏洞植入惡意腳本。

攻擊為什麼會發生

黑客利用作惡的前端代碼使 bybit 多簽錢包的簽名者確信這是一筆合法交易(例如例行的 token 轉賬),結果實際上誘導他們對非法交易進行簽名,為了阻止簽名者通過其他手段發現交易內容有問題,黑客甚至把這次攻擊偽造成一筆 transfer 交易,讓 bybit 的簽名者通常把交易通過其他方式檢查 calldata.

簡而言之攻擊方式是這樣的:

  1. 駭客獲得 Safe 前端的開發者權限,修改了前端程式碼,植入了針對 bybit 攻擊的惡意腳本;

  2. bybit 多簽成員造訪了被污染的網頁,看到了假的交易資訊:

  3. 他們看到的頁面: 轉帳100 ETH 到地址A

  4. 實際要求簽名的是: 修改冷錢包邏輯

這就像偷換了顯示器的ATM 機,螢幕顯示取100 元,實際操作卻是取100 萬元。

官方 APP —— 用戶的信任盲點

使用者認知中的多簽交易流程很簡單:看到交易→ 簽章→ 提交上鍊,但其實隱含著一層關鍵的分離:

  1. 用戶看到的交易

  2. 實際簽名的交易

而使用官方 app 會讓使用者的警覺心理大大降低,以至於忽略掉這一層分離。如果官方 app 頁面被攻擊了,會導致用戶的簽名是真實的,他們只是不知道自己在此時究竟簽了什麼內容。

這時如果可以有獨立管道驗證簽章內容的真實性,就可以大幅杜絕前端攻擊帶來的風險。這就是區塊鏈所主張的: Dont trust it, VERIFY it.

「獨立通路驗證」的理論基石

我們先來看 Safe 合約的工作原理(截至目前,Safe 合約還是足夠安全的):

  1. 先把交易內容算出一個哈希值(類似生成交易的「指紋」)

  2. 用私鑰對這個哈希值進行簽名

  3. 當收集到足夠數量的簽名後,提交把交易原文和這些簽名提交到鏈上

  4. 鏈上重新根據原文計算哈希值,並驗證這些簽章是否有效,收集足夠的有效交易則執行,否則則拒絕。

哈希和簽名的安全和難以偽造的屬性是區塊鏈 work 的兩大基石,不用懷疑。

因此,如果有獨立管道可以在交易提交上鍊之前,可以得到交易原文以及簽名,就可以驗證「用戶簽署的交易到底是什麼」以及「用戶是不是對這筆交易進行的簽名」。

因此,即使前端或後端被攻擊,最糟的情況只是傳回錯誤數據,而錯誤資料在「獨立管道」會產生以下幾種情況:

  • 錯誤交易原文,錯誤簽名-使用者拒絕傳送交易上鍊

  • 錯誤交易原文,有效簽名-使用者拒絕傳送交易上鍊

  • 錯誤交易原文,錯誤簽名-使用者拒絕傳送交易上鍊

我們可以看到最壞的情況也只是這筆交易不會被發送上鍊,除此之外,不會造成任何的鏈上損失。所以針對類似這種「顯示攻擊」最好的方式就是多管道驗證,這也符合區塊鏈的精神:dont trust it, VERIFY it.

現有的解決方案

多個多簽產品相互驗證

目前市面上有許多 safe-compatible 的多簽商品,例如 Safe 本身就部署了兩版獨立的前端頁面:

https://eternalsafe.vercel.app/welcome/
https://eternalsafe.eth.limo/welcome/
用戶在對一筆多簽交易簽名之後,自己或後續的簽署者登入到另一個多簽產品的頁面中,再次查看交易原文,如果不同多簽產品顯示完全相同的交易內容解析,則可以相信「自己要簽署的交易內容」是正確的。

但這需要不同的多簽產品都在使用{Safe}的後端存儲鏈下交易和簽名數據並且也會把自己收集到的簽名數據發送給{Safe}後端,這對產品之間的協作要求非常苛刻;而且 Safe 對一些不常規交易的原文解析並不友好,就算多個 Safe 前端顯示了同樣的 calldata,但是如果只是

註:目前 Safe 提供的兩個獨立的替代網站均需自行提供 RPC 連結:

後Safe時代:每個Safe使用者都該掌握的多簽安全新範式

獨立的 Safe 交易驗證工具

對於 Safe 前端攻擊事件,社群的反應也很快,我們在 Safe 官方的 telegram 群組發現已經有人提供了獨立的 Safe 交易解析工具,這種方式看起來更加簡單直接。

後Safe時代:每個Safe使用者都該掌握的多簽安全新範式

我們也對這個工具進行的驗證。如圖,只需要把 safe 頁面裡的交易分享鏈接粘貼進來,就可以自動讀取 Safe 後端數據,並獨立驗證交易原文的哈希值和簽名的正確性,簡而言之如果確定圖中的 calldata 解析是自己想要的交易,並且“SafeHash Check”和“Signature Check”驗證通過,就可以認為“這是自己已經正確的交易”簽名。

當然為了保險起見,也要再仔細核對Safe Address,透過簽名解析出的簽名者地址、交互的合約地址以及操作類型是 Call 還是 Delegatecall,例如 bybit 這次被攻擊的交易就是 delegatecall 和 transfer 同時出現,一個稍有經驗的開發者都會知道這樣的組合非常奇怪。

後Safe時代:每個Safe使用者都該掌握的多簽安全新範式

如果遇到不可讀的交易資訊:

後Safe時代:每個Safe使用者都該掌握的多簽安全新範式

可以點選 Decode,提供該交易方法的 ABI,如:

後Safe時代:每個Safe使用者都該掌握的多簽安全新範式

就可以展示可讀的交易資訊:

後Safe時代:每個Safe使用者都該掌握的多簽安全新範式

Stay Safe - VERIFY, not trust

Bybit 的多簽攻擊再次提醒我們,前端信任不等於交易安全。即便使用的是官方應用,交易內容依然可能被竄改,簽署者必須有獨立的方式來驗證自己簽署的內容。

不要輕信,務必驗證(Dont trust it, VERIFY it.)是Web3 安全的核心原則。希望未來Safe 生態和更多多簽產品能加強獨立驗簽機制,避免類似攻擊再次發生。

本文來自投稿,不代表Odaily立場。 如若轉載請注明出處。

ODAILY提醒,請廣大讀者樹立正確的貨幣觀念和投資理念,理性看待區塊鏈,切實提高風險意識; 對發現的違法犯罪線索,可積極向有關部門舉報反映。

推薦閱讀
星球精選