XPATH Assisted XXE Attacks

[Nytro]

XPATH Assisted XXE Attacks

DannyChrastil| March 17, 2015

I was in a coffee bar with some good friends of mine the other day and one of them asked me “Danny, if in one hand you have XPath Injection, and in the other XXE Processing… which would you choose?” With a wry smile I responded to him, “Put your hands together!” (miss the reference?

)

When testing applications which are employing XML, whether it be a web service for a mobile application or an ajax-mashup website, two of the main vulnerabilities you will see and hear about are XPath injection and XXE (XML External Entity) processing. While each of these on their own are interesting vulnerabilities, there is a unique situation that allows you to chain the two together in order to read data off a target system.

XPath Injection

XML documents act as a data store or database for applications. You can store large amounts of data in a hierarchical structure which can then be queried by the application the same way you would query a database. This querying protocol for XML is called XPath. Just like SQL queries can be vulnerable to injection attacks, so can XPath queries. If user-supplied data is not sanitized before being applied to the XPath query, an attacker could perform an injection attack much like the following:

Query:

$xquery = "//Customer[username/text()='" . $_POST[‘username’] . "' AND password/text()='" . $_POST("passwd") . "']";

Attack Request:

username=danny’ or 1=1 or ‘1’=’1&password=testing

Resulting XPath Query:

//Customer[(username/text()='danny’ or 1=1) or (‘1’=’1' AND password/text()='testing')]

This injection would match and return results for all of the customers in the XML document instead of data only belonging to ‘danny’. While this attack can be very powerful, it also has its limitations. Unlike SQL, XPath has very limited interactions with the OS and system files of the web server. There is a function in XPath called “doc()” that can read both local and remote files as long as they are XML documents. This is great if you can find a XML file on the server which contains sensitive information, but in most cases this won’t be helpful in trying to access /etc/passwd, etc.

XXE Processing

XXE stands for XML External Entity Processing. The XML data structure allows for elements called entities which are used as data variables to be used within the XML body. An XXE attack is when the user can control the XML structure that is sent along with the request to the server. If an attacker can create their own entity then they can perform attacks such as sensitive file disclosure, denial of server, port scanning and more.

Attacker controlled XML:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foobar [

<!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foobar>&xxe;</foobar>

This attack would load the file “/etc/passwd” from the server and return the data within the <foobar> element to the user. The attacker could get creative and load other files such as CMS config files for database credentials.

XPath assisted XXE

XPath Injection and XXE Processing are not commonly found together within the same application. So what if you find XPath Injection within a search form on a site which doesn’t contain sensitive information or authentication. Apart from changing the results which are displayed in the search response, there isn’t much to do. If only we had XXE to help us read files off the file system.

Remember that XPath “doc()” function that can only load XML documents? Because “doc()” can also load external XML documents, an attacker could force the application to load an evil XML document hosted on their own server. How does this help us read sensitive files on the target server? If the attacker creates the evil XML document to contain XXE processing that loads /etc/passwd. When this XML is loaded on the target server it will then load the file corresponding to its own file system, not the attackers.

How to Protect Yourself

Because this attack is chaining two vulnerabilities together, it is important that both are addressed in order to mitigate the risk. XPath Injection is similar to other injection vulnerabilities in that the best approach to remediation is by implementing thorough white list validation and input sanitization on any user supplied data; in this case, anything going into the XPath query. Theoretically, if the user supplied input is being validated before building the XPath query, then the attacker would not be able to inject the “doc()” function to load the malicious XML file; however, it would be best practice to disable the “doc()” function completely if it is not required by the application. If that is not a viable option, then the next step would be to disallow any remote calls by the “doc()” function only allowing local XML files to be loaded.

Here at HP Fortify on Demand, we are working to detect this issue for all of our customers' sites and provide them detailed remediation steps.

Reach out to us with any questions

Sursa: http://h30499.www3.hp.com/t5/Fortify-Application-Security/XPATH-Assisted-XXE-Attacks/ba-p/6721576