Tomcat任意文件上传漏洞CVE-2017-12615：原理、复现与防御

1. 项目概述

最近在整理一些经典的Web漏洞案例，CVE-2017-12615这个Tomcat任意文件上传漏洞总是绕不开。它虽然是个老洞，但原理和利用方式非常典型，对于理解中间件安全、文件上传绕过以及Windows系统特性都很有帮助。很多朋友在复现这个漏洞时，常常卡在一些细节上，比如环境搭建不对、PUT请求没生效，或者上传了JSP文件却执行不了。今天我就结合自己多次复现的经验，把这个漏洞从头到尾拆解一遍，不仅告诉你“怎么做”，更重点讲清楚“为什么这么做”，以及实际操作中会遇到哪些坑，怎么解决。无论你是刚入门安全的新手，还是想巩固基础的老手，这篇内容都能让你对这个漏洞有更透彻的理解。

2. 漏洞原理深度剖析

2.1 漏洞根源：PUT方法与Windows文件系统特性的碰撞

CVE-2017-12615的核心问题，出在Apache Tomcat对HTTP PUT请求的处理逻辑与Windows操作系统文件系统特性的一个危险结合点上。要理解它，我们得先拆开来看。

首先，HTTP PUT方法本身是用于向指定URI上传资源的。在Tomcat的默认配置中， conf/web.xml 文件里对 DefaultServlet 的配置有一个关键参数： readonly 。它的默认值是 true 。当 readonly 为 true 时，Tomcat会拒绝处理PUT和DELETE请求，这是一种安全限制。然而，如果开发人员或管理员为了某些特定的RESTful API功能，手动将这个值改为 false ，就等于为攻击者打开了一扇门——Tomcat会开始处理PUT请求，允许客户端向服务器上传文件。

但这还不够。如果仅仅是可以上传文件，那最多算个配置不当，还谈不上高危漏洞。真正的“助攻”来自Windows文件系统。在Windows环境下，文件路径的解析有一些特殊的“特性”或者说“兼容性处理”。其中最关键的两个是：

1. 末尾空格/点号自动去除 ：Windows API在处理文件路径时，会自动去除文件名末尾的空格（ ）和点号（ . ）。例如，你请求创建 shell.jsp （末尾有个空格），系统实际创建的文件名会是 shell.jsp 。
2. NTFS流文件（Alternate Data Streams, ADS） ：NTFS文件系统支持一种叫“数据流”的特性，格式为 文件名:流名 。其中 ::$DATA 是一个特殊的流名，代表文件的主数据流。当系统遇到 shell.jsp::$DATA 这样的路径时，它会将其解析为创建名为 shell.jsp 的普通文件。

Tomcat在7.0.0到7.0.79版本（Windows环境）中，对PUT请求上传的文件名安全检查逻辑存在缺陷。它没有充分考虑Windows的这些特性，导致安全检查（比如检查文件名是否以 .jsp 或 .jspx 结尾）与实际文件创建操作之间存在差异。攻击者可以利用这个差异，绕过Tomcat对JSP文件上传的拦截。

2.2 安全校验与文件创建的“时间差”

我们来模拟一下攻击者上传 shell.jsp/ （注意末尾斜杠）时，Tomcat内部可能发生的过程：

1. 请求接收与安全检查 ：Tomcat收到PUT /shell.jsp/ 的请求。它的安全校验模块会检查请求的URL路径。由于路径以 / 结尾，在某些实现逻辑中，可能不会将其识别为一个直接的 .jsp 文件请求，或者校验逻辑存在疏漏，认为这是一个目录路径，从而“放行”。
2. 传递给文件系统 ：Tomcat将经过（不完整）校验后的路径 shell.jsp/ 交给底层的Java文件API去创建文件。
3. Windows文件系统介入 ：Java调用Windows系统API创建文件。Windows API看到路径 shell.jsp/ ，它发现末尾是一个斜杠，这不符合文件命名规范。为了兼容性，它可能会尝试“修正”这个路径。一种常见的行为是，系统在创建文件时，如果遇到这种被视为无效字符或目录指示符的情况，可能会将其忽略或进行某种规范化处理，最终在磁盘上创建出名为 shell.jsp 的文件，而末尾的 / 没有被保留为文件名的一部分。
4. 结果 ：安全检查针对的是 shell.jsp/ ，而磁盘上实际创建的是 shell.jsp 。一个WebShell就这样被成功上传到了Web应用的根目录下。

shell.jsp%20 （空格URL编码）和 shell.jsp::$DATA 的绕过原理类似，都是利用了Tomcat校验环节和Windows文件系统实际创建环节对同一字符串解析不一致的“时间差”。这个漏洞之所以影响Windows环境，正是因为这些特殊的文件系统行为在Linux/Unix上不存在或表现不同。

注意 ：很多文章只说了“加斜杠/空格/::$DATA可以绕过”，但没讲清楚根本原因。理解这个“校验vs执行”的差异，是掌握此类文件上传漏洞的关键。以后遇到其他中间件或应用，也要思考它的安全检查点在哪里，文件最终落盘的操作又在哪里，两者之间是否有空隙可钻。

3. 漏洞复现环境搭建详解

3.1 环境选择与工具准备

复现漏洞，首要任务是搭建一个与漏洞匹配的环境。CVE-2017-12615影响的是Tomcat 7.0.0到7.0.79，并且需要运行在Windows上且 readonly 设置为 false 。为了复现方便，我们通常不会去真的找一个Windows服务器安装旧版Tomcat修改配置，而是使用Docker。Vulhub项目提供了现成的、配置好的漏洞环境镜像，极大简化了步骤。

你需要准备以下工具：

1. 一台安装Docker和Docker Compose的Linux主机 （如Kali Linux、Ubuntu或CentOS）。这是我们的实验环境。在Windows上直接运行Docker也可以，但可能涉及网络模式等额外配置，用Linux更纯粹。
2. Burp Suite Community/Professional版 ：用于拦截和修改HTTP请求。这是手动复现的核心工具。
3. 浏览器 ：用于访问目标Tomcat和触发WebShell。
4. 冰蝎（Behinder）或蚁剑（AntSword） ：用于连接上传的JSP WebShell，进行可视化交互。准备其中一个即可，我演示会用冰蝎。
5. 文本编辑器 ：用于编写和查看POC/EXP脚本。

首先，从GitHub上拉取Vulhub的漏洞环境库：

git clone https://github.com/vulhub/vulhub.git
cd vulhub/tomcat/CVE-2017-12615

进入对应目录后，使用 docker-compose 启动环境：

docker-compose up -d

这个命令会从Docker Hub拉取预先构建好的漏洞镜像（一个包含了存在漏洞的Tomcat 7.x的Linux容器，但模拟了Windows环境下 readonly=false 的配置），并在后台运行。

3.2 环境验证与关键配置确认

启动完成后，用 docker ps 查看容器是否正常运行，并记下容器的ID或名称。接着，我们最好验证一下漏洞环境的关键配置是否就绪。

# 查看运行的容器
docker ps
# 假设容器ID是 abc123def，进入容器shell
docker exec -it abc123def /bin/bash
# 进入Tomcat配置目录，查看web.xml
cd /usr/local/tomcat/conf/
cat web.xml | grep -A 5 -B 5 readonl