BRAK verzichtet bei beA auf Sicherheitsupdates

Das besondere elektronische Anwaltspostfach (beA) erhält von der Bundesrechtsanwaltskammer (BRAK) seit Anfang des Jahres keine JAVA Updates mehr.

So wurde es mir von der Bundesrechtsanwaltskammer schriftlich bestätigt.

Wie auf unserer Website mitgeteilt, ist für die Java Runtime Environment (JRE) 8.0 die Oracle Binary Code License relevant. Beim beA wird derzeit die nicht lizenzkostenpflichtige Version von JAVA 8.0 eingesetzt. 

Offizielle Stellungnahme der BRAK vom gestrigen 1.10.2019 auf meine Anfrage

Die Nennung der konkreten Version bleibt die BRAK trotz mehrfacher Rückfrage schuldig. Wieder einmal liegt es also an mir, das herauszufinden.

Auf Anfrage teilt mir Oracle (Hersteller der eingesetzten JAVA Software) mit:

Die BCL ist das alte Agreement, unter der die Java 8 Patches bis Update 202 liefen. Die neuen Patches laufen unter dem OTN Agreement. Wenn Sie nicht den aktuellsten Sicherheitsstand brauchen, könnten Sie u.U.noch manuell auf einer alten Version bleiben, die kostenfrei ist. Müssen Sie allerdings GDPR Regelungen einhalten, müssen Sie zwingend auf den aktuellen Stand und dann lizenzieren. 

Stellungnahme des Hersteller Oracle vom 12.9.2019 auf meine Anfrage
Anmerkung: Die „BCL“ ist die von der BRAK genannte „Binary Code License“

Die hier genannte, letzte kostenfreie Version von Java 8 ist Java 8 Update 201 CPU vom 15. Januar 2019¹⁾https://java.com/de/download/faq/release_dates.xml.

Alle Sicherheitsupdates, die es nach dem 15.1.2019 von Oracle gab, sind kostenpflichtig. Somit schließt sich der Kreis und es kann beim beA System („besonderes elektronisches Anwaltspostfach“) nur die veraltete Java Version vom Januar 2019 eingesetzt worden sein.

Kurz überlegen. Januar, Februar, März, April, Mai, Juni, Juli, August, September, ah… Oktober. Ist schon eine ziemlich lange Zeit ohne Updates. Kein Wunder, dass die BRAK von sich aus keine Angaben über die verwendete JAVA Version rausrückt.

Über die Notwendigkeit von Updates auf Webportalen

Für die Software unserer Webseite gibt es praktisch jede Woche irgend ein Sicherheitsupdate. Dass das beA Portal so lange ohne auskommt, das erscheint mir doch etwas sehr fragwürdig.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stellt dazu fest:

…ist die Anzahl von bekannt gewordenen Schwachstellen in der Java-Laufzeitumgebung, welchen der Hersteller Oracle in der jüngeren Vergangenheit immer wieder durch Sicherheitsaktualisierungen begegnen musste, signifikant hoch. (…) Das BSI empfiehlt, die Ausführung von Java-Inhalten im Browser zu deaktivieren.

Quelle: BSI, Sicherheit von Java, Grundlagen und Sicherheitsempfehlung²⁾https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSIFB/Publikationen/Sicherheit_von_Java.pdf?__blob=publicationFile&v=1

Für IT-Hersteller hat das BSI einen eigenen Leitfaden herausgegeben, der schon in der Einleitung konstatiert:

Integraler Bestandteil der Java Laufzeitumgebung (JRE) sind durchdachte Sicherheitsmechanismen. In der Vergangenheit wurden hier dennoch überdurchschnittlich viele Schwachstellen aufgedeckt.

Quelle: BSI, EMPFEHLUNG: IT-HERSTELLER, BSI-Veröffentlichungen zur Cyber-Sicherheit, Sicherheit von Java, BSI-CS 062 | Version 2.0 vom 11.07.2018³⁾https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI-CS_062.pdf?__blob=publicationFile&v=3

