XML External Entity Attack happens when an application allows an input parameter to be XML or incorporated into XML, which is passed to an XML parser running with sufficient privileges to include external or system files, which results in vulnerabilities like file inclusion, Server side request forgery and Remote Code Execution.
CONTENTS:
- Introduction
- Detection of XXE Vulnerability
- Tools to detect XXE Injection Vulnerability
- Exploitation of XXE vulnerability
- Mitigation for XXE vulnerability
- Conclusion
- References
Introduction:
Recently, there’s been an increase in the use of XML documents due to the growing use of the web services such as REST and SOAP API, which commonly uses XML to process the data.
XML has a feature to create entities dynamically. Some of the objects are predefined, and they’re referenced by using an ampersand (&) and a semicolon (;) at the end. However, XML also allows us to create custom entities, the most popular being the internal and external entities. Internal entities can be used to reference internal data and external entities to reference data from external sources.
Example for an Internal Entity:
]>
&name;
Cyber Security
Pentest
In the first line, we have defined an entity “name” having a value “Brisk”. The block used to define the entities is known as the ‘DTD block’. Next, in the third line, you can see that we have referenced the entity “&name;”, which holds the value “Brisk.” In this way, we don’t have to input the name each time. All that we have to do is use a reference to the entity.
Example for an External Entity:
]>
&name;
Data
pentest
In the first line, in the DTD block, we have defined an external entity, which contains a link to an external resource. When this XML document is processed, it would request an external source and would replace values of all instances of “&name;” with the content of the external resource. If the content of the external resource is processed and displayed back to the user without proper validation, an attacker may be able to abuse the parser in conducting an XXE injection attack.
Detection of XXE Vulnerability:
XXE injection can be detected using either automated or Manual techniques. To find an XXE (XML External Entity) injection vulnerability manually, either the attacker or tester needs to inject XML characters in all input fields and observe if XML parsing errors gets generated.
Using Web app vulnerability scanners like IBM Appscan, Burp Suite etc., it is possible to find XML related vulnerabilities.
Latest version of Burp Suite scanner can detect both traditional XXE and blind XML External Entity injection with a help of built in payloads and by analyzing the server’s response time. Below image shows the automated scan output of burp suite tool which detected a XXE injection using some built in payloads.
Tools to detect XXE Injection Vulnerability
XXEinjector is a ruby based script which automates retrieving files using direct and out of band methods. Directory listing only works in Java applications. Bruteforcing method needs to be used for other applications.
Below are some example command of XXEInjector tool usage,
Enumerating /etc directory in HTTPS application:
ruby XXEinjector.rb --host=192.168.0.2 --path=/etc --file=/tmp/req.txt –ssl
Enumerating /etc directory using gopher for OOB method:
ruby XXEinjector.rb --host=192.168.0.2 --path=/etc --file=/tmp/req.txt –oob=gopher
XXExploiter is a javascript based tool to generate the XML payloads, and automatically starts a server to serve the needed DTD's or to do data ex filtration.
It can be installed using npm with below command
npm install -g xxexploiter
Exploitation of XXE Vulnerability:
Use information disclosed in error messages to determine at what file path the XML parser is parsing. Also, try to load files that don’t exist to determine the operating system type and the path at which interpretation is taking place.
Let us consider a testing website (here I’m using OWASP Mutillidae application)
- In the below image, the application has an XML parser input page.
- Let’s try giving some XML inputs and check the response from the server.
- After that, we can try to inject the XML inputs with multiple user-defined entities.
- Now, we can try to include external data using section of XML input. The section of an XML document optionally defines external files to be included as a part of the XML document. Interestingly, these can even be files from the system parsing the XML.
By Using the section of XML input, we can try to access local files like /etc/ passwd files of a Linux server.
- Once we’ve given the above XML payload, we can get the password files details from the back-end Linux server.
- Similarly, we can try to load the boot.ini files if the server is Windows operating system. We can do it by using an XML payload like below:
]>
&systemEntity;
Mitigations for XXE injection attacks:
- XML parser functions like ‘unmarshaller’ should have a secure configuration to prevent allowing external entities as a part of an incoming XML document input.
- XML inputs should not be processed directly as java.io.File, java.io.inputstream.
- Use less complex data formats such as JSON, and avoiding serialization of sensitive data.
- Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system.
Conclusion:
Now-a-days, API applications are gaining significant traction and hence are predominantly being used in almost all the software firms. API applications use XML parser in the backend for processing the user’s inputs from the frontend/application. This XML parser is prone to XML external entity injection attacks when the user inputs aren’t properly sanitized. Hence, a complete security assessment that scrutinizes the entire attack surface of your applications is mandatory.
