vulhub shiro漏洞复现 | CVE-2010-3863、CVE-2016-4437、CVE-2020-1957漏洞复现（详细图解）

本文会先介绍漏洞原理、影响版本等理论知识，再进行漏洞复现，如果想直接看漏洞复现的，可直接戳右侧/下方标题跳转。

整体内容：

目录

CVE-2016-4437：Apache Shiro 1.2.4反序列化漏洞/shiro550

漏洞原理

影响版本

漏洞复现

1.环境启动

2.利用工具getshell

CVE-2010-3863：Apache Shiro 认证绕过漏洞

漏洞原理

影响版本

漏洞复现

1.环境启动

2.尝试访问登录页面

3.构造恶意请求进行权限绕过

CVE-2020-1957：Apache Shiro 认证绕过漏洞

漏洞原理

影响版本

漏洞复现

1.环境启动

2.尝试访问登录页面

3.构造恶意请求进行权限绕过

---

CVE-2016-4437：Apache Shiro 1.2.4反序列化漏洞/shiro550

漏洞原理

属于shiro550漏洞。Apache Shiro是一款开源安全框架，提供身份验证、授权、密码学和会话管理。Shiro框架直观、易用，同时也能提供健壮的安全性。

Apache Shiro 1.2.4及以前版本中，加密的用户信息序列化后存储在名为remember-me的Cookie中。攻击者可以使用Shiro的默认密钥伪造用户Cookie，触发Java反序列化漏洞，进而在目标机器上执行任意命令。

shiro默认使用CookieRememberMeManager，对rememberMe的cookie做了加密处理，在CookieRememberMeManaer类中将cookie中rememberMe字段内容先后进行序列化、AES加密、Base64编码操作。在识别身份的时候，需要对Cookie里的rememberMe字段解密。根据加密的顺序可以推断出解密的顺序为获取cookie-base64解码-AES解密-反序列化。

影响版本

Apache Shiro <= 1.2.4

漏洞复现

判断一个页面的登录是否使用了shiro框架进行身份验证、授权、密码和会话管理。

判断方法：勾选记住密码选项后，点击登录，抓包，观察请求包中是否有rememberme字段，响应包中是否有Set-cookie:rememberMe=deleteMe字段。类似于下图这样。

只要响应包中出现rememberMe=deleteMe字段就说明存在漏洞。这样说片面的，如果出现rememberMe=deleteMe字段应该是仅仅能说明登录页面采用了shiro进行了身份验证而已，并非直接就说明存在漏洞

• 未登录的情况下，请求包的cookie中没有rememberMe字段，返回包set-Cookie里也没有deleteMe字段登录失败的话，不管有没有勾选RememberMe字段，返回包都会有 rememberMe= deleteMe 字段
• 不勾选RememberMe，登录成功的话，返回包set-Cookie里有rememberMe=deleteMe字段。但是之后的所有请求中Cookie都不会有RememberMe字段
• 勾选RememberMe，登录成功的话，返回包set-Cookie里有rememberMe=deleteMe字段，还会有remember字段，之后的所有请求中Cookie都会有rememberMe字段
• 或者可以在cookie后面自己加—个rememberMe=1,看返回包有没有rememberMe= deleteMe

1.环境启动

cd vulhub-master/shiro/CVE-2016-4437/
docker-compose up -d
docker ps -a

2.利用工具getshell

工具地址：https://github.com/j1anFen/shiro_attack

CVE-2010-3863：Apache Shiro 认证绕过漏洞

漏洞原理

Apache Shiro是一款开源安全框架，提供身份验证、授权、密码学和会话管理。Shiro框架直观、易用，同时也能提供健壮的安全性。

在Apache Shiro 1.1.0以前的版本中，shiro 进行权限验证前未对url 做标准化处理，攻击者可以构造/、//、/./、/…/ 等绕过权限验证。

影响版本

shiro < 1.1.0和JSecurity 0.9.x

漏洞复现

1.环境启动

cd vulhub-master/shiro/CVE-2010-3863/
docker-compose up -d
docker ps -a

2.尝试访问登录页面

直接请求访问/admin，无法访问，将会被重定向到登录页面。抓包查看重定向过程：

3.构造恶意请求进行权限绕过

构造恶意请求/./admin，即可绕过权限校验，访问到管理页面。抓包查看过程：

注：

1.必须进行抓包、改包操作，方可复现成功。浏览器直接地址栏直接输入构造的恶意请求，无法成功。

2.此漏洞也可使用上述shrio一键利用工具进行复现。

CVE-2020-1957：Apache Shiro 认证绕过漏洞

漏洞原理

我们需要分析我们请求的URL在整个项目的传入传递过程。在使用了shiro的项目中，是我们请求的URL(URL1),进过shiro权限检验(URL2)，最后到springboot项目找到路由来处理(URL3)

漏洞的出现就在URL1，URL2和URL3 有可能不是同一个URL，这就导致我们能绕过shiro的校验，直接访问后端需要首选的URL。本例中的漏洞就是因为这个原因产生的。

Shiro框架通过拦截器功能来对用户访问权限进行控制，如anon, authc等拦截器。anon为匿名拦截器，不需要登录即可访问；authc为登录拦截器，需要登录才可以访问。

影响版本

Apache Shiro < 1.5.2

漏洞复现

1.环境启动

cd /vulhub-master/shiro/CVE-2020-1957
docker-compose up -d
docker-compose ps

2.尝试访问登录页面

访问页面

抓包

URL改为/admin会自动跳转到login登录页面

3.构造恶意请求进行权限绕过

URL改为/xxx/...;/admin/绕过了登录，直接访问成功！

/xxx/...;/admin/

（谢谢大家！欢迎提出批评和建议！你的支持是我持续更新的巨大动力！）