WSO2 #2: The many ways to bypass authentication in WSO2 products

The application defines route permissions via using path regular expressions. The permissions aren't part of the path! Immediately, the author thought there is no way this is being done correctly. The default is no authorization checks for some crazy reason. There is a set of OAuth endpoints for configuring authentication on the service. Obviously, these having bad regex's would break the security of the application. Some of the endpoint weren't included at all! Some could be bypassed by adding a trailing slash. For instance, the regex (.*)/keymanager-operations/dcr/register would NOT match to /keymanager-operations/dcr/register/. In 2022, a complete bypass for all authentication was found via finding a difference in the regex parsing and the server parsing. Adding a semicolon into a path was valid yet not counted in the regex's. For instance, /scim2/Users could be bypassed with /scim2;/Users. Apparently, semicolons are valid within the path segment as matrix parameters. So, this was a valid path but not picked up by the regex. Instead of rethinking this approach they doubled down and rewrote a lot of the regex's super crazy rules. The patch for this was to ensure that ;/ would always be rejected. To find a bypass for this, they reviewed the ordering of operations. Upon analyzing the code, they learned that the URL decoding happens after the regular expression test but before getting the URL. So, simply URL encoding parameters can also bypass the regex checks. The definition of a route contains a METHOD as well. If the method in the HTTP request doesn't have a corresponding route, then it will fail. Because a route can support multiple methods, the code uses a .contains() for the authorization checks. Sadly, this is case sensitive but it's normally to be capitialized later. So, invoking a route with a lowercased method will bypass authentication. Yikes! The service APIKeyMgtSubscriberService doesn't require any special besides valid credentials. This appears to be a legacy API for creation and management of OAuth clients. By calliing this API, you can use a low-level user to create an Admin user. Yikes! After reporting the vulnerabilities, the product team asked the author to stop testing their products. At the moment, they had dedicated a war room team to evaluate the architecture and find more issues. They ignored this and submitted more critical bugs the next day. Overall, an awesome post with great background, discovery thoughts and exploit notes.