几个月前，Contrast 安全团队向 VMWare 安全团队报告了有关 Spring Kafka 的 Java 反序列化漏洞。它立即引起了我的注意，我开始分析这个错误。如果您有兴趣，可以查看我之前的博客，详细内容。
https://blog.pyn3rd.com/2023/09/15/CVE-2023-34040-Spring-Kafka-反序列化-远程代码执行
经过明确分析，我认为这是一份发人深省的报告。于是，我立刻写下了这篇博客。
在 Java 安全性方面，Java 反序列化漏洞位居榜首。我想通过最近的 Spring Kafka 的 Java 反序列化漏洞来谈谈这个问题。
人们可能已经知道根本原因是来自用户的不安全序列化流未经验证有助于远程代码执行。
大多数Java应用程序都或多或少地关注过反序列化漏洞，例如Weblogic Server、Apache Shiro。就我个人而言，重写该ObjectInputStream函数已成为防御 Java 反序列化攻击的广泛使用。它可以使这个问题得到缓解。当覆盖 时ObjectInputStream，resolveClass会被钩住，并且可能会发现潜在危险的函数撤销。
实际上，Spring Kafka也利用同样的方式来防御Java反序列化漏洞。近距离观察 Java 片段。
虽然防御性编程表面上是存在的，但为什么Spring Kafka中仍然会出现Java反序列化漏洞呢？我想这种困惑已经体现在屏幕前某人的脸上了。
-
自定义ObjectInputStream & 钩子resolveClass
我只是提供了一个带有覆盖ObjectInputStream函数的演示。然后，我尝试反序列化恶意反序列化流。
不安全的尝试已被成功阻止。
然后我彻底模仿Spring Kafka的代码。我将类替换DeserializationException.class 为， Person.class让您知道会抛出异常。
因此，我可以简单地以封装的方式逃避这种验证。初始化后 ，可以将其作为参数CustomExceptionClass输入到 的实例中。DeserializationExeception
最后一步是将CommonCollection6小工具嵌入到静态代码块中。
综上所述，定制化的弱点ObjectInputStream导致了Spring Kafka反序列化漏洞。它只验证堆栈中的顶层函数。
除了自定义功能的方式之外ObjectInputStream，还有一些其他的防御选择。
-
Apache Commons IO 库中的 ValidatingObjectInputStream
Apache Commons IO库包含实用类、流实现等。它提供了一个只允许特定类被反序列化的功能ValidatingObjectInputStream，相当于一个白名单。
除了白名单中的类之外，任何类都无法反序列化！如您所见，该类org.springframework.kafka.support.serializer.DeserializationException已被阻止，因为它未包含在白名单中。
JEP290 是一个基于 JDK 的侦探编程。它提供了一种灵活的机制来防止Java应用程序遭受反序列化攻击。
开发人员可以自定义特定的类作为过滤器。它允许类被反序列化或不被反序列化。在我的例子中，该类com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl将被阻止。
不幸的是，这个机制或多或少有一些不足。我打算下次再谈。
原文地址（点击阅读原文也可跳转）：
https://blog.pyn3rd.com/2023/10/20/Java-Deserialization-Vulnerability-Still-Alive/
感谢您抽出
.
.
来阅读本文
点它，分享点赞在看都在这里
原文始发于微信公众号（Ots安全）：Java 反序列化漏洞仍然存在
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论