beA: Quellen-TKÜ leicht gemacht !

In den vergangenen Wochen wurde viel über gravierende Sichersicherheitslücken im beA - insbesondere des "ClientSecurity" diskutiert. Eine ganz grundlegende - konzeptionelle - Schwachstelle wurde leider nur unzureichend beleuchtet: der Webserver selbst !

Server sendet die Client-Software

Bei (komplexeren) Web-Anwendungen, wird Javascript-Code, welcher im Browser ausgeführt wird, vom Webserver gesendet. Dieser wird zwar in einer Sandbox ausgeführt, um keinen Zugriff auf den PC zu erlangen, aber der Server bestimmt, welcher Code in der jeweiligen Seite (innerhalb des Browsers) ausgeführt wird. Dieser Code hat zwangsläufig Zugriff auf alle Inhalte innerhalb der Seite - das ist schließlich die Idee dahinter.

Somit wird also der gesamte Javascript-Code des beA Web-Client jedesmal aufs Neue vom Server gessendet. Dieser Code verbindet sich uA. zum "ClientSecurity", um dieses zB. Nachrichtenschlüssel mittels Karte ver-/entschlüsseln, aber auch Fingerabdrücke von zu unterschreibenden Dokumente zu signieren.

Kurz: sobald eine entschlüsselte Nachricht dem Nutzer angezeigt wird, hat dieser Javascript-Code sie bereits - entschlüsselt - verarbeitet.

Quellen-TKÜ leicht gemacht !

Wer immer den beA-Webserver kontrolliert, kann hier beliebig weiteren / anderen Javascript-Code einschleusen. Dieser kann demnach bereits entschlüsselte bzw. noch unverschlüsselte Nachrichten jederzeit abgreifen, manipulieren und ausleiten. Ebenso kann er auch beim Signieren gefälschte Dokumente unterschieben.

Im Gegensatz zu einer präparierten lokalen Client-Software kann dieser Angriff auch leicht sehr selektiv und kurzzeitig geschehen, sodaß die Chance auf Entdeckung extem gering ist.

Dieses Problem ist jeglichen Web-Lösungen inherent !

beA: Webserver der BRAK unsicher

Bei einem kurzen Blick auf die Sicherheit des BRAK Webserver (www.brak.de) sieht es sehr bescheiden aus. Zahlreiche Schwachstellen.

Stark veraltete Server-Software mit bekannten Sicherheitslücken.

Es wird die veralteter Version 2.2.16 des Apache Webserver verwenden. Diese stammt aus dem Jahre 2010. Hierzu sind eine Reihe ernst zu nehmende Sicherheitslücken bekannt.

Seit Sommer 2017 wird die 2.2.*-Linie nicht weiter gepflegt.

Nicht vertrauenswürdiges Server-Zertifikat

Das https-Zerifikat wurde ausgestellt von einer unseriösen CA: RapidSSL, einer der vielen Billigmarken des berüchtigten Snakeoil-Herstellers Symantec. Diese sind in der Vergangenheit immer wieder für unseriöse Praktiken unter Beschuß geraten, uA. hatten sie gefälschte Zertifikate im Namen von Google ausgestellt.

Aus diesem Grunde werden alle CAs des Symantec-Konzerns schrittweise aus den Browsern entfernt, dh. deren Zertifikate nicht mehr akzeptiert.

Veraltetes / unsicheres Verschlüsselungsprotokoll - TLS 1.0 von 1999

Der Server unterstützt lediglich eine veraltete, nach dem Stand der Technik als unsicher einzustufende, Version des Verschlüsselungsprotokolls TLS. Diese stammt noch aus dem Jahre 1999 und wurde schon vor einem Jahrzehnt durch die Version 1.2 ersetzt.

Zudem werden eine Reihe veralteter bzw. als schwach / unsicher bekannte Verschlüsselungsverfahren (zB. RC4) eingesetzt und zahlreiche andere Sicherungsmaßnahmen unterlassen.

Siehe zB. hier.

Der Mailserver verwendet ähnlich schwache Verschlüsselung (TLSv1, zu kurze Schlüssel, etc).

