Wie funktioniert der Angriff?
Die von der Schwachstelle betroffene Komponente (Governikus Autent SDK) dient Online-Angeboten dazu mit wenig Aufwand eine Ausweis-Identifikation zu integrieren. Unter anderem kann diese Komponente prüfen, ob das Ergebnis einer Identifizierung, das der eID-Client sendet, gültig ist. Die Überprüfung dieser Daten erfolgt in zwei Schritten:
- Um sicherzugehen, dass dieses Ergebnis nicht gefälscht ist, wir im ersten Schritt die digitale Signatur der empfangenen Daten überprüft. Sind diese Daten nicht gültig vom Authentifizierungsserver unterschrieben, wird der Identifizierungsprozess abgebrochen.
- Im zweiten Schritt erfolgt die Überprüfung der signierten Daten, etwa ob der Ablaufzeitpunkt des Ergebnisses überschritten wurde. Die erhaltenen Daten werden von der Webanwendung weiterverarbeitet.
Durch eine Schwachstelle war es möglich, den beiden Verarbeitungsschritten unterschiedliche Daten zu senden. Für die Prüfung im ersten Schritt kann ein Angreifer gültige Daten mit einer gültigen Signatur senden. Da in diesem Fall die Signaturprüfung erfolgreich ist, wird die Verarbeitung fortgesetzt. Für den zweiten Schritt sendet der Angreifer manipulierte Daten ohne eine Signatur. Diese manipulierten Daten werden von der Anwendung als gültig angenommen und für die weitere Verarbeitung verwendet.
Technische Details
Die Authentifizierung gegenüber einer Webanwendung kann sowohl durch ein SOAP-basiertes Protokoll (eID) als auch durch SAML erfolgen. Von dieser Schwachstelle betroffen ist die SAML-basierte Authentifizierung. Grob funktioniert diese Authentifizierung folgendermaßen (eine detailliertere Beschreibung findet sich in BSI TR-03130):
- Der Benutzer wählt in der Webanwendung aus, dass er eine Ausweis-Authentifizierung wünscht. Danach leitet die Webanwendung den Browser auf eine Loopback-Adresse um. Bei der Demo-Anwendung sieht die aufgerufene URL beispielsweise so aus:
127.0.0.1/eID-Client - Auf diesem lokalen TCP-Port horcht der eID-Client. Dieser führt nach Aufruf der URL die Authentifizierung durch. Der eID-Client kommuniziert dazu mit der Webanwendung, mit einem Authentifizierungs-Server sowie der Chipkarte im Personalausweis.
- Nach erfolgreicher Authentifizierung überträgt der eID-Client die SAML-Response inklusive der ausgelesenen Ausweisdaten per HTTP GET an die Webanwendung:
<host>/<pfad> Response>&RelayState=[...]&SigAlg=<Signatur-Algorithmus>&Signature=<Signatur>
Häufig wird bei SAML-Authentifizierung die in der Response enthaltene Assertion durch eine XML-Signatur signiert. Die Ausweis-Authentifizierung verwendet das durch die OASIS spezifizierte „Web Browser SSO Profil“, bei welchem die Response keine Signatur enthalten muss. Stattdessen wird eine Signatur über den gesamten Query String (also über alle HTTP-Parameter) gebildet und als Parameter „Signature“ an diesen angehängt. - Der Browser wartet bis zu diesem Zeitpunkt auf eine Antwort der im Schritt 1 gestellten Anfrage. Diese wird nun vom eID-Client mit einer Weiterleitung zurück zur Webanwendung (HTTP 303) beantwortet. Der Benutzer ist nun gegenüber der Webanwendung authentifiziert.
Um die in Schritt 3 übertragene Signatur zu verifizieren, bietet das Governikus Autent SDK die Methode HttpRedirectUtils.checkQueryString an. Der folgende Auszug aus der Demo-Anwendung demonstriert wie diese Methode zu verwenden ist:
// check the signature of the SAML response. There is no XML signature in this response but the // parameter are signed. if (!HttpRedirectUtils.checkQueryString(request.getQueryString(), SamlExampleHelper.SERVER_SIG_CERT)) { storeError(request, response, "Signaturprüfung der SAML-Response fehlgeschlagen!"); return; }
Diese Methode nimmt den gesamten Query-String als Parameter, parsed diesen, erstellt eine kanonisierte Version des Query-Strings und prüft anschließend darauf die Signatur.
Danach wird der Parameter SAMLResponse geparsed:
// get the parameter value String samlResponseBasee64 = request.getParameter(HttpRedirectUtils.RESPONSE_PARAMNAME); [...] // parse the SAML Response. ParsedResponse parsed = parser.parse(samlResponse);
Die Schwachstelle nutzt den Umstand, dass es HTTP zulässt, in einem Request mehrere Parameter mit gleichem Namen anzugeben. Wenn die Methode HttpRedirectUtils.checkQueryString eine kanonisierte Form des Query Strings erstellt, werden die Parameter daraus entnommen und erneut in einer definierten Reihenfolge zusammengesetzt. Der Fall, dass ein Parameter mehrmals auftreten kann, wird dabei nicht berücksichtigt.
Das Verhalten der Servlet-API unterscheidet sich vom Verhalten dieser Methode: Während die Methode HttpServletRequest.getParameter gemäß der Servlet-Spezifikation den ersten einem Namen entsprechenden Parameter liefert, verwendet die Methode HttpRedirectUtils.checkQueryString aus dem Governikus Autent SDK stets den zuletzt vorkommenden Parameter.
Gibt ein Angreifer daher den Parameter SAMLResponse mehrmals an, wird die Signatur auf den letzten Parameter geprüft, während die SAML-Response, welche fortan verwendet wird, aus dem ersten gleichnamigen Parameter gelesen wird.
Mögliche Exploit-Szenarien
Um die Schwachstelle auszunutzen, benötigt ein Angreifer zumindest einen gültig signierten Query-String von einem Authentifizierungsserver. Es ist dabei unerheblich für welchen Bürger oder zu welchem Zeitpunkt dieser ausgestellt wurde. Natürlich sind die Signaturen der Query-Strings nur kurzzeitig gültig, bei einem Angriff findet die Überprüfung des Ablaufszeitpunkts jedoch auf den manipulierten Daten statt.
Ein Authentifizierungsserver kann nur für eine Webanwendung gedacht sein oder mehrere Webanwendungen bedienen. In der Praxis wird des Öfteren eine gemeinsame Instanz für mehrer Dienste verwendet (der Server eid1.eid-service.de wird z.B. zumindest von der BStU, dem Bundesamt für Justiz und der Deutschen Rentenversicherung verwendet). Ein von einem geteilten Authentifizierungsserver gültig signierter Query-String kann von einem Angreifer bei allen zugeordneten Webanwendungen für Angriffe missbraucht werden.
Natürlich könnte sich ein Angreifer einmalig selbst an einer Webanwendung authentifizieren, um an einen gültige Query-String zu gelangen. Das bedeutet jedoch, dass während eines Angriffs eine dem Angreifer zuordenbare SAMLResponse im Access-Log auftaucht und dieser damit leicht zu identifizieren wäre. Ein Angreifer könnte jedoch auch Query-Strings aus Logdateien von Servern oder Clients wie der AusweisApp oder der Alternative Open Ecard verwenden. Solche Logdateien können mit einer schnellen Google suche leicht online gefunden werden (z.B. „richclient_info.log+SAMLResponse“ oder „AusweisApp2 filetype:log“).
Demo
Dieses Video zeigt wie ein Angreifer sich als fiktive Person „Evil Attacker“ gegen die Demo-Anwendung authentifizieren kann:
Einschränkungen
Bei Diensten, die eine vorhergehende Registrierung erfordern, ist dieser Angriff nur bedingt durchführbar. Die Spezifikation sieht sog. Pseudonyme vor. Ein Pseudonym ist ein zufällig aussehender String, welcher vom Personalausweis bereitgestellt wird. Für jede Webanwendung generiert der Personalausweis einen unterschiedlichen String. Bei der erstmaligen Registrierung wird dieses Pseudonym von der Webanwendung gespeichert. Bei einem späteren Login muss die Webanwendung nur mehr das Pseudonym abrufen und mit den in der Datenbank gespeicherten Pseudonymen vergleichen.
Da das Pseudonym eines fremden Benutzers nicht leicht zu erraten ist, kann sich ein Angreifer nicht ohne Weiteres als fremder Benutzer an einer solchen Webanwendung anmelden. Anwendungen mit einmaliger Registrierung sind dennoch von dieser Schwachstelle betroffen, weil der Angreifer dazu auch einfach ein zufälliges Pseudonym wählen könnte.
Desweiteren ist diese Schwachstelle nur bei Webanwendungen ausnutzbar, welche die Methode HttpServletRequest.getParameter (s. oben) verwenden. Lehnt eine Anwendung mehrmals vorkommende Parameter ab, so kann die Schwachstelle in der betreffenden Webanwendung nicht ausgenutzt werden. Auch eine Web Application Firewall (WAF), deren korrekte Konfiguration mehrfach vorkommende Parameter abweisen kann, würde diesen Angriff ebenfalls verhindern.
Wer ist betroffen?
Betroffen sind Webanwendungen, welche Versionen kleiner oder gleich 3.8.1 des Governikus Autent SDKs für SAML-Authentifizierung verwenden und HTTP-Parameter wie oben beschrieben behandeln.
SEC Consult hat keine Informationen dazu, welche bzw. wie viele Webanwendungen diese Angriffsvoraussetzungen erfüllen. Wir gehen jedoch davon aus, dass ein großer Teil der Webanwendungen, welche die Bibliothek verwenden betroffen ist, da wir vermuten:
- dass viele Anwendungen typischerweise wie oben beschrieben mit HTTP-Parametern umgehen (d.h. dass die Methode HttpServletRequest.getParameter verwendet wird) insbesondere, da vermutlich viele Entwickler die Demo-Anwendung als Vorlage verwendeten
- und dass aufgrund diverser legitimer Anwendungsfälle für gleichnamige HTTP-Parameter (z.B. bei PHP Übergabe von Arrays) diese nicht blockiert werden.
Da diese Komponente auf ausweisapp.bund.de zum Zeitpunkt des Researchs zum Download angeboten wurde, gehen wir davon aus, dass ein großer Teil (bzw. möglicherweise alle) Webanwendungen, die eine Ausweis-Authentifizierung anbieten, diese Bibliothek verwenden. Die Demo-Anwendung, welche auch das betroffene SDK beinhaltete, steht inzwischen auf der Webseite von Governikus nicht mehr zum Download zur Verfügung.
Fehlerbehebung
Wir haben die beschriebene Schwachstelle im Juli 2018 an das CERT-Bund kommuniziert. Das CERT-Bund (BSI) übernahm weitere die Kommunikation und Koordination mit dem Hersteller. Bereits im August stellte Governikus eine fehlerbereinigte Version (3.8.1.2) des Autent SDKs bereit und informierte die betroffenen Kunden.
Betreibern von Webanwendungen, welche die Bibliothek noch immer in einer verwundbaren Version verwenden, empfehlen wir dringend die Version auf die aktuellste anzuheben. Da der beschriebene Angriff eindeutige Spuren im Access-Log des Web- oder Applikationsservers hinterlässt (mehrfach vorkommende Parameter mit gleichem Namen), empfehlen wir betroffenen Organisationen außerdem eine forensische Analyse auf solche Logs durchzuführen.
Update 26.11.2018
In einer offiziellen Stellungnahme sowie auf Twitter äußert sich Governikus KG zur kürzlich im SEC Consult Blog veröffentlichten und von Medien aufgegriffenen Schwachstelle. Das SEC Consult Vulnerability Lab steht für Genauigkeit sowohl in der Analyse als auch Kommunikation, weshalb Governikus das geplante technische Advisory als auch den Blog-Artikel vorab zur Durchsicht bekam (siehe auch „Vendor Contact Timeline“ im zugehörigen Advisory).
Unsere Security Consultants waren seit Juli 2018 mit Governikus über CERT-Bund in Abstimmung. So war es möglich, auch Feedback von Governikus direkt in den finalen Blog-Artikel einfließen zu lassen. Bis dahin empfanden wir die Kommunikation zwischen Governikus und SEC Consult sehr professionell und lösungsorientiert.
Ausgehend von der Aussage, dass der Angriff laut Governikus mit echten Applikationen nicht möglich sei, ist es bedeutend die Umstände offen zu legen, die zur Identifikation der Schwachstelle geführt haben: Während der Überprüfung im Zuge eines Projektes einer im Internet erreichbaren Web-Anwendung wurde die genannte Authentifizierungs-Schwachstelle gefunden. Um die Kommunikation sowohl zu Governikus als auch der Öffentlichkeit zu erleichtern, entschieden wir uns die Schwachstelle anhand einer öffentlich verfügbaren Komponente (konkret die Governikus Demo Anwendung, die bis vor Kurzem noch zum Download verfügbar war) nachzustellen.
Aus diesem Grund wussten wir von zumindest einem Fall zusätzlich zur Demo-Applikation, wo die Schwachstelle einen Angriff zulassen würde. Unabhängig davon haben wir und würden wir nie behaupten, dass alle Applikationen mit der Governikus Autent SDK automatisch verwundbar sind. Wir haben vielmehr versucht, die technischen Details der Schwachstelle bestmöglich darzulegen und etwaige Einschränkungen, wie in unserem Blog Post beschrieben, aufzuzeigen.
Diese Forschungsergebnisse wurden von Wolfgang Ettlinger (@ettisan) im Rahmen des SEC Consult Vulnerability Lab erarbeitet und auch als Security Advisory veröffentlicht.
