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

This article to share with you is about Apache Shiro permission bypass vulnerability CVE-2020-11989 analysis is how, Xiaobian think quite practical, so share to everyone to learn, I hope you can read this article after harvest, not much to say, follow Xiaobian to see it.

Vulnerability Analysis 1.1 Introduction to Apache Shiro Components

Apache Shiro is a powerful and easy-to-use Java security framework that performs authentication, authorization, passwords, and session management. Using Shiro's easy-to-understand API, you can quickly and easily get any app, from the smallest mobile app to the largest web and enterprise app. Realm is built in to connect to a large number of secure data sources (aka directories), such as LDAP, relational databases (JDBC), text configuration resources like INI, and property files.

1.2 vulnerability description

Apache Shiro before 1.5.3, due to differences in the matching process between the Shiro interceptor and requestURI and the Web Framework interceptor, an attacker could construct a special http request that bypasses Shiro's authentication and gain unauthorized access to sensitive paths. There are two ways to exploit this vulnerability.

1.3 vulnerability analysis

First Attack

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

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

Enter org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver#getChain method, first get the request URI path.

In Shiro 1.5.2, there are some differences in how requestURI is handled, which is also where the vulnerability trigger lies. Shiro 1.5.2 uses a concatenation of request.getContextPath(), request.getServletPath(), request.getPathInfo(). Since the getServletPath() method decodes the requestURI once, the second url decoding is done later in the decodeAndCleanUriString method.

Back in the getChain method, iterate to get the interceptor's expression.

Here we focus on the/hello/* expression. The code goes to the pathMatches method, which eventually calls the org.apache.shiro.util.AntPathMatcher#doMatch method to match the incoming requestURI to the interceptor expression.

In the matching process, the interceptor expression and requestURI are converted from strings to arrays with/as separators, and whether the requestURI matches the interceptor expression is judged by matching the corresponding elements in the array circularly.

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

Finally, we return to the doMatch method and complete the subsequent matching by determining the number of elements in the expression array and the number of elements in the requestURI, and whether the expression contains **.

Follow up to Spring's URI handler code and go to the org.springframework.web.servlet. handle.AbstractHandlerMethodMapping#getHandlerInternal method to get the requestURI. Because Spring uses the getRequestURI() method when getting the requestURI, this method does not decode the URL. URL decoding is done only once at decodeAndCleanUriString.

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

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

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

Since Spring decodes the URL only once, it takes the partially decoded part as a whole, thus completing the matching of the interceptor expression to the requestURI.

Second Attack

The trigger point of the vulnerability is also Shiro's use of requestURI by concatenating request.getContextPath(), request.getServletPath(), request.getPathInfo() when fixing CVE-2020-1957 vulnerability.

uri = valueOrEmpty(request.getContextPath()) + "/" + valueOrEmpty(request.getServletPath()) + valueOrEmpty(request.getPathInfo());

When the getContextPath() method is called to get the context-path, the removePathParameter method is called to clear the semicolon and the semicolon to the next/middle data.

Next, enter the for loop to match whether candidate and conotext-path are the same.

If not, continue reading the next level of directory from the incoming URL until the condidate is the same as the context-path, returning the directory intercepted from the URL as the contextPath. Due to the context-path fetching method and the handling of URLs by the removePathparameters method, an attacker could request that the contextPath variable fetch an unexpected value with a semicolon.

When requestURI concatenation is performed, a requestURI with a semicolon in the root path is constructed. CVE-2020-1957 exploit principle, after decodeAndCleanUriString method, truncate reqeustURI after semicolon data, and return. This circumvents shiro permission control.

Review CVE-2020-1957 vulnerability

During URI normalization, the decodeAndCleanUriString method is called to decode the path and clean 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 that/a/b;/c becomes/a/b.

Continue to the Spring interceptor's decodeAndCleanUriString method.

From the code, you can see that Spring handles semicolons differently from Shiro. Spring will first get the position of the semicolon, and check whether there is/after the semicolon. If there is, record the position of/in the slashIndex variable, and concatenate the data before the semicolon with the data after/, so that/a/b;/c becomes/a/b/c. Returns the processed requestURI.

patch analysis

Comparing Shiro 1.5.2 to Shiro 1.5.3, code was added to the org.apache.shiro.web.util.WebUtils class to remove/at the end of requestURI.

The patch mainly optimizes the getPathWithinApplication method, and separately defines the getServletPath method and getPathInfo method. After patch fix, calling getPathWithinApplication method to get requestURI will only decode url once in getServletPath method, keeping the same number of url decodes as Spring gets requestURI. Defends against double url encoding bypass.

Get requestURI and directly call getServletPath method and getPathInfo method for concatenation. Since there is no need to concatenate with contextpath, it can defend against First Attack attack.

1.4 bug recurrence

Set up Apache Shiro vulnerability environment, use the constructed payload to attack, and finally bypass authorized access to unauthorized resources, the effect is as shown in the figure:

Normal access:

First Attack

Second Attack

II. Scope of impact

Currently affected Apache Shiro versions:

Apache Shiro < 1.5.3

III. REPAIR SUGGESTIONS

The latest version of Apache Shiro has fixed this vulnerability, please download the latest version affected by the vulnerability, download link: shiro.apache.org/download.html

The above is how the analysis of Apache Shiro permission bypass vulnerability CVE-2020-11989 is, Xiaobian believes that some knowledge points may be seen or used in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.