ROBOT Attack – Security Advisory for the Shibboleth Identity Provider
- Home
- chevron_right
- General
- chevron_right
- ROBOT Attack – Security Advisory for the Shibboleth Identity Provider
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
Recent Posts
- Here to spread the word: DAASI International at it-sa 2024
- Federation Services – the new module in didmos
- New partnership: DAASI International and Remelda Technologies for secure and innovative software solutions
- Career in focus: DAASI International at the Tigers Career Day 2024
- AARC revolutionises authentication and authorisation in research
Categories
Newsletter
DAASI Newsletter 01/2024
DAASI Newsletter 02/2024
DAASI Newsletter 03/2024
Past Newsletters