Die Authentifizierung von Webanwendungen mittels des deutschen elektronischen Personalausweises lässt sich mit einem einfachen Trick aushebeln. Ein Sicherheitsforscher konnte sich – unter Verwendung einer bestimmten Software – mit den Daten von Goethe authentifizieren. Ergänzung: Eine Stellungnahme der Kopernikus KG, die die Randbedingungen verdeutlicht, wurde als Kommentar angefügt.
Anzeige
Mit dem deutschen Personalausweis können sich deren Besitzer auch elektronisch ausweisen. Dazu werden die neuen Personalausweise seit dem 1. November 2010 in Deutschland mit einem RFID-Chips ausgestattet.
Authentifizierung per Personalausweis
Die Authentifizierung per Personalausweis ermöglicht es einer Webanwendung die Identität des Benutzers festzustellen. Eine manuelle Kontrolle des Personalausweises zur Verifizierung der Daten ist nicht mehr notwendig. Private und öffentliche Organisationen bieten diese komfortable Login-Variante zur Auswahl (z.B. Elster Elektronische Steuererklärung, diverse De-Mail Dienste, diverse Versicherungen).
Der Benutzer benötigt neben dem Personalausweis noch einen Kartenleser und eine passende Client-Software. Diese Software kommuniziert dabei mit einem vertrauenswürdigen Authentifizierungsserver, der die Anfrage signiert. Eine signierte Anfrage liegt im SAML-Format vor. Diese wird anschließend an die jeweilige Webanwendung, die die Personalausweisfunktion nutzt, weitergeleitet und von dieser geprüft. Für solche Webanwendungen stellt die Firma Governikus eine in Java geschriebene Bibliothek bereit, das sogenannte Autent SDK.
Spezielle Fassung einer Client-Software
Im Rahmen eines Sicherheitstests entdeckte SEC Consult eine kritische Schwachstelle in der Governikus-Bibliothek. Diese Schwachstelle (in einem SDK) erlaubte es Angreifern, sich online als beliebige Person auszugeben. Dazu muss die Anfrage, die an die Webanwendung weitergeleitet werden soll, die Daten in der URL in einer GET-Variablen namens SAMLResponse kodieren. Das Problem: Man kann diese Variable auch mehrfach in der URL angeben. Die Autent-Software prüft dann die Signatur der letzten in der URL übergebenen Variablen. Verarbeitet werden aber die Daten aus der ersten übergebenen Variablen.
(Quelle: YouTube)
Als Konsequenz könnte ein Hacker (in dieser Anwendung) eine gültig signierte SAML-Anfrage versenden, aber in deren URL eine beliebige nicht signierte SAML-Anfrage mitschicken. Diese wird dann ungeprüft übernommen. Neben dem SEC Consult-Artikel hat auch Golem einen Beitrag veröffentlicht, der sich mit dem Sachverhalt auseinander setzt.
Governikus: Personalausweis-Webanwendungen lassen sich austricksen #personalausweis https://t.co/JsitVYoSJW
— Golem.de (@golem) 21. November 2018
An dieser Stelle der Hinweis: Das betrifft nicht den Personalausweis an sich, sondern eine bestimmte Anwendung zur Verifikation einer Person. Ergänzung: Es tritt wohl nur in einer Demofassung auf. Beachtet daher die nachfolgend als Kommentar angefügte Stellungnahme der Kopernikus KG. Das Beispiel zeigt aber wieder einmal, dass der Teufel im Detail liegt und Client-Software ein Einfallstor für Angriffe sein kann.
Anzeige
2015
Es gibt nichts, was nicht manipuliert werden kann. Selbst auf DNA-, Iris- und Fingerabdruck-Scanner ist kein Verlass, aber zumindest sind die GeStaPo-Nazis zufrieden und einige Konzerne machen fette Beute auf dem Milliardenmarkt — und darauf kommt es letzlich doch an.
Auf DNA ist kein Verlass?
Frag mal bei der Polizei und bei den Gerichten nach: Findet man deine DNA, bist du IMMER der Schuldige.
Wer auch Java einsetzt…
Das gehört abgeschafft. So wie flash player
Greift jemand die Daten (Fingerabdruck habe ich abgelehnt) irgendwo auf dem Weg ab, dann hast ein Riesenproblem!
Das Kabel vom Fingerabdruckleser (Unterseite ohne Aufdruck/Beschriftung) landet in einem Windowsrechner …
NFC Funktion habe ich per Induktionsherd deaktiviert, der Perso bleibt gültig!
Eine Woche vor dem neuen Perso bekam ich eine neue EC Karte, jetzt mit NFC.
Liebe Frau Sparkasse, das deaktivieren Sie bitte bei mir. Kein Thema, ich sollte aber auf einem Pad digital (Win Rechner) unterschreiben. Kurze Debatte, Sie druckte ein Formular aus und ich unterschrieb analog ;-)
Der DHL Bote bekommt auf sein Pad etwas was nicht im entferntesten nach meiner Unterschrift aussieht.
Die Bankkarten habe ich durchbohrt. Alle 3 funktioieren noch, nur eben NFC nicht mehr!
@nook
Vielen Dank – Du sprichst mir aus der Seele.
Ich muß jetzt nur mehr vom Boden hochkommen denn ich liege noch immer vor Lachen.
Ergänzung: Stellungnahme der Kopernikus KG
Von der Kopernikus KG wurde eine Stellungnahme zum obigen Thema versandt, die ich nachfolgend unkommentiert wiedergebe. Hier der Text in unkommentierter Form.
Stellungnahme zur Berichterstattung einer Schwachstelle im
Governikus Autent SDK
Diese Information dient der Klarstellung der aktuellen (November 2018) Berichterstattung zu einer Schwachstelle im Governikus Autent Software Development Kit (SDK) in der Version 3.8.1 und der daraus resultierenden und von der Presse aufgegriffenen Rückschlüsse zu unsicheren Implementierungen der eID-Funktion des deutschen Personalausweises: Im vergangenen Jahr wurde im Rahmen eines Anwenderforums zur AusweisApp2 von Governikus ein Demobeispiel auf Basis des Governikus Autent SDK vorgestellt, um die unkomplizierte und schnelle Implementierung der eID-Funktion des Personalausweises bei Diensteanbietern zu verdeutlichen. Dieses Demobeispiel wurde auch öffentlich zum Download zur Verfügung gestellt, ohne das vollständige Governikus Autent SDK zu beinhalten.
Das Unternehmen SEC Consult hat anhand dieses Demoszenarios, das ausdrücklich zu keinem Zeitpunkt den Anspruch hatte, eine vollumfängliche Implementierung im Realbetrieb vorzunehmen, eine Prüfung auf Schwachstellen vorgenommen und im Juli d.J. dem CERT-Bund eine Schwachstelle gemeldet.
Das von SEC Consult beschriebene Angriffsszenario bedient sich des Umstandes, dass im Demoszenario des Autent SDKs die Prüfung einer „SAMLResponse" zwar korrekt durchgeführt, anschließend aber ein weiterer angehängter Parameter mit dem Namen „SAMLResponse" verarbeitet wird. Während die Prüfroutine aus dem Autent SDK kommt, handelt es sich bei der Verarbeitung der SAMLResponse um einen Standardaufruf auf der Servlet API (getParameter) und ist somit Teil der Beispiel-Implementierung und hat nichts mit dem Autent SDK zu tun.
Die im Autent SDK enthaltenen Demoszenarien sind, wie aus dem Namen ersichtlich, zur Demonstration der Bibliotheken gedacht. Sie hatten und haben allerdings nicht den Anspruch, weitere Sicherheitsmaßnahmen, die im Realbetrieb erforderlich sind, zu erwähnen oder gar zu implementieren.
Diese müssen durch die jeweiligen Diensteanbieter bzw. Betreiber solcher Dienste ergriffen werden, zum Beispiel zum Schutz vor XSS-Angriffen, SQL-Injection, Replay-Angriffen usw. Diese URL-Prüfungen sind die Maßnahme, die den Angriff verhindert. Das von der OASIS spezifizierte und offene Protokoll „SAML Web Browser SSO Profil" (Redirect Binding) findet hier Anwendung. Das SAML Protokoll ist bewusst so offen, dass weitere Parameter übermittelt werden können, wenn das von der entsprechenden Anwendung benötigt wird. Die Prüfungsregeln für den Diensteanbieter ergeben sich u.a. aus dem Standard selbst
( siehe Abschnitt 3.4.4.1 „(…) the relying
party MUST ensure that the parameter values to be verified are ordered as required by the signing rules above"). Die zu ergreifenden Maßnahmen ergeben sich aus OASIS- und OWASP-Empfehlungen, welche von unseren Kunden im Rahmen der Integration beachtet und als Voraussetzung bei der Implementierung genannt werden. In diesem Fall sind besonders die Empfehlungen von OWASP
(Input Validation Cheat Sheet) zu beachten. Aber selbstverständlich müssen anwendungsbezogen weitere Maßnahmen umgesetzt werden.
An dieser Stelle nochmals der Hinweis: Das Demo-Szenario enthält nicht das vollständige Autent SDK und kann so nicht für eine vollständige Implementierung einer im realen Betrieb durchgeführten Personalausweisintegration verwendet werden und sollte lediglich verdeutlichen, wie einfach eine Implementierung vorgenommen werden kann! Dass allerdings im Realbetrieb weitere Maßnahmen im Rechenzentrum durchgeführt werden müssen, war nicht Bestandteil des Demoszenarios.
Wir stimmen insofern mit der Einschätzung überein, dass ein Beispiel häufig ungewollt übernommen wird, auch wenn die beigelegte Readme-Datei darauf hinweist, dass es eine Demo ist, welche zudem nur auf localhost läuft. Deswegen haben wir bereits im August 2018 einen Quick-Fix in die entsprechende Routine
aufgenommen, die einen Fehler zurückmeldet, wenn relevante URL-Parameter (SigAlg, SAMLResponse, RelayState) tatsächlich mehr als einmal vorkommen. Diese Aktualisierung haben wir unseren Kunden umgehend zur Verfügung gestellt. Diese inhaltliche Prüfung wird in Realszenarien durch die o.g. Umsetzung
der OASIS- und OWASP-Empfehlungen allerdings auch vor der Verarbeitung im SDK bereits durchgeführt.
Selbstverständlich läuft das SDK nur in Java-Umgebungen und die Online-Ausweisfunktion ist auch nur eine Anwendungsmöglichkeit. Darüber hinaus ist das SDK ein Produkt der Governikus. Daher kann es nicht stellvertretend für die Online-Ausweisfunktion stehen.
Der sowohl von SEC Consult als auch von einigen Berichterstattern aufgegriffene Rückschluss, sämtliche mit Autent realisierten Integrationen der eID-Funktion des Personalausweises wären unsicher, ist damit schlicht und ergreifend falsch.