撰文：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 安全体系，不仅要确保私钥不会轻易泄露，更要尽可能保证即使某个外部环节出了问题，整套机制依然能把风险死死卡在半路，不让它越过用户资产的最后一道雷池。