Exploring SOAP Web Service Through Hack The Box’s DevArea

I came across DevArea while exploring SOAP web services and used it as a practical way to understand how SOAP-based applications can be assessed for security.

This article focuses on the SOAP service, from enumeration and analysis to identifying a vulnerability and obtaining the user flag. Rather than providing a complete machine walkthrough, it documents what I learned from testing SOAP in a realistic challenge.

Initial Recon

I started by accessing the target at 10.129.244.208. To reach the application using its hostname, I first added the corresponding entry to /etc/hosts.

A web application was then discovered:

I explored the website to identify any immediately interesting functionality or potential attack vectors. However, the available links were non-functional, and the site appeared to be largely static.

I then used Wappalyzer to fingerprint the technologies used by the application and determine whether any of the identified components were associated with known publicly disclosed vulnerabilities.

The detected technologies are listed below:

There did not appear to be much of an attack surface here, so I shifted my focus toward the underlying web server.

The server was running Apache 2.4.58, so I checked whether this specific version was associated with any publicly disclosed vulnerabilities or available proof-of-concept exploits. During this research, I came across a PoC related to File Confusion & Resource Exhaustion vulnerabilities.

However, investigating this avenue ultimately led me down a rabbit hole without producing anything useful. After finding no practical way to leverage it against the target, I moved on to explore other parts of the attack surface.

Next, I turned my attention to the Nmap results. The scan revealed several open ports, so I started investigating them one by one. The first interesting finding was an exposed FTP service that allowed anonymous access.

Finding the JAR File

I then connected to the FTP service using ftp -p devarea.htb 21 and was able to authenticate successfully using anonymous access.

I then started enumerating the FTP server for any potentially useful information by listing the available files and directories using the ls command. Among the contents, I found a directory containing a single .jar file, which appeared to be a Java archive.

I needed to download the JAR file to my local system so I could inspect and extract its contents. To do so, I used the following command, which retrieves the file from the FTP server and saves it to the current working directory:

wget ftp://devarea.htb/pub/employee-service.jar

The file was successfully downloaded and could then be found in the current working directory:

Decompiling and Discovering the SOAP Service

With the JAR file now available locally, I could extract it and inspect its contents. I used the following command to unpack the archive:

jar xf employee-service.jar

This extracted the contents of the JAR file into the /extracted directory, allowing me to examine the application files and understand how the service was implemented.

While going through the extracted files, I found compiled Java classes that needed to be decompiled before I could inspect the underlying source code. I used CFR to decompile the JAR and output the resulting Java files into a separate directory:

java -jar cfr-0.152.jar employee-service.jar --outputdir decompiled

I then opened the decompiled code in VS Code for easier analysis. While reviewing the source, I identified an EmployeeService web service, which appeared to be a key component of the application and gave me a better direction for investigating the SOAP attack surface.

While examining the ServerStarter.java class, I found the endpoint used to expose the service at /employeeservice. I also identified the corresponding WSDL endpoint at /employeeservice?wsdl, which provided an entry point for further enumeration of the SOAP service.

I then navigated to http://devarea.htb:8080/employeeservice to see what the endpoint exposed and VOILA I finally had something interesting to work with.

I then navigated to http://devarea.htb:8080/employeeservice?wsdl and began examining the WSDL to identify any useful information about the service, its available operations, and the expected request structure.

The WSDL exposed only a single operation. I decided to construct a SOAP request using this operation and send it to the service to better understand how it handled the input and what information I could retrieve from it.

The report was submitted successfully, but the response did not reveal any sensitive information. At this point, I shifted my focus toward investigating whether the service exposed any functionality that was not documented in the WSDL.

Exploiting the Aegis Databinding SSRF

While reviewing the application files, I noticed the presence of Apache CXF under the org.apache.cxf package. The application was using Apache CXF 3.2.14, an open-source framework commonly used for building and processing web services, including SOAP-based services.

