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

This article introduces how to conduct Shiro permissions to bypass CVE-2020-1957 vulnerability analysis, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Preface

On March 23, 2020, Shiro developer Brian Demers posted a post in the user community reminding shiro users to make a security update. This update contains three fixes, including a fix for the Shrio license bypass vulnerability numbered CVE-2020-1957. The vulnerability affects shiro version 1.5.2 and below.

Analysis process SHIRO-682

According to the test cases for the PathMatchingFilter class in commit submitted by Shiro developers in version 1.5.2, you can associate directly to JIRA issueSHIRO-682, which was fixed in version 1.5.0. The update in version 1.5.2 is a bypass fix.

SHIRO-682 fixed the problem of uri = uri +'/ 'bypassing Shiro protection in spring framework. Then the following description clearly describes the cause of the error.

In the Spring web project, both the request URI/resource/menus and / resource/menus/ have access to the server's resources.

However, the URL path expression pathPattern in Shiro can correctly match / resource/menus, but it does not match / resource/menus/, correctly so that the filter chain does not match correctly, thus bypassing the protection mechanism of Shiro.

Shiro interceptor

The Shiro framework controls and intercepts user access rights through the interceptor function. The common interceptors in Shiro are interceptors such as anon,authc.

1.anon is an anonymous interceptor, which can be accessed without login. It is generally used for static resources or mobile interfaces.

2.authc is a login interceptor, which requires login authentication to access resources.

The user can write an interceptor in Shiro.ini that matches the URL configuration that will intercept the matching URL and execute the response. Thus, the access control of URL is realized, and the URL path expression is usually in ANT format. In the following configuration, Shiro will not determine the login of the / index.html home page when visiting it, and the anon interceptor does not need to log in to access it. For interfaces such as / user/xiaoming / user/xiaogang, the authc interceptor will judge their login, and only with login authentication can they access resources.