Stand der Technik nicht erreicht

Zusammenfassend muß man auch hier feststellen, daß die BRAK nichtmal beim Web- und Mailserver den Stand der Technik auch nur annähernd erfüllt. Hierbei handelt es sich sogar um das alltägliche Handwerkszeug eines jeden auch nur annähernd seriösen System-Administrators.

beA: ATOS/Governikus verweigert sich der Diskussion um den Sicherheits-GAU ("beAthlon")

Aufgrund des Sicherheits-GAU beim beA hat die BRAK einen sogenannten "beAthlon" anberaumt, bei dem von der BRAK eingeladene unabhängige Experten die Sicherheit des beA prüfen sollen. Hierzu wurden auch ATOS und seine Auftragnehmer (zB. Governikus) eingeladen.

Nach Meldung der BRAK hat ATOS jedoch nun - nach voriger mündlicher Zusage - seine Teilnahme abgesagt, und zugleich seinen Auftragnehmern selbige untersagt.

Das wirft die dringende Frage auf, ob ATOS überhaupt an einer Klärung des Skandals interessiert ist, oder sich schon kommende Klageverfahren einstellt. Eine Nachaltige Reperatur des beA - tatsächlich wäre eher ein vollständiger Neubau erforderlich - durch ATOS erscheint zweifelhaft.

Für Juristen spannend könnte die Frage sein, ob sich diese Verweigerung des Dialogs mit dem Auftraggeber auf Haftungsfragen (zB. bzgl. 439 BGB) auswirkt. An diesem Punkt wäre eine Schadensersatzklage seitens BRAK, ggf. auch vollständige Wandlung verständlich.

beA: die Rechtspflege in den Fängen einer magischen Schachtel

Im Folgenden eine weniger technische, denn eher prinzipiell gesellschaftliche Betrachtung der HSM-Problematik:

Das HSM ist beim beA der zentrale Dreh- und Angelpunkt. Die Nachrichten werden zunächst an das Postfach gesandt. Nur das HSM kennt die privaten Schlüssel der Postfächer und schlüsselt dann bei Abruf auf den jeweilgen Anwalt (oder dessen Vertrag) um. Ohne HSM kein Entschlüsseln der Nachrichten.

Das macht das HSM zur zentralen Schwachstelle !

Schon im Normalbetrieb ist das HSM das Nadelöhr - alle Kommunikation muß hierüber. Zwar nicht die gesamten Nachrichten (die sind separat symetrisch verschlüsselt), aber dennoch die jeweiligen (an das Postfach verschlüsselten) Nachrichtenschlüssel. Hier muß sich zunächst noch zeigen, ob das HSM überhaupt die Last im Vollbetrieb leisten kann - bisher hatte ja nur eine marginale Anzahl Anwälte überhaupt am beA teilgenommen.

Ein Ausfall des Rechenzentrums (bzw. dessen Internetverbindung) führt unweigerlich zu einem Totalausfall des beA. Eine Verteilung auf mehrere Standorte ist in dieser Konstellation nicht möglich, wenn das HSM nur einmal existiert.

Doch es kommt noch schlimmer:

Jede Technik hat eine begrenzte Lebenszeit - irgendwann fällt auch die beste Technik aus, der Zeitpunkt läßt sich im Einzelfall nicht vorhersagen.

Bei einem Ausfall des HSM steht das beA - damit die Rechtspflege - still !

Sofern die vollmundigen Sicherheitsverpreche des Herstellers (eine Tochter des ATOS-Konzerns) halten, sind dann die privaten Postfachschlüssel und damit alle Nachrichten unwiederbringlich verloren. Nach einem Austausch des HSM müssen alle Postfachschlüssel neu erzeugt und alle verlorenen Nachrichten neu versandt werden.

Den Aufwand zur Bereinigung eines solchen Katastrophenfalls (nicht zuletzt seitens der ohnehin chronisch unterbesetzten Gerichte) möchte man sich nicht ausmalen.

