fbpx

Datenschutz Kommunikationssystem für Justiz und Anwälte
Das elektronische Anwaltspostfach wartet trotz Sicherheitsaudit mit mehreren Sicherheitslücken auf. Zu ihnen gehört eine falsche End-zu-End-Verschlüsselung, Cross Site Scripting, ROBOT und veraltete Java-Libraries. Bis wenigstens Ende Januar bleibt es daher offline, wie die Bundesrechtsanwaltskammer in einem Rundbrief an ihre Mitglieder mitteilt.

Die End-zu-End-Verschlüsselung
Die sichere Übermittlung soll beim Anwaltspostfach BeA durch eine End-zu-End-Verschlüsselung gewährleistet werden, so die Bundesrechtsanwaltskammer. Sie behauptet, dass auch der Betreiber des BeA, die BRAK oder der Systemadmin der Kanzlei die elektronisch übermittelte Post nicht lesen können. Doch es gibt eine Funktion im Anwaltspostfach durch die die Sicherheit der End-zu-End-Verschlüsselung zunichtegemacht wird. Denn das Postfach nimmt eine „Umschlüsselung“ vor. Denn der Nutzer des Postfaches kann festlegen, dass die an ihn gerichteten Nachrichten auch von anderen berechtigten Personen angesehen werden können.

Dazu muss der Server Zugriff auf den Schlüssel des Adressaten der Post haben, welcher in einem Hardware Security Module hinterlegt ist. Hier kann von einer End-zu-End-Verschlüsselung keine Rede mehr sein. Die Rechtsanwaltskammer übt sich in Erklärungen, warum das Postfach dennoch sicher sein soll: Nur das HSM habe Zugriff auf diese Schlüssel, die Nachricht werde auch nicht vollständig entschlüsselt. Zur Umschlüsselung müsse nur ein asymmetrischer Teil der Hybridverschlüsselung vorgenommen werden.

Doch mit der End-zu-End-Verschlüsselung gibt es noch ein größeres Problem. Die Nutzer der Postfachanwendung kommunizieren mit dieser über ein Webinterface. Ein solches verträgt sich jedoch gar nicht mit der End-zu-End-Verschlüsselung, weil der Server jederzeit einen anderen Javascriptcode verschicken kann, welcher die Verschlüsselung aufhebt oder Post unverschlüsselt weiterleitet. Offensichtlich lagen bei der Konstruktion des Anwaltspostfachs grundlegende Missverständnisse bezüglich des Sinns einer End-zu-End-Verschlüsselung vor. Deren Idee ist, dass kein Vertrauen zum Betreiber der Serverinfrastruktur nötig ist. Doch beim BeA kann dieser gleich auf mehrere Weisen die Sicherheit kompromittieren und Nachrichten mitlesen.

Cross-Site-Scripting-Lücken
Ein weiteres Einfalltor zeigte sich in Form eines anfälligen URL-Parameters namens „dswid“. Er kann durch einfachen Cross-Site-Scripting-Angriff geknackt werden, indem der entsprechende Javascriptcode eingefügt wird. Angreifer hätten dadurch jederzeit die Seite unter ihre Kontrolle bekommen können.

Uralte Software
Die Software des Postfachs wurde in Java geschrieben und bedient sich mehrerer externer Libraries. Manche davon sind überaltert und weisen Sicherheitslücken auf, um die man längst weiß. Die gesamte Version wird ab 2015 nicht länger unterstützt. Manche der übrigen Bibliotheken sind noch älter. Auch die Serversoftware ist nicht aktuell. Von den Linuxsystemen wird nur eines genutzt, dessen Support 2017 endete. Windows wird bis zur Version 8.1 unterstützt. Eine Reihe weiterer Probleme lässt auf ein geringes Sicherheitsbewusstsein der Betreiber schließen.

Wurden die Fehler übersehen?
Der CCC Darmstadt teilte auf Anfrage mit, dass durch die Firma SEC Consult ein Sicherheitsaudit durchgeführt worden sei. Jedoch könne der Auditreport nicht zur Verfügung gestellt werden – er stelle gewissermaßen ein Geschäftsgeheimnis des Herstellers Atos dar. Zu Details darf auch SEC Consult nach deren Auskunft nichts sagen. Interessant ist, dass SEC Consult bereits im Jahr 2015 über ein Fehler bei privaten Schlüsseln bei Firmware bei Embeddedgeräten berichtet. Es handelt sich dabei um Lücken, die dem Problem des BeA ähnelt.

Im Jahr 2017 hat SEC die Software OSCI wegen Sicherheitslücken bemängelt. OCSI wurde für sicheren Datenaustausch von Regierungsanwendungen von der Herstellerfirma Governicus erstellt. Diese wiederum war auch bei der Erstellung von BeA mit von der Partie. BeA kommuniziert auch nach dem Standard des OCSI. Bekannt ist allerdings nicht, ob dabei die gleiche Softwareimplementierung eingesetzt wird.

Das von der Bundesrechtsanwaltskammer beauftragte Kommunikationsbüro soll gegenüber Golem.de mitgeteilt haben, dass die Version von 2015, die durch SEC Consult geprüft wurde, das Problem mit dem privaten Schlüssel und dem Zertifikat schon bestand. Dennoch wurde durch SEC Consult die Sicherheit der Anwendung bescheinigt. Welche Rolle Governicus hierbei spielt und wie es mit der Anwendung weitergeht, ist bislang nicht bekannt.