RE: XXE (Xml eXternal Entity) attack

["Michael Howard" <mikehow () microsoft com>]

> From one of our SOAP guys...

At the protocol/spec level, both SOAP/1.1 and SOAP/1.2 explicitly
prohibit SOAP messages from containing document type declarations (which
is where entity declarations appear or are referenced). So no LEGAL SOAP
messages can use this trick.

As I recall, the .NET stacks (both remoting and asmx) won't expand
external entity references.  This is a side-effect of using
XmlTextReader as our parser (it won't expand external or internal entity
references).  You need to use XmlValidatingReader to get entity
reference expansion (and yes, the default config for XmlValidatingReader
is to expand entity references).  However, neither WS stack uses
XmlValidatingReader, so we're safe.

I don't know whether we explicitly reject the messages or whether we
silently skip the DOCTYPE declaration if present. Either would be
reasonable in the face of the "liberal in what you accept, conservative
in what you emit" philosophy of the Internet.

Cheers, Michael
Secure Windows Initiative
Writing Secure Code 
http://www.microsoft.com/mspress/books/5612.asp


-----Original Message-----
From: Gregory Steuck [mailto:greg-xxe () nest cx] 
Sent: Tuesday, October 29, 2002 4:30 PM
To: webappsec () securityfocus com
Subject: XXE (Xml eXternal Entity) attack


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is an abbreviated variant of my post to bugtraq. I hope webappsec
subscribers will find this useful too. I excluded the section discussing
particular products since it didn't fit the list charter. Legalese is
also gone to improve content/fluff ratio.

Overview:
 XXE (Xml eXternal Entity) attack is an attack on an application that
parses  XML input from untrusted sources using incorrectly configured
XML parser.  The application may be coerced to open arbitrary files
and/or TCP connections.

Details:
 External entity references allow embedding data outside the main file
into  an XML document. In the DTD, one declares the external reference
with the  following syntax:
  <!ENTITY name SYSTEM "URI">

 XML processor behavior as specified is
 [http://www.w3.org/TR/REC-xml#include-if-valid]:

  "When an XML processor recognizes a reference to a parsed entity, in
  order to validate the document, the processor must include its
  replacement text. If the entity is external, and the processor is not
  attempting to validate the XML document, the processor may, but need
  not, include the entity's replacement text..."

 Now assume that the XML processor parses data originating from a source
under  attacker control. Most of the time the processor will not be
validating,  but it MAY include the replacement text thus initiating an
unexpected  file open operation, or HTTP transfer, or whatever system
ids the XML  processor knows how to access.

Suspect systems:
 The buzz on the street is "web services". They accept XML encoded  data
over the network, sometimes from untrusted clients. So, the  prime
targets are SOAP and XMLRPC implementations. Yet, there are  many more
XML based protocols and vulnerability does not necessary  lie with the
servers. Pick any "XML based network protocol" and  try to apply the
attack methodology.

Suggested fix:
 Most XML parsers allow their user to explicitly specify external
entity handler. In case of untrusted XML input it is best to prohibit
all external general entities.

Successful exploitation may yield:
 * DoS on the parsing system by making it open, e.g.
   file:///dev/random | file:///dev/urandom | file://c:/con/con
 * TCP scans using HTTP external entities (including behind firewalls
   since application servers often have world view different
   from that of the attacker)
 * Unauthorized access to data stored as XML files on the parsing
   system file system (of course the attacker still needs a way to
   get these data back)
 * DoS on other systems (if parsing system is allowed to establish
   TCP connections to other systems)
 * NTLM authentication material theft by initiating UNC file access to
   systems under attacker control (far fetched?)
 * Doomsday scenario: A widely deployed and highly connected application
   vulnerable to this attack may be used for DDoS.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (OpenBSD)
Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard
<http://www.gnupg.org/>

iEYEARECAAYFAj2/J/QACgkQCxVCvY31obBK8wCffqAzS+GIlpT63xwsCVli1K62
YJMAn1HVWmkfbte0nSR7QHQ6JBR2+DLh
=xQ3s
-----END PGP SIGNATURE-----