思科在 10 月 28 日的安全公告中确认，ASA 与 FTD 防火墙的远程访问 SSL VPN 服务存在一个可被未认证攻击者利用的逻辑缺陷：向 SSL VPN 服务发送一个特制请求，就能让整台设备意外重载。思科产品安全事件响应团队（PSIRT）已确认该漏洞正在被在野利用，美国 CISA 也在 10 月 29 日将其列入已知被利用漏洞目录（KEV），联邦机构的修复期限是 11 月 1 日。对把 ASA/FTD 当作远程办公 VPN 网关的企业来说，这是未来几天内需要优先处理的网络设备安全问题。
事件概述：一个能让防火墙反复重启的零日
本次漏洞编号为 CVE-2026-76418，思科自评 CVSS 3.1 基准分 8.6（截至 10 月 30 日 NVD 尚未发布自己的评分，以厂商公告为准）。问题出在 ASA 软件与 FTD 软件的远程访问 SSL VPN 服务处理隧道组二次认证的逻辑上。未认证的远程攻击者向可达的 SSL VPN 服务发送特制请求，即可触发漏洞，导致设备意外重载——也就是防火墙直接重启，形成拒绝服务（DoS）效果。
有两个细节值得注意。第一，利用不需要成功的 VPN 登录：漏洞代码路径在认证流程完成之前就可以被触发，攻击者甚至不需要合法账号。第二，这个漏洞是思科 TAC 在一起支持案例的调查中内部发现的，并非外部研究者报告，随后 PSIRT 确认攻击者已经在实际利用它。
漏洞原理：问题出在 SSL VPN 的二次认证
远程访问 SSL VPN 是 ASA/FTD 上承载员工远程办公的核心功能。为了加强认证强度，很多企业会在主认证之外再叠加一层二次认证（secondary authentication），并把它配置到具体的隧道组（tunnel group）上——包括默认的 DefaultWEBVPNGroup。
CVE-2026-76418 正是这条二次认证处理逻辑里的缺陷。思科公告的描述是：只要设备运行受影响版本、SSL VPN 服务在网络可达、并且至少有一个隧道组（含默认隧道组）启用了 secondary-authentication-server-group，这三个条件同时满足，设备就可能被一个特制请求打到底层重载。攻击载荷本身并不复杂，未认证、远程、可反复发送，这意味着攻击者可以低成本地让目标防火墙不断重启。
影响范围与暴露面：哪些设备会中招
受影响的产品范围相当广，涵盖了 ASA 与 FTD 当前几乎所有主力版本线：
- Cisco Secure Firewall ASA 软件：9.16 及更早版本、9.18、9.20、9.22、9.23、9.24 版本线；
- Cisco Secure Firewall FTD 软件：7.0 及更早版本、7.2、7.4、7.6、7.7、10.0、10.1 版本线。
但请注意，并不是所有运行这些版本的设备都一定暴露——真正的判定条件是上面说的三个要素同时成立。没有开启 SSL VPN、或者所有隧道组都没有配置二次认证的设备，不在受影响的判定范围内。这也是为什么 Cisco 的建议是先做配置核查，再谈升级。
暴露面方面，Shadowserver 基金会的扫描数据显示，公网上有超过 51,000 台 Cisco ASA SSL VPN 设备暴露。这 5 万多台设备里有多少同时启用了二次认证，思科没有披露，攻击者是谁、攻击规模多大，截至发稿也都没有公开信息。可以确定的只有一点：这类边界设备一直是各种攻击团伙的重点关注对象。
为什么普通用户和企业都要关心
对运维和安全团队来说，这个漏洞的危险不在于"数据被偷走"，而在于"业务被直接打断"：
- 远程办公直接瘫痪。ASA/FTD 承载着企业员工的 SSL VPN 接入，设备一旦重载，所有远程员工会同时掉线，正在进行的远程会话、传输中的文件全部中断，而且需要人工介入恢复。
- 攻击门槛极低。未认证、单条请求、可重复发送。不需要漏洞利用链的精心构造，也不需要账号，脚本化的扫描加攻击成本非常低。
- 防线上还有前科。这已经是约 11 周内，同一 SSL VPN 服务第二次出现被在野利用的拒绝服务类零日。此前的 CVE-2026-20349（思科同样评分 8.6）在 8 月 11 日进入 KEV 目录，思科称其从 8 月起就被利用。同一个服务在三个月内两次出事，说明它正在被持续、系统地盯上。
- 连锁影响。对把防火墙同时用作唯一出口的网络，设备反复重启意味着内外网通信、站点到站点 VPN、依赖它的下游业务都会受到牵连，恢复期间的日志断层也会给事后溯源添麻烦。
在野利用与 KEV：为什么必须抢时间窗
CISA 在 10 月 29 日把 CVE-2026-76418 加入 KEV 目录，联邦文职机构必须在 11 月 1 日前完成修复。KEV 条目的含义很直接：CISA 掌握的证据表明该漏洞正在被真实攻击者使用。这个条目还带有取证分类（forensic triage）标记——也就是说，即便补上了，也建议对受影响设备做一次失陷排查，而不是简单认为"打完补丁就没事了"。
结合思科公告中"10 月开始意识到被利用"的表述，以及上一个同类漏洞 8 月起被利用的时间线，安全团队在排查日志时，建议把回溯起点放到 10 月初，重点核对设备在这段时间内是否有无法解释的重载记录。
排查思路：四步确认自己是否暴露
对使用 ASA/FTD 的团队，建议按下面的顺序做一轮自查（操作前请先确认变更窗口，改配置前备份现有配置）：
- 查版本。用思科 Software Checker 或登录设备查看当前系统版本，对照公告中的受影响版本列表，确认自己是否运行受影响版本线上的版本。
- 查配置。逐个检查隧道组配置（包括默认的 DefaultWEBVPNGroup），确认是否存在 secondary-authentication-server-group 的配置。思科特别提醒：简单地禁用隧道组列表并不足以消除风险，因为默认隧道组可能仍然启用着二次认证，必须逐一确认。
- 查暴露面。从外网侧确认 SSL VPN 服务（通常是 TCP/443 的 Web 登录界面）是否对外可达，评估实际暴露范围。
- 查日志。检索 10 月初以来设备日志中的意外重载记录（思科 ASA 的 %ASA-1-104001 类日志），把重载时间点与 SSL VPN 入站流量记录做关联，寻找可疑来源 IP。如果 SIEM 已收集防火墙日志，可以直接做异常重载告警。
修复与缓解建议：升级为主，临时关闭二次认证需谨慎
最根本的修复是升级到思科公告中的固定版本。以公告发布时点为准，主要修复版本包括：
- ASA：9.16.4.104、9.18.4.96、9.20.4.50、9.22.3.200、9.23.1.48、9.24.1.27、9.24.10.1；
- FTD：7.0.11、7.2.13、7.4.9、7.6.7、7.7.14、10.0.3、10.1.1。
升级防火墙属于生产网络的高风险变更，正式操作前请注意：先在测试环境或备用设备上验证目标版本的兼容性（特别是与现有特性配置、AnyConnect/ Secure Client 客户端、认证服务器联动的情况）；完整备份当前配置；把升级安排在业务低峰期并预留回滚窗口；升级后验证 VPN 拨测与二次认证流程是否正常。
如果短时间内无法升级，思科给出的临时缓解方式是在受影响的隧道组上关闭二次认证。需要强调的是：这会直接削弱远程访问 VPN 的认证强度，等于把双因子认证降回单因子，思科也明确提示这会降低远程访问 VPN 的安全水位，且每个客户必须在自己环境里验证影响后再执行。对于强依赖二次认证满足合规要求的组织，建议把"关闭二次认证"作为有时间上限的应急手段，同时叠加其他补偿措施——例如临时限制 SSL VPN 管理界面的来源 IP、加强 AAA 服务器的异常登录监控、对 VPN 账户的异常地理位置登录告警——并尽快排上升级窗口。
无论是否已经升级，都建议按 KEV 的取证要求做一轮失陷排查：核对设备配置是否有未授权变更、检查本地账户与 ACS/ISE 侧的异常认证记录、把升级前的日志与配置归档留存。具体操作口径请以思科官方公告与 CISA 的 KEV 说明为准。
后续观察
接下来一段时间值得留意的点：思科是否会披露更多攻击归因或规模信息；NVD 何时给出独立的 CVSS 评分；11 周内两次同类事件之后，SSL VPN 服务是否还会有后续漏洞披露；以及各行业是否有公开的受影响案例。对运维团队而言，更现实的动作是把"边界 VPN 设备的版本基线 + 配置基线 + 异常重载监控"纳入常态化巡检——毕竟这类设备的共同特点是：不出事时没人看，一出事就是全公司远程办公中断。
（本文基于思科安全公告、CISA KEV 目录及公开安全媒体报道整理，具体影响版本、修复版本与操作口径请以官方公告为准。）
暂无评论内容