CVE-2019-12422 Shiro721反序列化漏洞

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/