Shibboleth Security Advisory [23 January 2018]

Wed Jan 24 10:06:14 EST 2018

Hi Mark,

What it means is that there is potential for an attacker to generate
arbitrary SAML and have it signed by the vulnerable IdP or load
balancer.  (subtlety here is that the key is not compromised.  The
vulnerable IdP/LB actually can be made to sign the SAML on behalf of the
attacker).  Such things as impersonation of a user to an SP is then
possible.

For testing, I have found this tool to be most useful, and it is written
by the authors of the ROBOT paper so should be an accurate indication of
vulnerability to current attack methods, or at least the ones they
developed:

https://github.com/robotattackorg/robot-detect

In limited testing a small percentage of sites *were* found to be
vulnerable.  The majority of those sites were due to vulnerable load
balancers which had access to the SAML key material.  Due to load
balancer use, it's often not the IdP operator that is in a position to
remedy the immediate problem.  (I know F5s have patches available)

The immediate remedy I would suggest if a site is vulnerable would be to

1) Patch the vulnerable device/software (load balancer, Tomcat/Java/JSSE
stack, etc.)
2) Inspect the cipher suite used and adjust accordingly
3) Determine a longer term strategy around points 1 & 2 in the advisory
recommendations (and in his follow up email just now).

My testing suggests that vulnerability is reasonably rare, but it is a
major vulnerability when it exists.

Best,
Shannon

On 1/24/18 9:03 AM, Mark Cairney wrote:
> 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
>>
> 