Völlig unklar ist zudem noch, wie selbst ein geplanter Austausch des HSM - in Zukunft zweifellos unabdingbar - überhaupt ablaufen soll. Insbesondere wenn möglicherweise in Zukunft kein kompatibles Modell mehr lieferbar sein könnte. Hier fehlt es in den Verlautbarungen der BRAK bzw. deren Diensleister ATOS/Governikus an jeglicher klarer Planung. Ob dieses Problem überhaupt berücksichtigt wurde, bleibt unklar.

Ein Ausweg wäre die Verteilung auf mehrere redundante HSMs an verschiedenen Standorten. Das wiederum erfordert, daß sich die privaten Schlüssel aus dem HSM extrahieren lassen - womit aber die von BRAK und ATOS ins Feld geführten Sicherheitsargumente dahin.

Grundsätzlich gilt es, sich vor deutlich Augen zu halten, daß die BRAK hier faktisch die gesamte Rechtspflege von einer magischen Wunderschachtel und einem Privatkonzern abhängig gemacht hat.

Allein das hieraus entstehende exorbitante Machtpotential eines einzelnen ausländischen Konzerns über die gesamte Rechtspflege bedarf noch gründlicher juristischer und politischer Aufarbeitung.

Abschließend sei nochmals daran erinnert, daß eine solche Konstruktion - mit Bruch der Ende-zu-Ende-Verschlüsselung und vollständiger Abhängigkeit von einem einzelnen Spezialgerät - zur Einhaltung der normativen Vorgaben (insbesondere Vertreter-Regelung) grundsätzlich nicht erforderlich ist. Eine strikte Ende-zu-Ende-Verschlüsselung ist hierfür gut umsetzbar.


UPDATE: wie aktuell kolpotiert wird, handele es sich um insgesamt 4 HSMs, jeweils zwei an zwei Standorten, welche synchronisiert werden. Dies widerspricht aber grundsätzlich der Behauptung, eine Ausleitung der privaten Schlüssel sei generell nicht möglich.

beA/beN - der nächste Anschlag: Notarkammer nötigt zu Java-Malware und dubiose Software mit vollen Rechten

Die BNotK wollte ihre hübsche Signatur-Karten wohl ganz besonders sicher machen: diese müssen vor Benutzung mit einem (per normaler Post verschicktem!) Aktivierungs-Code freigeschaltet werden. Soweit so gut - wenn wir mal vom unsicheren Postweg absehen.

Aber die Sache hat einen gewaltigen Haken: die Notare und Anwälte benötigen dazu eine spezielle closed-source (=Geheimcode) Java-Software, die über ein Browser-Plugin läuft und zugleich volle Rechte verlangt:

1. Die Software verlangt ein Java-Plugin im Browser. Genau das ist aber schon seit Jahrzehnten als extrem unsicher bekannt - es handelt sich um Malware. Hier kam es schon zu zahlreichen fatalen Lücken, wo eine x-beliebige Website mal nebenbei den ganzen Rechner übernehmen konnte. Kein auch nur annähernd fähige Administrator wird heute noch Java-Plugins installieren - das wäre grobe Fahrlässigkeit, ein schwerwiegender Kunstfehler, der zumindest eine fristlose Kündigung rechtfertigt.

2. Zudem verlangt diese Software volle Rechte auf dem PC. Sie kann also alles tun, sich einnisten, sensible Daten ausleiten, strafbare Inhalte plantieren, etc. Der Anwender ist dem voll ausgeliefert - ihm bleibt nur die Möglicheit, an die Gutmütigkeit und sorgfältige Arbeit des Herstellers zu glauben. Auch Schlangenöl wie zB. Virenscanner kann hier nicht helfen.

3. Hergestellt und betrieben wird die Software von einem unter IT-Experten berüchtigem Schlangenöl-Hersteller, dessen Qualifikation eher im Vertrieb konzentriert ist, und der offenbar Sicherheit mit maximaler Intransparenz (zB. geheimer Quellcode) verwechselt. Der Kunde/Nutzer muß GLAUBEN, prüfen darf er nicht.

