Shiro反序列化漏洞检测：别等被打了才想起补课

某甲方内网，序列一台部署着Shiro框架的化漏Java应用，管理员登录后台时一切正常。洞检三天后，序列安全团队发现服务器上多了一个叫c3p0-config.xml的化漏陌生文件——攻击者早就通过反序列化漏洞拿到了RCE，连日志都被清洗得干干净净。洞检这场景不新鲜，序列但每次发生都让人后背发凉。化漏

Shiro的洞检rememberMe功能是漏洞核心。它把用户身份序列化后加密进Cookie，序列可加密密钥如果是化漏硬编码的默认值（比如kPH+bIxk5D2deZiIxcaaaA==），攻击者就能伪造任意Cookie。洞检更麻烦的序列是，即便密钥被改，化漏某些老版本还存在Padding Oracle攻击面。洞检检测这事，别指望等出事了再复盘。

最直接的检测方式，是主动发一个畸形Cookie。构造rememberMe=deleteMe的请求，观察响应头——如果返回Set-Cookie: rememberMe=deleteMe，基本能确认目标用了Shiro。但这只算“指纹识别”，离漏洞利用还差得远。真正要验证是否存在反序列化风险，得走下面三步。

第一步：密钥爆破。用公开的Shiro密钥字典（GitHub上一搜一大把）生成恶意序列化Payload，分别塞进Cookie发送。响应时间出现明显差异（比如某密钥触发异常导致延迟），说明密钥命中。这里有个坑：有些WAF会拦截包含java关键字的请求，得用CommonsBeanutils或JRMPClient这类不依赖明文类的链子绕过。

第二步：检测链依赖。光有密钥不够，还得看目标Classpath里有没有可利用的Gadget。手动试错效率太低，推荐用ysoserial配合ShiroExploit这类工具，自动探测CommonCollections、CommonBeanutils等常见链。判断依据很简单：如果发送URLDNS链（无依赖，仅触发DNS解析），你在自己的DNSLog服务器上收到查询记录，说明目标能反序列化外部输入——此时漏洞已实锤。

但检测不等于利用。生产环境里，我见过太多团队跑完工具就交差，结果漏了版本差异。比如Shiro 1.7.1修复了CVE-2020-1957的权限绕过，但反序列化问题在1.8.0才彻底解决。工具扫不出“版本不匹配”这种逻辑漏洞，得手动抓包看rememberMe的加密模式——如果Cookie长度异常（正常约180字节，恶意Payload可能超过500字节），哪怕密钥没爆出来，也值得警惕。

还有种隐蔽情况：目标用了自定义RememberMeManager，默认密钥被替换成随机值，但CipherService的AES模式是CBC且未设置IV。这种场景下，攻击者虽无法直接伪造，却能通过Padding Oracle逐字节解密Cookie内容。检测方法更刁钻——发送大量填充错误的Cookie，观察响应中deleteMe出现频率是否与正常请求不同。这需要写脚本统计，别指望手工试。

最后说点实战心得。检测Shiro漏洞，别迷信单一工具，最好把Cookie的HMAC-SHA1签名算法也纳入检查——有些魔改版Shiro会用MD5代替，直接降级了安全性。另外，如果目标部署了Nginx反向代理，记得在请求头里加X-Forwarded-For模拟内网IP，否则某些基于IP白名单的防护可能干扰检测结果。

检测完，别急着写报告。先把Cookie的Max-Age属性翻出来——如果设置为-1（会话Cookie），说明rememberMe功能默认开启，风险等级直接拉高。你手里那份“修复建议”模板，可能只写了“升级到最新版”，但现实是很多老旧系统根本升不动。那就得考虑用Filter拦截恶意请求，或者干脆在网关层把rememberMe置空。安全这行，能落地的方案才叫方案。