XXE: XML external entity

In this article, we will explain what is the injection of external XML entities, describe some common examples, explain how to find and use different types of XXE injections, and also generalize how to prevent attacks with their help.

What is the injection of external XML entities?

Injection of external XML entities (also known as XXE) is a web security vulnerability that allows an attacker to interfere with the processing of XML data by the application. It often allows an attacker to view files in the application server's file system and interact with any server or external systems that the application itself can access.

In some situations, an attacker can leverage the XXE attack to compromise the back-end server or other internal infrastructure, using the XXE vulnerability to perform request forgery requests on the server side (SSRF).

How do XXE vulnerabilities arise?

Some applications use XML format to transfer data between the browser and the server. Applications that do this almost always use a standard library or platform API to process XML data on the server. XXE vulnerabilities arise from the fact that the XML specification contains various potentially dangerous functions, and standard analyzers support these functions even if they are not commonly used by the application.
')
XML external entities are a type of custom XML entity whose specific values ​​are loaded from the DTD files in which they are written. External entities are especially interesting from a security point of view, since they allow the entity to be determined based on the contents of the file path or URL.

What types of XXE attacks exist?

• Using XXE to retrieve files, where an external entity including the contents of the file is defined and returned in the application response.
• Using XXE to perform SSRF attacks, where the external entity is determined based on the URL of the internal system.
• Using blind extraction of XXE information over a control channel, where confidential data is transmitted from an application server to a system that is controlled by an intruder.
• Use XXE blind to return data from error messages when an attacker can cause an error message containing the necessary information.
• Using XXE to extract files

To perform an attack of the XXE-injection type, which extracts an arbitrary file from the server's file system, you must modify the submitted XML in one of two ways:

• Enter (or change) the DOCTYPE element that defines the external entity containing the file path.
• Change the value of the data in the XML returned in the application response to use a specific external entity.

For example, suppose a shopping application checks the amount of product stocks by sending the following XML to the server:

<?xml version="1.0" encoding="UTF-8"?> <stockCheck><productId>381</productId></stockCheck>      XXE,     XXE    /etc/passwd,    XXE: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <stockCheck><productId>&xxe;</productId></stockCheck> 

This XXE structure defines an external & xxe entity whose value is the contents of the / etc / passwd file, and uses an entity with the value of productId. This causes the application's response to include the contents of the file:

 Invalid product ID: root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin ... 

In the case of real XXE vulnerabilities, there will often be a large number of data values ​​in the submitted XML, any of which can be used in the application response. To systematically test XXE vulnerabilities, it will usually be necessary to test each data node in XML separately, using a specific entity and see the status of the response.

In addition to extracting sensitive data, another way to use attacks with XXE is to use them to fake requests on the server side (SSRF).

This is a potentially serious vulnerability, with which the server application can be used to execute HTTP requests to any URL that the server can access.

To use the XXE vulnerability to execute an SSRF attack, you need to define the external XML entity using the URL you want to access and use a specific entity with a data value. If you can use a specific entity with a data value that is returned in the application response, you can view the response from the URL in the application response and thus get a two-way interaction with the server system. If not, you can only perform blind SSRF attacks (which can also have critical consequences).

In the following example, using XXE, the external entity will cause the server to perform an internal HTTP request to the internal system within the system infrastructure:

 <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://internal.vulnerable-website.com/"> ]> 

Using XXE to perform SSRF attacks:

Many types of vulnerabilities XXE blind. This means that the application does not return the values ​​of any specific external entities in its responses, and therefore it is not possible to directly search for files on the server side.

XXE blind vulnerabilities can still be discovered and exploited, but more advanced methods are required. Sometimes you can use external methods to search for vulnerabilities and use them to exfiltrate data. It can also sometimes cause XML parsing errors that lead to the disclosure of sensitive data in error messages.

Finding and exploiting blind vulnerabilities XXE:

The ability to attack with the XXE injection is obvious in many cases, since the normal HTTP traffic of the application includes requests containing data in XML format. In other cases, the ability to attack is less noticeable. However, if you look in the right places, you will find an opportunity to attack XXE in queries that do not contain XML.

XInclude attacks

Some applications receive the data sent by the client, insert it on the server side into an XML document, and then analyze it. An example of this is the case where client data is placed in a SOAP backend request, which is then processed by the SOAP backend service.

In this case, you cannot execute the classic XXE attack because you do not control the entire XML document and therefore cannot define or change the DOCTYPE element. However, you can use XInclude instead. XInclude is part of the XML specification that allows you to create an XML document from nested documents. You can place an XInclude attack in any data value in an XML document, so an attack can be performed in situations where you control only one data element placed in the XML document on the server side.

To execute an XInclude attack, you must reference the XInclude namespace and specify the path to the file you want to involve. For example:

 <foo xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include parse="text" href="file:///etc/passwd"/></foo> 

Some applications allow users to upload files, which are then processed on the server side. Some common file formats use XML or contain XML subcomponents. Examples of XML formats are Office document formats such as DOCX and image formats such as SVG.

For example, an application may allow users to upload images and process or check them on the server after downloading. Even if an application expects to receive a PNG or JPEG format, the image processing library used can support SVG images. Since the SVG format uses XML, an attacker can send a malicious SVG image and thus be able to attack the XXE vulnerabilities.

Using XXE through downloading image files:

Most POST requests use the default content type created by HTML forms, such as application / x-www-form-urlencoded. Some sites expect to receive requests in this format, but allow other types of content, including XML.

For example, if a regular query contains the following:

 POST /action HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 7 foo=bar         : POST /action HTTP/1.0 Content-Type: text/xml Content-Length: 52 <?xml version="1.0" encoding="UTF-8"?><foo>bar</foo> 

If an application accepts queries that contain XML in the body of the message, and parses the content as XML, you can get the ability to attack XXE by simply reformatting the queries to use the XML format.

How to find and test XXE vulnerabilities

The overwhelming majority of XXE vulnerabilities can be quickly and safely found using the Burp Suite web vulnerability scanner.

• Manual testing of vulnerabilities of , as a rule, includes:
• Testing the extraction of files by determining the external entity based on the known operating system file and using this object in the data returned in the application response.
• Testing XXE blind vulnerabilities by defining an external entity based on the URL of the system you are managing and monitoring interaction with this system. The Burp Collaborator client is ideal for this purpose.
• Testing for vulnerable inclusion of non-XML user data into a server-side XML document using an XInclude attack to attempt to retrieve a known operating system file.

How to prevent XXE vulnerabilities

Virtually all XXE vulnerabilities arise because the XML parsing library supports potentially dangerous XML functions that the application does not need or is not intended to be used. The easiest and most effective way to prevent XXE attacks is to disable these features.

As a rule, it is enough to disable the resolution of external entities and disable support for XInclude. This can usually be done using configuration settings or software overriding default behavior. For more information about disabling unnecessary features, see the XML parsing library or API documentation.

---

You can use specialized laboratories as a training ground to test your exploitation skills for such vulnerabilities.

---

The latest dual-processor configurations of dedicated servers with Intel Scalable 2019 processors are available on DEDIC.SH :

• 2x Xeon Silver 4214 - a total of 24 cores
• 2x Xeon Gold 5218 - total 32 cores
• 2x Xeon Gold 6240 - configuration with 36 cores.

Server cost with two Xeon Silver 4214 - from 15210 rub / month
We are also ready to collect any configuration for you - write to us !

If a large capacity of a dedicated server is not required - VDS from 150 rubles / month - what you need!