vulnerability description
Apache Shiro is a powerful and easy-to-use Java security framework that performs authentication, authorization, password and session management. Using Shiro’s easy-to-understand API, you can quickly and easily get any application, from the smallest mobile application to the largest web and enterprise application.
When it is used in combination with Spring, under certain permission matching rules, an attacker can complete identity authentication bypass by constructing a special HTTP request packet.
Scope of influence: Apache Shiro <1.7.1
Author: jweny @ 360 cloud security
Vulnerability environment construction
shiro 1.7.0
https://github.com/jweny/shiro-cve-2020-17523
poc test
http://127.0.0.1: 8080 /admin/%20
Use blank characters such as spaces to bypass shiro authentication.
vulnerability analysis
In the vulnerable environment, the URL matched by “/admin/*” should be within the authentication scope of shiro. The function of shiro checking path is pathMatches. When pathMatches returns true, the matching URL will enter the subsequent authentication logic.
Place a breakpoint at pathMatches in the org.apache.shiro.util.AntPathMatcher#doMatch method.
First manually verify the cause of the vulnerability:
Call up Evaluate, calculate it pathMatches（"/admin/*","/admin/1"）, normal match, return true.
Calculate pathMatches（"/admin/*","/admin/ "）, there is no normal match, return false, so it will not go through shiro authentication when visiting the url, but what Spring receives is that the url is /admin/%20, and returns a normal response, where the response is admin page.
Start following debugging:
Debugging will begin with a boring F7. Until doMatch("/admin/*","/admin/ ").
It can be seen that tokenizeToStringArraythere are no spaces in the returned pathDirs. Thus causing /admin/*and /admin/do not match.
Here is a brief talk about why it is not the matching function matchStrings()of shiro . matchStrings()When matching *, as long as the string to be matched is not empty, the matching success is returned. Therefore, only when the space is deleted, the *match fails.
Visible is tokenizeToStringArray caused. Follow the tokenizeToStringArray method and find that tokenizeToStringArray the trimTokens parameter when calling the method is true.
In the tokenizeToStringArray method, when the parameter trimTokens is true, it will be trim() processed, so that blank characters such as spaces are cleared.
To sum up: In the vulnerable shiro version, tokenizeToStringArray when the method is called , the trimTokens parameter defaults to true, which causes blank characters such as spaces to be deleted, so it cannot match the pattern *, and the path cannot be authenticated. However, the access path received by spring is to /admin/%20return a response according to the normal logic, which causes the permission to be bypassed.
Official repair plan
After the above analysis, the repair plan has been very clear and will be trimTokens set to false.
About trim
In principle, it trim()will clear all the whitespace before and after the string, the space is just one, but in addition to other whitespace found outside spaces, such as in testing %08, , %09, %0awhen spring returns processing 400.
Therefore, apart from spaces, no other useful payloads have been found.