So ganz von der Hand zu weisen ist es wohl eher nicht, dass der Betrieb einer JAVA-basierten Plattform ohne Sicherheitsupdates nicht zu empfehlen ist.

Neu ist das alles keineswegs. In der Datenbank des allseits bekannten National Institute of Standards and Technology (NIST) sind Tausende durch JAVA Komponenten verursachte Sicherheitsrisiken verzeichnet⁴⁾https://nvd.nist.gov/view/vuln/search-results?query=java&search_type=all&cves=on.

Halten wir also fest, es gibt einleuchtende Gründe dafür, dass der Hersteller Sicherheitsupdates bereitstellt. Dass diese als beA entwickelt wurde kostenlos waren und Oracle irgendwann Geld für die ständige Weiterentwicklung wollte ist nur legitim. Natürlich ist es blöd, dass der Start des beA Portals wegen immer neuer Sicherheitsprobleme des System ständig verschoben werden musste und jetzt, wo es endlich so halbwegs läuft, Geld an Oracle zu entrichten wäre. Dafür kann aber doch Oracle nichts. Daran ist die BRAK schon selbst schuld.

Aus Sicht der BRAK sind Sicherheitsupdates unnötig

Die BRAK hat wie so oft eine andere Einstellung dazu. Hinsichtlich der von mir geäußerten Sicherheitsbedenken erklärt sie lapidar:

Die Dienstleister der Bundesrechtsanwaltskammer betreiben ein engmaschiges Monitoring, um auf sicherheitsrelevante Veränderungen, die den Einsatz von JAVA bei Benutzern der beA-Webanwendung betreffen, zeitnah und angemessen zu reagieren.

Offizielle Stellungnahme der BRAK vom gestrigen 1.10.2019 auf meine Anfrage

Die Dienstleister, die in der Vergangenheit dafür verantwortlich waren Zertifikate und private Schlüssel im Klartext zu speichern⁵⁾https://www.golem.de/news/bea-bundesrechtsanwaltskammer-verteilt-https-hintertuere-1712-131845.html, sollen also nun angeblich die Sicherheit hinsichtlich veralteter JAVA Software im Griff haben?

Anders ausgedrückt, die Dienstleister der BRAK können Sicherheitslücken ohne Sicherheitsupdates besser schließen als der Hersteller der Software, der die Sicherheitslücken längst in Updates geschlossen hat. Um es mit Rezos und Philipp Amthors Worten zu sagen: Ja LOL ey. Eine so wenig überzeugende Argumentationskette habe ich selten gelesen. Ein leichtes Schmunzeln geht mir über die Lippen, gepaart mit ungläubiger Verwunderung und einem entgeisterten Staunen. Überdurchschnittliche Kompetenz erfordert offenbar keinen Qualifikationsnachweis. Die BRAK ist wie immer über jeden Zweifel erhaben.

Updates auf Serverseite

Selbst falls – nur mal gedanklich – selbst falls diese Dienstleister Sicherheitslücken entdecken würden, wie wollen sie diesen bekannten Sicherheitslücken der JAVA Software denn entgegen wirken wenn auf die (kostenpflichtigen) Updates verzichtet wird?

Auf der Seite des Webservers mag es noch die ein oder andere Möglichkeit geben, bekannte Sicherheitslücken abzufangen. Vielleicht hat die BRAK ja entsprechende Firewalls, SSL Terminatoren und Loadbalancer vorgeschaltet, die zumindest mal einen aktiven Angriff gegen bekannte Sicherheitslücken partiell abfangen könnten.

