Ein Kernkonzept des beA ist das sogenannte "Umschlüsseln". Was verbirgt sich dahinter ?
Man möchte die Möglichkeit haben, daß Nachrichten auch nach dem Absenden an andere als die zunächst bestimmten Empfänger umgelenkt und von diesen auch gelesen werden können. Das ist natürlich das komplette Gegenteil einer Ende-zu-Ende-Verschlüsselung. Diese besagt schließlich per Definition, daß nur der vom Absender bestimmte Empfänger die Nachricht auch bekommen und entschlüsseln kann.
Zur Umsetzung hat man den verschlüsselten Weg in zwei verschiedene aufgebrochen:
Zunächst vom Sender in ein Schattenpostfach, dazwischen die "Umschlüsselung", dann weiter zum eigentlichen Empfänger. Während der "Umschlüsselung" liegt die Nachricht (bzw. der Inhaltsschlüssel, mit die eigentliche Nachricht verschlüsselt ist) zwischenzeitlich im Klartext vor.
Ist das nicht unsicher ? Ja, sehr sogar.
Hier kommt nun das HSM ins Spiel: das HSM ist eine kleine magische Box, welche private Schlüssel aufbewahrt, welche man dort - der Theorie nach - nicht rausbekommt. Die Box kann mit diesen nun eingegebene Daten ver- und entschlüsseln.
Das "Umschlüsseln" läuft (etwas vereinfacht) so:
Die Server-Software sucht aus ihre Datenbank die ID zum Schlüssel zum Schattenpostfachs sowie jene des aktuell festgelegten Empfängers heraus. Diese werden zusammen mit der (fürs Schattenpostfach) verschlüsselten Nachricht ins HSM eingegeben und dieses angewiesen, mit ersterem zu ent- und anschließend letzerem zu verschlüsseln (die Schlüssel selbst sind ja bereits im HSM). Heraus kommt die "umgeschlüsselte" Nachricht, die nur der aktuell bestimmte Empfänger lesen kann.
Ist das nun sicherer ? Nein, kein wenig.
Die Schwachstelle ist derjenige, der das HSM kommandiert. Eben jener kann gewillkürt von einem beliebigen Schattenpostfach auf einen beliebigen Empfänger "umschlüsseln".
Was braucht man für erfolgreichen Angriff ?
Wenig: Administrator-Privilegien auf o.g. "Umschlüssel"-Server. Wenn man sorgfältig arbeitet, bekommen das die anderen/echten Administratoren nicht mit. Zumindest nicht, solange sie nicht sehr genau nach eben solchen Angriffen Ausschau halten.
Ergo:
Das HSM verhindert zwar - sofern es tatsächlich sicher aufgebaut ist (!) - das Entwenden von Schlüssel. Aber das ist zum Abhören überhaupt nicht nötig.
Snakeoil ! Der Zugewinn an Sicherheit durch das HSM nähert sich asymptotisch an Null an - und zwar von unten.
Es existiert keine Ende-zu-Ende-Verschlüsselung. Ein Ablauschen innerhalb der beA-Infrastruktur bzw. durch den Provider ist leicht möglich.
Broken-by-design.
Nachtrag:
Sicherlich werden nicht alle Schlüssel der Schattenpostfächer und tatsächlicher Empfänger permanent im HSM lagern, sondern bei Bedarf vom "Umschlüssel-Server" eingeladen. Die privaten Schlüssel der Schattenpostfächer sind für das HSM verschlüsselt (sodaß nur dieses sie entschlüsseln und verwenden kann), die öffentlichen Schlüssel brauchen selbstredend nicht verschlüsselt sein.
Mittwoch, 10. Januar 2018
Dienstag, 2. Januar 2018
Wie man EGVP richtig macht ? Teil 1: Einleitung
Diese Artikel-Reihe beschreibt eine Reihe Vorschläge um die Aufgabenstellung von EGVP und dessen Ableger wie zB. beA richtig zu lösen (beA, beN, etc werden im Folgenden lediglich als Zugangsweise bzw. Teilsysteme der EGVP-Infrastruktur betrachtet). Darunter verstehen wir einerseits höchstmögliche Sicherheit, andererseits aber auch praktische Benutzbarkeit und den effizienten Betrieb.
Selbstverständlich wird hier noch kein geschlossenes Systemkonzept geliefert.
In der Analyse / Konzeption müssen wir uns zunächst klar werden, welche konkreten Anforderungen gestellt werden bzw. wo genau klassischen Mailing-Systeme für unseren Anwendungsfall unzureichend sind.
Klassische Email bietet keine verläßliche Zustellbestätigung - die Abstreitbarkeit des Empfangs ist stets gegeben. In der materiellen Welt lösen wir das über einen vertrauenswürdigen Dritten, dessen Aussage wir vertrauen.
Beim Einschreiben-Rückschein muß der Empfänger den Eingang vor Erhalt der Sendung (bevor er vom Inhalt Kenntnis nehmen kann) quittieren. Die Annahmeverweigerung wird vom Boten protokolliert.
Eine solche Quittierung läßt sich mittels Cryptographischer Signaturen in bestehende Übertragungsprotokolle (SMTP, IMAP, POP3) nachrüsten. Wir müssen lediglich einige Faktoren sicher stellen:
Einfache eMails im Klartext bieten keinerlei Vertraulichkeit. Hierzu gibt es aber seit Jahrzehnten gute technische Lösungen, zB. GPG/PGP oder auch S/MIME. Die eigentliche Kunst besteht hier vorallem in der Schlüsselverwaltung. Das überschneidet sich auch mit der Verwaltung der Addressaten.
Hierbei gilt es auch verschiedene Vertreter mit einzubeziehen in den unterschiedlichen Rollen mit einzubeziehen. (auch Sekretärin vertritt den Anwalt, allerdings nur in der Büroverwaltung, nicht in prozessualen Fragen). Dies läßt sich durch parallele Addressierung (im Addressverzeichnis verwaltete Verteilerlisten) abbilden - jedoch ist hier zwischen technischem Empfängern (zB. die Kanzlei als Organisation) und Leseberechtigten (zB. dem bestimmten Anwälten selbst) zu unterscheiden. Die Befugnisse und Verantwortlichkeiten der Beteiligten müssen klar definiert und nachvollziehbar sein.
Für die digitale Signatur sind entsprechende Technologien (zB. GPG) schon seit langem vorhanden. Wichtig ist jedoch, daß diese von der Zustellung und Leseberechtigung strikt zu unterscheiden ist. Die persönliche Key-Cards des Anwalts kann sowohl die Signatur-Keys als auch Empfangs-Keys enthalten, allerdings sollten diese dennoch stets unterschieden werden - niemals ein Key für alles !
Bildlich gesprochen: mehre Karten in einem Stück Plastik, aber niemals eine Karte für alles.
Dies ist wichtig sowohl für die Veränderungen der Rollen / Befugnisse einzelner Personen, als auch zur Minimierung von Störungen bei Verlust oder Defekt der Karten notwendig.
In den allermeisten Fällen ist die Vertretung - bzw. vom einzelnen Anwalt selbst abweichende Empfänger/Leser im Vorraus planbar. So geht die Post üblicherweise an die Kanzlei als solche.
Hier lassen sich im Vorfeld entsprechende Addressaten über Verteiler festlegen: die Kanzlei als solche stellt einen Verteiler dar, welcher die internen Empfänger (Anwälte, Sekretariat, etc).
Hier ist aber auch die Empfangs-/Leseberechtigung von der prozessualen Vertretung zu unterscheiden.
Selbst bei einem blitzartigem Ausscheiden (zB. fristlose Kündigung bei schwerwiegenden Fällen) kann zB. über eine Hotline eine sofortige Zertifikat-/Karten-Sperrung veranlaßt werden. Hier kann es ohnehin nur noch um Schadensbegrenzung gehen, da solcher Kündigungen üblicherweise ganz andere schwere Verstöße vorausgehen.
Bei prozessualen Vertretungen innerhalb von Sozietäten sind die Vertreter üblicherweise vorher bekannt bzw. können dem Sender (zB. Gericht) zeitnah bekannt gegeben werden. Bereits empfangene Dokumente kann vertetende Anwalt bzw. das Sekretariat dem Vertreter zur Verfügung stellen - wie das auch schon bei der Papier-Post der Fall ist. Abgesehen von Aktualisierung des Kanzlei-Verteilers sind hier keine weiteren Maßnahmen im EGVP nötig.
Härtefälle wie zB. Tod des Anwalts (und damit ggf. Verlust auschließlich an ihn selbst gesandter Dokumente) stellen extreme Ausnahmefälle dar, mit denen die Justiz auch heute schon umgehen muß. Hier muß so oder so ein neuer Anwalt bestellt, Fristen zurückgestellt und Dokumente ggf. neu versandt werden. Entsprechende Mechanismen hiefür müssen ohnehin existieren, die Postzustellung ist nur ein kleiner Aspekt dabei, sodaß besondere Maßnahmen - etwa sogar "Umschlüsseln" im EGVP nicht erforderlich sind.
Selbstverständlich wird hier noch kein geschlossenes Systemkonzept geliefert.
In der Analyse / Konzeption müssen wir uns zunächst klar werden, welche konkreten Anforderungen gestellt werden bzw. wo genau klassischen Mailing-Systeme für unseren Anwendungsfall unzureichend sind.
Zustellbestätigung:
Klassische Email bietet keine verläßliche Zustellbestätigung - die Abstreitbarkeit des Empfangs ist stets gegeben. In der materiellen Welt lösen wir das über einen vertrauenswürdigen Dritten, dessen Aussage wir vertrauen.
Beim Einschreiben-Rückschein muß der Empfänger den Eingang vor Erhalt der Sendung (bevor er vom Inhalt Kenntnis nehmen kann) quittieren. Die Annahmeverweigerung wird vom Boten protokolliert.
Eine solche Quittierung läßt sich mittels Cryptographischer Signaturen in bestehende Übertragungsprotokolle (SMTP, IMAP, POP3) nachrüsten. Wir müssen lediglich einige Faktoren sicher stellen:
- alle beteiligten Server und Clients auf dem Nachrichtenweg müssen die entsprechenden Protokoll-Erweiterungen implementieren
- die Server-Infrastrukturen und deren Betreiber bedürfen eine besonderen öffentlichen Vertrauensstellung (analog zu Hoheitsträgern) - das Personal muß technisch und juristisch befähigt sein (analog zu amtlich bestellten Gutachtern) - das Gesamtsystem muß kontinulierlicher öffentlicher Überprüfung unterzogen werden
- die jeweiligen Vorgänge (Übertragungsschritte) müssen fälschungssicher protokolliert werden (einfache Logfiles oder Datenbankeinträge sind leicht zu fälschen)
- die signierenden Systeme müssen besonders gesichert werden, sodaß zB. manipulierte Zustellbestätigungen wirksam unterbunden und Versuche schnell erkannt werden
- bei extern eingespeisten Nachrichten oder externen Empfängern - sofern überhaupt zulässig - müssen die hier fehlenden Sicherungsfunktionen klar (auch innerhalb der einzelnen Transaktionen) kommuniziert und protokolliert werden
- saubere Unterscheidung der beteiligten Rollen (zB. hat der RA selbst oder nur die Sekretärin in Empfang genommen ?) - dh. zB. für eine Mailbox sind prinzipiell mehrere User mit verschiedenen Berechtigungen vorzusehen.
- vor einem wirksamen Empfang muß der Empfänger auch die technische Verarbeitungsmöglichkeit (Dateiformate, etc) prüfen und aus diesem Grunde zurückweisen können. Die für den Zusteller sichtbaren Metadaten müssen Auskunft hierüber geben und protokolliert werden, damit im Nachgang auch eine rechtliche Prüfung möglich ist.
Vertraulichkeit des Inhalts:
Einfache eMails im Klartext bieten keinerlei Vertraulichkeit. Hierzu gibt es aber seit Jahrzehnten gute technische Lösungen, zB. GPG/PGP oder auch S/MIME. Die eigentliche Kunst besteht hier vorallem in der Schlüsselverwaltung. Das überschneidet sich auch mit der Verwaltung der Addressaten.
Hierbei gilt es auch verschiedene Vertreter mit einzubeziehen in den unterschiedlichen Rollen mit einzubeziehen. (auch Sekretärin vertritt den Anwalt, allerdings nur in der Büroverwaltung, nicht in prozessualen Fragen). Dies läßt sich durch parallele Addressierung (im Addressverzeichnis verwaltete Verteilerlisten) abbilden - jedoch ist hier zwischen technischem Empfängern (zB. die Kanzlei als Organisation) und Leseberechtigten (zB. dem bestimmten Anwälten selbst) zu unterscheiden. Die Befugnisse und Verantwortlichkeiten der Beteiligten müssen klar definiert und nachvollziehbar sein.
Digitale Unterschrift:
Für die digitale Signatur sind entsprechende Technologien (zB. GPG) schon seit langem vorhanden. Wichtig ist jedoch, daß diese von der Zustellung und Leseberechtigung strikt zu unterscheiden ist. Die persönliche Key-Cards des Anwalts kann sowohl die Signatur-Keys als auch Empfangs-Keys enthalten, allerdings sollten diese dennoch stets unterschieden werden - niemals ein Key für alles !
Bildlich gesprochen: mehre Karten in einem Stück Plastik, aber niemals eine Karte für alles.
Dies ist wichtig sowohl für die Veränderungen der Rollen / Befugnisse einzelner Personen, als auch zur Minimierung von Störungen bei Verlust oder Defekt der Karten notwendig.
Problemkreis Vertretung:
In den allermeisten Fällen ist die Vertretung - bzw. vom einzelnen Anwalt selbst abweichende Empfänger/Leser im Vorraus planbar. So geht die Post üblicherweise an die Kanzlei als solche.
Hier lassen sich im Vorfeld entsprechende Addressaten über Verteiler festlegen: die Kanzlei als solche stellt einen Verteiler dar, welcher die internen Empfänger (Anwälte, Sekretariat, etc).
Hier ist aber auch die Empfangs-/Leseberechtigung von der prozessualen Vertretung zu unterscheiden.
Selbst bei einem blitzartigem Ausscheiden (zB. fristlose Kündigung bei schwerwiegenden Fällen) kann zB. über eine Hotline eine sofortige Zertifikat-/Karten-Sperrung veranlaßt werden. Hier kann es ohnehin nur noch um Schadensbegrenzung gehen, da solcher Kündigungen üblicherweise ganz andere schwere Verstöße vorausgehen.
Bei prozessualen Vertretungen innerhalb von Sozietäten sind die Vertreter üblicherweise vorher bekannt bzw. können dem Sender (zB. Gericht) zeitnah bekannt gegeben werden. Bereits empfangene Dokumente kann vertetende Anwalt bzw. das Sekretariat dem Vertreter zur Verfügung stellen - wie das auch schon bei der Papier-Post der Fall ist. Abgesehen von Aktualisierung des Kanzlei-Verteilers sind hier keine weiteren Maßnahmen im EGVP nötig.
Härtefälle wie zB. Tod des Anwalts (und damit ggf. Verlust auschließlich an ihn selbst gesandter Dokumente) stellen extreme Ausnahmefälle dar, mit denen die Justiz auch heute schon umgehen muß. Hier muß so oder so ein neuer Anwalt bestellt, Fristen zurückgestellt und Dokumente ggf. neu versandt werden. Entsprechende Mechanismen hiefür müssen ohnehin existieren, die Postzustellung ist nur ein kleiner Aspekt dabei, sodaß besondere Maßnahmen - etwa sogar "Umschlüsseln" im EGVP nicht erforderlich sind.
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.
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).
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.
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.
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.
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.
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.
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.
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.
Abonnieren
Posts (Atom)