漏洞详情

Shiro组件

Apache Shiro是一个强大且易用的Java安全框架执行身份验证、授权、密码和会话管理。使用Shiro的易于理解的API,可以快速、轻松地获得任何应用程序,从最小的移动应用程序到最大的网络和企业应用程序。内置了可以连接大量安全数据源(又名目录)的Realm,如LDAP、关系数据库(JDBC)、类似INI的文本配置资源以及属性文件等。

漏洞描述

Apache Shiro 1.5.2之前的版本,由于Shiro拦截器和requestURI的匹配流程与Web框架的拦截器的匹配流程有差异,攻击者构造一个特殊的http请求,可以绕过Shiro的认证,未授权访问敏感路径。

此漏洞有两种攻击方式:

第一种攻击方式适用于Shiro < 1.5.0版本。

由于Shiro 1.5.0版本修复补丁考虑不全面,导致补丁绕过,出现了第二种攻击方式,适用于Shiro < 1.5.2版本。

漏洞分析

Shiro 1.4.2 -> 1.5.0 版本补丁分析

对比Shiro 1.4.2与Shiro 1.5.0版本的改动,Shiro在org.apache.shiro.web.filter.PathMatchingFilter类中添加了删除requestURI结尾的/的代码。

Shiro 1.4.2 代码分析

传入的payload首先被服务器接收,并传送给Shiro拦截器处理(org.apache.shiro.web.servlet.OncePerRequestFilter#doFilter方法作为入口)。

调用createSubject方法创建Subject,并调用execute方法进入Shiro FilterChain中。

进入org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver#

getChain方法中,首先获取请求URI路径,之后迭代获取拦截器的表达式。

这里重点关注/hello/*表达式。代码进入pathMatches方法,最终调用org.apache.shiro.util.AntPathMatcher#doMatch方法进行传入的requestURI与拦截器表达式进行匹配。

匹配过程中,分别将拦截器表达式与requestURI以/作为分隔符进行字符串到数组的转换,通过循环匹配数组中对应的元素,判断requestURI是否符合拦截器表达式匹配形式。

如果表达式中存在通配符*,会将containsStar标志位赋值为true,进入 else if (patIdxEnd == 0)判断条件,返回true。

继续跟进代码,在requestURI与拦截器表达式匹配结束后,还会进行一次判断,而漏洞产生的原因也是由于判断的条件。如果Shiro拦截器表达式不以/结尾,且requestURI以/结尾,判断代码将返回false表示匹配失败,从而绕过Shiro认证

跟进到Spring处理URI的代码,进入org.springframework.web.servlet.handler.AbstractHandlerMethodMapping#getHandlerInternal方法,获取requestURI。

img

进入lookupHandlerMethod方法,调用addMatchingMappings方法,获取Spring拦截器。

img

img

进入org.springframework.web.servlet.mvc.condition.PatternsRequestCondition#getMatchingCondition方法进行调用doMatch方法进行requestURI和拦截器表达式的匹配。

img

img

Spring拦截器匹配流程和Shiro大致相同,都是将字符串转换为数组进行匹配。

img

img

由于Spring多了一个环节,在检测拦截器表达式与requestURI结尾是否为/之后,并没有直接返回false。而是将拦截器表达式结尾添加/,并继续进行

path.startsWith(this.pathSeparator) != pattern.startsWith(this.pathSeparator)

测试,从而完成了拦截器表达式与requestURI的匹配。

img

Shiro 1.5.1 -> 1.5.2 版本补丁分析

对比Shiro 1.5.1与Shiro 1.5.2版本的改动

img

Shiro 1.5.2版本中,在进行decodeAndCleanUriString方法之前会先进行URI解析,调用request.getServletPath()和request.getPathInfo()获取ServletPath和PathInfo并进行路径拼接。

*Shiro 1.5.1代码分析*

Shiro 1.5.0 - 1.5.1在认证过程中基本没有变化,主要分析一下二次绕过的利用点。还是以org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver#getChain作为起点。

img

在获取requestURI时,依旧会在getPathWithinApplication方法中调用getRequestUri方法进行requestURI的解析并获取,但是在URI正规化处理时,先调用decodeAndCleanUriString方法进行路径的解码,并清理URI。

img

img

进入decodeAndCleanUriString方法,发现此方法会以分号将传入的URI进行截断,并将分号以及分号后面的数据进行清空,返回分号前面的URI数据,从而让/a/b;/c变为/a/b。

继续跟进到Spring拦截器的decodeAndCleanUriString方法中。

img

img

从代码中可以发现,Spring对于分号的处理方式与Shiro不同,Spring会先获取分号的位置,并检测分号后是否存在/,如果有,将/的位置记录在slashIndex变量中,并将分号前的数据与/之后的数据进行拼接,从而让/a/b;/c变为/a/b/c。返回处理后的requestURI。

由于Spring与Shiro的decodeAndCleanUriString方法不同,攻击者可以使用分号构造路径,绕过Shiro认证,并可以匹配Spring的动态控制器。

当Shiro 的Ant格式的pathPattern 中的的通配符是不支持匹配路径的,所以/hello/ 不能成功匹配/hello/1/ ,也就不会触发authc拦截器进行权限拦截。从而成功绕过了Shiro拦截器,而后再进入到spring拦截器中,/hello/1/与/hello/1能获取到相同的资源。

漏洞复现

直接请求管理页面/admin/,无法访问,将会被重定向到登录页面:

构造恶意请求/xxx/..;/admin/,即可绕过权限校验,访问到管理页面:

参考文章

https://www.freebuf.com/vuls/249112.html

评论