ROBOT-Attacke – Security Advisory zum Shibboleth Identity Provider

Am 23. Januar 2018 wurde ein weiteres Security Advisory zum Shibboleth Identity Provider veröffentlicht, worüber wir Sie hiermit in Kenntnis setzen möchten.

Die Schwachstelle basiert auf der sogenannten ROBOT-Attacke, bei der ein Angreifer HTTPS-Datenverkehr mitlesen und verändern kann, wenn der Webserver die veraltete RSA-Verschlüsselung anbietet. Im Falle eines Identity Providers (IdP) kann ein Angreifer durch einen betroffenen vorgeschalteten Webserver gefälschte SAML-Assertions an Service Provider (SP) ausstellen. Ein SP würde diese Assertions von IdP akzeptieren, wenn der öffentliche Schlüssel eines solchen Zertifikats in den SAML-Metadaten des IdP als Signatur-Zertifikat genannt wird. Dies kommt a) bei fehlender Trennung von Webserver- und SAML-Zertifikat vor, und b) bei Verwendung von Backchannel-Kommunikation (Artifact, Attribute Query, zumeist auf Port 8443).

1. Unsere kurzfristige Empfehlung lautet daher, die verwendeten Webserver (Apache, IIS) auf Unterstützung von RSA zu untersuchen bzw. diese Verschlüsselungsalgorithmen zu deaktivieren. Algorithmen, die RSA mit DHE oder ECDHE kombinieren, sind sicher. Auch ihre verwendeten Load Balancer müssen überprüft werden; laut robotattack.org sind hier namhafte Hersteller betroffen. Es muss weiterhin der Backchannel-Port 8443 des Shibboleth IdP überprüft werden, sofern dieser verwendet wird.
2. Unsere mittelfristige Empfehlung ist es, zusätzliche Zertifikate für die betroffenen Server auszustellen, die nur für die SAML-Signatur und nicht für HTTPS/TLS verwendet werden. Diese müssen natürlich den Vorgaben der angebundenen SAML-Föderationen entsprechen.
3. Nach Möglichkeit wird außerdem empfohlen, die Backchannel-Kommunikation auf Port 8443 entweder zu deaktivieren (wenn vertretbar) oder auf Port 443 zu verlagern (was Shibboleth IdP 3.x und Shibboleth SP 2.5.x unterstützen). Diese Entscheidung muss nach einer Nutzungsanalyse von Fall zu Fall getroffen werden.

Im Falle einer erfolgreichen Attacke muss das betroffene Webserver-Zertifikat nicht ausgetauscht werden, da der private Schlüssel hierbei dem Angreifer nicht offenbart wird.

Für alle Kunden, die das Support-Modul „Betrieb IdP“ und „Betrieb SP“ gebucht haben, haben wir die unter 1. beschriebene Überprüfung durchgeführt. Es war kein System betroffen. Die Änderungen von 2. werden bei unseren Supportkunden durchgeführt, sobald die aktuellen TLS-Zertifikate auslaufen. Ebenso werden wir für unsere Supportkunden Analysen für Maßnahme 3 durchführen, konkrete Empfehlungen ausstellen und in Abstimmung umsetzen.