在Shiro反序列化漏洞修复的过程中，如果仅进行Shiro的版本升级，而没有重新生成密钥，那么AES加密的默认密钥扔硬编码在代码里，仍然会存在反序列化风险。

01、漏洞案例

本案例引用的shiro版本已是目前最新的1.8.0。尝试访问系统进行登录，抓包获取参数特征，包含xxx_rememberMe=deleteMe字段。

注意：在Shiro1.4.2版本后，Shiro的加密模式由AES-CBC更换为 AES-GCM，Shiro高版本下的漏洞利用，就需要考虑加密模式变化的情况。另外，这里cookie传递的参数是自定义的，而不是常见的rememberMe，这也是需要注意的地方。

02、漏洞利用

为了减少手工构造生成反序列化数据的繁琐，这里，我们使用一个Shiro反序列化利用工具，python编写，而且作者增加了AES-GCM加密方式的漏洞利用支持，可以很方便地进行修改和参数构建，

Github项目地址：

https://github.com/Ares-X/shiro-exploit.git

首先，我们需要修改python脚本参数，将rememberMe 替换为 xxx_remeberme，使参数能够正常传递。

利用脚本来爆破Shiro key：

python shiro-exploit.py check -u http://10.xxx.xxx.72/shiro-cas.shtml

成功获取到了Shiro key。

发送回显Payload，获取命令执行结果。

python shiro-exploit.py echo -g CommonsBeanutils2  -v 2 -k 3AvVhmFLUs0KTA3Kprsdag== -c whoami -u http://10.xxx.xxx.72/shiro-cas.shtml

修改python脚本设置代理，在requests使用代理proxies，增加proxies={'http': 'http://' + '127.0.0.1:8888'}。

这样就可以将流量引入BurpSuite，抓取HTTP数据包，手动利用查看回显。

以上便是Shiro高版本下默认密钥的漏洞利用过程，So，修复Shiro默认密钥漏洞，除了升级shiro至最新版本，一定要注意生成新的密钥替换。

记录个有意思的事情，之前有个内部系统确认过Shiro版本和密钥都有更换，但后来还是被检测到存在漏洞，一度有点怀疑人生。找开发一起排查了一下，原来有两台服务器负载，其中一台是修复了，还有一台旧服务器被遗忘了。我复测的时候是修复的状态，别人一扫描，漏洞还存在，直接泪崩。