This caught my attention, so I began researching the framework for publicly disclosed vulnerabilities that could be relevant to the version and implementation used by the application. During this research, I came across a publicly documented exploitation technique that specifically targeted the version of Apache CXF used by the application.

The exploit leverages the misconfiguration in Aegis databinding inside Apache CXF that is prone to SSRF vulnerability . The vulnerability lies in how Aegis handles XOP (XML-binary Optimized Packaging) references, which allow binary data to be referenced by a URL. In vulnerable versions, these references can be manipulated to make the server retrieve arbitrary URLs, potentially allowing access to internal resources.

XOP is a mechanism that allows SOAP messages to reference binary data as an attachment instead of encoding the binary data directly inside the XML.

Aegis DataBinding is an Apache CXF data binding module that maps Java objects and types to their corresponding XML representations when serializing and deserializing SOAP messages.

For the exploit to succeed, the request must be sent with a multipart/related content type, causing Apache CXF to process the message using MTOM (Message Transmission Optimization Mechanism) and recognize the XOP elements instead of treating the payload as a standard XML message.

MTOM is a standard way to send large files (like images or PDFs) inside SOAP web messages using XML-binary Optimized Packaging (XOP) without slowing down the network.

As shown above, we were able to successfully retrieve the /etc/passwd file. Now that we have confirmed the ability to read local files, we can investigate further and look for other potentially sensitive files on the system such as:

/proc/self
/etc/hosts
/etc/passwd

/proc/self
/etc/hosts
/etc/passwd

Note:_ The response is returned in Base64-encoded format, so it needs to be decoded to read the file contents._

Escalating Local File Disclosure Into a Credential Leak

By reading /proc/self the server returned base64 encoded string

After decoding the response, I was introduced with a list of Pseudo files for the current process.

cmdline was particularly interesting because it reveals the command strings and parameters used to spawn the process, opening the door for sensitive information to be revealed.

Unfortunately, none of the previously tested paths revealed any useful or sensitive information for the /self process, so I turned my attention to the parent directory itself, which in our case is /proc. By reading /proc, I was able to enumerate the processes currently running on the server.

By decoding the response, a list of Process IDs was revealed.

For each discovered PID, I checked /proc/<PID>/cmdline again to see if it revealed any sensitive information from the other processes running on the server.

One process with PID 1430 revealed the administrator's credentials for a service called hoverfly.

Hoverfly is a lightweight, open-source API simulation and service virtualization tool used by developers and testers.

From Leaked Credentials to RCE via Hoverfly

Looking back at the Nmap scan, I found a service running on port 8888. This was the Hoverfly Dashboard.

And by navigating to it through the browser, I entered the credentials I had previously extracted.

I then started looking for vulnerabilities affecting the specific Hoverfly version, v1.11.3. I found that this version has a publicly disclosed vulnerability in its middleware functionality, which can lead to RCE through command injection at the /api/v2/hoverfly/middleware endpoint.

By exploring the dashboard, I found an API documentation under the Docs tab, which helped me identify the vulnerable endpoint and understand how to interact with it.

While exploring the docs, I was able to identify two endpoints that seemed particularly interesting:

GET /api/v2/hoverfly/middleware PUT /api/v2/hoverfly/middleware

Since the vulnerability leads to RCE, the PUT method was the one worth investigating further.

And since I understood the request structure, I crafted the request and sent the reverse shell command, specifying my IP address and listening port through the script parameter.

By navigating back to the home directory, I found a directory belonging to a user named dev_ryan. Inside it, I was able to retrieve the user flag.

Conclusion

To wrap up, here's how the path unfolded: starting from an exposed FTP share, I traced a route through a decompiled JAR to a live SOAP service, then exploited a misconfiguration in Apache CXF's Aegis databinding to achieve SSRF via XOP/MTOM. That led to local file disclosure, a leaked credential in a process's command line, and ultimately RCE on a Hoverfly instance which was enough to reach the user flag.

Privilege escalation and the root flag are outside the scope of this writeup.