A WebLogic Vulnerability Highlights the Path-Based Authorization Dilemma

Image

A WebLogic server vulnerability fixed by the October CPU has come under active exploitation after a Vietnamese language blog post detailed the steps needed to bypass authentication and achieve remote code execution on unpatched systems. Although there have been a series of actively exploited WebLogic deserialization bugs, the exploit payload in this case immediately grabbed my attention because of how similar it is to vulnerabilities I’ve analyzed in a wide range of consumer and enterprise products. Per a tweet from @jas502n: http://x.x.x.x:7001/console/images/%252E%252E%252Fconsole.portal The piece of this which grabbed my attention is the %252E%252E%252F. If we URL decode this string, the three %25 become % leaving %2E%2E%2F. Decoding this value again yields ../ which should be familiar as a directory traversal pattern. This URL can be used to directly access the /console/console.portal resource due to a series of errors in how the application was designed and configured. The web application is making an authorization decision based on the requested path but it is doing so without first fully decoding and canonicalizing the path. The result is that a URL can be constructed to match the pattern for a permitted resource but ultimately access a completely different resource. Over the years, I have seen this vulnerability pattern come up in quite a few different places including products from Netgear, Asus, TrendNET, Ruckus, and Citrix. The first place I remember seeing this was on Netgear when I realized that my router would treat any request ending .gif as authenticated. Allowing access to all the GIF would normally not be a big deal but because the web server only looked at the requested URI, it could be duped by placing ?.gif at the end. The authentication handler would approve the request because it ends .gif and pass it along to a file handler which then continues parsing the request URI before determining which file to serve. This allows for a direct authentication bypass which could then be chained with authenticated command injection flaws I had separately found. The code responsible for this flaw was intended to provide a sort of MIME handling so that files of different types would be streamed and authenticated accordingly. In other cases, such as with Ruckus, I noted that there were multiple directories from which all requests were treated as authenticated. Using a plain path traversal like /images/../, you could access authenticated resources without a password. Another way of looking at this is that we have a time-of-check/time-of-use inconsistency when processing request URIs. The path is checked when the request is received but the value is decoded further before use creating an opportunity for exploitation. The lesson here for developers hoping to avoid slipping on this particular banana peel is to make sure that path-based authorization checks are only ever considered after all transformations have been made to the requested URI. Detection for CVE-2020-14882 is available in ASPL-913 and later.