XML External Entity Injection Opens Door to Attacks, Theft

XML is a popular language for web developers, partially due to its software and hardware independence. Recently, however, XML security is under threat from XML external entity injection (XXE) attacks, a dangerous vulnerability in XML web applications. Even the most secure app, including those from Facebook and Google, can be affected by this vulnerability.

The XML external entity injection vulnerability allows an attacker to exploit an application that parses XML input and reflects it back to the user without any validation. Basically it concerns the misconfiguration of the XML parser that executes malicious input. An attacker can compromise users through an XML external entity exploit and carry out serious attacks such as obtaining sensitive information, denial of service, port scanning, server side request forgery, and others.

Before stepping through an XXE exploit, let’s take a look at the role entity plays in an XML structure.

Entity is a shortcut that defines a value. It is very useful in XML when developers do not want to repeat their work for large items or want to use internal or external file content as a variable value. They can just use entity in place of reworking the same set of data. Entity generally has two types of declaration: internal and external.

Internal entity: The user sets the entity’s static value while defining it via XML document type definition. When the entity parsed, its value is the word “testing.”
Example:

<?xml version=”1.0″ encoding=”utf-8″?>

<!DOCTYPE Any [

<!ENTITY test “testing”>

External entity: The user can set an internal (local path) or external reference as the entity’s value. When the entity parsed, its value is the referenced file, in this case boot.ini.

Example:

<?xml version=”1.0″ encoding=”utf-8″?>

<!DOCTYPE Any [

<!ENTITY test SYSTEM “file:///c:/boot.ini“>

The potentially vulnerable entry point in the web application occurs when a user’s XML input is parsed by the XML parser:

The application accepts user XML input and shows it in the response.
The application has a file-upload function and the uploaded file content is reflected to the user. This may happen through an XML file upload or .PPTX, .DOCX, .XLX, etc.

Manual test

Case 1: When user-given XML input is reflected in the response page:

Modify the user input in form of entity declaration and observe if the XML Parser provides the same response as with a static value. This can be done with any proxy server. In the following example we have modified tag value (“testuser”) in entity declaration.

Original request example:

Modified request example:

Now, if the XML parser parses both requests in the same way, with the same result, then the application is vulnerable to XXE. In such a case, try XXE exploits such as obtaining system files. Your results may depend on file permissions.

Example of XXE payload to access a system file:

You can find more exploit cases at this OWASP page.

Case 2: File upload function

XXE is also possible via file upload when XML is parsed in the file content (XML structure) and shown to the user in response. In such a case, an attacker may be able to upload a file with embedded XXE payloads. For more details, refer to the following article.

Tools

The proxy tool Burp can perform this check and report a blind XXE. For more details, refer to this link.

Solutions

Do not trust the user input and perform proper validation.
Disallow the uploading of any document that has entity declaration via document type definition.
Check out language-specific solutions suggested by OWASP.

References:

The post XML External Entity Injection Opens Door to Attacks, Theft appeared first on McAfee.