最后几块拼图（一）：使用 Yakit 打破 Java 序列化协议语言隔离

原创

已于 2023-11-06 17:28:37 修改 · 423 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#python #开发语言

于 2023-11-06 17:27:23 首次发布

文章讨论了Java中ysoserial工具的利用与反利用，强调了Java序列化过程中的安全挑战，提出通过控制载入的类和流来防止被反制，并探讨了不同漏洞扫描方法的优缺点。作者还介绍了如何通过工具如SerialDumper和Yak来理解和处理序列化流，以及未来更安全的payload生成和RMIExploit的发展方向。

一句话背景知识

众所周知，在使用 Java 编写漏洞利用或检测时，ysoserial 或类似工具会构造一个特定的执行命令的对象，然后进行序列化，作为用户只把序列化（Marshal）后的二进制对象作为 Payload，打到特定位置或注册为远程对象，通过 RMI 或者远程服务 readObject 后直接 RCE。
虽然这是一个人人都知道的过程。

威胁

当然，“赛博回忆录-反制系列” 针对这个问题做了详细的文章，Java 实现的漏洞利用实际上是一把 “双刃剑”，在使用各种链来构造特定反序列化流的同时，自己也是一个“靶子”。
其实早在反制系列出现之前，笔者在长亭工作时，子航师傅就提过 Java RMI 的反制，可以做到放一个 1099 RMI 蜜罐在公网，谁来打就打回去反向 RCE。这个原理也非常容易理解。

如何不被“反制”？

大家做漏洞扫描这类安全开发的时候，非常头痛的事情在于，偏爱 Python 或 Golang，不考虑用 Java 实现。
就直接导致很多 Java 漏洞的检测变得非常扭曲。
如果用了 Java 又需要思考如何不被反制，用户需要严格控制不要加载任何来源于攻击者的类或者流。

现状：

市面上关于有 Java 相关的漏洞扫描现在主流分两类：

依赖 Java 环境，并且 ysoserial.jar 作为扫描器依赖打包，以 Popen / system / subprocess / Exec 调用 java -jar ysoserial.jar 来生成特定 Payload 来进行漏洞检测或攻击。
另一类选择硬编码利用链的 Payload，然后根据执行命令的 Payload 长度构造合适的 “块”，替换原 Payload 位置，从而构造出一个可用的 Payload。大家常见的 xray 就是通过 “硬编码” 来实现利用链的。

众所周知，针对一些 Groovy 链和常见的 CC1 链都是可以直接找到对应的命令的位置，直接替换即可。实际在第二种实现中，有着非常大的限制：TemplatesImpl
com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl 模版是很多链执行命令的关键。
尝试过进行一些分析的读者其实非常清楚，我们在有 TemplatesImpl 的链（例如 CC2[CommonCollections2] / CC3 / CC4）中，无法直接 “搜到” 执行的命令的关键字。其实本质上是因为，有一些命令和代码被编译成了 “Java 字节码”，然后又被序列化成了 “TC_BLOCKDATA”，表象就是，每个字节都加了 Padding，我们发现无法 “搜” 到对应 string 了。当然，我们也可以人为去做 “Padding”，然后把 Payload 自己去 Padding 后塞入链中特定位置，也可以构造出一个 “可用” 的 P