[urls] / index.html = anon/user/** = authc

Shiro's URL path expression is in Ant format, and path wildcards support? *.

Match one character *: match zero or more strings * *: match zero or more paths in the path

Where * means to match zero or more strings, and / * can match / hello, but not / hello/ because * wildcards cannot match the path. Assuming that authc interceptor is set on the / hello interface, access to / hello will be judged. If the requested URI is / hello/, the path expression of / * URL will not match correctly and be released. Then go to the spring (Servlet) interceptor, and the resources accessed by URL in the form of / hello and / hello/ in spring are the same.

Loophole recurrence

Knowing the above, it is easy to reproduce the vulnerabilities, which mainly refer to the open source demo on the web.

1. Download the demo code shiro-basic.

two。 Import idea

3.Shiro version 1.4.2

Org.apache.shiroshiro-web1.4.2org.apache.shiroshiro-spring1.4.2

4. Modify ShiroConfig configuration file to add intercept rules for authc interceptor

@ Bean ShiroFilterFactoryBean shiroFilterFactoryBean () {ShiroFilterFactoryBean bean = new ShiroFilterFactoryBean ();... / / map.put ("/ *", "authc"); map.put ("/ hello/*", "authc"); bean.setFilterChainDefinitionMap (map); return bean;}

5. Modify the routing controller method

GetMapping ("/ hello/ {currentPage}") public String hello (@ PathVariable Integer currentPage) {return "hello";}

6. Start the application

If you visit the / hello/1 interface, you can see that it has been intercepted by the authc interceptor and will jump to the login interface to log in.

The access / hello/1/, successfully bypassed the authc interceptor and got the resource.

Causes of loopholes

The initial cause of the vulnerability can be located under the getChain function of PathMatchingFilterChainResolver, which matches the input URL according to the url path expression configured in URL path matching to determine whether it matches the interceptor. If the match is successful, the interceptor execution chain of the response will be returned and the ShiroFither will perform permission operations.

The matching of the URL path expression and the input URL is mainly carried out through the pathMathches function.

The pathMatches function will eventually call doMatch in the shiro.util.AntPathMatcher class to match pathPattern and requestURI in ant format.

/ / pathMatches:135, PathMatchingFilterChainResolver (org.apache.shiro.web.filter.mgt) protected boolean pathMatches (String pattern, String path) {PatternMatcher pathMatcher = this.getPathMatcher (); return pathMatcher.matches (pattern, path);}

DoMatch:109, AntPathMatcher (org.apache.shiro.util), when the * wildcards in Shiro's Ant format pathPattern do not support matching paths, so / hello/* cannot successfully match / hello/1/, will not trigger the authc interceptor to intercept permissions. Thus successfully bypassing the Shiro interceptor, and then entering the spring interceptor, / hello/1/ and / hello/1 can get the same resources.

Vulnerability repair

The vulnerability was submitted by Chinese developers on the ShiroGitHub project on March 25, 2019, and the branch code 589f10 was PR to add the vulnerability repair code. Finally, the branch code was merged in version 1.5.0, and the merger time was November 20, 2019.

Fix version 1.5.0

Version 1.5.0 fixes from the PR code submitted by tomsun28. The location of the code fix is pathsMatch:125, PathMatchingFilter (org.apache.shiro.web.filter). The fix method is to determine whether the requestURI ends with /, and if it ends with /, the trailing / symbol is removed and compared with the URL expression.

That is, when requestURI is / hello/1/ and other URI ending with /, the last / sign will be cleared, and then the URL path will be matched.

≤ version 1.5.1 Bypass

Observe the newly added test cases in version 1.5.2.

Switch the test version to 1.5.1, and then extract payload from the above test case to bypass it.

In version 1.5.1, adding / still jumps directly to login.

Bypass payload,/fdsf;/../hello/1, successfully bypass.

The problem can also be located in the acquisition of requestURI in the getChain function. As shown in the following figure, the requestURI obtained by this.getPathWithinApplication (request) is / fdsf instead of the / fdsf;/../hello/1 we entered, which causes the subsequent URI path pattern matching to return False, thus bypassing the shiro interceptor again.

The getRequestUri function in WebUtils (org.apache.shiro.web.util) is called in the getPathWithinApplication function to get the RequestUri.

Public static String getRequestUri (HttpServletRequest request) {String uri = (String) request.getAttribute ("javax.servlet.include.request_uri"); if (uri = = null) {uri = request.getRequestURI ();} return normalize (decodeAndCleanUriString (request, uri));}

In the RequestUri function, the decodeAndCleanUriString function is finally called to clean the URI.

Private static String decodeAndCleanUriString (HttpServletRequest request, String uri) {uri = decodeRequestString (request, uri); int semicolonIndex = uri.indexOf (59); / / get the position of the sign return semicolonIndex! =-1? Uri.substring (0, semicolonIndex): uri;}

If the; sign exists in the URI, all characters following it are deleted. / fdsf;/../hello/1/ eventually becomes / fdsf.

1.5.2 version fix

It is fixed in version 1.5.2, and the way to obtain requestURI is changed from request.getRequestUri to ContextPath,ServletPath,PathInfo of request, and then re-spliced.

The / fdsf;/../hello/1/, entered will be concatenated to / / hello/1/1 for URI path matching, and the interceptor cannot be bypassed.

In the web container, the interceptor of Shiro is first executed with spring (Servlet). The difference in the pattern matching of the two interceptors to URI leads to the bypass of the Shiro interceptor, and Shiro fixes it twice. One is to delete the / number after the requestURI for URL path matching, which is a simple way to fix the way of adding / number bypass, and then / fdsf is repaired by independent splicing of requestURI in version 1.5.2. /.. / hello/1/, etc., use the; sign way to bypass.

Then there will be some form of bypass, or there will be some other container caused by differentiation bypass. You don't know.

Repair scheme

1. Upgrade version 1.5.2 or above

two。 Try to avoid using the * wildcard as the URL path expression of the dynamic routing interceptor.

On how to conduct Shiro permissions to bypass CVE-2020-1957 vulnerability analysis is shared 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.