Apache Shiro 身份验证绕过漏洞 (CVE-2020-11989)
Shiro这个框架,我相信各位经常挖洞的师傅都不会陌生,因为这个框架有着臭名昭著的反序列化漏洞(CVE-2016-4437),攻击者可以使用Shiro的默认密钥伪造用户COOKIE,触发Java反序列化漏洞,进而在目标机器上执行任意命令。
但是,今天我们要讲的是Shiro身份验证绕过漏洞,这个漏洞已经出来大半年了,只是之前一直觉得作用并不明显(这是因为自己太菜了),最近正好遇到一次,遂之记录一下(开学前的最后一篇,开学后估计没时间更新了,大家看我名字应该知道了)。
0x00漏洞详情
Apache Shiro是一个强大且易用的Java安全框架,它可以用来执行身份验证、授权、密码和会话管理。目前常见集成于各种应用中进行身份验证,授权等。在Apache Shiro 1.5.3之前的版本,将Apache Shiro与Spring控制器一起使用时,特制请求可能会导致身份验证绕过。
关键字:身份验证、Apache Shiro 1.5.3、Spring控制器
0x01漏洞影响范围
- Apache Shiro <1.5.3
- Spring 框架中只使用 Shiro 鉴权
0x02漏洞分析
- Apache Shiro权限绕过漏洞分析(CVE-2020-11989)
- Shiro权限绕过漏洞详细分析
0x03漏洞实战复现(这是第一种方法&#xff1a;url开头为/;
关键词)
当我们在进行渗透时&#xff0c;若是遇到了shiro站&#xff0c;但站点已经将反序列化漏洞修复的时候&#xff0c;不妨试一试shiro权限绕过&#xff0c;有时是会有惊喜的&#xff01;
在挖洞的过程中&#xff0c;看到了我的burp发出警报&#xff0c;看了一眼&#xff0c;发现原来是Shiro框架。
&#xff08;后来瞄了一下这个页面&#xff0c;熟悉感扑面而来。&#xff09;
测试了一波弱口令但没有成功之后&#xff0c;立马掏出我珍藏已久的Shiro反序列化利用工具梭哈一波&#xff01;
很遗憾&#xff0c;Shiro反序列化漏洞已经修复了&#xff0c;难道我就要败在这里了吗&#xff1f;&#xff1f;
突然想起了之前的Shiro权限绕过这个漏洞&#xff0c;于是查阅资料&#xff0c;复现一波
在Shiro框架的网站后面拼接/;/查看页面是否正常
这里我们拼接到刚刚的网站上
http://xxxxxx.com/;/login
查看网页是否正常
好家伙&#xff0c;页面正常回显&#xff0c;并且连验证码都不需要了。
这时候&#xff0c;一个疑问出现了&#xff0c;虽然Shiro权限绕过成功复现了&#xff0c;但是如何利用这个权限绕过打开局面呢&#xff1f;
一个思路突然出现了&#xff0c;我们可以利用fofa搜寻同样类型站点&#xff0c;利用弱口令进入同类型的站点后台&#xff0c;收集一波后台各种接口的URL,利用Shiro权限绕过的漏洞&#xff0c;将这些URL拼接在目标站点&#xff0c;达到未授权访问的目的&#xff01;
说干就干&#xff0c;利用弱口令进入了一个同类型的站点后台&#xff0c;收集到了一波接口的URL。
接下来就要拼接到目标站点了。
http://xxxxxx.com/;/xxxxx/xxxx/xxxx
成功访问到这些敏感的功能点了。
下一步&#xff0c;找到上传功能点&#xff0c;上传绕过&#xff0c;即可Getshell。
另外一种&#xff1a;uri中包含%25%32%66关键词
如果请求/hello/aaa
那么将会被禁止&#xff1a;
但是这里我们可以通过url双编码的方式来绕过&#xff1a;
/ -> %2f ->%25%32%66
GET /hello/a%25%32%66a HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0
Accept: text/html,application/xhtml&#43;xml,application/xml;q&#61;0.9,*/*;q&#61;0.8
Accept-Language: zh-CN,zh;q&#61;0.8,zh-TW;q&#61;0.7,zh-HK;q&#61;0.5,en-US;q&#61;0.3,en;q&#61;0.2
Connection: close
Upgrade-Insecure-Requests: 1
成功绕过身份验证。
当然这个场景下需要一些限制条件&#xff0c;首先权限ant风格的配置需要是*
而不是**
&#xff0c;同时controller需要接收的request参数(&#64;PathVariable)的类型需要是String&#xff0c;否则将会出错。
其中中间的代码分析过程请看这篇文章&#xff1a;https://xlab.tencent.com/cn/2020/06/30/xlab-20-002/
总结一下&#xff0c;当进入应用后我们的请求页面被解析成/hello/a%2fa
&#xff0c;所以它可以进入到spring controller中的/hello/{name}
&#xff0c;但是因为shiro再次做了url解码&#xff0c;导致判断的uri成为了/hello/a/a
它不属于我们配置的权限判断地址/hello/*
。
此绕过核心原理可以归因为shiro与spring对RFC标准实现的差异。
转载http://www.0dayhack.net/index.php/554/