前言

最近在学习fastjson的相关漏洞,一直跟到了1.2.47的RCE,鉴于网上关于该版本的分析文章较为简略,这里提供相关分析过程供入门java代码审计的小伙伴学习~

漏洞分析

FastJson1.2.24 RCE

在分析1.2.47的RCE之前先对FastJson1.2.24版本中的RCE进行一个简单的漏洞链分析,为在本篇文章后面1.2.47中漏洞的调用过程做个铺垫。在本文中的1.2.24的payload只研究针对类jdbcRowSetImpl的,因为针对templatesImpl的payload而言在高版本java中要开启Feature.SupportNonPublicField才能进行对非共有属性的反序列化处理,因此是存在一定的限制的。因此针对类jdbcRowSetImpl的payload更具有通用型一些。本中所示代码及jar包请见附件。

exp.java

Exploit.class

首先在本地用marshalsec起一个ldap服务,用rmi也可以,只需将datasourcename中的服务更改为rmi即可

本文中环境为jdk1.8.0,首先在parse处下一个断点然后运行exp.java,本来打算正向找到setvalue函数,可是fastjson扫描json字符串的过程及反序列化时处理jdbcrowsetimpl类处处理流程过于繁琐,中间不知道得跟进多少个F7,很容易让人没有耐心继续调试分析,遂这里直接关注漏洞的核心点,即我们在setDataSourceName处下断点

即此时将从我们payload中指定的DataSourceName中去加载工厂类

在setautoconnect函数中调用了connect()函数,跟进后此时就能看到熟悉的lookup函数啦,我们知道jndi注入攻击中从远程加载恶意工厂类即是我们控制了lookup的入口参数,即控制了远程工厂类的加载地址,即此处即为关键点,F7步入

此时getDataSourceName()的返回值也可以看到即为我们所指定的恶意工厂类地址


然后跟进lookup看看如何调用实例化,这里调用了getURLOrDefaultInitCtx(name).lookup()函数

此时就到了java的命名服务管理的类,此时调用getURLContext函数请求ldap,进一步在其中调用getURLObject来通过从远程的ldap服务获取Context对象

最终完成exploit.class类的实例化,也就是工厂类的实例化,熟悉的getObjectInstance(),此时就完成了反序列化,从而触发exploit里的构造函数


整个漏洞的函数调用栈如下图所示

以下是一些针对fastjson不同版本的payload,可以看到bypass其实在@type类的前面加上L或者[,这都是因为fastjson在处理域时会将扫描到的这些字符进行去除

FastJson1.2.47 RCE

漏洞影响版本:fastjson<1.2.51

exp.java

Exploit.class与1.2.24相同,在1.2.24以后fastjson默认关闭了反序列化任意类的操作,增加了checkautotype,也就是指定要用来反序列化的类不能够在一些黑名单中,从而做了一定的限制。此次漏洞利用的核心点是java.lang.class这个java的基础类,在fastjson 1.2.48以前的版本没有做该类做任何限制,加上代码的一些逻辑缺陷,造成黑名单以及autotype的绕过。我们仍然在parse处下断点,这里正向F7跟进到如下图所示

在DefaultJSONParser中,对json字符串进行扫描解析,此时解析到key值为a,接下来就对a中的字段进行解析,这里解析到@type以后,进而扫描到typename为java.lang.class,此时将调用parseconfig类的checkautotype函数来检测要反序列化的类。

接着在checkautotype函数中此时从mappings中或者deserializers.findClass()方法来获取反序列化对象的对应类

这里实际上在findClass函数中的this.bucktet中去找要反序列化的类,而在bucket变量中包含了大量的基础类


这里关键点在这几句代码,找到的类通过getName()函数调用后就能获得类的类名,然后将该类名与传入的要反序列化的类名比较,若相等,即找到,则直接返回该类,这里返回值为类类型。

接着回到IedentityHashMap的checkautotype函数中返回java.lang.class类

进一步回到com/alibaba/fastjson/parser/DefaultJSONParser.class中调用了对应的序列化处理类,也就是有了要反序列化的类,此时咋处理这类就是接下来的操作,获取的类为com.alibaba.fastjson.serializer.MiscCodec

接下来到364行即开始调用MiscCodec的deserialze函数

在其deserialze函数中可以看到其首先取得了我们payload字符串中var对应的值,也就是我们要利用的JdbcRowSetImpl类

接着对我们要反序列化的类进行一个类型判断,一直到303行,此时类满足判断,即java.lang.class为类类型的类,所以直接返回strVal,也就是恶意类

在TypeUtils类中可以看到此时loadclass函数的cache默认为true,这也是个重要的导致bypass的地方

那么这里首先loadclass尝试在mapping中取加载java.lang.class要引入的类,要是没有找到的话,此时将通过mapping.put方法将该类放到mapping中,那么不需要autotype就完成了对恶意类的加载

完成了对第一部分的json的字符串的解析已经成功加载了恶意类,因此此时json字符串继续向后扫描,扫描到b,此时处理b对应的值,当扫描到@type时继续调用checkautotype函数

那么因为之前我们已经通过java.lang.class的加载类的功能将jdbcrowsetimpl类加载到了mappings中,因此这里getclassfrommapping就能够返回我们的恶意类

接着又回到Defaultjsonparse类中

接着对于jdbcrowsetimpl类,调用fastjsonDeserialize_1_jdbcrowsetimpl类来对该类进行解析调用,那么接下来因为已经bypass了黑名单和autotype,因此之后rce的流程和1.2.24的一样了

还是回到熟悉的setAutoCommit函数,具体流程见上面1.2.24的描述,最终能够触发calc,此时用mashalsec打ldap一样是可以的

整个漏洞的函数调用栈如下图所示

漏洞修复

在1.2.48版本的补丁中,首先黑名单做了更新,其中就包含了java.lang.class这个类,并且MiscCodec中也将传入的cache参数置为了false,这样通过payload中a部分的java.lang.class引入JdbcRowSetImpl类,b部分通过
mappings获取JdbcRowSetImpl类的方法就失效了。

参考

https://www.anquanke.com/post/id/181874
https://www.kingkk.com/2019/07/Fastjson%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E6%BC%8F%E6%B4%9E-1-2-24-1-2-48/
https://saucer-man.com/information_security/346.html

code.zip (0.876 MB) 下载附件
点击收藏 | 1 关注 | 2
  • 动动手指,沙发就是你的了!
登录 后跟帖