BundID: Eine digitale Identität schafft (falsches) Vertrauen
Die BundID ist als das zentrale Anmeldesystem für Verwaltungsdienstleistungen zu einem Single Point of Failure in der deutschen Verwaltungsinfrastruktur geworden. Und damit auch zu einem idealen Ziel für die verschiedensten Angriffe. Dank ihr und einer kleinen Sicherheitslücke wurden nun die Verwaltungsportale von Hunderten Kommunen unbenutzbar.
Die BundID ist ein Dienst des Innenministeriums und ist unter https://id.bund.de erreichbar. Dort können Bürger*innen ein Nutzer*innenkonto anlegen und dieses mit ihrem Personalausweis verifizieren. Mit diesem Konto ist es möglich, sich bei anderen Verwaltungsdiensten im Internet anzumelden. Aktuell geht das bei einigen Leistungen des Bundes wie z.B. dem Elterngeld, BAföG digital oder im letzten Jahr bei der Einmalzahlung 200. Außerdem kann man in einigen Bundesländern und bei etwa 300 Kommunen online Formulare ausfüllen. Da kann man dann z.B. online einen Hund anmelden oder einen Bauantrag stellen.
Die Anmeldung mit der BundID funktioniert ähnlich wie bei einem “Login mit Facebook”-Button. Eine Webseite der Verwaltung fragt bei der BundID an, ob sie einen User verifizieren kann, indem sie ihn zur Webseite der BundID weiterleitet. Der User loggt sich dann der BundID ein und die Daten werden an die Webseite der Verwaltung übermittelt und der User dorthin weitergeleitet.
Die Authentifizierung kann dabei in mehreren Vertrauensstufen erfolgen. Die Vertrauensstufe sagt aus, wie sicher sich die BundID ist, dass der User seine echten Daten eingegeben hat. Eine niedrige Vertrauensstufe haben User, die ihre Daten selbst eingegeben haben und sich mit einem selbst gewählten Nutzernamen und Passwort anmelden. Eine hohe Vertrauensstufe erhalten jene, die ihre Daten elektronisch aus dem Personalausweis ausgelesen haben.
Die BundID soll dabei als Vertrauensanker dienen. Wenn ein Login über die BundID auf einer Webseite möglich ist, dann soll das bedeuten “Ich habe mich gerade bei der Verwaltung eingeloggt und kann der Webseite bzw. Verwaltungsleistung vertrauen”. Das ist insbesondere wichtig, da es in Deutschland mittlerweile einige Hundert Verwaltungswebseiten gibt und es so immer einfacher für Betrüger wird, eine gefälschte Verwaltungswebseite zu bauen.
Deswegen ist es wichtig, dass die Systeme der BundID so geschützt sind, dass niemand einfach auf seiner Webseite einen BundID-Login integrieren kann. Weil sonst Menschen denken könnten, dass sie sich gerade in einem legitimen Verwaltungsprozess befinden, während sie z.B. gescammt werden.
Die Technik
Die BundID benutzt für die Authentifizierung das sogenannte SAML-Verfahren. Dabei wird (vereinfacht) eine Anfrage an die BundID vom Verwaltungsverfahren generiert und diese Anfrage dann mit einem geheimen Schlüssel signiert. Dank des geheimen Schlüssels weiß die BundID dann “Das ist eine Anfrage von einem Portal, dem ich vertrauen kann” und der User kann sich einloggen und wird mit signierten Daten, die vom Verwaltungsverfahren angefragt wurde, wieder zurück zur Webseite geschickt.
Das SAML-Verfahren ist grundsätzlich relativ sicher. Es ist aber kompliziert zu implementieren und die meisten Entwickler haben das noch nie gemacht. Das liegt auch daran, dass es neben dem SAML-Verfahren auch noch das OAuth-Verfahren gibt, welches ähnlich funktioniert, aber viel verbreiteter ist und zu dem es mehr Dokumentation und fertige Software gibt. Es ist also für Entwickler relativ schwierig, SAML richtig sicher in ihrer Applikation zu integrieren.
Wenn man das SAML-Verfahren also implementiert, können schon einmal Fehler unterlaufen. Und wenn viele Menschen das Verfahren auf vielen unterschiedlichen Webseiten implementieren, dann ist es sogar wahrscheinlich, dass jemandem ein Fehler unterläuft.
Das Verfahren ist aber nicht nur technisch kompliziert, sondern auch organisatorisch. So müssen für die benötigten Zugänge und Zertifikate viele Excel-Listen ausgefüllt und hin und her geschickt werden. Ein Prozess, bei dem auch mal etwas schiefgehen kann.
Die Lücke
Weil ich weiß, wie oft SAML falsch implementiert wird, habe ich also in den Verwaltungsportalen von Städten gezielt nach solchen Sicherheitslücken gesucht und bin auch innerhalb von etwa einer Stunde beim Durchsehen von Anmeldeprozessen fündig geworden.
Das Produkt OpenR@athaus von ITEBO wies einen solchen Fehler in der Implementierung auf. Der Hersteller wollte eine kleine Komfortfunktion zum SAML-Protokoll hinzufügen. Eine Funktion, die es ermöglicht, dass man als User nach dem Login direkt auf die richtige Webseite weitergeleitet wird. Also z.B. den Antrag, den man vor dem Login eigentlich ausfüllen wollte.
Das ist natürlich ein praktisches Feature und es gibt auch eine Möglichkeit, das korrekt zu implementieren. Allerdings wurde es in dem Fall falsch implementiert, was dazu führte, dass ich mich nach dem Login auf jede beliebige Webseite weiterleiten lassen kann.
Die Software OpenR@thaus wird nicht nur in einer, sondern angeblich in rund 300 Kommunen eingesetzt und die Sicherheitslücke existierte in jeder Instanz, die ich finden konnte.
Die Veröffentlichung
Nachdem ich die Lücke gefunden hatte, musste ich nun ihre potenzielle Auswirkung irgendwie demonstrieren. Also baute ich ein Fake-Verwaltungsverfahren. Den “Heizöl-2000” Antrag, bei dem Bürger*innen angeblich bis zu 2000€ Heizölkostenzuschuss bekommen können. Das hielt ich für so absurd, dass es niemand für ein echtes staatliches Angebot halten könnte.
So eine Scam-Seite zu bauen ist dank Diensten wie ChatGPT heute wirklich nicht mehr schwer und eine Stunde später hatte ich einen passablen Verwaltungsservice (Code).
Und so wurde aus einer kleinen Sicherheitslücke bei einer kleinen Kommune ein Antrag, den man so ähnlich zum Ausspähen von Daten oder zum Betrug von Menschen benutzen könnte.
Weil ich keine Lust auf den Papierkram hatte, habe ich die Lücke dann einfach getwittert.
Was danach passierte hat mich positiv überrascht:
Freitag 7. Juni
19:45 — Veröffentlichung der Lücke auf Twitter
21:46 — das Fachverfahren, welches für die Demonstration verwendet wurde, wurde durch das BMI abgeschaltet.
23:06 — nach einem Hinweis durch mich, dass viel mehr Portale über diese Sicherheitslücke verfügen, wurden sie auch alle abgeschaltet. (Darunter Braunschweig, Goslar, …)
Samstag, 8. Juni
08:00 das BMI sowie alle Dienstleister sind das ganze Wochenende mit Dienste abschalten und reparieren beschäftigt.
Sonntag, 9. Juni
- 06:00 — Ich sehe erste Hinweise auf Verwaltungswebseiten, dass die BundID nicht verfügbar ist.
- 10:00 erste Kommunen mit der BundID sind wieder online
Es ist noch einmal wichtig zu sagen, dass solche Fehler passieren, wenn viele Menschen ein kompliziertes Authentifizierungsverfahren implementieren. Nicht die Implementierung ist das Problem, sondern dass es überhaupt implementiert werden soll.
Die UX
In solchen Authentifizierungsmaßnahmen hätte es aber auch Wege gegeben, diese Risiken durch gutes Design zu mitigieren. So sind es User heute gewohnt, dass sie bei Anmeldeverfahren aktiv freigeben, an wen sie was übermitteln möchten, das fehlte in dem Prozess der Bund ID komplett.
Zum Beispiel wäre es möglich gewesen, eindeutig anzuzeigen, welche Institution warum Zugriff auf welche Daten erhält. Damit wäre es deutlich wahrscheinlicher, das ein potenzielles Scam-Opfer bemerkt, wenn es dort der Weiterleitung seiner Daten an ein ganz anderes Portal zustimmt als gedacht.
Das ist zwar keine Maßnahme, um die konzeptionellen Risiken zu vermeiden, aber es wird eben etwas schwieriger für Betrüger.
Grundsätzlich ist die Frage, ob viele einzelne Verwaltungsportale überhaupt eine gute Idee sind. Oder ob es nicht eigentlich eher ein Portal/App geben sollte, mit dem Bürger interagieren und welches dann die Daten direkt in die Systeme der zuständigen Verwaltung übermittelt. Dadurch könnten weniger Fehler in der Umsetzung passieren, es müssen keine 300 Hundesteueranträge gebaut und gewartet werden und die Qualität der User Experience könnte einfacher verbessert werden.
[In einem solchen gemeinsamen Verwaltungsportal könnten maschinenlesbare Anträge z.B. als JSONSchema über das PVOG bereitgestellt werden. Die Übermittlung der Antragsdaten könnte dann E2E-Verschlüsselt von der App in die Verwaltung via Fitconnect passieren.]
Die Politik
Ursprünglich war im Onlinezugangsgesetz einmal vorgesehen, dass es sogenannte Portalverbünde gibt, in denen Anträge zusammengeführt werden. Das wurde aber — wie so vieles im OZG-Kontext — nie umgesetzt.
Im OZG steht auch, dass jedes Bundesland ein eigenes ID-System implementieren muss. Also eine Berlin-ID, eine Hamburg-ID, …. Das haben die meisten Bundesländer auch getan. Dann merkte man, dass 17-mal dieselbe Infrastruktur zu betreiben, keine gute Idee ist. Deshalb wurden die 16 Landes-IDs durch eine Bundes-ID ersetzt.
Mit dem OZG 2.0 sollte die eine zentrale ID auch ins Gesetz. Zusammen mit der Regelung, dass die BundID freiwillig verwendet werden kann. Aber nicht verwendet werden muss. Diese Einschränkung wurde allerdings von vielen Kommunen und auch vom Bund in der Vergangenheit bereits ignoriert. So wurde z.B. beim Prozess der Einmalzahlung 200 vielfach kritisiert, dass das BundID-Konto obligatorisch war.
Und weil die Kommunen diese gesetzlichen Regelungen ignoriert haben, stehen sie jetzt, nachdem der Bund ihre BundID Integration abgeschaltet hat, ganz ohne digitale Verwaltungsdienstleistungen da.
Manche Menschen denken deshalb das dezentrale Anmeldesysteme über sogenannte Wallets eine bessere Alternative zur zentralen BundID wären. Welche noch schwerwiegenderen Probleme es mit denen gibt, haben Flüpke und ich z.B. schon im Kontext der ID-Wallet aufgezeigt.
Momentan ist geplant, dass die BundID in Zukunft noch mehr Aufgaben übernehmen soll. Zum Beispiel die Weitergabe von garantiert echten digitalen Nachweisen (z.B. Zeugnisse) an Verwaltungsleistungen oder auch Webseiten außerhalb der Verwaltung.
Garantiert echte digitale Nachweise sind grundsätzlich eine schlechte Idee. Gepaart mit einem zentralen System, das als ein Single Point of Failure agiert und dabei nicht einmal über Sicherheitsmaßnahmen nach Stand der Technik verfügt bzw. aufgrund seiner Architektur nicht darüber verfügen kann, ist ein Desaster.
Der Gesetzgeber sollte seine Chancen bei der weiteren Ausgestaltung des OZG 2.0 so wie im Implementierungsprozess des eIDAS 2.0 Standards nutzen und dieses Desaster verhindern.
Update 17.06 2024 — It was so nice — I did it twice!
Natürlich schaffte es ITEBO nicht, ihre Software dazu zu bekommen keine Redirects mehr zu machen. Also geht es jetzt wieder in der Demo oder hier als Video.
Das geht Dank einer Seit 2015 bekannten Lücke in der Software Liferay, auf der OpenRathaus basiert.
Timeline:
- 17.06-22:19 Veröffentlichung auf twitter/mastodon
- 18.06-07:40 Abschaltung aller ITEBO Instanzen verifiziert — wieder mal 300 Kommunen ohne digitale Verwaltungsleistungen. (09:20h bis Abschaltung)
- 18.06–12:50 Alle Open R@athaus Instanzen sind für “Wartungsarbeiten” offline. Vllt hat das BSI gemerkt, dass da noch mehr (z.B. CORS) im Argen liegt.
- 19.06-xx:xx Das BSI bezeichnet mich als “einschlägig auffällige Angreiferin”.
Eine zentrale ID als Vertrauensanker der Verwaltung ist eine schlechte Idee, versprochen.
Kommunen brauchen keine Dienstleistungen mit irgendwelchen Identitätssystemen dran auf ihrer Webseite (für die Hundesteueranmeldung reicht ein einfaches Formular…).
Für alles, wo eine staatliche Identität wirklich zweifelsfrei festgestellt werden muss — online und sofort — sollte einfach der Personalausweis benutzt werden.
Die BundID ist also unsicher und nutzlos.
Wenn ihr meine zivilgesellschaftliche Arbeit zu Themen wie z.B. Verwaltungsdigitalisierung, Sicherheitsforschung und Open Data unterstützen wollt, dann könnt ihr das via 💸Patreon💸 tun. Und wenn ihr bei meiner nächsten Recherche live dabei sein wollt, dann folgt mir auf Twitter oder Mastodon.