Der Serverpart lässt sich ohne nähere Kenntnis kaum beurteilen, denn ich kann nicht in die Server reinschauen und es gibt keine Dokumentation darüber, wie die Infrastruktur der BRAK aussieht. Deshalb kann ich hier leider kaum näher darauf eingehen. Der CCC fordert genau aus diesem Grund schon seit geraumer Zeit, dass beA eine Open Source Software werden muss. Nur durch eine Open Source Lösung könnten Sicherheit und Transparenz auf ein akzeptables Niveau gehoben werden⁶⁾https://www.ccc.de/de/updates/2018/bea.

Updates auf Rechnern der beA-Nutzer

Auf die Rechner der beA-Anwender hat die BRAK indes gar keinen Einfluss.

Da gibt es keine spezielle Firewall oder dergleichen. Der beA-Nutzer wird vom Gesetzgeber genötigt, eine sicherheitskritische und veraltete Software von der Bundesrechtsanwaltskammer zu installieren und ist den Folgen auf Gedeih und Verderb ausgeliefert.

Rechtlich äußerst fragwürdig, gebietet die DS-GVO doch ausdrücklich, dass derartige Systeme nach dem Stand der Technik zu schützen sind⁷⁾https://dsgvo-gesetz.de/art-32-dsgvo/. Da fühle ich mich richtig gut aufgehoben, wenn solche Experten für die Sicherheit meines Rechners und meiner hochsensiblen anwaltlichen Dokumente und Gerichtskorrespondenz sorgen sollen.

Dies bezieht sich insoweit übrigens nur auf die JAVA Software, die durch den beA Security Client zwangsweise mitgeliefert wird. Im Rahmen der Erstinstallation darf der Benutzer ja zusätzlich auch noch die (kostenpflichtige) „original“ Oracle JAVA installieren (wir haben darüber ausführlich berichtet), denn ohne das funktioniert das Einrichten der PIN für die Signaturkarte nicht. Mac User müssen auch noch das (ebenfalls kostenpflichtige) JAVA Development Kit installieren.

Ich habe bei der BRAK mehrfach ganz gezielt nachgefragt, wie sie sich das denn vorstellt. Keine Antwort. Bis heute. Wahrscheinlich läuft es irgendwann darauf hinaus, dass die BRAK die Schuld der BNotK in die Schuhe schiebt. Denn die Signaturkomponente wird zwar von beA benötigt, ist aber streng genommen eigentlich eine Software der Bundesnotarkammer⁸⁾https://bea.bnotk.de/sak/. Linke Tasche rechte Tasche.

Was die zusätzlich durch den Anwender selbst installierte JAVA Software angeht kann es nur zwei Optionen geben:

1. Aktuelle Version nehmen und dafür zahlen.
2. Alte Version nehmen – kostenfrei – aber mit ungepatchen Sicherheitslücken leben. Und alle Warnhinweise, dass man endlich aktualisieren möge, ignorieren. So zumindest ist es offenbar die Empfehlung der Bundesrechtsanwaltskammer.

Im Test konnten wir JAVA nach der Erstinstallation wieder deinstallieren. Sobald die Signaturkarten einmal eingerichtet sind, funktioniert das beA Portal prinzipiell auch ohne gesondert installiertes JAVA.

Zum Einrichten neuer Signaturkarten oder regelmäßigen Ändern der PIN – wozu der Benutzer verpflichtet ist – brauche ich aber wieder die Signaturkomponente die nur mit zusätzlich installiertem JAVA startet.

Die Aussage der Bundesrechtsanwaltskammer, dass alle beA Komponenten bereits ein für beA Nutzer kostenfreies JAVA inkludiert haben, stimmt einfach nicht. Es fehlt hier bei der BRAK offenbar wirklich an Fachkompetenz.

Eine Alternative könnte sein, OpenJDK zu verwenden. Das ist eine kostenfreie JAVA Alternative, die es auch für Windows PCs gibt⁹⁾https://jdk.java.net/13/. Nur dürfte das kaum jemand kennen und es ist auch nicht für beA freigegeben¹⁰⁾https://bea.bnotk.de/documents/Schluesselverwaltung_beA.pdf. Versuche à la try & error dürften bei beA aber fehl am Platz sein. Also bleibt alles beim alten und wir stehen wieder am Anfang der Überlegung. Die BRAK sollte hier endlich klar Stellung beziehen.

