Fastjson68版本绕过autotype原理及利用场景分析 – 作者:平安银行应用安全团队

引言

fastjson 68版本前一阵子有些闹得沸沸扬扬的,我这边也一直忙着写字节码扫描器没太用心关注,今天看到fastjson代码已经跟进到71版本了,所以对68和69版本的代码做了一下比对,看了一下修复代码,这里对68版本fastjson的RCE漏洞做一下原理以及利用场景的分析。

注:其实最初在5月10号的时候我这边就已经看到了68版本的一种利用方式,基于Throwable子类的利用方式,不过这种方式只是68版本利用方式中的一种。

原理

fastjson的漏洞跟进的比较多的情况下,可以明白一个基本的套路就是,不管绕过怎么样的风骚,修复代码大部分都在ParserConfig类的checkAutoType里面,所以就话不多说,把68版本和69版本的ParserConfig类做个比较,看到改动还是很少的。

基本上一看可以看出是和expectClass有关,所以在函数的上上下下看了一下这个变量,可以归并一下发现的信息:

1、expectClass不为代码中的那些类的时候可以将expectClassFlag设置为true

2、当expectClassFlag为true的时候,即使fastjson的autoype为false我们也能生成期望类的实例。

OK但从上诉两点,我们就可以看到借由expectClass我们是可以绕过fastjson的autotype安全限制的,这个安全通告相符合,代表我们走在正确的方向上。

但是在阅读checkAutoType函数中expectClass的代码的时候,也发现了其中一些会限制Gadget的点,

1、黑名单检测逻辑是放在loadClass之前的,也就是说我们的Gadget将依旧受到黑名单的限制。(代码太长,我就不贴了)

2、Gadget必须实现了expectClass接口(或是expectClass的子类),才能成功生成Gadget的实例。

上面便是阅读代码得到的关键性信息了,接下来就要思考一下expectClass的问题了,第一个问题,expectClass是从哪里来的,看一下checkAutoType函数,

public Class<?> checkAutoType(String typeName, Class<?> expectClass, int features)

很清晰,expectClass就是直接传给checkAutoType函数的,那么接下来我们需要去寻找,究竟哪些地方会给checkAutoType函数传expectClass,全局搜索一下,可以看到场景非常少,

1、JavaBeanDeserializer类的deserialze函数

2、ThrowableDeserializer类的deserialze函数

关于第二种场景,我这边5月10号就到了别的大佬的分析,有兴趣大家可以去看一下,我就不再赘述,这里着重讲第一种。(当然其实就原理而言完全是一回事。)

DefaultJSONParser调用parseObject,用@type生成的clazz实例会紧接着传入JavaBeanDeserializer类的deserialze方法的type参数中,并继续解析json数据,如果json数据中还有@type,则把@type的值作为typeName,type参数作为expectClass传入checkAutoType函数中,

那根据我们刚刚分析代码得出的结论,如果typeName刚好为expectClass的子类,那么接下来就能生成typename的对象,从而达成绕过autotype的目的。

但是,这里一定要注意一个特别重要的问题,由于默认autotype是关着的,那么我们又怎么样去用@type来生成传给deserialze的clazz呢,下面我就先给出目前fastjson在autotype关闭的情况下能生成的clazz的范围:

1、cache mapping:48版本以前fastjson允许用户通过{“@type”:”java.lang.Class”,”val”:”com.evilClass”}的形式向mapping里面添加恶意类,这样不需要依赖autotype可以直接从cahce的mapping里获取clazz,但是48版本已经修复该问题。当然cache mapping在刚fastjson启动的时候就已经放了不少clazz,加载的时候不受autotype限制。

2、白名单:不赘述,白名单的目的就是不受autotype的限制嘛。不过新版本白名单已经被加密,需要爆破一下。

3、默认deserializers的buckets(在PaserConfig类的initDeserializers函数中初始化):可以把fastjson理解为一个编译器,它在进行初始化的时候也需要加载一些基础类型的对象,这些对象为了组件的正常工作是必须的。

所以我们需要的clazz就是要从上诉列举的三种情况里面寻找到,与此同时保证它不在黑名单里面。

OK,全部的分析已经到位,我们来汇总一下,看看poc究竟要怎么写:

1、首先要用@type来生成一个clazz(不受autotype影响的)。从而把这个clazz传入deserialze函数的exceptClass中,要保证clazz不能为以下类。(这个是68版本的,69版本又添加了三个。)

2、紧跟在生成在第一个@type后面,再跟一个@type,它的value不能是黑名单里面的类,而且必须是第一个clazz的子类。

之后便能生成一个不受autotype影响的clazz,以达到利用效果。

关于漏洞的复现,为了方便起见,我就直接去拿了69版本被拉黑而68版本没被拉黑的AutoCloseable接口来构造poc了。

因为想要利用成功必须保证第二个clazz实现AutoCloseable的接口,恶意类难找,我们只聊原理,我就随便写了一个利用类。

package defaultpack;
import com.alibaba.fastjson.JSON;
import com.sun.rowset.JdbcRowSetImpl;
import org.h2.tools.SimpleResultSet;
import java.lang.reflect.Field;
public class Person implements AutoCloseable{
    private String name;
    private int age;
    private String gender;
    public Person() {
        System.out.println("no-arg construct invoked!!!");
    }
    public Person(String name, int age, String gender) {
        this.name = name;
        this.age = age;
        this.gender = gender;
    }
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public int getAge() {
        System.out.println("getAge invoked!!!");
        return age;
    }
    public void setAge(int age) {
        this.age = age;
        System.out.println("setAge invoked!!!");
    }
    public String getGender() {
        return gender;
    }
    public void setGender(String gender) {
        this.gender = gender;
    }
    @Override
    public void close() throws Exception {
    }
}

利用的poc如下,

String payload = "{\"@type\":\"java.lang.AutoCloseable\",\"@type\":\"defaultpack.Person\",\"age\":\"13\"}";
JSON.parseObject(payload);

成功利用的截图如下,可以看到在68版本autype默认为关的情况下,依旧成功调用了Person类的setAGe方法。:

利用场景分析

可以从上面的分析看出,虽然在原理层面上,的确存在着代码执行的风险,且绕过了autotype机制,但是这个利用受到了多方面限制:

1、黑名单限制

2、漏洞利用类必须拥有一个在autotype关着的情况下可以生成实例的父类(目前在68版本我已知的是Throwable和AutoCloseable)。

所以因为以上两点的限制,就可以发现利用是非常局限的,当然也不排除黑客大佬们思路广阔而笔者才疏学浅的可能性,因此我也仅在这里给出自己的看法。

*本文作者:平安银行应用安全团队@Glassy,转载请注明来自FreeBuf.COM

来源:freebuf.com 2020-06-17 11:30:12 by: 平安银行应用安全团队

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论