4. Die Software wurde signiert mit einem Zertifikat eines berüchtigten US-Billiganbieters und altbekanntem CIA-Partner, der aufgrund nachweislich fehlender Vetrauenswürdigkeit schon aus einigen Browsern entfernt wurde.

5. Desweiteren hat man sich einige Mühe gegeben, den Aufbau der Software extra zu verschleiern (wohl in der naiven Hoffnung, wir könnten sie nicht trotzdem zerlegen). Offenbar hat man hier einiges zu verbergen. Schutz irgendwelcher besonders genialer Ideen kann es aber kaum sein - so schwer ist die Aufgabenstellung schließlich nicht.

7. Die Anleitung der BNotK (PDF) wurde so absichtlich generiert, daß sich der Link nicht direkt anclicken oder kopieren läßt. Da der Schlangenöl-Hersteller (ebenso wie die BNotK) nichtmal durchgängige TLS-Verschlüsselung verwendet, besteht die ernste Gefahr, daß der Nutzer falsch abtippt und versehentlich das Programm komplett unverschlüsselt abruft!


Ergo: wenn schon bei der Freischaltung der Signaturkarte die Sicherheit deart miserabel ist, dürfen wir gespannt sein, welche Katastrophen beim beN in nächster Zeit noch auftauchen. Bekanntlich ist ja schon das beA ein Totalschaden.

Es ist nun an den Juristen, den Verdacht auf schwere Nötigung und Computersabotage zu untersuchen.

Begriff: Schlangenöl

Als Schlangenöl (Bezug auf unwissentschaftliche "Magie") bezeichnen wir Informatiker solche Produkte und Dienstleistungen, die den falschen Eindruck von "Sicherheit" erwecken.

Eventuell verhelfen sie einem Unkundigen zu ruhigerem Schlaf, tragen aber wenig bis garnichts zur Sicherheit bei - ganz im Gegenteil: durch den falschen *GLAUBEN* bewirken sie eher eine Vernachlässigung wichtiger Maßnahmen. Einige reißen auch gleich nochmal ganz eigene Sicherheitslöcher auf.

Üblicherweise zählen dazu zB. "Virenscanner", die maximal als ein ganz groben Sieb laienhafte bekannte Malware abgreifen. Gegen halbwegs intelligente Angreifer helfen sie nicht.

Erwiderung auf das Rundschreiben der RAK Nürnberg vom 11.01.2018

Werter Hr. Link,


ich habe Ihr aktuelles Rundschreiben vom 11.01. vorliegen und möchte aus
meiner Sicht als IT-Berater, der schon 2013 Konzepte für ein ähnliches
System (für die BNotK) erarbeitet hat, darauf eingehen:

1. Ihre Formulierung zum zweiten Zertifikat "ebenfalls fehlerhaft" ist
   leider sehr verkürzt und wird dem Ausmaß nicht gerecht:

Man könnte den Eindruck gewinnen, hier wurde lediglich der erste Fehler
wiederholt, dh. die bisherige (nun schon über Jahre vorhandene) Lücke
nicht repariert. Die unangenehme Wahrheit ist aber, daß nun (sofern die
Nutzer die Anleitung der BRAK befolgt und der Zertifikat eingespielt
haben) eine noch viel fatalere Lücke hinzugefügt: nun wurde gleich die
gesamte Verschlüsselung für alle Websites, aber auch andere Dinge wie
zB. eMail, Software-Updates, etc. komplett ausgehebelt. Somit haben
Angreifer nun zB. die Möglichkeit, sich permanent auf den Anwalts-PCs
einzunisten und die Kontrolle zu übernehmen - hier helfen auch keine
Virenscanner mehr !

Stellen Sie sich vor, beim Versuch einer Reparatur am Briefkasten wurde
nun auch das Schloß Ihrer Kanzleitür ausgebaut. Die Konsequenzen können
Sie sich sicher vorstellen.

Hier muß ich auch mit der BRAK hart ins Gericht gehen: eine Anleitung,
welche explizit technisch Unkundige dazu auffordert, eindringliche
Warnungen zu umgehen, scheint mir doch grob fahrlässig. Würde mir mein
Anwalt empfehlen, bewaffnet im Gerichtssaal zu erscheinen, dann wäre
ich auch gelinde gesagt äußerst skeptisch.