Klar Stellung beziehen setzt natürlich voraus, dass man weiß, wovon man redet. Wie gut das klappt haben wir in der Vergangenheit ja oft genug gesehen.

An der Stelle möchte ich mal eben eine Headline des bekannten Onlinemagazins Golem zitieren:

Das besondere elektronische Anwaltspostfach hat mehr als nur eine Sicherheitslücke. Die Probleme reichen von einer falschen Ende-zu-Ende-Verschlüsselung über Cross Site Scripting bis hin zu ROBOT und veralteten Java-Libraries. Dabei hat die Firma SEC Consult einen Sicherheitsaudit durchgeführt.

Quelle: golem.de IT-News für Profis, BEA:Noch mehr Sicherheitslücken im Anwaltspostfach. Bericht vom 4.1.2018¹¹⁾https://www.golem.de/news/bea-noch-mehr-sicherheitsluecken-im-anwaltspostfach-1801-131942.html

Doch damit nicht genug:

Die lokale BeA-Software ist in Java geschrieben und nutzt eine ganze Reihe von externen Libraries. Einige davon sind uralt und haben bekannte Sicherheitslücken. So wird beispielsweise die Bibliothek log4j in Verison 1.2.17 eingesetzt. Laut der Projektwebseite wird der gesamte Versionszweig 1 seit Oktober 2015 nicht mehr unterstützt. Einige der anderen Bibliotheken sind laut Felix Rohrbach [Anmerkung: Felix Rohrbach ist vom Chaos Computer Club Darmstadt] älter als das gesamte BeA-Projekt. (…) Auch auf dem Server nimmt man es bei BeA offenbar mit aktueller Software nicht so genau. Der Host bea-brak.de ist für die ROBOT-Sicherheitslücke in TLS anfällig. Es handelt sich dabei vermutlich um ein Netscaler-Gerät von Citrix, für das die jüngsten Sicherheitsupdates noch nicht installiert wurden.

Quelle: golem.de IT-News für Profis, BEA:Noch mehr Sicherheitslücken im Anwaltspostfach. Bericht vom 4.1.2018¹²⁾https://www.golem.de/news/bea-noch-mehr-sicherheitsluecken-im-anwaltspostfach-1801-131942-2.html

Updates auf den BRAK Webservern

Wer jetzt glaubt, die BRAK hätte aus ihren Fehlern gelernt… ja weit gefehlt.

Jagen wir mal die Webseite der Bundesrechtsanwaltskammer über den Qualys (SSL Labs) Test drüber.

Puh… selten so ein schlechtes Ergebnis gesehen. Selbst für den Nicht-Fachmann aufgrund der vielen Warnfarben recht einfach ersichtlich, dass das so nicht in Ordnung ist.

Bei der Bundesrechtsanwaltskammer nutzt man kostenfreie Let’s Encrypt Zertifikate, was per se nicht schlecht sein muss. Aber für ein System wie beA würde ich mir schon ein grünes SSL Symbol in der Adresszeile wünschen damit man sich als normaler Anwender auf Anhieb sicher sein kann, dass man auch wirklich auf der Seite der BRAK gelandet ist. Außerdem hat die BRAK eine veraltete Serversoftware oder Konfiguration und schneidet so schlussendlich mit einer ziemlich schlechten Sicherheitsbewertung „C“ ab.

Auf der beA Seite sieht es etwas besser aus, aber für ein angeblich „sicheres Nachrichtenportal“ noch immer schlecht:

Zum Vergleich, wenn ich denselben Test mit unserer eigenen Webseite mache, dann schaut das so aus:

