ESB-2018.0254 - [Win][UNIX/Linux] Shibboleth: Access privileged data - Remote/unauthenticated 2018-01-24

Printable version
PGP/GPG verifiable version

Hash: SHA256

             AUSCERT External Security Bulletin Redistribution

             A vulnerability has been identified in Shibboleth
                              24 January 2018


        AusCERT Security Bulletin Summary

Product:           Shibboleth
Publisher:         Shibboleth
Operating System:  Windows
                   UNIX variants (UNIX, Linux, OSX)
Impact/Access:     Access Privileged Data         -- Remote/Unauthenticated
                   Provide Misleading Information -- Remote/Unauthenticated
Resolution:        Mitigation

Original Bulletin:

- --------------------------BEGIN INCLUDED TEXT--------------------

Hash: SHA256

Shibboleth Security Advisory [23 January 2018]

Implications of ROBOT TLS vulnerability
Late in 2017, a group of researchers identified a TLS implementation
vulnerability they termed "ROBOT" [1]. It involves flaws in the
implementation of TLS cipher suites that rely on RSA for encryption.

Most modern TLS deployments encourage and sometimes require the use
of newer cipher suites that utilize more modern encryption algorithms
even when an RSA public/private key pair is used. The researchers found
that many implementations supporting the older ciphers contained bugs that
can undermine the confidentiality of the channel.

While this obviously has the potential to impact any secure web
site, a more subtle consequence of this flaw is that it can sometimes
allow for a signature over arbitrary data to be forged under the web
server's private key.

In the context of SAML and Shibboleth, this becomes a much more
significant concern because of the conflation in the metadata between
"signing" and TLS. There are various equivalencies drawn such that
an IdP that supports both the HTTP-POST and HTTP-Artifact bindings
(with either SAML 1 or SAML 2) will generally be advertising the
TLS key it uses to host its ArtifactResolutionService endpoint
as equivalent to the key it uses to sign its POST-carried responses
and/or assertions.

In such a case, the TLS key affected by this vulnerability could
potentially be used as the basis for an attack that could result in
the forgery of SAML responses that could impersonate users from that
Identity Provider to virtually any service.

It was particularly common with older deployments to find the same
key used for both purposes, with the signing key used as a TLS key
on a dedicated virtual host or back-channel port such as 8443. This
has long been recognized as a bad idea (think Heartbleed, and other TLS
vulnerabilities that actually led to key exposure), so much so that
Shibboleth IdP V3 began to explicitly default to generating a dedicated
"back channel" key during installation.

However, sharing the key is not a precondition for this attack because
any key in the metadata role used for Browser SSO when Artifacts are
used can be transparently misused as a signing key with metadata-
compliant software, Shibboleth included.

The other common use case for the back-channel with older Shibboleth
deployments was to support SAML Attribute Queries. Because queries
involve a separate metadata role from SSO, one would have to reuse the
key in that case to be subject to the same degree of risk.

There are lower-probability attacks possible if a vulnerable key
is present solely in other role elements, such as an
<AttributeAuthorityDescriptor>, or in an SP's metadata. These attacks
would typically require a more active attacker along a network path
between IdP and SP, and a more limited timing window.

Attacks involving an SP's key are inherently more limited in scope
(since they tend to involve just one service) and would tend to be of
the information disclosure variety more traditionally associated with
the ROBOT vulnerability. As an example, forging queries or artifact
resolution requests under an SP's key could in theory result in
disclosure of user data by an IdP under the misapprehension that it
was responding to a legitimate request from that SP.

Affected Versions
This issue is orthogonal to the IdP and SP software and depends on the
software used to host the IdP or SP. The ROBOT site has some tools
available that can assess the status of a system.

While many of the common TLS assessment sites have been updated to
account for the issue, it is not uncommon for them to be limited to
scanning port 443, which may impact the ability to effectively assess
a back channel port. If the same software/configuration is used on port
443, that may be sufficient to assess a system's posture.

To be most seriously impacted, an IdP key within the <IDPSSODescriptor>
metadata role element that is marked with use="signing" or no use
attribute must be used as a TLS private key on a ROBOT-vulnerable
web site.

Other attacks are possible if a key on a ROBOT-vulnerable endpoint is
present in metadata in any form, but the forging of authentication
responses is the most serious threat.

Note that one must also take into consideration any sharing of an
at-risk key through means other than SAML metadata, such as by manually
configuring it with relying party systems.

1. Be aware of which keys you include in the metadata you advertise
and whether they are used for TLS, and remove any unnecessary keys

2. Ensure any unused/unsupported SAML features (e.g. Artifact support)
are omitted from the metadata you advertise.

3. Ensure that your TLS software is patched, well-maintained, and
carefully configured in accordance with modern best practice (which
is itself a moving target needing periodic review).

URL for this Security Advisory


Shannon Roddy, Internet2

Version: GnuPG v2


- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

Australian Computer Emergency Response Team
The University of Queensland
Qld 4072

Internet Email:
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.


« Back to bulletins