2. Zum Vergabeverfahren:

Hier wäre ich doch sehr neugierig auf den konkreten Ausschreibungstext,
Vergabekriterien, udgl. In meiner täglichen Arbeit erlebe ich oft, daß
Ausschreibung (ob gewollt oder nicht) schon so aufgebaut sind, daß hier
nur ein bestimmter Anbieter, oder ein technisch schlechtes Konzept zum
Zuge kommen kann.

Gerade bei öffentlichen Projekten derartiger Tragweite und zugleich
technisch nicht versiertem Auftraggeber sehe ich keine andere
praktikable Lösung als regelmäßige _öffentliche_ Begutachtung,
insbesondere auch des Quellcode der Software selbst.

Generell ist IT-Sicherheit mit Geheimhaltung der Konzepte, Verfahren
und Quellcode nicht verträglich - das hat die Praxis seit vielen
Jahrzehnten zahllose Male gezeigt, und selbiges erlebe ich auch
regelmäßig bei meiner Kundschaft.

3. Unternehmensgrößen:

Ihr Schreiben vermittelt den Eindruck, große Unternehmen, hohe Umsätze,
etc, seien ein positiver Indikator für Qualität. Die Praxis beweist das
Gegenteil, und das ist in der soziologischen Forschung bereits gut
aufgearbeitet:

Mit steigender Organisationsgröße - vorallem in Hierarchien - nehmen der
Handlungsspielraum und Motivation der Beteiligten _dramatisch_ ab.
Bereits in unteren Ebenen gewinnt die Sicherung und Verbesserung der
eigenen Position rasch eine höhere Priorität als Qualität der Produkte,
Auf höheren Management-Ebenen ist das faktisch die einzige Tätigkeit.
Solche Organisationen filtern ihr Personal, vorallem in Verantwortungs-
Positionen systemisch nach Konformität zum soziologischen Apparat,
nicht nach fachlichen Leistungen und Begabungen.

Exzellente Experten sind üblicherweise nicht mit solchen soziologischen
Apparaten kompatibel - sofern man sie überhaupt in solchen Apparaten
findet (die überwiegende Mehrheit wird dort nicht lang bleiben), führen
sie ein unbeachtetes Schattendasein, sie werden garnicht erst nicht mit
verantwortungsvollen Aufgaben betraut. Diese Tendenzen sind bereits
im Mittelstand gut sichtbar, in Konzernen ist das Alltag.

Großunternehmen sind also systemisch nicht zu fachlicher/technischer
Exzellenz fähig. Genau diese ist aber für Projekte wie beA dringend
not-wendig.

Der wirtschaftliche Erfolg solcher Unternehmen gründet sich mitnichten
auf technische Kompetenz, sondern an den reinen _Glauben_ der Kundschaft
(bzw. dortiger Entscheider) an solche. Ein religiöser Mechanismus.

3. "beste Referenzen" von ATOS

Hier möchte ich - vorallem mit Hinblick auf og. Problem - deutlichst
hinterfragen, wer besagte Referenzen in welchem konkreten Zusammenhang
ausgestellt hat, und was diese konkret beinhalten.

Der Umstand, daß die ausgelagerte Siemens IT-Abteilung über große und
bekannte Auftraggeber verfügt, sagt über die technische Kompetenz rein
garnichts aus. Siehe oben: die referenzierten Vergabe-Entscheidungen
sind bereits religiös begründet. Und die Entscheider der Kundschaft,
sofern sie überhaupt auf ihren Hierarchieebenen von den tatsächlichen
Problemen erfahren, werden sich aus og. Gründen wohl kaum exponieren
und falsche Entscheidungen öffentlich einräumen - das würde ja ihre
Karriere rasch beenden. Solch abstrakte Referenzen haben somit keine
fachliche bzw. technische Aussagekraft, offenbaren lediglich og.
religiösen Mechanismus.

