shiro框架漏洞

2016年，架漏JR当时还是架漏个安全圈的新人，第一次在客户内网看到Shiro的架漏登录页面——那个经典的蓝色默认favicon和/login.jsp路径，他当时没意识到这东西后来会变成渗透测试里的架漏高频突破口。Shiro是架漏Apache旗下的Java安全框架，做认证、架漏授权、架漏会话管理和加密，架漏国内用得非常广，架漏尤其是架漏后台管理系统。问题恰恰出在它“太方便”了。架漏

最出名的架漏是Shiro-550，也就是架漏CVE-2016-4483那个反序列化漏洞。根因在RememberMe功能：Shiro会把用户身份序列化后用AES加密，架漏再Base64编码塞进Cookie里。架漏但早期版本硬编码了一个默认AES密钥——kPH+bIxk5D2deZiIxcaaaA==。攻击者拿到这个密钥，就能自己构造恶意序列化数据，加密后发给服务器，服务器解密时直接触发反序列化，RCE就这么来的。说白了，加密成了摆设，因为钥匙挂在门上。

实际打起来是什么样？JR印象最深的一次，目标系统登录框下面有个“记住我”勾选框。他抓包看到rememberMe=deleteMe，心里就有数了。用ysoserial生成CommonsCollections链的payload，AES加密，替换Cookie，发送。等了几秒，DNSLog平台收到了回显。整个过程不需要任何账号密码，未授权就能打。这种漏洞的杀伤力在于，它不依赖业务逻辑，只要Shiro版本在受影响范围内，且classpath里有可利用的gadget链，基本就是一键getshell。

后来Shiro在1.2.5版本换了默认密钥生成方式，但问题没完。因为很多开发人员图省事，自己写配置类时又硬编码了一个自定义密钥，或者从网上抄了一段“最佳实践”代码，结果密钥还是公开的。JR在GitHub上搜过setCipherKey，能翻出一堆带着固定密钥的ShiroConfig.java。这种“换汤不换药”的操作，让Shiro-550的变种至今还活跃在各类攻防演练里。

另一个常被忽略的是Shiro-721，CVE-2019-12422。它利用Padding Oracle攻击，在不知道密钥的情况下伪造RememberMe Cookie。条件更苛刻一些，需要有效登录后的Cookie作为基础，但危害一样大。JR觉得这个漏洞有意思的地方在于，它暴露了Shiro在加密实现上的设计缺陷——CBC模式下的填充校验反馈了足够的信息，攻击者可以逐字节爆破。安全圈有句话：加密不等于安全，Shiro-721就是活例子。

防守方怎么办？JR给的建议很直接：第一，升级到1.7以上版本，别用默认密钥；第二，如果业务不需要RememberMe，直接在配置文件里关掉；第三，实在要用，密钥用随机生成的长字符串，别提交到代码仓库；第四，WAF加规则拦截rememberMe字段里的异常Base64长度和特征。他见过一个甲方，内网几百个系统，扫描器一跑，三十多个Shiro后台存在550漏洞，修复方案发下去，三个月后复测还有一半没改。漏洞本身不复杂，复杂的是人。

Shiro的漏洞史其实是个缩影：框架为了降低使用门槛，把安全决策替开发者做了，但默认值往往是最危险的。JR现在看到Shiro，第一反应不是登录框，而是去翻Cookie里有没有那个Base64串。习惯成自然了。

很赞哦!（28）