1. 从一次内部安全审计说起前段时间公司内部做了一次应用安全专项审计我负责检查几个核心的Java后台服务。用工具扫了一圈常见的SQL注入、XSS都没啥大问题但在一个老项目的依赖里工具报出了一个让我心里“咯噔”一下的提示AspectJWeaver反序列化漏洞风险。这个依赖我太熟悉了Spring AOP、事务管理背后或多或少都有它的影子很多项目为了引入切面编程都会间接带上它。问题在于这个看似人畜无害的“编织器”如果配置不当或者被攻击者找到了入口就能成为一条直通内网的“高速公路”。这可不是危言耸听利用AspectJWeaver进行反序列化攻击可以直接在目标服务器上执行任意代码危害等级是致命的。今天我就把这个漏洞从原理到利用再到防御给大家彻底拆解清楚。无论你是负责安全的同学还是日常开发的Java工程师理解这个漏洞都非常有必要。它不像某些冷门的0dayAspectJWeaver在Java生态里太普遍了而且利用链相对稳定是红队手里的一把“好枪”也是蓝队必须堵上的一个“暗门”。我们会从为什么AspectJWeaver会被卷入反序列化风波讲起一步步分析它的利用链是如何“编织”起来的并给出实实在在的修复和排查方案。2. 漏洞核心为什么AspectJWeaver会被反序列化利用要弄明白这个漏洞首先得搞清楚两个看似不相关的东西是怎么被联系在一起的反序列化和AspectJWeaver。2.1 反序列化对象的“复活”与风险在Java里我们经常需要把对象Object转换成字节流byte stream进行存储或网络传输这个过程叫序列化Serialization。反过来把字节流恢复成对象就是反序列化Deserialization。Java通过实现java.io.Serializable接口来支持这个机制。问题就出在“恢复”对象上。Java反序列化机制在重建对象时不仅会恢复对象的数据还会自动调用该对象类中一个特殊的方法readObject。如果开发者在一个可序列化的类里重写了readObject方法那么反序列化时这个方法里的代码就会被执行。想象一下这个场景攻击者精心构造了一段恶意的字节流里面“包裹”着一个特殊的对象。这个对象的readObject方法里写的是下载木马、执行命令的代码。当你的程序不加甄别地反序列化这段来自网络或文件的数据时就相当于亲手把攻击者的代码请进来并执行了。这就是反序列化漏洞最根本的原理——利用目标类库中已有的、可被序列化且readObject方法或相关方法如readResolve、readExternal存在危险操作的类构造出一条调用链Gadget Chain最终达到执行任意代码的目的。2.2 AspectJWeaver不止是编织切面AspectJWeaver是AspectJ项目的一部分主要功能是在编译时或加载时“编织”切面代码到目标类中实现AOP。它包含一个关键的JAR包aspectjweaver.jar。这个包里有很多用于处理类加载、字节码和缓存的工具类。漏洞的起点就在这个JAR包里的一个类org.aspectj.weaver.tools.cache.SimpleCache。这个类实现了Serializable接口意味着它可以被序列化和反序列化。更关键的是它的readObject方法里有一个非常危险的操作private void readObject(java.io.ObjectInputStream in) throws ... { // ... 读取一些字段 this.map (Map) in.readObject(); // 关键点直接读取一个Map对象 // ... }它直接从输入流中读取一个Map对象并赋值给内部的map字段。在Java反序列化中in.readObject()会递归地反序列化这个Map对象以及它内部的所有键值对。如果这个Map的Key或Value是另一个复杂的、其readObject方法有危险操作的对象那么危险就被传递下去了。SimpleCache本身没做坏事但它开了一个“口子”允许攻击者控制一个Map被反序列化。这就像一栋大楼的门卫SimpleCache#readObject只检查了访客序列化流的身份证类型就允许他带了一个大箱子Map进来并且对箱子里装了什么Map里的内容完全不检查。2.3 链路的连接从SimpleCache到命令执行仅有SimpleCache这个入口还不够我们需要找到一条能从“控制一个Map”通到“执行系统命令”的完整路径。这条路径就是所谓的利用链Gadget Chain。在经典的AspectJWeaver反序列化利用链中后续的环节通常依赖于另一个非常著名的通用库Apache Commons Collections特别是3.x版本即commons-collections-3.2.1。这个库提供了大量好用的集合工具类其中一些类如TransformedMap、InvokerTransformer为了灵活性允许传入并调用任意的Transformer接口实现。攻击者可以这样构造链条入口实例化一个SimpleCache对象并准备一个恶意的Map作为其map字段。传递这个恶意Map的Value是一个Apache Commons Collections中的LazyMap或TransformedMap。这类Map的特点是在获取get某个不存在的Key时会通过一个Transformer来动态生成Value。触发攻击者将Transformer设置为InvokerTransformer这个类可以通过反射调用任意类的任意方法。执行在反序列化过程中通过精心构造的链式调用可能涉及AnnotationInvocationHandler、TemplatesImpl等最终让InvokerTransformer反射调用Runtime.getRuntime().exec(“恶意命令”)。简单来说AspectJWeaver的SimpleCache提供了漏洞的“发射井”而Commons Collections等库提供了“火箭”和“弹头”。当存在漏洞的应用反序列化了攻击者构造的SimpleCache数据时整个链条就会被自动触发在服务器上执行命令。注意这里描述的是一条经典且常见的利用链。实际环境中根据目标类路径ClassPath上存在的其他库如Groovy、Spring、Fastjson等攻击者可能会组合出不同的利用链。但AspectJWeaver Commons Collections是其中非常典型和稳定的一种。3. 漏洞利用的实战环境搭建与原理深潜光讲原理有点抽象我们动手搭一个最简单的环境把利用过程走一遍你会理解得更透彻。再次强调以下所有实验请在完全隔离的虚拟机或测试环境中进行严禁对生产或他人系统进行测试3.1 实验环境准备你需要准备JDK 8很多老项目运行在JDK 8上其内置的sun.reflect.annotation.AnnotationInvocationHandler类是早期利用链的关键一环。漏洞依赖JARaspectjweaver-1.9.0.jar存在漏洞的版本例如1.9.0到1.9.5等。commons-collections-3.2.1.jar提供关键利用类。一个简单的靶机程序就是一个会反序列化网络数据的Java应用。靶机程序示例代码import java.io.*; import java.net.*; public class VulnerableServer { public static void main(String[] args) throws Exception { ServerSocket server new ServerSocket(9999); System.out.println([*] Server listening on port 9999...); while (true) { Socket socket server.accept(); try (ObjectInputStream ois new ObjectInputStream(socket.getInputStream())) { // 高危操作直接反序列化来自客户端的数据 Object obj ois.readObject(); System.out.println([*] Received and deserialized an object: obj.getClass()); // 这里通常会有一些业务逻辑处理obj... } catch (Exception e) { e.printStackTrace(); } } } }这个服务器的危险之处一目了然它打开一个端口对接收到的数据直接进行readObject()没有任何白名单校验或安全检查。3.2 构造攻击载荷Payload攻击端需要构造一个恶意的序列化对象。我们使用ysoserial这个著名的Java反序列化利用工具来生成。ysoserial内置了针对AspectJWeaver的利用链名为AspectJWeaver。生成Payload的命令java -jar ysoserial.jar AspectJWeaver “calc.exe” payload.bin在Linux/Mac下命令可换成“touch /tmp/hacked”这条命令的意思是使用AspectJWeaver利用链生成一个执行calc.exe弹出计算器命令的序列化字节流并保存到payload.bin文件。3.3 发起攻击在攻击机器上使用ncNetcat或简单的Socket客户端将payload.bin发送给靶机。nc 靶机IP 9999 payload.bin如果靶机运行在Windows上且环境正确你会看到计算器被弹出。这直观地证明了反序列化漏洞的威力——通过网络发送一段数据就能在远程服务器上启动一个图形化程序。如果是服务器命令如wget下载木马、bash -c反弹shell后果不堪设想。3.4 关键原理步骤拆解让我们深入ysoserial的AspectJWeaver链源码看看这个payload.bin里面到底“编织”了什么外层包裹SimpleCache生成的字节流最外层是一个org.aspectj.weaver.tools.cache.SimpleCache对象。这是利用链的入口也是触发点。恶意Map注入在SimpleCache的readObject方法中会调用in.readObject()来填充其内部的map字段。攻击者在这里注入了一个精心构造的Map。Commons Collections的Transformer链这个Map通常是一个LazyMap或TransformedMap其valueTransformer被设置为一个ChainedTransformer。ChainedTransformer里包含了一系列的Transformer其中最关键的是一个InvokerTransformer它被配置为通过反射调用Runtime.getRuntime().exec()方法。触发转换为了在反序列化时自动触发这个Transformer链利用链会借助其他类如AnnotationInvocationHandler、BadAttributeValueExpException等的readObject或toString、hashCode方法在反序列化过程中去访问get恶意Map的某个Key。链式反应一旦访问发生LazyMap就会调用其Transformer链来生成Value。ChainedTransformer开始工作执行到InvokerTransformer时反射调用发生最终执行我们预设的系统命令。整个过程完全依赖于Java反序列化机制自动调用readObject方法的特性以及各个类库之间方法调用的连锁反应。AspectJWeaver的SimpleCache因其“无脑”反序列化一个Map的特性成为了启动这个连锁反应的第一块多米诺骨牌。实操心得在分析利用链时不要只盯着入口点。像AspectJWeaver这类漏洞真正的杀伤力来自于整个ClassPath环境。如果你的应用同时引入了存在类似“危险特性”的多个库如CC链、CB链、Fastjson链的依赖它们就可能被攻击者“拼接”起来形成利用链。因此安全加固必须是全局性的。4. 影响范围与排查方案知道了漏洞怎么利用接下来最关键的是我的系统受影响吗怎么查4.1 影响范围评估满足以下条件你的应用就存在风险使用了存在漏洞版本的aspectjweaver通常版本号在1.9.0 至 1.9.5之间需要重点排查。Spring Boot项目如果使用了AOP、Async、Transactional等特性很可能会间接引入这个依赖。项目中同时存在可被利用的“链”库最常见的就是Apache Commons Collections 3.x (3.0 - 3.2.1)。其他如commons-beanutils,groovy,spring-aop等也可能在特定组合下成为利用链的一部分。存在不安全的反序列化入口这是漏洞被触发的必要条件。常见的入口包括RMI使用Java RMI进行远程通信并且注册了接收Object类型参数的远程对象。JMX开启了JMX服务端并且暴露了MBean接口处理序列化数据。HTTP参数接收Base64编码或其他格式的序列化数据并直接进行反序列化一些旧的Java框架或自定义协议可能存在此问题。消息队列消费MQ消息时直接对消息体进行ObjectInputStream反序列化。文件/数据库读取存储的序列化对象文件或Blob字段并直接反序列化。FasterXML/jackson-databind在特定配置下也可能触发基于类的反序列化。4.2 系统化排查方案你可以按照以下步骤进行自查第一步依赖扫描使用Maven或Gradle的依赖树命令检查aspectjweaver的版本。# Maven mvn dependency:tree | grep aspectjweaver # Gradle gradle dependencies | grep aspectjweaver对于非Maven/Gradle项目直接检查WEB-INF/lib或类路径下的JAR文件。第二步识别反序列化入口这是排查中最关键也最困难的一环。你需要审查代码全局搜索ObjectInputStream、readObject、readUnshared。搜索Serializable接口的实现类特别是那些重写了readObject、readResolve方法的类。检查网络服务Socket、RMI、HTTP接口、文件读取、数据库Blob字段处理等所有可能接收外部数据的地方看是否直接将数据流传递给了ObjectInputStream。检查框架配置例如Spring HTTP Invoker、Hessian、Burlap等旧的RPC框架它们可能默认使用Java序列化。第三步使用自动化工具辅助静态扫描工具可以使用FindSecBugs、SonarQube等SAST工具它们能识别不安全的反序列化代码模式。动态测试工具在测试环境可以使用ysoserial生成各种利用链的Payload配合Burp Suite等代理工具对应用的各个接口进行模糊测试Fuzzing观察是否有异常响应或命令执行迹象。此操作风险极高务必在授权和隔离环境进行。第四步检查安全防护查看应用中是否已经部署了以下防护措施我们将在下一章详述是否使用了反序列化过滤器ObjectInputFilter是否替换了不安全的序列化框架如换用JSON是否升级了所有已知存在危险利用链的第三方库5. 修复与加固的实战指南排查出问题后修复必须多管齐下。单一措施很难做到绝对安全我们需要构建一个纵深防御体系。5.1 根本性修复升级或移除首选方案升级aspectjweaver到安全版本。AspectJ团队在后续版本中修复了此问题。请升级到1.9.6或更高版本。在新版本中SimpleCache类的readObject方法增加了安全性检查或者修改了实现方式阻断了利用链。检查并升级其他危险依赖。同样将commons-collections等已知存在危险类的库升级到最新版本。例如commons-collections升级到3.2.2或4.x版本注意API可能有变化。commons-beanutils升级到1.9.4及以上。关注其他安全公告及时升级fastjson、jackson-databind、xstream等序列化相关库。注意升级后务必进行全面的功能回归测试。因为高版本库可能有不兼容的API变更。5.2 代码层加固关闭危险入口如果无法立即升级或者希望增加一层防护可以在代码层面进行加固。1. 使用反序列化过滤器JDK ≥ 8u121, JDK ≥ 9这是JDK提供的最有效的内置防护机制。你可以定义一个ObjectInputFilter只允许反序列化来自可信白名单的类。import java.io.*; public class SafeObjectInputStream extends ObjectInputStream { // 定义一个严格的白名单只允许应用核心的、安全的类 private static final ObjectInputFilter FILTER ObjectInputFilter.Config.createFilter( “java.lang.String;java.util.HashMap;com.yourcompany.safe.*;!*” // 允许String, HashMap以及com.yourcompany.safe包下所有类拒绝其他所有类 ); public SafeObjectInputStream(InputStream in) throws IOException { super(in); super.setObjectInputFilter(FILTER); } } // 使用方式 try (SafeObjectInputStream sois new SafeObjectInputStream(socket.getInputStream())) { Object obj sois.readObject(); // ... }配置要点白名单要尽可能精确、最小化。从只允许java.lang.String和java.util.*中的基础不可变类开始再逐步添加业务必须的类。使用!*显式拒绝所有未在白名单中的类。此过滤器在JDK 9及以上功能更完善在JDK 8u121后需通过sun.misc.ObjectInputFilter使用不推荐用于长期方案。2. 替换序列化方案这是最推荐的长期方案。放弃Java原生序列化改用更安全、更高效的序列化协议。JSON使用Jackson或Gson。它们默认只反序列化数据到POJO的属性不会任意执行代码。Protocol Buffers / Thrift跨语言、高性能、强类型的二进制序列化方案安全性远高于Java原生序列化。Kryo (需谨慎配置)虽然性能极高但Kryo本身如果不做安全配置如设置kryo.setRegistrationRequired(true)也存在反序列化风险。3. 校验序列化数据在反序列化前对输入数据进行强校验。完整性校验使用HMAC等签名机制确保数据未被篡改。业务逻辑校验反序列化后的对象必须经过严格的业务逻辑校验如字段范围、关联关系后才能使用。5.3 JVM层与运维层防护1. 使用Security Manager或Java Agent可以编写自定义的SecurityManager策略文件或使用Java Agent在类加载时进行拦截禁止加载或实例化危险的利用类如org.apache.commons.collections.functors.InvokerTransformer。这种方式对代码侵入小但配置复杂对性能有一定影响。2. 使用RASP运行时应用自我保护在生产环境中部署RASP产品。RASP可以注入到应用运行时实时监控ObjectInputStream.readObject()等危险方法的调用栈和参数一旦发现行为符合攻击特征如调用Runtime.exec立即进行阻断并告警。这是目前企业级防护非常有效的手段。3. 网络与主机隔离最小化暴露关闭不必要的RMI、JMX端口。如果必须开启将其绑定到内网或管理网络禁止从公网访问。权限最小化运行Java应用的系统用户应使用低权限账户避免其拥有执行敏感命令或写入关键目录的权限。5.4 修复方案对比与选择修复方案优点缺点适用场景升级依赖版本从根本上修复漏洞一劳永逸可能引入兼容性问题需要测试首选方案所有受影响系统都应尽快安排升级。反序列化过滤器JDK原生支持防护粒度可控白名单维护成本高JDK8早期版本支持有限无法立即升级且使用高版本JDK的过渡方案。替换序列化协议彻底摆脱Java原生序列化风险提升性能改造工作量较大涉及前后端/多服务协调新系统设计或老系统重大重构时。代码入口校验灵活可与业务结合依赖开发人员安全意识容易遗漏作为辅助手段与其他方案结合使用。RASP/安全产品无侵入实时防护可防御未知漏洞需要额外采购和部署可能有性能损耗对安全要求极高的生产环境作为纵深防御的一环。我的个人建议是“升级替换”为主“过滤监控”为辅。对于存量系统立即制定计划升级aspectjweaver和commons-collections等关键库。同时在新功能开发或旧模块重构时坚定不移地弃用Java原生序列化转向JSON或Protobuf。对于核心的、暂时无法改造的旧服务务必启用反序列化过滤器并考虑部署RASP进行运行时保护。6. 从AspectJWeaver漏洞看Java反序列化防御体系AspectJWeaver漏洞不是一个孤例它是Java反序列化安全问题的一个典型缩影。通过这个案例我们可以建立起一套更普适的防御思路。1. 建立“危险依赖”清单将已知存在反序列化利用链的第三方库纳入统一管理。这个清单应该包括但不限于commons-collections:3.2.1及以下commons-beanutils:1.9.2及以下存在历史漏洞的fastjson版本存在历史漏洞的jackson-databind版本groovy、spring-aop等在特定组合下危险 在项目的CI/CD流水线中集成依赖检查工具如OWASP Dependency-Check、GitHub Dependabot自动阻断引入危险版本依赖的构建。2. 推行“安全反序列化”编码规范强制代码审查在Code Review中将ObjectInputStream的使用列为高危项重点检查。提供安全工具类在公司内部基础组件库中提供封装好的、内置了白名单过滤器的SafeObjectInputStream要求所有项目必须使用。框架选型引导在新项目技术选型时明确推荐使用HTTPJSON/RESTful而非RMI、Hessian等基于原生序列化的RPC框架。3. 加强运行时监控与应急响应日志监控在应用日志中对反序列化异常InvalidClassException、ClassNotFoundException进行监控和告警异常的类名可能就是攻击载荷的特征。主机监控监控服务器上是否突然出现可疑的子进程如bash、curl、wget、powershell等。制定应急预案一旦发现反序列化攻击迹象如何快速定位入口、下线服务、排查后门需要有清晰的预案。反序列化漏洞的攻防是一场持久战。攻击者在不断挖掘新的利用链“ gadget chain ”而防御者需要从开发框架、编码习惯、依赖管理、运行时环境等多个层面构建立体防线。AspectJWeaver这个案例告诉我们即使是一个看似与安全无关的基础工具库也可能因为一个不经意的设计细节成为整个系统安全的“阿喀琉斯之踵”。作为开发者我们必须时刻保持对安全的敬畏将安全思维融入到软件生命周期的每一个环节。 Java反序列化漏洞深度解析：从AspectJWeaver漏洞看安全防御实战
1. 从一次内部安全审计说起前段时间公司内部做了一次应用安全专项审计我负责检查几个核心的Java后台服务。用工具扫了一圈常见的SQL注入、XSS都没啥大问题但在一个老项目的依赖里工具报出了一个让我心里“咯噔”一下的提示AspectJWeaver反序列化漏洞风险。这个依赖我太熟悉了Spring AOP、事务管理背后或多或少都有它的影子很多项目为了引入切面编程都会间接带上它。问题在于这个看似人畜无害的“编织器”如果配置不当或者被攻击者找到了入口就能成为一条直通内网的“高速公路”。这可不是危言耸听利用AspectJWeaver进行反序列化攻击可以直接在目标服务器上执行任意代码危害等级是致命的。今天我就把这个漏洞从原理到利用再到防御给大家彻底拆解清楚。无论你是负责安全的同学还是日常开发的Java工程师理解这个漏洞都非常有必要。它不像某些冷门的0dayAspectJWeaver在Java生态里太普遍了而且利用链相对稳定是红队手里的一把“好枪”也是蓝队必须堵上的一个“暗门”。我们会从为什么AspectJWeaver会被卷入反序列化风波讲起一步步分析它的利用链是如何“编织”起来的并给出实实在在的修复和排查方案。2. 漏洞核心为什么AspectJWeaver会被反序列化利用要弄明白这个漏洞首先得搞清楚两个看似不相关的东西是怎么被联系在一起的反序列化和AspectJWeaver。2.1 反序列化对象的“复活”与风险在Java里我们经常需要把对象Object转换成字节流byte stream进行存储或网络传输这个过程叫序列化Serialization。反过来把字节流恢复成对象就是反序列化Deserialization。Java通过实现java.io.Serializable接口来支持这个机制。问题就出在“恢复”对象上。Java反序列化机制在重建对象时不仅会恢复对象的数据还会自动调用该对象类中一个特殊的方法readObject。如果开发者在一个可序列化的类里重写了readObject方法那么反序列化时这个方法里的代码就会被执行。想象一下这个场景攻击者精心构造了一段恶意的字节流里面“包裹”着一个特殊的对象。这个对象的readObject方法里写的是下载木马、执行命令的代码。当你的程序不加甄别地反序列化这段来自网络或文件的数据时就相当于亲手把攻击者的代码请进来并执行了。这就是反序列化漏洞最根本的原理——利用目标类库中已有的、可被序列化且readObject方法或相关方法如readResolve、readExternal存在危险操作的类构造出一条调用链Gadget Chain最终达到执行任意代码的目的。2.2 AspectJWeaver不止是编织切面AspectJWeaver是AspectJ项目的一部分主要功能是在编译时或加载时“编织”切面代码到目标类中实现AOP。它包含一个关键的JAR包aspectjweaver.jar。这个包里有很多用于处理类加载、字节码和缓存的工具类。漏洞的起点就在这个JAR包里的一个类org.aspectj.weaver.tools.cache.SimpleCache。这个类实现了Serializable接口意味着它可以被序列化和反序列化。更关键的是它的readObject方法里有一个非常危险的操作private void readObject(java.io.ObjectInputStream in) throws ... { // ... 读取一些字段 this.map (Map) in.readObject(); // 关键点直接读取一个Map对象 // ... }它直接从输入流中读取一个Map对象并赋值给内部的map字段。在Java反序列化中in.readObject()会递归地反序列化这个Map对象以及它内部的所有键值对。如果这个Map的Key或Value是另一个复杂的、其readObject方法有危险操作的对象那么危险就被传递下去了。SimpleCache本身没做坏事但它开了一个“口子”允许攻击者控制一个Map被反序列化。这就像一栋大楼的门卫SimpleCache#readObject只检查了访客序列化流的身份证类型就允许他带了一个大箱子Map进来并且对箱子里装了什么Map里的内容完全不检查。2.3 链路的连接从SimpleCache到命令执行仅有SimpleCache这个入口还不够我们需要找到一条能从“控制一个Map”通到“执行系统命令”的完整路径。这条路径就是所谓的利用链Gadget Chain。在经典的AspectJWeaver反序列化利用链中后续的环节通常依赖于另一个非常著名的通用库Apache Commons Collections特别是3.x版本即commons-collections-3.2.1。这个库提供了大量好用的集合工具类其中一些类如TransformedMap、InvokerTransformer为了灵活性允许传入并调用任意的Transformer接口实现。攻击者可以这样构造链条入口实例化一个SimpleCache对象并准备一个恶意的Map作为其map字段。传递这个恶意Map的Value是一个Apache Commons Collections中的LazyMap或TransformedMap。这类Map的特点是在获取get某个不存在的Key时会通过一个Transformer来动态生成Value。触发攻击者将Transformer设置为InvokerTransformer这个类可以通过反射调用任意类的任意方法。执行在反序列化过程中通过精心构造的链式调用可能涉及AnnotationInvocationHandler、TemplatesImpl等最终让InvokerTransformer反射调用Runtime.getRuntime().exec(“恶意命令”)。简单来说AspectJWeaver的SimpleCache提供了漏洞的“发射井”而Commons Collections等库提供了“火箭”和“弹头”。当存在漏洞的应用反序列化了攻击者构造的SimpleCache数据时整个链条就会被自动触发在服务器上执行命令。注意这里描述的是一条经典且常见的利用链。实际环境中根据目标类路径ClassPath上存在的其他库如Groovy、Spring、Fastjson等攻击者可能会组合出不同的利用链。但AspectJWeaver Commons Collections是其中非常典型和稳定的一种。3. 漏洞利用的实战环境搭建与原理深潜光讲原理有点抽象我们动手搭一个最简单的环境把利用过程走一遍你会理解得更透彻。再次强调以下所有实验请在完全隔离的虚拟机或测试环境中进行严禁对生产或他人系统进行测试3.1 实验环境准备你需要准备JDK 8很多老项目运行在JDK 8上其内置的sun.reflect.annotation.AnnotationInvocationHandler类是早期利用链的关键一环。漏洞依赖JARaspectjweaver-1.9.0.jar存在漏洞的版本例如1.9.0到1.9.5等。commons-collections-3.2.1.jar提供关键利用类。一个简单的靶机程序就是一个会反序列化网络数据的Java应用。靶机程序示例代码import java.io.*; import java.net.*; public class VulnerableServer { public static void main(String[] args) throws Exception { ServerSocket server new ServerSocket(9999); System.out.println([*] Server listening on port 9999...); while (true) { Socket socket server.accept(); try (ObjectInputStream ois new ObjectInputStream(socket.getInputStream())) { // 高危操作直接反序列化来自客户端的数据 Object obj ois.readObject(); System.out.println([*] Received and deserialized an object: obj.getClass()); // 这里通常会有一些业务逻辑处理obj... } catch (Exception e) { e.printStackTrace(); } } } }这个服务器的危险之处一目了然它打开一个端口对接收到的数据直接进行readObject()没有任何白名单校验或安全检查。3.2 构造攻击载荷Payload攻击端需要构造一个恶意的序列化对象。我们使用ysoserial这个著名的Java反序列化利用工具来生成。ysoserial内置了针对AspectJWeaver的利用链名为AspectJWeaver。生成Payload的命令java -jar ysoserial.jar AspectJWeaver “calc.exe” payload.bin在Linux/Mac下命令可换成“touch /tmp/hacked”这条命令的意思是使用AspectJWeaver利用链生成一个执行calc.exe弹出计算器命令的序列化字节流并保存到payload.bin文件。3.3 发起攻击在攻击机器上使用ncNetcat或简单的Socket客户端将payload.bin发送给靶机。nc 靶机IP 9999 payload.bin如果靶机运行在Windows上且环境正确你会看到计算器被弹出。这直观地证明了反序列化漏洞的威力——通过网络发送一段数据就能在远程服务器上启动一个图形化程序。如果是服务器命令如wget下载木马、bash -c反弹shell后果不堪设想。3.4 关键原理步骤拆解让我们深入ysoserial的AspectJWeaver链源码看看这个payload.bin里面到底“编织”了什么外层包裹SimpleCache生成的字节流最外层是一个org.aspectj.weaver.tools.cache.SimpleCache对象。这是利用链的入口也是触发点。恶意Map注入在SimpleCache的readObject方法中会调用in.readObject()来填充其内部的map字段。攻击者在这里注入了一个精心构造的Map。Commons Collections的Transformer链这个Map通常是一个LazyMap或TransformedMap其valueTransformer被设置为一个ChainedTransformer。ChainedTransformer里包含了一系列的Transformer其中最关键的是一个InvokerTransformer它被配置为通过反射调用Runtime.getRuntime().exec()方法。触发转换为了在反序列化时自动触发这个Transformer链利用链会借助其他类如AnnotationInvocationHandler、BadAttributeValueExpException等的readObject或toString、hashCode方法在反序列化过程中去访问get恶意Map的某个Key。链式反应一旦访问发生LazyMap就会调用其Transformer链来生成Value。ChainedTransformer开始工作执行到InvokerTransformer时反射调用发生最终执行我们预设的系统命令。整个过程完全依赖于Java反序列化机制自动调用readObject方法的特性以及各个类库之间方法调用的连锁反应。AspectJWeaver的SimpleCache因其“无脑”反序列化一个Map的特性成为了启动这个连锁反应的第一块多米诺骨牌。实操心得在分析利用链时不要只盯着入口点。像AspectJWeaver这类漏洞真正的杀伤力来自于整个ClassPath环境。如果你的应用同时引入了存在类似“危险特性”的多个库如CC链、CB链、Fastjson链的依赖它们就可能被攻击者“拼接”起来形成利用链。因此安全加固必须是全局性的。4. 影响范围与排查方案知道了漏洞怎么利用接下来最关键的是我的系统受影响吗怎么查4.1 影响范围评估满足以下条件你的应用就存在风险使用了存在漏洞版本的aspectjweaver通常版本号在1.9.0 至 1.9.5之间需要重点排查。Spring Boot项目如果使用了AOP、Async、Transactional等特性很可能会间接引入这个依赖。项目中同时存在可被利用的“链”库最常见的就是Apache Commons Collections 3.x (3.0 - 3.2.1)。其他如commons-beanutils,groovy,spring-aop等也可能在特定组合下成为利用链的一部分。存在不安全的反序列化入口这是漏洞被触发的必要条件。常见的入口包括RMI使用Java RMI进行远程通信并且注册了接收Object类型参数的远程对象。JMX开启了JMX服务端并且暴露了MBean接口处理序列化数据。HTTP参数接收Base64编码或其他格式的序列化数据并直接进行反序列化一些旧的Java框架或自定义协议可能存在此问题。消息队列消费MQ消息时直接对消息体进行ObjectInputStream反序列化。文件/数据库读取存储的序列化对象文件或Blob字段并直接反序列化。FasterXML/jackson-databind在特定配置下也可能触发基于类的反序列化。4.2 系统化排查方案你可以按照以下步骤进行自查第一步依赖扫描使用Maven或Gradle的依赖树命令检查aspectjweaver的版本。# Maven mvn dependency:tree | grep aspectjweaver # Gradle gradle dependencies | grep aspectjweaver对于非Maven/Gradle项目直接检查WEB-INF/lib或类路径下的JAR文件。第二步识别反序列化入口这是排查中最关键也最困难的一环。你需要审查代码全局搜索ObjectInputStream、readObject、readUnshared。搜索Serializable接口的实现类特别是那些重写了readObject、readResolve方法的类。检查网络服务Socket、RMI、HTTP接口、文件读取、数据库Blob字段处理等所有可能接收外部数据的地方看是否直接将数据流传递给了ObjectInputStream。检查框架配置例如Spring HTTP Invoker、Hessian、Burlap等旧的RPC框架它们可能默认使用Java序列化。第三步使用自动化工具辅助静态扫描工具可以使用FindSecBugs、SonarQube等SAST工具它们能识别不安全的反序列化代码模式。动态测试工具在测试环境可以使用ysoserial生成各种利用链的Payload配合Burp Suite等代理工具对应用的各个接口进行模糊测试Fuzzing观察是否有异常响应或命令执行迹象。此操作风险极高务必在授权和隔离环境进行。第四步检查安全防护查看应用中是否已经部署了以下防护措施我们将在下一章详述是否使用了反序列化过滤器ObjectInputFilter是否替换了不安全的序列化框架如换用JSON是否升级了所有已知存在危险利用链的第三方库5. 修复与加固的实战指南排查出问题后修复必须多管齐下。单一措施很难做到绝对安全我们需要构建一个纵深防御体系。5.1 根本性修复升级或移除首选方案升级aspectjweaver到安全版本。AspectJ团队在后续版本中修复了此问题。请升级到1.9.6或更高版本。在新版本中SimpleCache类的readObject方法增加了安全性检查或者修改了实现方式阻断了利用链。检查并升级其他危险依赖。同样将commons-collections等已知存在危险类的库升级到最新版本。例如commons-collections升级到3.2.2或4.x版本注意API可能有变化。commons-beanutils升级到1.9.4及以上。关注其他安全公告及时升级fastjson、jackson-databind、xstream等序列化相关库。注意升级后务必进行全面的功能回归测试。因为高版本库可能有不兼容的API变更。5.2 代码层加固关闭危险入口如果无法立即升级或者希望增加一层防护可以在代码层面进行加固。1. 使用反序列化过滤器JDK ≥ 8u121, JDK ≥ 9这是JDK提供的最有效的内置防护机制。你可以定义一个ObjectInputFilter只允许反序列化来自可信白名单的类。import java.io.*; public class SafeObjectInputStream extends ObjectInputStream { // 定义一个严格的白名单只允许应用核心的、安全的类 private static final ObjectInputFilter FILTER ObjectInputFilter.Config.createFilter( “java.lang.String;java.util.HashMap;com.yourcompany.safe.*;!*” // 允许String, HashMap以及com.yourcompany.safe包下所有类拒绝其他所有类 ); public SafeObjectInputStream(InputStream in) throws IOException { super(in); super.setObjectInputFilter(FILTER); } } // 使用方式 try (SafeObjectInputStream sois new SafeObjectInputStream(socket.getInputStream())) { Object obj sois.readObject(); // ... }配置要点白名单要尽可能精确、最小化。从只允许java.lang.String和java.util.*中的基础不可变类开始再逐步添加业务必须的类。使用!*显式拒绝所有未在白名单中的类。此过滤器在JDK 9及以上功能更完善在JDK 8u121后需通过sun.misc.ObjectInputFilter使用不推荐用于长期方案。2. 替换序列化方案这是最推荐的长期方案。放弃Java原生序列化改用更安全、更高效的序列化协议。JSON使用Jackson或Gson。它们默认只反序列化数据到POJO的属性不会任意执行代码。Protocol Buffers / Thrift跨语言、高性能、强类型的二进制序列化方案安全性远高于Java原生序列化。Kryo (需谨慎配置)虽然性能极高但Kryo本身如果不做安全配置如设置kryo.setRegistrationRequired(true)也存在反序列化风险。3. 校验序列化数据在反序列化前对输入数据进行强校验。完整性校验使用HMAC等签名机制确保数据未被篡改。业务逻辑校验反序列化后的对象必须经过严格的业务逻辑校验如字段范围、关联关系后才能使用。5.3 JVM层与运维层防护1. 使用Security Manager或Java Agent可以编写自定义的SecurityManager策略文件或使用Java Agent在类加载时进行拦截禁止加载或实例化危险的利用类如org.apache.commons.collections.functors.InvokerTransformer。这种方式对代码侵入小但配置复杂对性能有一定影响。2. 使用RASP运行时应用自我保护在生产环境中部署RASP产品。RASP可以注入到应用运行时实时监控ObjectInputStream.readObject()等危险方法的调用栈和参数一旦发现行为符合攻击特征如调用Runtime.exec立即进行阻断并告警。这是目前企业级防护非常有效的手段。3. 网络与主机隔离最小化暴露关闭不必要的RMI、JMX端口。如果必须开启将其绑定到内网或管理网络禁止从公网访问。权限最小化运行Java应用的系统用户应使用低权限账户避免其拥有执行敏感命令或写入关键目录的权限。5.4 修复方案对比与选择修复方案优点缺点适用场景升级依赖版本从根本上修复漏洞一劳永逸可能引入兼容性问题需要测试首选方案所有受影响系统都应尽快安排升级。反序列化过滤器JDK原生支持防护粒度可控白名单维护成本高JDK8早期版本支持有限无法立即升级且使用高版本JDK的过渡方案。替换序列化协议彻底摆脱Java原生序列化风险提升性能改造工作量较大涉及前后端/多服务协调新系统设计或老系统重大重构时。代码入口校验灵活可与业务结合依赖开发人员安全意识容易遗漏作为辅助手段与其他方案结合使用。RASP/安全产品无侵入实时防护可防御未知漏洞需要额外采购和部署可能有性能损耗对安全要求极高的生产环境作为纵深防御的一环。我的个人建议是“升级替换”为主“过滤监控”为辅。对于存量系统立即制定计划升级aspectjweaver和commons-collections等关键库。同时在新功能开发或旧模块重构时坚定不移地弃用Java原生序列化转向JSON或Protobuf。对于核心的、暂时无法改造的旧服务务必启用反序列化过滤器并考虑部署RASP进行运行时保护。6. 从AspectJWeaver漏洞看Java反序列化防御体系AspectJWeaver漏洞不是一个孤例它是Java反序列化安全问题的一个典型缩影。通过这个案例我们可以建立起一套更普适的防御思路。1. 建立“危险依赖”清单将已知存在反序列化利用链的第三方库纳入统一管理。这个清单应该包括但不限于commons-collections:3.2.1及以下commons-beanutils:1.9.2及以下存在历史漏洞的fastjson版本存在历史漏洞的jackson-databind版本groovy、spring-aop等在特定组合下危险 在项目的CI/CD流水线中集成依赖检查工具如OWASP Dependency-Check、GitHub Dependabot自动阻断引入危险版本依赖的构建。2. 推行“安全反序列化”编码规范强制代码审查在Code Review中将ObjectInputStream的使用列为高危项重点检查。提供安全工具类在公司内部基础组件库中提供封装好的、内置了白名单过滤器的SafeObjectInputStream要求所有项目必须使用。框架选型引导在新项目技术选型时明确推荐使用HTTPJSON/RESTful而非RMI、Hessian等基于原生序列化的RPC框架。3. 加强运行时监控与应急响应日志监控在应用日志中对反序列化异常InvalidClassException、ClassNotFoundException进行监控和告警异常的类名可能就是攻击载荷的特征。主机监控监控服务器上是否突然出现可疑的子进程如bash、curl、wget、powershell等。制定应急预案一旦发现反序列化攻击迹象如何快速定位入口、下线服务、排查后门需要有清晰的预案。反序列化漏洞的攻防是一场持久战。攻击者在不断挖掘新的利用链“ gadget chain ”而防御者需要从开发框架、编码习惯、依赖管理、运行时环境等多个层面构建立体防线。AspectJWeaver这个案例告诉我们即使是一个看似与安全无关的基础工具库也可能因为一个不经意的设计细节成为整个系统安全的“阿喀琉斯之踵”。作为开发者我们必须时刻保持对安全的敬畏将安全思维融入到软件生命周期的每一个环节。