Shibboleth Security Advisory [23 January 2018]

[Mark Cairney]

Hi,

What (practically) does this mean and what's the best way to protect
against it?

I've read through the below email and https://robotattack.org/ and ran
the tool from https://testssl.sh/bleichenbacher/ against both 443 and
8443 and it says we're not vulnerable.

As we upgraded from a legacy V2 setup we are currently using the same
keypair for backchannel/signing/encryption. Should we migrate to using
separate keypairs for each and is there a way to generate these
independent of the install script as you can with the SP? This is likely
to cause some issues as we do have a number of SPs with our metadata
loaded directly rather than via the UK Federation metadata feed.

Alternatively can this be mitigated with an appropriate cipher suite
configuration at the webserver level?

We currently have the following ciphersuites for our backchannel:
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS:!EXPORT¶





On 23/01/18 19:49, Cantor, Scott wrote:
> 
> 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.
> 
> Recommendations
> ===============
> 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
> promptly.
> 
> 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).
> 
> 
> References
> ==========
> URL for this Security Advisory
> http://shibboleth.net/community/advisories/secadv_20180123.txt
> 
> [1] https://robotattack.org/
> 
> 
> Credits
> =======
> Shannon Roddy, Internet2
> 
> --
> To unsubscribe from this list send an email to announce-unsubscribe at shibboleth.net
> 

-- 
/****************************

Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh

Tel: 0131 650 6565
Email: Mark.Cairney at ed.ac.uk
PGP: 0x435A9621

*******************************/

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.