威胁情报动态：CISA KEV 收录 PAN-OS CVE-2025-0108，管理面暴露设备应立即排查

背景

2025 年 2 月，Palo Alto Networks 发布 PAN-SA-2025-0002，披露 PAN-OS 管理 Web 接口身份验证绕过漏洞 CVE-2025-0108。随后 CISA 将其加入已知遭利用漏洞目录（KEV），说明该漏洞已经出现真实攻击活动，而不是停留在概念验证阶段。

该漏洞位于管理面 Web 请求处理链路中，攻击者可能通过路径解析差异绕过身份验证，访问原本需要登录的 PHP 组件。CVE-2025-0108 本身不应直接等同于远程命令执行，但如果设备同时存在未修复的管理面权限提升或命令执行漏洞，例如 CVE-2024-9474，实际风险会明显放大。

本文仅讨论资产确认、非破坏性验证、日志排查和修复。生产设备不建议直接发送公开利用载荷，也不要只依赖漏洞扫描器返回结果判断是否失陷。

受影响范围与修复版本

根据厂商公告，以下分支需要升级到对应修复版本或更高版本：

• PAN-OS 11.2：升级至 11.2.4-h4 或更高版本。
• PAN-OS 11.1：升级至 11.1.6-h1 或更高版本。
• PAN-OS 10.2：升级至 10.2.13-h3 或更高版本。
• PAN-OS 10.1：升级至 10.1.14-h9 或更高版本。
• 已经结束支持且没有修复版本的分支，应迁移到受支持版本，不能继续依赖临时访问控制长期运行。

实际升级前仍应核对 PAN-SA-2025-0002 的最新修订内容、设备型号兼容性、HA 升级顺序及推荐版本。云托管产品是否受影响也应以租户类型和厂商公告为准，不宜只按照 PAN-OS 版本号推断。

问题定位：先确认管理面是否对外暴露

这类事件的首要工作不是复现绕过，而是确认哪些设备将管理接口暴露给了互联网或非可信办公网。需要同时检查独立管理口、数据口上的 Interface Management Profile、NAT 映射、上游负载均衡和临时运维策略。

在已获授权的资产范围内，可进行低频、非侵入式探测：

nmap -Pn -sT -p 443,4443 --script ssl-cert,http-title -iL authorized_hosts.txt

curl -skI --connect-timeout 5 --max-time 10 

重点记录证书主题、响应标题、开放端口及最终解析地址。不要把“没有识别出 PAN-OS 标题”当成安全结论，反向代理、自定义证书和登录页定制都可能影响指纹结果。

如果能够通过控制台或可信管理网络登录设备，可直接确认运行版本：

show system info
show admins all
show jobs all

其中应重点核对 sw-version、最近管理员会话以及异常升级、导入或提交任务。扫描侧版本识别只能作为辅助，最终应以设备本地信息和资产平台记录为准。

技术分析：为什么普通流量日志可能查不到

CVE-2025-0108 针对的是 PAN-OS 管理 Web 接口。若攻击流量直接进入专用 Management Interface，请求通常不会像经过安全策略的数据面流量一样完整出现在普通 Traffic Log 中。因此，仅在流量日志里搜索源 IP，容易得到错误的“没有攻击”结论。

排查时至少需要关联以下数据：

• PAN-OS System Log、Configuration Log 和管理员认证记录。
• 管理接口上游交换机、防火墙、VPN 网关或反向代理日志。
• 设备 Tech Support File 中的管理 Web 服务、认证和进程日志。
• 集中身份平台的登录记录，包括管理员账号来源地址和登录时间。
• 配置备份差异、本地管理员变化、API Key 使用及证书变更记录。

管理面路径混淆类攻击通常会出现编码路径、重复分隔符、目录跳转片段，或请求资源后缀与实际 PHP 路由不一致的情况。检测规则应保留原始 URI，不能只分析代理归一化后的路径。

日志排查步骤

第一步是在设备上导出近期系统日志和配置日志，时间窗口至少覆盖漏洞公开前后及当前最长日志保留周期：

show log system direction equal backward
show log config direction equal backward
request tech-support dump

Tech Support File 可能包含配置、主机名、地址和故障信息，应按敏感数据管理，不要上传到公共分析平台。若怀疑设备已被控制，应先完成证据保全，再执行重启或恢复操作。

第二步是在上游代理、WAF 或采集到的管理面访问日志中搜索异常路径。下面的命令只用于离线日志分析，不会向目标发送请求：

grep -RniE '(%2e|%252e|/\.\.?/|//+|/php/[^ ?]+\.(css|js)(/|[? ]))' ./management_logs/

grep -RniE '(POST|PUT).*(/php/|/api/|/unauth/)' ./management_logs/

这些表达式属于启发式检测，会产生误报。命中后应检查原始请求方法、完整 URI、状态码、响应大小、User-Agent、来源地址和同一会话的后续行为，不能直接将单条命中定性为入侵。

如果日志已进入 Splunk，可先从管理域名和异常路径特征收敛范围：

index=proxy earliest=-30d
| eval request_uri=coalesce(uri, url, cs_uri_stem)
| where dest_host="fw-mgmt.example.com"
| where match(lower(request_uri), "%2e|%252e|/\\.\\.?/|//+|/php/.*\\.(css|js)(/|$)")
| stats count values(status) values(user_agent) min(_time) max(_time) by src_ip request_uri
| sort - count

第三步是检查绕过后的行为，而不是只搜索入口请求。优先关注以下异常：

