撰文：imToken
一台原廠晶片完好、韌體正版，甚至能順利通過官方正品驗證（Genuine Check）的硬體錢包，裡面的資產竟然還是可能被駭客偷走？
最近的 Ledger 安全事件，恰恰暴露了這種看似不可能的風險。
按照 Ledger 安全團隊後續披露的調查結果，攻擊者在涉事設備內部額外植入了一塊惡意電路，它能夠截取螢幕上顯示的助記詞，並透過行動通訊網路發送給攻擊者。
換句話說，原廠安全晶片沒有被攻破，助記詞卻在第一次顯示到螢幕上時，就可能已經落入駭客手中。
而且，這並不是近期唯一值得關注的安全事件。
9 月以來，從 Bitget 遭遇第三方安全產品漏洞利用，到 Trezor 的郵件服務商 Brevo 被入侵，再到 MetaMask 部分基礎設施出現安全問題，一系列事件正在提醒我們，當 Crypto 產品越來越複雜，安全已經不只是保護好私鑰、避免智能合約漏洞那麼簡單。
那些藏在設備流通、第三方服務、內部權限和使用者通訊中的風險，同樣可能成為攻擊者尋找的突破口。
一、Ledger 敲響的「供應鏈安全」新警鐘
先來拆解 Ledger 這次的遭遇。
大家平時買硬體錢包，提防的無非是兩件事：買到假貨，或者收到一台被人提前初始化過的設備。
早年最常見的套路，就是一些惡意中介先把助記詞生成好、印在刮刮卡上塞回包裝，賭新手使用者不懂規則直接往裡充錢。
這種騙局雖然凶險，但防禦邏輯很清晰——找正規渠道、檢查設備狀態、看著設備自己生成新助記詞，絕不用包裝盒裡現成的助記詞。
但這次針對 Ledger 的攻擊，手段明顯上了個台階，駭客在殼體內部額外塞進了一套帶有微控制器、eSIM 和蜂窩通訊能力的電子模組，使用者首次初始化錢包時，總歸要通過螢幕讀取助記詞並抄寫下來。
換句話說，植入的惡意電路完全不干預助記詞的生成過程，它只是監視助記詞並直接傳走，這也是為什麼「私鑰沒有從安全晶片中被直接提取」，並不意味著使用者的錢包恢復資訊仍然安全。
更麻煩的是，即使設備通過官方 Genuine Check 正品驗證，也未必能識別這種額外加裝的硬體，因為正品驗證主要是在確認安全晶片身份和韌體可信性。
所以這次事件，也確實暴露了一個易被大家日常忽視的嚴重「供應鏈風險」：硬體錢包的安全，不只取決於晶片和韌體，還取決於它從原廠到使用者手中的整個交付過程。
畢竟一款設備可能需要經過區域經銷商、第三方倉庫、物流和零售商等多個環節，任何擁有實際接觸設備機會的參與者，都可能成為需要額外評估的風險點。
二、從 Trezor 到 Bitget：攻擊者如何繞過核心安全防線？
理解了 Ledger 的問題，再來看近期 Bitget、Trezor 接連撞上的安全事件，就會發現底層邏輯驚人地相似：攻擊者同樣避開了最堅固的正面防線，轉頭從外圍的「第三方服務」切了進來。
先看 Trezor。
9 月初，部分 Trezor 使用者收到了一封主題為「Critical Security Alert: STM32 Entropy Vulnerability」的郵件，聲稱硬體錢包出現嚴重安全漏洞，需要立即採取措施。
這類郵件很容易讓使用者緊張，畢竟涉及硬體錢包和安全漏洞，誰也不希望自己的資產因此受到損失。
這正是攻擊者利用了 Trezor 所使用的第三方郵件行銷平台 Brevo，讓惡意內容通過正常的郵件發送基礎設施抵達使用者信箱。
根據 Brevo 後續事故報告，攻擊者利用其單點登入系統的權限邊界缺陷，獲得了對其他客戶帳戶的未授權存取能力，最終涉及 138 個客戶帳戶，其中部分被用於發送釣魚郵件或匯出聯絡人資料。
Trezor 隨後確認，有 347149 個行銷郵件聯絡人地址在事件中被匯出，攻擊郵件則試圖誘導使用者下載惡意應用，並輸入錢包備份資訊。
需要注意的是，這起事件並沒有證據表明 Trezor 的硬體錢包或私鑰保護系統被攻破，攻擊者首先獲取的是使用者資訊與官方通訊渠道的濫用能力。
但對於收到郵件的普通使用者而言，識別風險反而變得更加困難，因為郵件可能來自熟悉的官方網域，也能通過正常的郵件認證檢查，內容卻已經被攻擊者替換成了釣魚資訊。
如果使用者因此主動填寫助記詞，原本只是第三方郵件服務的問題，就可能進一步演變成真實的資產損失。
再來看 Bitget。
9 月 24 日，Bitget 部分熱錢包和溫錢包發生未經授權的資產轉出，最終核實涉及約 3.88 億美元。
根據 Bitget 官方公布的調查結果，攻擊者利用了一款第三方安全產品的漏洞，獲取交易所內部的高權限憑證，隨後侵入錢包相關後端系統，偽造提現指令，繞過原有風控檢查，使異常轉帳進入正常執行流程。
Bitget 表示，此次事件並未發現私鑰洩露，冷錢包也沒有受到影響，這聽起來似乎有些矛盾：既然私鑰沒被偷，為什麼錢還能被轉走？
其實不難理解。
對於交易所這種託管式平台來說，使用者發起提現後，並不是每次都由人工拿著私鑰逐筆簽名，而是需要經過帳戶校驗、風控審核、交易生成、錢包簽名等一整套內部流程。
這就像銀行金庫。即使金庫鑰匙保管得非常嚴格，如果有人能夠冒用內部的高權限身份，偽造一份通過審批的轉帳指令，金庫裡的資金仍然可能被錯誤地轉出去。
Bitget 這次暴露的，正是上游權限和指令校驗失守後，風險如何進一步傳導至資產執行系統，所以，「私鑰沒有洩露」和「資金不會被非法轉走」，其實是兩回事。
至於 9 月底 MetaMask 披露的基礎設施安全事件，則呈現了另一種維度的營運風險。
當時 MetaMask 採取預防性措施，主動退出部分受影響的質押驗證者。根據官方 10 月 1 日的調查更新，尚未發現 MetaMask 錢包或客戶資金受到影響的跡象，相關質押業務也不代替客戶管理提款密鑰。
不過，這並不意味著基礎設施出問題就不會產生其他影響。非託管解決的主要是資產控制權問題，卻不能自動消除外部基礎設施的營運風險。
把這幾件事拼在一起看，脈絡其實非常清晰：
- Ledger 暴露的是硬體流通環節的物理竄改風險，最終可能導致助記詞被竊取；
- Trezor / Brevo 暴露的是用戶資訊洩露與官方通訊管道被濫用的風險，並不等於錢包本身被攻破；
- Bitget 暴露的是第三方產品漏洞向內部高權限系統傳導的風險，能夠直接影響資金執行；
- MetaMask 則提醒我們，資產控制權和服務營運風險並不是同一個概念。
總的來看，今天的 Crypto 產品早就不是一座座孤島了。
錢包要靠外部 RPC 節點讀取鏈上數據、靠聚合介面拉取行情；交易所離不開外部的安全監控、KYC 認證和風控組件；往外再延伸，還有節點營運商、雲廠商、客服工單以及像 Brevo 這樣的郵件系統。
這些外部服務讓產品運行得更高效，也改善了用戶體驗，但與此同時，每引入一個新的外部依賴，產品就多了一層需要管理的信任關係：
第三方能夠存取什麼、擁有多大權限，以及它一旦失守，會不會把風險繼續傳導至其他核心系統？
三、產品和用戶該怎麼防？
面對越來越複雜的第三方依賴風險，以及環環相扣的依賴關係，指望產品團隊退回到「不借助任何外部服務」的原始狀態顯然不現實，也不符合市場規律。
真正考驗安全架構功力的，是盡可能縮小每一個可能的風險敞口。
比如，一家只負責發營銷郵件的 SaaS 服務商，憑什麼長期留存全量用戶的聯絡數據？第三方安全監測工具，為什麼能在缺乏獨立多重授權的情況下觸達核心生產環境？尤其是涉及到資金劃轉的敏感動作，內部系統之間絕不能搞「預設信任」，必須做嚴格的權限隔離與獨立交叉驗證。
這也是安全架構中常說的「最小權限」和「職責分離」：發郵件的平台只應該擁有發送郵件所需的權限，安全監控工具不應該隨意執行資金劃轉，而一筆大額提現，也不能僅憑某個內部系統傳來的指令就直接放行。
而 Ledger 事件進一步提醒硬體錢包廠商，安全管理甚至需要向產品的物理流通環節延伸。
從出廠、倉儲、物流到經銷商交付，如何建立可追溯的管理流程，如何發現設備異常拆裝或被替換，以及出現問題後如何定位受影響批次和用戶，都不應該被視為單純的渠道管理工作。
因為對一款保護私鑰的硬體設備而言，交付過程本身就是安全體系的一部分。
當然，對於普通用戶來說，我們既無法審計錢包的軟體供應鏈，也無法逐一調查硬體錢包的每一處倉儲和物流環節。
但這並不意味著只能被動承擔風險，至少有幾件事情，值得在日常使用中養成習慣。
首先，盡量減少硬體錢包購買過程中的不必要中轉。
如果條件允許，優先選擇品牌官網下單、原廠或官方倉庫直接發貨，通常可以減少設備脫離原廠控制後被第三方接觸、拆裝或調換的機會。
從風險管理的角度來看，接觸設備的獨立主體越多，需要額外信任的環節也就越多；此外設備收到後，仍應檢查包裝與外觀異常、使用官方軟體完成驗證，並嚴格遵守初始化流程。
其次，需要重新理解「官方消息」是否可信。
Trezor 的事件已經說明，即使郵件確實通過官方使用的服務平台發送，也不代表其中的連結和操作要求一定安全。
尤其涉及錢包升級、帳戶凍結、資產遷移、漏洞修復等敏感操作時，最好不要直接點擊消息內的連結，而是通過自己保存的官網地址或已經安裝的官方 App 主動核實。
對於 imToken 這類非託管錢包而言，用戶同樣需要認準官方渠道，下載安裝以 token.im 為準，遇到異常資訊時優先通過 App 內「幫助與反饋」等官方入口核實。
無論對方自稱官方客服、安全團隊，還是提供看起來十分專業的漏洞說明，都不應該向其透露助記詞或私鑰。
最後，需要分清不同安全事件對自己的實際影響。
郵箱地址洩露，主要意味著未來可能面臨更多定向釣魚；點擊可疑連結，需要進一步確認是否下載、運行了惡意程式；如果已經輸入助記詞，則應立即按錢包控制權洩露處理。
如果簽署過可疑交易或授權，還需要結合具體鏈上操作，判斷是否存在持續的合約授權風險。
而對於第三方服務故障或基礎設施異常，則更需要參考官方披露的影響範圍，判斷是否涉及自己的資產、服務可用性或收益。
不能一聽到「錢包安全事件」，就預設私鑰已經被攻破，更不應該因為所謂的緊急安全通知，貿然將資產轉向陌生地址。
畢竟，很多時候攻擊者真正期待的，並不是突破最堅固的技術防線，而是讓用戶在恐慌中主動完成最後一步（延伸閱讀《AI「挑戰」密碼學？Web3 必須未雨綢繆，但絕不能倉促遷移》）。
寫在最後
過去，Crypto 行業最常強調的一句話是「Not your keys, not your coins」。
這句話依然重要，因為私鑰控制權決定了用戶能否真正自主掌握資產。
但隨著錢包、交易所與鏈上金融產品逐漸成熟，我們也需要意識到，私鑰保護只是整個安全體系中的一部分。
一台真正的硬體錢包，仍然可能在交付過程中遭到物理竄改；一封真正來自官方郵件系統的通知，也可能被攻擊者利用；而一套原本用於加強安全的第三方工具，甚至可能成為核心資金系統的入口。
這些案例並不意味著我們應該對所有錢包和外部服務失去信任，恰恰相反，它提醒整個行業，需要把安全從單一產品內部，進一步延伸到供應鏈、權限管理、用戶通訊和應急響應的全過程。
畢竟，真正成熟的 Crypto 安全體系，不僅要確保私鑰不會輕易洩露，更要盡可能保證即使某個外部環節出了問題，整套機制依然能把風險死死卡在半路，不讓它越過用戶資產的最後一道雷池。
