原文作者：Moonbeam
時間軸
2025 年 2 月 21 日：Bybit 多籤錢包被攻擊， 15 億美金通過「合法」簽名交易流出。
鏈上追蹤：資金轉入匿名地址並分拆混幣，攻擊者與部分驗證節點存在潛在關聯。
事後分析：安全審計發現攻擊者利用 Safe 前端的供應鏈漏洞植入惡意腳本。
攻擊為什麼發生
黑客利用作惡的前端代碼使 bybit 多籤錢包的簽名者確信這是一筆合法交易（例如例行的 token 轉賬），結果實際上誘導他們對非法交易進行簽名，為了阻止簽名者通過其他手段發現交易內容有問題，黑客甚至把這次攻擊偽造成一筆 transfer 交易，讓 bybit 的簽名者儘量不通過其他方式檢查交易 calldata. (通常把交易內容叫做 calldata)
簡而言之攻擊方式是這樣的：
黑客獲得 Safe 前端的開發者權限，修改了前端代碼，植入了針對 bybit 攻擊的惡意腳本；
bybit 多籤成員訪問了被汙染的網頁，看到了假的交易信息：
他們看到的頁面: "轉賬 100 ETH 到地址 A"
實際要求籤名的是: "修改冷錢包邏輯"
這就像一個偷換了顯示屏的 ATM 機，屏幕顯示取 100 元，實際操作卻是取 100 萬元。
官方 APP —— 用戶的信任盲區
用戶認知中的多籤交易流程很簡單：看到交易 → 簽名 → 提交上鍊，但實際上隱含著一層關鍵的分離：
用戶看到的交易
實際簽名的交易
而使用官方 app 會讓用戶的警惕心理極大降低，以至於忽略掉這一層分離。如果官方 app 頁面被攻擊了，會導致用戶的簽名是真實的，他們只是不知道自己在此時究竟簽了什麼內容。
這時如果可以有獨立渠道驗證簽名內容的真實性，就可以極大程度地杜絕前端攻擊帶來的風險。這就是區塊鏈所提倡的： Don't trust it, VERIFY it.
「獨立渠道驗證」的理論基石
我們先來看 Safe 合約的工作原理（截至目前，Safe 合約還是足夠安全的）：
先把交易內容計算出一個哈希值（類似於生成交易的“指紋”）
用私鑰對這個哈希值進行簽名
當收集到足夠數量的簽名後，提交把交易原文和這些簽名提交到鏈上
鏈上重新根據原文計算哈希值，並驗證這些簽名是否有效，收集足夠的有效交易則執行，否則則拒絕。
哈希和簽名的安全和難偽造的屬性是區塊鏈 work 的兩大基石，不用懷疑。
因此，如果有獨立渠道可以在交易被提交上鍊之前，可以得到交易原文以及簽名，就可以驗證「用戶簽名的交易到底是什麼」以及「用戶是不是對這筆交易進行的簽名」。
因此，即使前端或後端被攻擊，最壞的情況只是返回錯誤數據，而錯誤數據在「獨立渠道」會產生以下幾種情況：
錯誤交易原文，錯誤簽名——用戶拒絕發送交易上鍊
錯誤交易原文，有效簽名——用戶拒絕發送交易上鍊
錯誤交易原文，錯誤簽名——用戶拒絕發送交易上鍊
我們可以看到最壞的情況也只是這筆交易不會被髮送上鍊，除此之外，不會造成任何的鏈上損失。所以針對類似這種「顯示攻擊」最好的方式就是多渠道驗證，這也符合區塊鏈的精神：don't trust it, VERIFY it.
現有的解決方案
多個多籤產品相互驗證
目前市場上有很多 safe-compatible 的多籤產品，例如 Safe 自己就部署了兩版獨立的前端頁面：
https://eternalsafe.vercel.app/welcome/
https://eternalsafe.eth.limo/welcome/
用戶在對一筆多籤交易簽名之後，自己或者後續的簽名者登錄到另一個多籤產品的頁面中，再次查看交易原文，如果不同多籤產品顯示完全相同的交易內容解析，則可以相信「自己要簽名的交易內容」是正確的。
但是這需要不同的多籤產品都在使用{Safe}的後端存儲鏈下交易和簽名數據並且也會把自己收集到的簽名數據發送給{Safe}後端，這對產品之間的協作要求非常苛刻；而且 Safe 對一些不常規交易的原文解析並不友好，就算多個 Safe 前端顯示了同樣的 calldata，但是如果只是一串沒有意義0x abcdefsf，也會讓簽名者望而卻步。
注：目前 Safe 提供的兩個獨立的替代網站均需自己提供 RPC 鏈接：
獨立的 Safe 交易驗證工具
對於 Safe 前端攻擊事件，社區的反應也很快，我們在 Safe 官方的 telegram 群裡發現已經有人提供了獨立的 Safe 交易解析工具，這種方式看起來更加簡單直接。
我們也對這個工具進行的驗證。如圖，只需要把 safe 頁面裡的交易分享鏈接粘貼進來，就可以自動讀取 Safe 後端數據，並獨立驗證交易原文的哈希值和簽名的正確性，簡而言之如果確定圖中的 calldata 解析是自己想要的交易，並且「SafeHash Check」和「Signature Check」驗證通過，就可以認為「這是自己想發送的交易」並且「自己已經正確簽名」了。
當然為了保險起見，也要再仔細核對Safe Address, 通過簽名解析出的簽名者地址、交互的合約地址以及操作類型是 Call 還是 Delegatecall，例如 bybit 這次被攻擊的交易就是 delegatecall 和 transfer 同時出現，一個稍有經驗的開發者都會知道這樣的組合非常奇怪。
如果遇到不可讀的交易信息：
可以點擊 Decode，提供該交易方法的 ABI，如：
就可以展示可讀的交易信息：
Stay Safe - VERIFY, not trust
Bybit 的多籤攻擊再次提醒我們，前端信任並不等於交易安全。即便使用的是官方應用，交易內容依然可能被篡改，簽名者必須有獨立的方式來驗證自己簽署的內容。
不要輕信，務必驗證（Don’t trust it, VERIFY it.）是 Web3 安全的核心原則。希望未來 Safe 生態和更多多籤產品能加強獨立驗籤機制，避免類似攻擊再次發生。
