Apache Tomcat RewriteValve 路径遍历漏洞（CVE-2025-55752）分析与防御

更危险的是，攻击者可通过多层编码绕过（如 %252e%252e/ 对应 ../，%c0%ae%c0%ae/ 是 ../ 的 UTF-8 变形编码），突破部分 WAF（Web 应用防火墙）的基础规则拦截，实现精准攻击。

四、漏洞危害：从信息泄露到供应链攻击的连锁风险

该漏洞的危害并非局限于单一的文件读取，而是会引发链式攻击效应，具体可分为四个层级：

1. 核心配置与凭证泄露：攻击者可读取 Tomcat 的核心配置文件（如 conf/server.xml、conf/tomcat-users.xml），获取 Tomcat 管理后台的账号密码；读取 Java Web 应用的配置文件（如 WEB-INF/web.xml、application.yml），获取数据库连接字符串、Redis 密码、API 密钥等敏感凭证。
2. 系统级信息泄露与权限探测：若 Tomcat 运行用户权限过高（如 root、Administrator），攻击者可读取系统敏感文件，如 Linux 的 /etc/passwd、/etc/shadow（需对应权限），Windows 的 C:\Windows\System32\drivers\etc\hosts、C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools，从而掌握服务器的用户列表、权限配置、网络拓扑等核心信息，为后续的权限提升攻击铺路。
3. 业务数据泄露与合规风险：若企业将核心业务数据（如用户订单、个人信息）存储在 Tomcat 部署目录外的文件系统中，攻击者可通过该漏洞直接读取数据文件，导致数据泄露事件。此类事件不仅会造成企业经济损失，还会违反《网络安全法》《数据安全法》《GDPR》等合规要求，面临高额罚款。
4. 供应链攻击的跳板：对于内嵌 Tomcat 的应用，若该应用被作为第三方组件集成到其他系统中，攻击者可通过漏洞读取该应用的源码与配置，进而发现上下游系统的安全缺陷，发起供应链攻击，其影响范围可快速扩散至多个企业。

五、漏洞验证：手动测试与自动化扫描方案

漏洞验证需严格遵循授权测试原则，仅可在自有资产或获得明确授权的目标上进行，具体方法分为手动测试与自动化扫描两类：

（一）手动测试步骤

1. 确认 RewriteValve 是否启用
   登录目标服务器，检查 Tomcat 的配置文件：
   • 全局配置：查看 conf/server.xml 或 conf/context.xml 中是否存在 <Valve className="org.apache.catalina.valves.rewrite.RewriteValve" /> 配置；
   • 应用级配置：查看应用目录下的 META-INF/context.xml 文件，确认是否存在上述配置。
     若存在，则目标存在漏洞触发的前置条件。

构造恶意请求进行验证
使用 Burp Suite、curl 等工具发送测试请求，示例如下：

# 测试读取 Linux 系统文件
curl -v "http://target:8080/任意已配置的重写路径/../../etc/passwd"

# 测试读取 Tomcat 配置文件
curl -v "http://target:8080/任意已配置的重写路径/../../conf/tomcat-users.xml"

# 测试编码绕过（针对存在基础 WAF 的目标）
curl -v "http://target:8080/任意已配置的重写路径/%2e%2e/%2e%2e/etc/passwd"

若返回文件内容（如 root:x:0:0:root:/root:/bin/bash），则说明漏洞存在。

（二）自动化扫描方案

1. 开源工具扫描：使用 Nmap 的 http-tomcat-rewrite-path-traversal 脚本、OpenVAS 的 CVE-2025-55752 专属插件，可批量检测目标是否存在漏洞；
2. 自研扫描规则：在企业内部的漏洞扫描平台中，可添加以下检测规则——
   • 规则 1：检测目标是否启用 RewriteValve（通过扫描 /manager/html 页面的响应头，或发送特定请求触发 RewriteValve 的错误日志）；
   • 规则 2：构造包含多层路径遍历字符的请求，校验响应内容是否包含敏感文件的特征字符串（如 root:x:0:0、<user username=）。

六、修复方案：从紧急缓解到长期防御的全维度策略

针对该漏洞的修复，需遵循**'先应急、后根治、再加固'**的原则，分阶段实施：

（一）紧急缓解措施（无法立即升级时）

适用于业务无法中断、无法立即升级 Tomcat 版本的场景，可快速降低漏洞风险：

1. 临时禁用 RewriteValve：若业务不依赖 URL 重写功能，直接删除 server.xml/context.xml 中的 <Valve className="org.apache.catalina.valves.rewrite.RewriteValve" /> 配置，重启 Tomcat 实例；若业务依赖该功能，可临时注释该配置，待业务低峰期进行升级。
2. 限制 Tomcat 运行用户权限：立即将 Tomcat 的运行用户从 root/Administrator 切换为低权限用户（如 tomcat 用户），并修改服务器文件权限，禁止低权限用户读取 /etc/shadow、C:\Windows\System32 等敏感目录的文件。
3. 部署 WAF 精准拦截规则：在 WAF 中添加针对该漏洞的专属规则，拦截包含多层路径遍历字符、编码变体的请求，同时开启'URI 规范化'功能，对所有请求 URI 进行预处理后再转发至后端 Tomcat。

