Step-by-step lab guide for exploiting CVE-2017-10271 (WebLogic XMLDecoder deserialization RCE) with manual payload construction, blind RCE bypass, and post-exploitation techniques including privilege verification and data exfiltration.
AdminServer belonging to base_domain running in Development Mode).7001.http, t3, iiop, ldap, snmp.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).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:
/uddiexplorer:
/wls-wsat:
⇒ 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.
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.
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>"
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>"
com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix "soapenv".Analysis: