实验环境

jdk1.8
windows10

Fastjson版本

1.2.24

pom依赖

先编写一个具有RCE功能的类，和一个工厂类：

再编写一个简单的RMI服务端：

编写漏洞验证代码：

将服务端启动后，执行FastjsonDeserializePoc类，先看一下效果，弹出了计算器：

JdbcRowSetImpl利用链分析

将断点打至JSON.parse处：

然后一直步入到这行：

继续步入到DefaultJSONParser的这里：

单步执行到239行，获取一个key，

可以看到此时获取的key是序列化json字符串中的@type。
继续单步至322行：

这里先获取了一个typeName，其值为"com.sun.rowset.JdbcRowSetImpl"，并获取了一个该类型的Class对象。
继续单步至367行，

这里将获取一个分序列化器，步入getDeserializer方法，一直步入到ParserConfig类的362行：

这里有一个黑名单，如果要加载的类在黑名单内，则会抛出异常。
PS：1.2.24版本黑名单中只有Thread类。
继续单步至461行：

这里将根据clazz对象创建一个javabean的反序列化器并最终返回。
接下来返回到DefaultJSONParser的368行，用上一步创建的反序列化器执行反序列化操作：

这个函数进去之后，可能没办法继续步入了，不过可以直接将断点打至JavaBeanDeserializer的773行：

再步入parseField方法，单步至71行：

此时将反序列化JdbcRowSetImpl类中的autoCommit字段，是一个boolean类型的字段，反序列化出的value是true。
继续单步至83行，此处将要给JdbcRowSetImpl对象设置autoCommit属性：

步入该方法，单步至66行：

这里获取到一个Method，代表了JdbcRowSetImpl的setAutoCommit方法，然后单步至96行，通过反射调用该方法：

可见fastjson反序列化是通过调用bean的setter方法设置值的。
在setAutoCommit方法内打个断点执行到此处：

调用了connect方法，步入该方法，执行到326行：

这里调用了InitialContext的lookup方法，是JNDI的API，该方法会根据给定的名称查找一个对象的引用，如果传入RMI协议，则会加载一个远程对象，而此处传入的是根据getter方法获取的dataSourceName，也就是序列化字符串中的rmi://127.0.0.1:1099/Calc，所以该行执行后就会请求到Calc类，从而触发RCE。
总结：JdbcRowSetImpl利用链如下：

1.2.25版本修复及绕过

将POM依赖改为

此时再执行POC，会抛出一个异常：

说明1.2.24版本的漏洞已修复，看看他的修复逻辑，根据异常堆栈，将断点打到ParserConfig的checkAutoType方法中844行：

发现黑名单中新增了很多条目，其中包括com.sun.包下的所有类，而JdbcRowSetImpl正是该包下的，所以此处就被过滤了。
虽然被拉黑了，但也不是不可绕过，观察checkAutoType后面的代码，在861行调用了TypeUtils.loadClass方法：

进入该方法内部第1089行有这样一段逻辑：

如果className以L开头，并且以;结尾，那么将掐头去尾得到中间的字符串，继续递归调用loadClass方法，那么我们就可以利用这点，将Payload改成这样：

注意@type后面的类型字符串前面加了L，后面加了;
再次debug：

此时className已经不以com.sun.开头，顺利绕过了黑名单，但是别高兴太早，

代码运行至881行的时候，还有一个autoTypeSupport的判断，这项配置在新版本中默认是关闭的，所以还会走到下面一行抛异常，所以我们需要在POC中显式的开启autoTypeSupport：

这样就顺利绕过了1.2.25版本的限制，不过在真实环境中autoTypeSupport通常不会显式开启，这项就很难绕过了。
未完待续。。。