添加重写规则的防御逻辑：在 rewrite.config 文件中添加路径遍历字符的拦截规则，拒绝所有包含 .、.. 的请求：

# 拦截包含../的请求
RewriteCond %{REQUEST_URI} ^(.*)/\.\./(.*)$ [NC,OR]
# 拦截包含./的请求
RewriteCond %{REQUEST_URI} ^(.*)/\./(.*)$ [NC]
# 返回 403 禁止访问
RewriteRule ^ - [F,L]

（二）根治方案：官方补丁升级

这是解决漏洞的最根本方法，需根据 Tomcat 的部署类型选择对应的升级路径：

1. 独立部署的 Tomcat 实例：直接下载 Apache Tomcat 官方发布的修复版本，覆盖安装或全新部署，具体版本对应如下：
   • Tomcat 8.5.x：升级至 8.5.116 及以上
   • Tomcat 9.0.x：升级至 9.0.96 及以上
   • Tomcat 10.1.x：升级至 10.1.20 及以上
   • Tomcat 11.0.x：升级至 11.0.0-M18 及以上
     升级后需验证 RewriteValve 的功能是否正常，避免因版本兼容问题导致业务异常。
2. 嵌入式 Tomcat 应用：
   • Spring Boot 应用：在 pom.xml（Maven）或 build.gradle（Gradle）中升级 spring-boot-starter-tomcat 的依赖版本至最新；
   • 自研嵌入式 Tomcat 应用：升级 tomcat-embed-core、tomcat-embed-valves 等核心依赖的版本，确保与官方修复版本一致。

（三）长期防御策略：构建中间件安全的左移防御体系

该漏洞再次暴露了企业在中间件安全管理中的短板——重功能、轻安全，重应急、轻预防。要从根本上降低类似漏洞的风险，需构建左移防御体系：

1. 版本管理与补丁自动化：建立中间件版本台账，定期同步官方安全公告，通过自动化工具（如 Ansible、Jenkins）实现补丁的批量检测与升级，避免因人工疏漏导致漏洞长期存在。
2. 配置安全基线检查：制定 Tomcat 的安全配置基线，包括禁用不必要的 Valve 组件、限制运行用户权限、开启访问日志、配置目录访问白名单等，并通过自动化工具（如 OpenSCAP）定期检查配置合规性。
3. 开发阶段的依赖安全检测：在 Java 应用的开发流程中，集成依赖扫描工具（如 OWASP Dependency-Check、Snyk），实时检测内嵌 Tomcat 等第三方组件的漏洞，将安全问题从运维阶段提前至开发阶段解决。
4. 零信任架构下的中间件防护：在零信任模型中，将 Tomcat 实例视为不可信的资源，通过微隔离技术限制 Tomcat 与其他系统的通信范围；同时部署运行时应用自我保护（RASP）工具，实时拦截内存中的路径遍历攻击行为，实现'应用自防御'。

七、前瞻性展望：中间件安全的未来挑战与应对方向

随着云原生、微服务架构的普及，中间件的形态正从'独立部署'向'嵌入式、分布式'转变，这也给中间件安全带来了新的挑战：

1. 漏洞的隐蔽性越来越高：嵌入式中间件的漏洞难以通过传统的端口扫描发现，需要结合代码审计、依赖扫描等技术手段；
2. 攻击的连锁效应越来越强：微服务架构中，一个中间件漏洞可能导致整个服务链的瘫痪，供应链攻击的风险持续升高；
3. 防御的复杂度越来越高：企业需要同时兼顾中间件的功能稳定性、性能与安全性，传统的'一刀切'防御策略已不再适用。

针对这些挑战，未来的中间件安全防御需向三个方向演进：

• 智能化漏洞检测：利用 AI 技术分析中间件的运行日志与流量特征，实现漏洞的主动发现与预警；
• 轻量化安全防护：将安全功能内嵌到中间件本身，如 Tomcat 官方可在核心组件中内置路径规范化、权限校验等安全逻辑，降低用户的配置成本；
• 标准化安全合规：建立云原生中间件的安全合规标准，明确厂商与用户的安全责任边界，推动整个行业的安全水平提升。

注：本文所述的漏洞验证方法仅用于授权安全测试，未经授权的攻击行为均属于违法行为，需承担相应的法律责任。企业若发现自身系统存在该漏洞，应立即启动应急响应流程，排查攻击痕迹，并及时向相关监管部门报备。