摘要

  • 未获授权的 162.55.80.0/24 公告把 Hetzner 的 AS24940 留在路径末端，并利用允许 /24 的 ROA 获得 RPKI Valid 结果，随后帮助攻击者取得有效 TLS 证书。
  • Virtualizor 借助 368 个 RIPE RIS 对等观测点复原了路由传播，却表示恶意响应由攻击者服务器提供，未进入厂商日志，因此无法列出全部受影响安装。
  • 缺少的证据对象是一张保护隐私的本地更新收据：把请求版本、签名清单、软件包摘要、接受的密钥、验证判断以及安装或回滚结果绑定在一起。

安全事件复盘常被最大的数字牵着走。本案的数字是 368。Virtualizor 称，在事件期间，RIPE Routing Information Service 样本中的 368 个对等观测点都曾至少一次携带劫持路由。这个结果足以说明路径传播广泛，却不能回答有多少客户、多少更新请求、多少完整下载或多少实际入侵。

这些不是同一个分母。BGP 收集器记录自治系统路径；证书机构记录域名控制验证和证书签发；攻击者的服务器看到被引走的请求；每台 Virtualizor 服务器则在本地决定是否接收、验证和执行软件包。攻击之所以成功，正因为四套记录在关键时刻分开，而不是因为其中某套记录完全不存在。

LACNIC 在 2026 年 9 月 10 日刊出了 Kentik 分析的西班牙语版本。这是本地区域互联网社群值得关注的新闻线索，但不应据此把 LACNIC 写成受害系统的运营方。页面明确说明，文中意见属于作者，并不一定代表 LACNIC。准确的归属是：LACNIC 刊发案例，Kentik 分析路由，Virtualizor 陈述产品影响。

路由记录能证明什么

8 月 28 日约 20:57 UTC，全球路由表出现 162.55.80.0/24，路径尾部为 6204 62390 24940。这个 /24 比 Hetzner 平常宣告的 162.55.0.0/16 更具体。在同时接受两条公告的网络中，最长前缀匹配会把发往该 /24 的流量交给新路径。

关键并不是伪造一个新的起源号，而是把真实的 AS24940 留在 AS path 最右侧。覆盖该地址空间的 ROA 允许 AS24940，并把前缀长度放宽到 /24。于是，起源验证可以把这条未授权路径判为 RPKI Valid。它核对的是前缀、长度和表面起源，并不核对 AS62390 是否真是获准的上游，也不证明中间邻接关系真实。

RFC 9319 专门讨论了这种“伪造起源的子前缀劫持”。当 ROA 授权了持有人平常并未宣告的更具体前缀，攻击者可以把合法起源附在路径尾端，占用那片空白。文档建议在条件允许时采用最小 ROA，只授权实际发布的前缀。这能缩小攻击面，但不能把起源验证变成逐跳路径签名。

因此，“RPKI Valid”必须带着限定语阅读。它表示公告符合一项起源授权，不表示整条路径获得认可，不表示 TLS 终点属于预期运营者，更不表示通过连接取得的软件可信。把这个边界说清楚不是贬低 RPKI，而是保护它的实际价值：它完成了设计中的检查，攻击者利用的是检查之外的权限空隙。

Virtualizor 把事件窗口定在 8 月 28 日约 20:57 UTC 至 8 月 30 日约 06:10 UTC，并描述了两轮活跃期，中间约有 11 小时低谷。复原数据还包含约 10,600 次路由撤回。十分钟一格的观测因此只是连续事件的切片，不是完整录像。厂商也提示，每八小时 RIB 转储对齐的时间点更可靠，剧烈抖动期间的中间快照可能低估可见对等点。

“368 个里有 368 个”同样带有时间条件：每个观测点都曾看见，不等于同一时刻全都看见。活跃波次的峰值约为完整 368 点集合的 72%。而且，这个比例是拓扑代理，不是字节比例。一个大型骨干网的对等点与一个较小参与者在计数中各占一格。只有保留这些限制，数字才有审计价值。

有效证书让错误终点看起来正常

被引走的流量还包括域名控制验证。Virtualizor 表示，攻击者为 Softaculous 产品家族的多个域名取得了技术上有效的 TLS 证书，其中包括软件分发端点。被错误路由的客户端因而可以完成加密连接，而且不收到证书警告。TLS 保护了客户端与路由系统交付的终点之间的会话，却没有恢复厂商原本指定的终点。

多视角签发核验 MPIC 的用途正是提高此类攻击成本。证书机构不再只从一个网络位置判断域名控制，而是要求多个远端视角形成法定数量的同意。现行 CA/Browser Forum 规则自 2026 年 6 月 15 日起，对相关检查至少要求四个远端网络视角，并要求确认结果横跨至少两个 RIR 服务区域。Let’s Encrypt 也早已说明，只要攻击者劫持或重定向验证路径，单点验证就可能被欺骗。

本案出现有效证书，并不证明 MPIC 毫无作用。Kentik 提出的边界更具体：一条没有同等具体合法路径竞争的更具体公告传播得足够广，可以让多个视角同时看到攻击者。多视角靠“意见不一致”识别局部谎言；如果谎言成为多数位置的共同景象，法定数量仍可能一致。严格 ROA、异常路径告警、路径级约束和真正分散的证书验证必须并行存在。

攻击者的响应不会写入厂商日志

Virtualizor 确认恶意更新包送达了少量安装，也使用了“少数服务器”的表述；同时，它不能提供确定名单。原因十分直白：恶意响应由攻击者的系统提供，根本没有到达厂商自己的日志。

服务器日志只记录抵达该服务器的请求。路由劫持成功时，合法服务器没有某条请求记录，既可能意味着客户没有发起请求，也可能意味着别的服务器已经回答。恰恰在攻击者接管流量的时候，中心日志最不完整。反复检查合法源站日志，无法补出它从未参与的交易。

正常更新方式放大了这块盲区。Virtualizor 文档称，若未关闭自动更新，产品默认每 24 小时检查一次；管理员也能从控制面板或命令行触发更新。真正需要回答的是：哪些安装在活跃时段发出检查，哪些请求当时经过劫持路径，哪些下载完成，哪些软件包被接受，哪些安装成功。BGP 表格没有这些字段，源站访问日志也看不到攻击者的回复。

厂商披露了更关键的薄弱环节：当时更新客户端尚未对软件包进行密码学验证，并承诺为所有包建立代码签名机制。这个修复不可省略。拥有高权限的更新器必须校验签名元数据、软件包摘要、版本、渠道和授权密钥，验证失败就停止。传输加密不能独自承担代码来源证明。

但签名与事后归因不是一回事。签名能让未来客户端拒绝没有授权密钥的文件；它不会自动告诉调查者某台机器此前做过什么。即便已经部署签名，运营者仍需要知道客户端请求了哪个版本、收到哪个摘要、接受哪把密钥、验证是否失败、安装是否执行、是否隔离或回滚。

在安装端写下更新收据

每次更新尝试都应在决策发生处留下小型、可检测篡改的收据。字段包括更新渠道与请求版本、请求时间、签名清单摘要、软件包摘要、被接受的密钥或密钥门限、验证结果，以及拒绝、隔离、安装、失败或回滚等本地结果。后续撤销、事故通告和修复版本也应能指向原收据。

这不等于公布客户名单。收据可以由运营者保管，以假名化设备或机群标识记录，只在事故中披露最少证据。厂商可以提供可选的确认服务：接收盲化或假名化凭据，返回带时间戳的确认。大型托管商在内部聚合，小型运营者在提交支持请求时导出单机证据。隐私是数据收集的边界，不是拒绝留证的理由。

收据真正建立的是两项陈述之间的连接。厂商发布记录说明“这份清单、软件包和密钥获得授权”；本地记录说明“这台机器请求了该版本，校验了该摘要，并采取了这一行动”。如果攻击者控制路由和网站，却没有签名密钥，收据会记录拒绝。如果密钥后来被撤销，运营者能定位接受过它的机器。如果验证器本身出错，软件包摘要能圈出实际安装群体。

它还迫使事故报告分开五个阶段。RIS 对等点见到路径，是网络暴露证据；活跃劫持窗口内发起请求，是交付机会；完成下载，是取得文件；安装成功，是执行；发现恶意服务或其他入侵指标，才是影响证据。每一步都有自己的总体和观察方法。把它们统称“受影响”只会掩盖未知量。

现有应对值得肯定，证据设计仍需补齐

批评之前应先承认厂商做对的部分。Virtualizor 公开了恶意包送达，发布入侵指标，要求轮换并限制凭据、审查访问并保全证据，报告证书以便撤销，复原路由事件，并承诺包签名。Kentik 和 LACNIC 则说明严格 ROA 与监测的重要性，没有把起源验证说成完整路径认证。

问题不是厂商没从攻击者日志中得出不可能的确定结论，而是行业此前没有要求更新决策点产生一份可携带记录。当攻击者服务器回答请求，中心日志已经退出交易，独立证据只能来自安装端。在名单未知时要求所有运营者检查是谨慎做法，也正好显示“没有收据”的运营成本：每台机器都必须被当作可能对象。

成熟的下一份复盘应并列三本账。路由账记录哪个视角在何时看见哪条路径；发布账记录厂商授权了哪份清单、软件包和密钥；安装账记录每个客户端如何决定。三者不能互相代替，连接起来却能把面向全部用户的警报缩小成可证明的修复清单。

资料来源