We would like to inform you about a new security advisory for the Shibboleth Identity Provider, which was published on 23rd January 2018.
The vulnerability is based on the so-called ROBOT Attack which allows attackers to read and modify the HTTPS data traffic if the webserver offers an outdated RSA encryption. In case of an Identity Provider (IdP), the attacker is able to issue faked SAML assertions to a Service Provider (SP) by utilizing such a preceding webserver. An SP would accept those assertions from the IdP if the public key of such a certificate is mentioned in the SAML metadata of the IdP as signature certificate. This occurs a) if the webserver and the SAML certificate are not segregated, and b) if a back-channel communication is used (Artifact, Attribute Query, typically run on port 8443).
- Therefore, in the short term we recommend to examine if the utilized webserver (Apache, IIS) is supported by RSA, or to deactivate these encryption algorithms. Algorithms that combine RSA and DHE or ECDHE can be considered as secure. Additionally, their Load Balancers have to be reviewed as well; according to robotattack.org, reknowned developers are afflicted. Furthermore, the back-channel port 8443 of the Shibboleth IdP has to be checked if it is used.
- Our medium-term recommendation is to issue further certificates for the afflicted servers that are only used for the SAML signature and not for HTTPS/TLS. Of course, they must meet the specifications of the connected SAML federation.
- If possible, we recommend either to deactivate the back-channel communication of port 8443 (if acceptable), or to relocate the communication to port 443 (which is supported by Shibboleth IdP 3.x and Shibboleth SP 2.5.x). This decision has to be made on a case-by-case basis after a utilization analysis.
In case of a successful attack, the afflicted webserver certificate does not have to be replaced, because the private key is not revealed to the attacker.
For all our clients who have subscribed to the support modules “Operation IdP” and “Operation SP”, we have executed the examination described under 1. No system was afflicted. The steps of 2. will be implemented as soon as the current TLS certificates expire. Furthermore, we will execute all measures of 3. for our support clients, give detailed recommendations and implement them in coordination with the clients.
Subscribe to our newsletter
- DAASI International Will Become an “Architect for the Next Generation Internet”
- Graduate Thesis at DAASI International: Interview with Gabriel Dimitrov
- DAASI International released new version of their open source solution didmos
- Cooperation between the Publishing House Cornelsen and DAASI International enables SCIM Interface to midPoint
- Video Conference Tool for NGOs Free of Charge – DAASI International Provides Jitsi Servers