本文选自 Horizon 2026年9月2日技术简报。
摘要
2026 年 8 月 28 日至 30 日，Virtualizor 所依赖的一段更新基础设施地址遭遇 BGP 劫持。攻击者发布更具体的 /24 路由，把部分网络访问引向恶意服务器，并利用同样被劫持的域名验证流程取得有效 TLS 证书。部分恰好在窗口期检查更新的服务器收到恶意软件包；载荷以更新程序的高权限运行，植入 SSH 密钥、Java 程序与持久化服务。这起事件说明，HTTPS 只能证明当前连接与证书匹配，无法独立证明路由正确或更新包真实。软件更新必须建立包级签名、密钥隔离、透明审计与多通道验证。
路由层发生了什么
互联网自治系统通过 BGP 交换可达前缀。路由器通常优先选择更具体的前缀：162.55.80.0/24 会优先于覆盖范围更大的 162.55.0.0/16。事件中，未获授权的网络发布了包含 Softaculous 服务地址的 /24 路由，许多接收该通告的网络便把流量送向攻击者。
这不是修改域名 DNS，也不是侵入 Virtualizor 源代码仓库，而是改变了数据包在互联网中的去向。官方依据 RIPE RIS 等公共路由数据重建时间线，确认劫持分两轮出现，中间曾因合法运营商发布相同精度的修正路由而暂时消退。
BGP 的历史设计依赖网络之间的信任，缺少强制的起源授权验证。RPKI 可以发布 Route Origin Authorization，声明某个自治系统有权起源某段地址；启用 Route Origin Validation 的网络可拒绝“无效”路由。但全球部署并不完整，路由泄露、路径伪造和配置错误仍可能传播。
为什么攻击者能拿到有效 TLS 证书
TLS 证书由公开证书机构签发。自动签发通常要求申请者证明对域名的控制，例如让证书机构访问该域名下的特定 HTTP 路径。BGP 劫持发生后，证书机构发出的验证流量也可能被送到攻击者服务器。攻击者正确回应挑战，就能获得技术上有效的证书。
因此，受影响客户端建立 HTTPS 连接时不会看到证书警告：域名匹配、证书链有效、私钥也由当前服务器掌握。TLS 成功完成了“加密到持证者”的任务，却无法判断持证者是否通过路由劫持暂时控制了验证路径。
多视角域名验证能降低风险。证书机构从不同网络、不同地理位置同时检查挑战，攻击者必须劫持足够广的路由才可能全部通过。CAA 记录可限定允许签发证书的机构，证书透明度日志便于发现异常签发，但二者都不能替代对更新包本身的密码学验证。
从网络劫持到 root 后门
被劫持的地址承载软件更新端点。少量服务器在攻击窗口中执行更新检查，下载到攻击者提供的恶意包。更新程序为了安装系统组件通常具有 root 权限，一旦仅以 HTTPS 连接作为信任依据，恶意包就获得了直接进入最高权限的通道。
公开取证材料显示，载荷可能添加 root SSH 公钥、安装 Java 组件并创建持久化服务。管理员不能只删除一个可疑文件，因为攻击者可能已经使用后门登录、修改其他密钥或访问客户虚拟机。更稳妥的处置包括隔离主机、保存证据、轮换凭据、审计横向移动，并在无法证明系统完整性时从可信介质重建。
官方无法从自身日志列出所有受害者，因为恶意响应来自攻击者服务器，没有抵达合法基础设施。因此，“官方日志没有下载记录”不能证明客户端安全。所有在相应窗口期更新的运营者都需要在本地检查版本、文件哈希、服务、SSH authorized_keys 和网络连接。
更新系统为什么必须双重验证
成熟更新链应同时验证传输通道和软件对象。HTTPS 防止普通链路窃听与篡改；包签名则用离线或严格保护的发布密钥证明制品由项目发布。即使 DNS、BGP、镜像站或 CDN 被控制，客户端也应拒绝签名不正确的包。
签名方案仍需正确设计。长期根密钥应离线保存，在线构建系统只持有受限、可轮换的签名角色；元数据应包含版本号、有效期和目标文件哈希，防止回滚和冻结攻击。TUF 等框架通过根、目标、快照和时间戳角色分权，降低单一密钥失陷造成的影响。Sigstore 则强调短期身份签名与透明日志，适合云原生软件供应链。
更新客户端还可以采用多源校验：从独立网络查询发布元数据，通过 DNSSEC 或固定公钥核对关键记录，发现路由和证书透明度异常时暂停自动更新。高权限平台应设置分阶段发布、金丝雀节点和人工确认窗口，避免所有宿主机同时接收未经观察的新包。
对企业和工业软件的提醒
虚拟化控制面、远程运维软件、容器平台和工业边缘网关都具有高权限，更新链一旦被利用，攻击者可以跨越大量隔离层。很多企业把注意力放在代码漏洞，却默认官网和更新服务器天然可信。本次事件说明，分发基础设施也是供应链的一部分。
企业采购软件时应询问更新包是否独立签名、签名密钥怎样保护、能否离线验证、是否提供 SBOM、是否支持固定版本和回滚。生产环境应由内部仓库先同步并验证外部制品，再经测试与审批推向现场。无法验证签名的脚本式在线安装，不适合直接在大规模 root 环境中运行。
结语
Virtualizor 事件把三层风险串在一起：BGP 决定流量去向，自动证书系统确认临时控制，更新程序再把网络信任提升为 root 权限。任何单层机制都没有“失效”，组合后却形成了完整攻击链。防守方也需要跨层设计：RPKI 与路由监测降低劫持概率，多视角验证与透明日志发现异常，包级签名和分权密钥保证制品真实性，终端检测与分阶段更新控制损失范围。
参考资料
- Virtualizor, Security Incident – BGP Hijacking
- RIPE NCC, Routing Information Service
- RFC 6480, An Infrastructure to Support Secure Internet Routing
- The Update Framework, Specification
- Certificate Transparency, RFC 9162