OWASP Top 4 – XML External Entities (XXE)

owasp top 4

OWASP Top 4 – XML ​​External Entity Processing is ranked as the vulnerability number four on the OWASP Top 10 list. This vulnerability is prevalent on online systems for two reasons:

  1. When web developers complete the functionality of an application, the application is assumed to be ready to run. Most of the time, rechecking your code for security flaws is impossible because there are other projects waiting to be developed.
  2. When the application interface is online, system administrators spend most of their time creating new profiles and training users to use the new interface. Testing the application for security flaws is not an option because they must perform other critical procedures on the system such as server updates and provide support to employees and end users.

With all this, it is quite difficult to find this type of vulnerability which allows an attacker to modify and upload infected XML files designed to execute commands, enumerate user names, passwords and obtain reverse connections from the infected application to enter the internal network.

The best way to discover this vulnerability is through manual testing and a clear understanding of these processes.

What exactly is the process that generates the vulnerability in XML external entities?

This vulnerability is generated in the XML parser through the execution of applications on websites. This occurs because the XML parser has not been configured with security in mind. It is important to mention that the XML parser is the method used to convert text into XML DOM objects. These objects are a type of a neutral language that allows programs and scripts to dynamically access and update the content, structure, and style of a document.

What are the types of attacks that a hacker could carry out if he finds this type of vulnerability in a web application and what would be the consequences?

There are different types of attacks that a hacker can execute if he finds this type of vulnerability in a web application. We will analyze the three most common types of attacks:

OWASP Top 4 – Anatomy of a Website Attack

  1. Attack on XML external entity processing to retrieve files:

The purpose of this type of attack is to access files on the server where the vulnerable XML application resides. Critical files for Linux operating systems such as “/etc/passwd” and “/etc/shadow” could be compromised. The same situation occurs with the Windows operating system; system files such as “web.config” and “unattend.xml” could be compromised. The attack spectrum would increase exponentially if internal access credentials were found in those files (as is almost always the case).

Here we have a simple login page used for demonstration purposes:

If we enter random credentials and click on Login:

We received a response in our parser tool showing that the login system was configured using XML language:

Examining the application from the server side we find this is the file that manages the login system:

As we noticed in the response to our request made, “admin” is the constant output and is printed through the tag “$name“. We can see this output on the website login page:

Knowing this information, the next question would be:

How can an attacker make use of this setting that was written having no security in mind and get unauthorized access to the server?

Some analysis tools allow you to send modified requests to interact with servers where web applications reside. In this case, we create a request with XML configuration specifying that it will use the “$name” tag to gain unauthorized access to system files.

In response to our request obtained through our XML code, we can access the file “/etc/passwd” that allows us to list the usernames that have access to the system.

As you noticed, we use the entity “&sp;” exactly where the tag resides to gain unauthorized access to the “/etc/passwd” file.

Now we will request a .php file located in the file system:

As you can see, this time we were unsuccessful in our request because the .php language uses different containers to interact with the .php code.

The solution to access the file “index.php” would be to use the container “php://filter” in our XML code.

This time, the attack succeeded, and it allowed us to access the “index.php” file. As you can see, the file is shown Base64 encoded.

The next step would be to decode the code:

To finally have full access to the file.

  1. Attack on XML external entity processing to spoof requests from server side

Server-side request spoofing allows an attacker to identify services running on other ports on the compromised server to discover other applications; the ideal for the attack would be that these applications were also vulnerable. In other words, this is an attack within an attack.

For demonstration purposes, we are testing connectivity to closed port 8080 and open port 5355. Based on the response time, we can confirm the status of those ports.

The response of 10,747 mills confirms that port 5355 is open. If this vulnerability had been patched, it would be impossible for an attacker to find this type of information.

  1. Attack on XML external entity processing to filter out-of-band data:

This is a very interesting type of attack; the out-of-band technique requires hosting a malicious hacker-controlled DTD (document type definition) file (out-of-band process) on a web server; then, call the malicious DTD file from the vulnerable application. When this process is executed, the DTD designed out-of-band will enter the process with a set of actions previously determined by the attacker that will be executed on the vulnerable system. These actions can transfer specific data to the attacker’s environment, scan another internal network, or perform enumeration procedures on other computers.

Let’s see how we can extract the file “/etc/passwd” using the out-of-band attack:

We host a malicious file called evil.dtd on the attacking machine with a code designed to read and exfiltrate the file “/etc/passwd” when served from IP address

And we connect our server to the Internet by opening port 8000:

To call the evil.dtd file, the previously created XML must be reconfigured. In this way, the malicious file will run as a response process on the vulnerable website:

When the request is sent to the server, the evil.dtd file is processed, and we get the content of the file “/etc/passwd” which is shown as base64 encoded.

And finally, the file after being decoded:

Is this a common vulnerability?

Yes. It is. We have seen these types of vulnerabilities in web servers, databases such as MySQL and PostgreSQL, image platforms, and web browsers. Every website that runs XML code must be parsed.

How can I find out if my web applications are affected by this vulnerability?

A review of the applications on your website is required along with other types of analysis to discover other more dangerous vulnerabilities such as remote or local inclusion of files, servers with PUT option configured, authentication via token vulnerabilities, POODLE, XSS, and SSRF, among others.

How can RedDefense Global help me to keep my corporate website safe?

RedDefense Global will put your corporate websites and databases to the test. We use advanced scanners, manual penetration testing, and different techniques and procedures that may include crawling, rough tampering, code review, and folder permissions. We do all of this in coordination with your internal staff in charge of your information systems. These procedures are necessary to find out if the potential vulnerabilities are false positives or real vulnerabilities. If they are real vulnerabilities, we will provide you with effective methods to patch, update or remove the vulnerability according to the situation to keep your environment safe.



Additional resources regarding this type of attack :