Aus dem Siemens-Konzern höre regelmäßig von gravierender Inkompetenz
seitens ATOS - sowohl technisch als auch organisatorisch. Analog auch
bei vielen anderen Konzernen.

Anbei sei angemerkt, daß die fatalste Komponente, "beA ClientSecurity",
offenkundig - zumindest zum größten Teil - von BOS/Governikus entwickelt
wurde. Diese sollten wir im Kreis der Verursacher nicht vernachlässigen.


4. Gutachten durch SEC

Das Gutachten unterliegt ja bis heute strikter Geheimhaltung. Schon das
erweckt den Eindruck, daß es hier gravierendes zu verbergen gilt. Das
weitere Festhalten daran, auch nach dem GAU, legt auch den dringenden
Verdacht, daß der BRAK die gravierenden Sicherheitsmängel bekannt waren.

Zudem wird uns weiterhin vorenthalten, worin überhaupt der Auftrag
bestand und was genau geprüft wurde. Eine Hochsicherheitstür nutzt
wenig, wenn sie allein auf freiem Feld steht.

Nach bisherigem öffentlichen Kenntnisstand konnte SEC den Quellcode nicht prüfen. Dabei wäre nämlich das Problem mit dem veröffentlichtem
privaten Schlüssel (im "ClientSecurity") sofort aufgefallen. Desweiteren
wären auch bei einem Blackbox-Test der Web-Anwendung die fatalen XSS-
Lücken rasch aufgefallen - das gehört zu den alltäglichen Standard-
Problemen bei Web-Anwendungen.

Daß nicht schon die Verwendung extrem veralteter Software-Komponenten
(teils über 10 Jahre nicht mehr gepflegt !), kann ich beim besten
Willen nicht nachvollziehen.

Daraus ergeben sich iW. drei Möglichkeiten:

a) die problematischen Punkte wurden überhaupt nicht geprüft, waren
   im Prüfauftrag nicht enthalten
b) die Prüfer sind komplett inkompetent
c) die BRAK hat fatale Mängel vertuscht

Neben den technischen Problemen sind übrigends auch Urheberrechts-
verstöße - inwieweit diese heilbar sind, ist noch zu prüfen.


5. Aufarbeitung:

Wenn Sie Ihr Versprechen einlösen und mit allen zur Verfügung stehenden
Mitteln zur Lösung beitragen möchte, kann ich Ihnen nur dringlich
anraten, auf den folgenden Minimalforderungen zu bestehen:

1. vollständige Offenlegung zwecks öffentliche Begutachtung von:
   * allen Konzept-Dokumenten, incl. Pflichten- und Lastenheft
   * Dokumentation des Entwicklungsprozess
   * Review- und Abnahmeprotokolle
   * Architektur-Dokumentation
   * Konformitätserklärung zu Einhaltung technischer Normen sowie des
     allgemeinen technischen Standes.
   * Quellcode der Software (sowohl Client- als auch Server-Seitig)
   * Sicherheitskonzept (technisch und organisatorisch)
   * Infrastruktur-und Betriebskonzept
   * die benannten externe Gutachten (incl. Abnahmeprotokolle)
   * Prüfprotokolle bzgl. gesetzlicher Normen (BSDG, DSGVO, etc)

2. Hinzuziehung *fachlich geeigneter* unabhängiger technischer Experten,
   welche in keinerlei ökonomischer Beziehung zu den Verantwortlichen
   (zB. ATOS oder BOS/Governikus) stehen - insbesondere auch solche,
   die sich bereits tiefergehend mit dem Problemkomplex EGVP/beA
   auseinander gesetzt und ähnliche Lösungen entwickelt haben.

3. Dauerhafte Einbindung der einzelnen RAK'en, DAV-IT, sowie der
   IT-Sicherheitsforschung (Universäten, CCC, etc).


Abschließend bleibe ich bei meiner Darstellung in der LTO:
Das beA ist ein Totalschaden - wir müssen von Grund auf neu beginnen.


Sollten Sie Fragen haben, stehen ich auch gern kurzfristig für eine
fernmündliche Konsultation zur Verfügung.


mit freundlichen Grüßen