Zum Verständnis, unsere Webseite ist einfach nur unsere Firmenwebseite, auf der ich hin und wieder ein paar Artikel veröffentliche, keine nennenswerten „sensiblen“ Daten gespeichert werden, nichts dergleichen. Sie besteht den Test mit Bestnote „A“.

Bei beA aber geht es um eine Webseite zum sicheren Übertragen von extremst sensitiven Nachrichten. Alles außer „A“ ist hier inakzeptabel.

Arbeit von Profis schaut anders aus.

Gravierende Sicherheitslücken

Angesichts dieser „Profis“ von der BRAK erstaunt es dann auch nicht weiter, dass beA-Nutzer mit dem beA Security Client eine JAVA Version auf ihren Rechnern installieren sollen, die bekannter Weise unzählige Sicherheitslücken aufweist. Der Expertenmeinung der Rechtsanwaltskammer darf man sicherlich mehr vertrauen als den Veröffentlichungen von als kritisch eingestufter Updates und Sicherheitswarnungen durch den Herstellers selbst. Wohlgemerkt, diese Sicherheitslücken sind von Oracle alle bereits geschlossen worden, nur die BRAK ist der Meinung, diese Updates braucht es auf Rechnern von Anwälten, AsssistentInnen, wissMits und Gerichten nicht:

• Critical Patch Updates, Security Alerts and Bulletins¹⁶⁾https://www.oracle.com/technetwork/topics/security/alerts-086861.html
• JDK 8u211 Bug Fixes¹⁷⁾https://www.oracle.com/technetwork/java/javase/2col/8u211-bugfixes-5292912.html
• JDK 8u221 Bug Fixes¹⁸⁾https://www.oracle.com/technetwork/java/javase/2col/8u221-bugfixes-5480117.html

Fazit

Die Art und Weise, wie die BRAK meinen Fragen wiederholt ausweicht, lässt vermuten, dass man sich dort sehr wohl der Problematik bewusst ist.

Ohne, dass ich danach gefragt hätte, fügt die BRAK in ihrer letzten Stellungnahme an:

Zeitgleich erarbeiten die Bundesrechtsanwaltskammer und ihre Dienstleister eine Umstellung auf eine andere JAVA-Version und damit verbunden auf ein alternatives Lizenzmodell.

Offizielle Stellungnahme der BRAK vom gestrigen 1.10.2019 auf meine Anfrage

Auch da gibt es, wie immer, keine konkreten Angaben.

Ich interpretiere das so, dass man sich bei der BRAK durchaus darüber im Klaren ist, dass man so ein Portal nicht ohne Sicherheitsupdates betreiben kann und es irgendwann so richtig knallt.

Wenn man sich keine JAVA Lizenzen leisten kann oder will, ist die einzige Alternative, auf ein kostenfreies Alternativprodukt zu wechseln. Ich tippe auf OpenJDK¹⁹⁾https://openjdk.java.net/. Es gibt aber auch noch verschiedene weitere Alternativen²⁰⁾https://blog.oio.de/2019/04/08/java-auch-in-zukunft-kostenlos-ein-uberblick-uber-die-alternativen/.

Bei ihren Erklärungsversuchen verstrickt sich die BRAK dabei immer mehr in unklare Aussagen zur beA Plattform, anstatt ein für alle Mal eine qualifizierte Aussage über die verwendeten Softwarekomponenten zu treffen.

Der Leidtragende ist der Anwalt, der diese Plattform verwenden muss und über die Nutzungsbedingungen der Clientsoftware von seiner Kammer im Unklaren und vom Support der BRAK im Stich gelassen wird.

Wie dem auch sei, Stand heute ist es eben noch eine alte JAVA Version, für die praktisch das gesamte Jahr 2019 keine Updates mehr durchgeführt wurden. Die Rechtfertigung durch ein Monitoring welcher Art auch immer ist hanebüchen. Das eine hat mit dem anderen nichts zu tun.