In a recent project, I’ve uncovered a significant security issue that revolves around XML External Entity attacks.

This article delves into my journey of identifying and exploiting the XXE threat in our project in an unusual way to output the attack results — via Java exceptions in the log files.

XML External Entity (XXE) is a security vulnerability that occurs in applications handling XML input. In an XXE attack, an attacker can exploit an application’s XML parser to include external entities, which can lead to a range of malicious actions, such as reading local files, initiating server requests, or even executing arbitrary code on the server. This type of vulnerability can have severe consequences if not addressed, making it a crucial concern in the realm of cybersecurity.

As I dove into comprehensive testing for my recent project, I encountered an alarming functionality. The project’s solution allowed for the upload of schema files that incorporated XML markup, opening the door to XXE vulnerabilities.

Intrigued, I decided to delve deeper into this potential threat. My initial breakthrough came when I discovered an XXE that allowed Server-Side Request Forgery (SSRF) vulnerability. SSRF is a type of security vulnerability that occurs when an attacker tricks a server into making unintended requests to other resources on the server’s internal network or to external websites.

This vulnerability was achieved by injecting the following XXE payload inside the schema file:

With this payload in hand, I simply created a schema file from a template and appended it with the payload.

After creating the schema, I proceeded with uploading it into the system:

The application, by default, auto-processes the schema after upload. After loading, the error will occur due to the invalid schema file (because of the injection):

Despite the error, the injected XML entity was still processed, causing the server’s backend to perform an HTTP request. This was the defining moment in the discovery, as I successfully achieved an SSRF.

I soon realized that reading files was not feasible, as no direct output was available. All we received was a generic error message. The schema file needed to adhere to a specific template, rendering techniques like DTD with multiple instructions were impractical, due to the XML parsing error after the first instruction.

But I was undeterred, determined to find a way to disclose files on the target machine. My continued exploration led me to a solution: the application had a logging functionality, and logs could be displayed. This revelation opened a new path for me.

My quest to extract valuable information from the processed injected XML entities took shape.

I created a schema from a template containing a payload that declares an entity, loading an external XML DTD.

An external DTD allows the application to reference a separate file for defining XML structure, providing an avenue for potential exploitation:

Then I prepared the evil.dtd file itself on the remote host:

Same as previously I uploaded a schema file from a template and appended it with my payload:

The schema uploads but the loading process fails due to an error as usual:

However, this way it will still load the external DTD (evil.dtd) and process it:

The payload in the DTD file triggers a server exception by referencing a non-existent file. This file name is created by combining the ‘nonexistent/’ path with a string that represents the listing of the C:/ drive.
Basically, the unhandled exception text will look like:

Error, non-existing file at: file:///nonexistent/(C:/)LISTING.

And this text will appear in the error log:

Besides directory listing, this technique could be used to read a file as well. By manipulating the content of the DTD file, an attacker could target specific files within the system: