-----BEGIN PGP SIGNED MESSAGE----- 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 , 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 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJaZ5D+AAoJEDeLhFQCJ3liaAIQAKNFbVpIGYQ49p1+FqDT2qWx jhQrVqiiLXPRehCwlASIzdfRq/md9Hsm0pFClSIVW4jJjNx5BUEjoo/21z+a2/mi ThHYCwlXSaZd6TcqAQJW39wtju2osUS1O7hOmnGQwm4/rJLACQekRYIQ8ZTGnvjm OYIV68LjyN4KHhnwnzSooGC0XehI6TvTndaQCCzozGUkCfUiP9wGzMN/8KSEGSI1 4WDSKdcbxB/jxcqDYAX5NrPtwNJH0kfKyySlCGTTmUnibK5HpG9ZY5XjBvnhLo/E 7knFy8+m4reRTKoqyhegSb0fdVS9nweuUj5JOcUHMURFkH87esjg8xX5bKVnyIoR vkku1e7zL4uUVUQuZ+pvTYT+UPrdMYfEwH0sgiEEdllyLTVeo3KA8klasoh8rOsN DXPdoXTVsLePKDawB4V0VKzOpuvXG/oRDqbNVD8Jdqbbh2V238L3/23bQ6JtGd6K HSWiJHY9Thfwlyectn/BnH3Wqk1Q0XuFJg9CboBNbaixNfeQdO1BPUZCuJv/dMoO snFUuEJBbsZ7MW3ScznzINw5SxPl5C86LQP6h2ZK9XIo6MM063P5fSzo3vvl3QJ7 xBQ/Us2zwMLYfu0zwA9A0pABilfcbSgSqW/x3HcgO8O/P4ehtfKTlMK1csbJIDLQ cBkq1IfMHpNbSawTNjEc =Putk -----END PGP SIGNATURE-----