• 未知来源地址访问管理面后，短时间内出现管理员登录、配置提交或 API 调用。
• 新增本地管理员、管理员角色变化、认证配置变化。
• 新建或修改 GlobalProtect、证书、SAML、LDAP、RADIUS、SNMP、日志转发配置。
• 导出配置、生成 API Key、安装软件或内容包等高价值操作。
• HA 主备设备配置不一致，或非变更窗口出现提交任务。
• 管理面进程异常重启、崩溃或出现与运维活动不匹配的外联。

授权验证建议

对于渗透测试或漏洞验证项目，建议把验证标准分为三个层级：

• 版本验证：通过设备本地命令、配置平台或厂商支持信息确认是否处于受影响版本。
• 暴露验证：确认管理接口是否可从互联网、访客网、普通办公网或低权限内网访问。
• 控制验证：确认是否存在可信源地址限制、独立管理网络、堡垒机和多因素认证。

没有必要在生产环境复现身份验证绕过。只要同时满足“受影响版本”和“非可信网络可达”，就应按高风险问题处理。若业务必须验证补丁效果，可在隔离实验环境使用相同版本和配置完成，生产侧只做修复前后的版本、连通性和访问控制检查。

修复与缓解措施

补丁升级是根本措施，访问控制只能降低暴露面，不能替代修复。建议按以下顺序处置：

• 立即从公网撤下管理接口，删除不必要的 NAT、端口映射和临时运维策略。
• 通过独立管理网、VPN 或堡垒机访问，并将允许源地址限制为明确的运维网段。
• 升级到厂商修复版本，HA 环境按官方流程分节点升级并确认会话、配置同步状态。
• 升级完成后重新执行资产探测，确认公网侧端口已经关闭，而不是仅确认版本变化。
• 轮换管理员密码、API Key 和相关自动化凭据；如果存在可疑会话，应同时检查集中身份源。
• 审计本地管理员、认证配置、证书、GlobalProtect 和日志转发配置，和可信基线进行差异比较。

在具备控制台回退条件时，可以通过 PAN-OS 配置限制管理接口来源网段。执行前必须确认当前运维地址包含在允许范围内，避免远程锁死：

configure
set deviceconfig system permitted-ip 10.20.30.0/24
set deviceconfig system permitted-ip 10.20.40.10/32
commit

如果管理服务开放在数据口，还需要检查对应 Interface Management Profile 的 Permitted IP Addresses。只修改独立管理口配置，并不能自动约束数据口上的 HTTPS 管理服务。

失陷判断与应急处置

发现异常路径请求并不一定代表攻击成功，但出现未知配置提交、管理员变更、API Key 创建或异常外联时，应按疑似失陷处理。建议先隔离管理面访问，保留 Tech Support File、集中日志和配置快照，再开展凭据轮换与恢复。

仅升级固件不能清除攻击者已经创建的账号、密钥或持久化配置。若无法解释关键配置变化，或者管理面日志已经被覆盖，应考虑从可信配置备份重建，并检查与该设备共享凭据的堡垒机、自动化平台和身份系统。

总结

CVE-2025-0108 的现实风险来自“管理面暴露、身份验证绕过、旧漏洞或弱配置叠加”这一链路。排查时不能只看普通 Traffic Log，也不应把补丁安装等同于完成事件处置。比较可靠的闭环是：确认版本与暴露面、保全管理面日志、检查配置和身份变更、完成升级与网络隔离，最后通过外部视角复测管理接口是否仍可达。

这类漏洞不能只按“管理口是否配置公网 IP”判断。需要同时检查数据口是否绑定了允许 HTTPS/HTTP/SSH 的 Interface Management Profile，很多实际暴露来自这里。

建议先做三件事：

1. 确认版本与修复状态。受影响分支至少应升级到厂商公告中的修复版本：
   • 10.1.14-h9 或更高
   • 10.2.13-h3 或更高
   • 11.1.6-h1 或更高
   • 11.2.4-h4 或更高
   11.0 已停止维护的环境不要继续停留，直接规划迁移到受支持分支。升级前仍应以 Palo Alto 最新公告为准，避免遗漏后续 hotfix。
2. 核对实际暴露面。导出 running config，重点搜索管理服务和来源限制：

   show config running | match "permitted-ip"
   show config running | match "interface-management-profile"
   show config running | match "https"
   show config running | match "http"

   管理接口应配置 permitted IP；数据接口上的管理 Profile 原则上只允许专用运维网访问，公网接口不要启用 HTTPS/HTTP 管理。
3. 升级前保全日志，升级后继续做失陷排查。修补只能阻止后续利用，不能证明此前未被利用。建议先生成并留存 tech support file，同时保存配置快照、管理员列表、配置审计和系统日志。

CVE-2025-0108 的利用点涉及 Web 请求路径解析差异，排查代理、WAF 或管理面访问日志时，可重点找“PHP 路径后继续拼接静态文件后缀”的异常请求，例如：

grep -Eai '/php/[^? ]+\.php/[^? ]+\.(css|js|png|jpg|map)(\?| |$)' management-access.log
grep -Eai 'ztp_gate\.php|X-PAN-AUTHCHECK' management-access.log

设备侧可先查看管理平面 Web 日志，再结合对应时间检查配置变化：

less mp-log webserver.log
show admins all
show jobs all
show config audit

如果发现异常路径请求、未知管理员、非变更窗口内的 commit、管理服务配置被放宽，建议不要只做改密。应立即从网络侧隔离管理面，撤销现有管理员会话和凭据，检查外部认证账户及 API key，并按潜在设备失陷处理；证据不足或日志已轮转时，重建到可信版本通常比继续在线观察更稳妥。