摘要:Electrum 发布 4.8.3 版本,紧急修补一个可被恶意服务器利用的高危漏洞。攻击者通过替换未确认交易,诱使用户在提升手续费时误授权欺诈性支付,已确认两起真实损失事件。

币圈界报道:
Electrum 4.8.3 版本上线修复重大安全缺陷:防范恶意服务器劫持交易
Electrum 推出 4.8.3 版本,以应对一个已被实际利用的严重安全漏洞。该漏洞允许攻击者操控待处理的比特币交易,导致用户资金被非法重定向。开发者证实,已有至少一例资金被盗事件发生。
攻击路径揭示:恶意服务器如何篡改未确认交易
在发现恶意服务器正积极利用此漏洞后,Electrum 迅速发布补丁。攻击者通过伪造交易信息,在用户尝试提高手续费时,诱导其签署指向攻击者控制地址的欺诈性支出请求。
目前已记录两起独立报告,其中一名用户因执行手续费升级操作而蒙受损失。该漏洞影响所有早于 4.8.3 的版本,但具体经济损失尚未公开。
根据 10 月 24 日发布的《安全公告》,攻击者利用了 Electrum 对未确认交易的签名验证缺失机制。当用户发起“按费替换”(Replace-by-Fee)操作时,钱包会显示由恶意服务器提供的修改后交易,而旧版本未进行签名核验,致使用户误认为是合法交易并批准。
作为轻量级钱包,Electrum 依赖外部服务器获取交易数据和广播信息,采用简化支付验证(SPV)模式。其设计默认信任主服务器提供的待处理交易信息,这一信任机制成为攻击入口。
攻击者拦截未上链的原始交易,将其替换为收款地址指向自身控制账户的伪造交易。尽管该替换交易签名无效,但旧版 Electrum 在展示前未做校验,从而将欺诈交易呈现为有效记录。
RBF 功能的正常使用在此场景下反成风险点:用户为加快确认而提交新交易,却在不知情中签署了另一笔支付给攻击者的有效交易。
真实案例验证漏洞危害已从理论转为现实
开发者披露了两起经核实的攻击事件,证明漏洞已被成功实施:
10 月 11 日,用户 dannydeezy 报告其钱包历史中出现与原支付不符的交易条目;10 月 18 日,用户 Raju-K12 在调整手续费后遭遇资金流失,并向团队反馈。
调查显示,两个欺诈地址均以相似末四位字符伪装目标接收方,第二起案件中,攻击者故意设置零手续费,旨在诱导用户主动发起费用提升操作。
首例涉及一个 2-of-3 多重签名钱包(使用两个 Trezor 设备)。原始交易含 31 个输入、1 个输出,所有签名对原交易有效,但对替换交易无效。假交易将大部分资产转移至仿冒地址,仅返还少量余额。原始交易虽合法,但始终未进入公共网络。
Electrum 官方承认存在活跃的恶意服务器部署此类攻击,但未公布具体数量、被盗总额或是否发现更多受害者。
4.8.3 版本新增签名校验机制阻断攻击链
修复方案已于 10 月 23 日合并至代码库,二进制文件于次日上线。通过 commit 90fe308,新版本引入对用户拥有输入权的未确认交易进行签名验证的功能。
现在,钱包在将交易纳入本地历史前,会强制检查其签名有效性,从而阻止伪造交易被错误显示为合法。本次更新不改变 Electrum 的轻客户端属性,传入的未确认交易仍不受签名检查覆盖,已确认交易继续沿用原有验证流程。
所有运行旧版本的用户被强烈建议从官方渠道下载并升级至 4.8.3。对于无法立即更新者,开发者提醒应仔细核对交易的完整收款地址与金额。若仅连接可信服务器(如自建节点),则可规避此类中间人攻击。
历史教训凸显轻钱包服务器依赖风险
此次事件延续了 Electrum 长期面临的安全挑战——对外部服务器的高度依赖。2018 年 12 月曾有报道指出,恶意服务器诱导用户下载虚假更新,造成近百万美元损失;2019 年亦发生过通过伪造更新与拒绝服务手段引导用户安装受损客户端的攻击。
这些早期攻击依赖欺骗性下载行为,而本次漏洞则发生在用户看似正常操作的过程中,实现对交易内容的隐蔽篡改。2020 年的一次访谈曾讨论轻钱包在性能与安全性之间的权衡,强调其对主服务器的信任机制带来的潜在威胁。
Electrum 官方文档指出,客户端通常连接约 10 个服务器,优先选择一个主服务器获取钱包历史与交易广播。然而,对主服务器在未确认交易上的无条件信任,构成了当前攻击的核心前提。
声明:本站所有文章内容,均为采集网络资源,不代表本站观点及立场,不构成任何投资建议!如若内容侵犯了原著者的合法权益,可联系本站删除。
