Shiro 权限绕过的历史线（下）

0x5 CVE-2020-13933

0x5.1 漏洞简介

影响版本: shiro<1.6.0

类型: 权限绕过

其他信息:

这个洞跟CVE-2020-11989有点相似的地方就是就是利用URL解码的差异性来实现绕过。

CVE-2020-13933：Apache Shiro 权限绕过漏洞分析

0x5.2 漏洞配置

这个洞是不会受到Spring的版本限制的。

        <dependency>
            <groupId>org.apache.shiro</groupId>
            <artifactId>shiro-web</artifactId>
            <version>1.5.3</version>
        </dependency>
        <dependency>
            <groupId>org.apache.shiro</groupId>
            <artifactId>shiro-spring</artifactId>
            <version>1.5.3</version>
        </dependency>

Shiro配置,这个洞也是有限制的只能是ant的风格为单*号才可以:

map.put("/hello/*", "authc");

    @ResponseBody
    @RequestMapping(value="/hello" +
            "" +
            "/{index}", method= RequestMethod.GET)
    public  String hello1(@PathVariable String index){
        return "Hello World"+ index.toString() + "!";
    }

0x5.3 漏洞演示

访问302，然后poc:

/hello/%3bluanxie

看到这个POC的时候，我当时就觉得我前面分析两个洞的时候，是不是漏了什么关键点没去分析。

然后最让我头疼的的是，为什么需要对;要编码才能利用成功,下面我们通过分析来复盘我们前两次学习过程出现的问题。

0x5.4 漏洞分析

断点依然是在上一次的修补点:

org.apache.shiro.web.util.WebUtils#getPathWithinApplication

这里我们逐步跟进去，上一次我没跟removeSemicolon, 因为从函数名这个其实就是Shiro一直以来的操作，就是去除;号后面的内容,然后normalize,这个并没有很大问题。

然后函数返回的结果是这个:

本来应该获取到uri的是/hello/,然后因为最早的那个shiro-682的洞，所以会执行去掉末尾的斜杆。

            if (requestURI != null && !"/".equals(requestURI) && requestURI.endsWith("/")) {
                requestURI = requestURI.substring(0, requestURI.length() - 1);
            }

变成了:/hello

首先通过，Iterator var6 = filterChainManager.getChainNames().iterator()获取了我们定义的filter，进入do循环逐个取值给pathPattern

其实都没必要去看这个算法怎么做匹配的，因为/hello/*本来就不会匹配/hello,

那么这样,如果是这样呢,map.put("/hello/", "authc");,emm,在取出来进行匹配的时候，

就会被去掉/,那么我来多几个呗。

 map.put("/hello//", "authc");

稍微绕过了

这个时候我们就可以回头去读一下Shiro的匹配算法了。

首先是如果pattern和path开头不一样直接false

然后就是StringUtils.tokenizeToStringArray分割字符串得到数组

然后一个循环，比较，如果出现某数组字符串不匹配，除开**就会返回false

只要没有**出现的话，且字符串数组=1，就没那么复杂的解析过程，直接返回
pattern.endsWith(this.pathSeparator) ? path.endsWith(this.pathSeparator) : !path.endsWith(this.pathSeparator);
如果pattern是以/结尾的话，那么是 True,返回path.endsWith(this.pathSeparator),这个时候path不是以/结尾的，所以最终也不匹配。

如果是/*的话，字符串数组>1,

那么最终会进入

这个过程说明,/hello/* 可以匹配/hello/,但是没办法匹配到/hello,然后shiro又做了去除/处理，emmm，根本不可能构造出/hello/，构造出来也没啥可用的

但是如果是,/hello/**,这里就不返回false，直接跳到下面了，最终会返回True，没办法绕过。说明/hello/**可以匹配到/hello

其实来到这里我们就明白了，第一步通过%3b解码成;,然后以前的洞删掉了/,导致了bypass Shiro。

如果我们不用%3b,而是直接

那么;直接会被request.getServletPath()处理掉，从而变成了/hello/aa,被/hello/**这种ant所匹配，导致第一层都没办法绕过。(这个其实就是cve2020-1957的绕过思路呀！肯定是没办法的呀)

0x5.5 漏洞修复

说实话，关于这个洞，我当时思考的修复方式是，好像只能是去屏蔽%3b这个字符了，感觉真的很无奈。

diff:https://github.com/apache/shiro/compare/shiro-root-1.5.3…shiro-root-1.6.0

发现确实新增InvalidRequestFilter.java，但是具体作用不知道在哪里起的，

然后在这个文件被调用:

support/spring/src/main/java/org/apache/shiro/spring/web/ShiroFilterFactoryBean.java

这个文件新增了一个/**匹配没有设置filter类型，用于解决失配的时候还是可以调用默认的过滤器

然后输入特殊字符的时候，过滤器会进行过滤，关于是如何进行过滤的，值得详细写一篇文章，这里我们只要知道它的修复方式，是做了特殊字符，存在就抛出400就行了。

return !this.containsSemicolon(uri) && !this.containsBackslash(uri) && !this.containsNonAsciiCharacters(uri);

0x6 CVE-2020-17510

0x6.1 漏洞简介

影响版本: shiro<1.7.0

类型: 权限绕过

其他信息:

中风险，需结合Spring使用环境，危害偏低一点

0x6.5 漏洞分析

diff:https://github.com/apache/shiro/compare/shiro-root-1.6.0…shiro-root-1.7.0

改动:

这个洞我发现他增加了request.getPathInfo的方式检测字符，而在Spring-boot默认这个值是空，但是在其他情况，这个值可控的话，我们可以在这里插入;和..实现绕过，结合前面的分析，可以知道URI是由request.getServletPath + request.getPathInfo得到的，所以是可以去绕过的，不过由于这个洞鲜少人讨论，作者也没去公开，这个利用方式研究价值很低，笔者对此没有很大兴趣，所以就没去折腾场景来利用，欢迎其他师傅感兴趣地话继续研究。

0x7 CVE-2020-17523

0x7.1 漏洞简介

影响版本: shiro<1.7.0

类型: 权限绕过

其他信息:当Apache Shiro与Spring框架结合使用时，在一定权限匹配规则下，攻击者可通过构造特殊的 HTTP 请求包绕过身份认证。

0x7.2 漏洞配置

        <dependency>
            <groupId>org.apache.shiro</groupId>
            <artifactId>shiro-web</artifactId>
            <version>1.6.0</version>
        </dependency>
        <dependency>
            <groupId>org.apache.shiro</groupId>
            <artifactId>shiro-spring</artifactId>
            <version>1.6.0</version>
        </dependency>

这个漏洞我建议spring-boot用2.4.5的，这个版本默认会开启全路径匹配模式。

当Spring Boot版本在小于等于2.3.0.RELEASE的情况下，alwaysUseFullPath为默认值false，这会使得其获取ServletPath，所以在路由匹配时相当于会进行路径标准化包括对%2e解码以及处理跨目录，这可能导致身份验证绕过。而反过来由于高版本将alwaysUseFullPath自动配置成了true从而开启全路径，又可能导致一些安全问题