Samstag, 30. Dezember 2017

Zum 20sten Jubiläum meines Schulprojekts explodiert das #beA

Es ist nun ziemlich genau 20 Jahre her - 1997, da ich 17 Jahre - da habe ich im Rahmen eines Schulprojekts schon ein ähnliches System gebaut.

Damals waren Dinge wie PGP noch recht neu. Wir haben da mit 6 Leuten zusammen einen Keyserver und Mailcrypto gebaut. Also praktisch wie PGP, nur halt alles selbst programmiert (übrigends in Oberon - falls das noch jemand kennt).

Okay, die Protokolle haben wir uns selbst ausgedacht, nix standardisiert (habe auch schon vergessen, ob's damals überhaupt schon echte Standards gab). Aber das ist ja bei EGVP/beA auch nicht anders.

Freilich war das nicht auf hunderttausende Nutzer und große Mails ausgelegt. Und die Usability war äußerst bescheiden. Also genau wie EGVP/beA.

Aber es hat funktioniert - ganz im Gegensatz zu EGVP/beA.


Danke, BRAK und BOS/ATOS, daß Ihr diese lang verschütteten Erinnerungen an meine Jugend wieder hochgeholt habt, passend zum Jubiläum meines damaligen Schulprojekts. Da waren die mindestens 38 Millionen EUR ja nicht komplett verschwendet.


PS: ich könnte ja mal bei meiner damaligen Schule nachfragen, ob's irgendwo im Archiv ein Backup unserer damaligen Projektarbeit gibt. Das dürfen BRAK+Co gern lizensiern. Für jeden von uns eine Million, und noch eine für die Schule. Im Vergleich zu ATOS doch ein Schnäppchen.

Kostenmonster beA: 34 Miio EUR + 10,7 Mio pro Jahr

Das nun als komplett kaputt bekannte #beA-Projekt hat offenbar bisher ca. 34 Millionen EUR verschlungen. Mit dem Ergebnis, daß nichts brauchbares vorliegt - aufgrund der fundamentalen konzeptionellen Probleme ist kein kompletter Neubau erforderlich.

Die BRAK erhebt eine jährliche beA-Sonderumlage - pro Anwalt ca. 65 - 70 EUR - summiert sich auf 10,7 Mio EUR pro Jahr. Zwar hoffte die BRAK auf eine baldige Senkung - diese dürfte aber angesichts des nun vorliegenden Totalschadens sehr unwahrscheinlich sein.

Bei genauerer Betrachtung der eigentlichen Aufgabenstellung dürfte schon ein Jahresbetrag für eine komplette Neuentwicklung äußerst großzügig bemessen sein. Vorrausgesetzt, man gibt das Projekt an entsprechende Profis, nicht der Hilfsprogrammierer von ATOS bzw. Governicus.

An der Stelle sei angemerkt, daß bereits das EGVP auf tönernen Füßen steht: die darunter liegenden Technologien, insbesondere OSCI, sind gänzlich nicht für deartige Zwecke geeignet. Hier gibt es seit Jahrzehnten bewährte Standard-Technologien (tatsächlich internationale Standards), welche lediglich geeignet kombiniert werden müssen.

(Der Autor hatte derartiges bereits umgesetzt. Zu einem Bruchteil der Kosten).

beA-Anwendung auch für XSS anfällig

Neben den ohnehin schon bekannten gravierenden Sicherheitslücken im #beA kommt nun noch eine XSS-Lücke hinzu - ein alltägliches Problem, das jeder Web-Programmierer kennen und beherrschen muß.

Hier ein schönes Demonstrations-Video.

Was kann man hier erkennen ?



Ein Angreifer kann in einer präparierter URL direkt Programmcode in die Website (der beim Nutzer ausgeführte Teil) einschleusen. Im Demo-Video wurde einfach nur ein neues Fenster geöffnet. Man könnte auch Code einschleusen, mit dem private Daten, zB. der Sitzungsschlüssel zum Server eines Angreifers ausgeleitet werden kann.

Nach erfolgtem Angriff besitzt der Angreifer also den aktuellen Sitzungsschlüssel des Opfers. Hatte sich dieses angemeldet (oder meldet sich in derselben Sitzung später an), hat der Angreifer denselben Zugriff wie das Opfer - hat also das Login komplett umgangen. Unerheblich wie sicher dieses ist - da helfen auch Crypto-Cards, Hardware-Tokens, etc nicht weiter - sie werden komplett umgangen.

Wie kann der Angriff stattfinden ?


Ein Angreifer muß das Opfer lediglich zum Abruf eines präparierten Links bewegen. Dieser kann sich zB. in einer eMail oder einer in irgendeiner Website verstecken.

Das Opfer muß hierfür nichtmal selbst aktiv werden (zB. Link anclicken) - der Abruf kann auch verdeckt geschenen (zB. verdecktes iframe).

Ergo: der Angriff funktioniert völlig unbemerkt.

Ein klein wenig Schutz könnten evtl. besonders strikte Browser-Einstellungen bzw. zusätzliche Filter-Toosl liefern (zB. iframes auf bzw. Nachladen von anderen Domains komplett unterbinden) - dann müßte das Opfer immerhin den Link selbst anclicken. Aber dann funktionieren zahlreiche Websites nicht mehr.


Vergleich aus der 'analogen' Welt:


Die Teilnehmer einer Veranstaltung werden im Vorfeld einer strikten Sicherheitsüberprüfung unterzogen (zB. erkennungsdienstliche Behandlung, etc) - nach erfolgter Prüfung bekommen sie eine einfache Eintrittskarte, mit der sie das Gelände beliebig betreten und verlassen können. Diese identifiziert auch den Teilnehmer.

Der Angreifer macht heimlich Photos von Eintrittskarten und fertigt sich Kopien davon an. Damit kann er das Gelände beliebig betreten und sich als sein Opfer ausgeben.

Lösung:


Programmierer müssen stets darauf achten, daß aus dem Netz kommende Eingaben geprüft werden. Insbesondere dürfen diese Eingaben niemals als Programmcode eingebunden werden.

Die Aufgabe ist technisch sehr leicht - es bedarf lediglich eines Grundmaß an Sorgfalt, dies schlicht konsequent umzusetzen. Zudem sind solche Fehler auch leicht durch Penentrationstests (großenteils sogar automatisiert) aufzudecken.

Grober handwerkliche Fehler


Der Fehler ist derart banal und offentsichtlich, daß man von einem Kunstfehler ausgehen muß. Das gehört schlicht zum grundsätzlichen Handwerkszeugs der Web-Programmierung. Ähnlich wie ein Rechtsanwalt BGB und ZPO kennen muß.

Die betroffenen Juristen mögen eine grobe Pflichtverletzung / grobe Fahrlässigkeit prüfen und entsprechende Haftungen der Verursacher bei #ATOS / #Governicus ableiten.