Original-URL des Artikels: https://www.golem.de/news/bea-noch-mehr-sicherheitsluecken-im-anwaltspostfach-1801-131942.html    Veröffentlicht: 04.01.2018 07:00    Kurz-URL: https://glm.io/131942

BeA

Noch mehr Sicherheitslücken im Anwaltspostfach

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.

Das besondere elektronische Anwaltspostfach (BeA) bleibt vorerst offline, und das wohl mindestens bis Ende Januar. Das hat die Bundesrechtsanwaltskammer ihren Mitgliedern in einem Schreiben mitgeteilt. Hintergrund ist, dass die Software aufgrund eines integrierten Zertifikats samt privatem Schlüssel eine gravierende Sicherheitslücke aufwies. Golem.de hatte vor Weihnachten darüber berichtet und war auch an der Aufdeckung der Details beteiligt.

Doch die Probleme mit dem Zertifikat sind längst nicht die einzige Baustelle beim Anwaltspostfach. Einiges war schon vorher bekannt, anderes hatten Markus Drenger und Felix Rohrbach vom Chaos Computer Club Darmstadt auf dem 34C3 in einem Vortrag erläutert.

Eine Ende-zu-Ende-Verschlüsselung, die keine ist

"Die sichere Übermittlung der Nachrichten wird beim BeA durch eine sogenannte Ende-zu-Ende-Verschlüsselung gewährleistet", heißt es auf den Webseiten der Bundesrechtsanwaltskammer. Weiter wird behauptet, "auch die BRAK als Betreiber des BeA oder der Systemadministrator der Kanzlei können die Nachrichten nicht lesen." Doch das Anwaltspostfach hat eine Funktion, die die gesamte Sicherheit der Ende-zu-Ende-Verschlüsselung wieder aushebelt.

Das Anwaltspostfach sieht nämlich eine "Umschlüsselung" der Nachrichten auf dem Server vor. Die Idee dabei: Ein Nutzer des Postfachs kann definieren, dass Nachrichten an ihn auch von einer anderen berechtigten Person gelesen werden können.

Damit das funktioniert, muss der Server natürlich Zugriff auf den privaten Schlüssel des Empfängers haben. Dieser befindet sich in einem sogenannten Hardware Security Module (HSM). Hier noch von einer Ende-zu-Ende-Verschlüsselung zu sprechen, ist eine sehr kreative Auslegung des Begriffs.

Diese Konstruktion war auch bisher kein Geheimnis. Auf der übrigens nur unverschlüsselt über HTTP erreichbaren Webseite der Rechtsanwaltskammer zum BeA wird mit einigen Klimmzügen versucht, zu begründen, warum das Ganze trotzdem sicher sein soll. Da ausschließlich das HSM Zugriff auf die Schlüssel hat und die Nachricht auch niemals vollständig entschlüsselt wird - zur Umschlüsselung muss nur der asymmetrische Teil einer Hybridverschlüsselung durchgeführt werden -, sah man in dieser Konstruktion offenbar kein Problem.

Webinterfaces vertragen sich nicht mit einer sicheren Ende-zu-Ende-Verschlüsselung

Doch die Ende-zu-Ende-Verschlüsselung hat ein noch viel fundamentaleres Problem: Die Nutzer der BeA-Anwendung kommunizieren mit dieser generell über ein Webinterface. Die lokale Software ist nur dazu da, die Kommunikation mit der Chipkarte durchzuführen.

Ein Webinterface verträgt sich aber überhaupt nicht mit einer Ende-zu-Ende-Verschlüsselung, da der Server jederzeit anderen Javascript-Code schicken kann, der die Verschlüsselung aushebelt oder Nachrichten unverschlüsselt an Dritte weiterleitet.

Es ist offensichtlich, dass bei der Konstruktion von BeA grundlegende Missverständnisse über den Sinn und Zweck einer Ende-zu-Ende-Verschlüsselung vorlagen. Die Idee einer Ende-zu-Ende-Verschlüsselung ist, dass man dem Betreiber der Serverinfrastruktur nicht vertrauen muss. Beim BeA hat dieser aber gleich mehrere Möglichkeiten, die Sicherheit des Systems zu kompromittieren und Nachrichten mitzulesen.



Verwundbar für simple Cross-Site-Scripting-Lücke

Eine weitere Sicherheitslücke zeigte Markus Drenger in einem kurzen Video. Auf der Startseite der Anwendung - die natürlich zurzeit offline ist - gibt es einen URL-Parameter "dswid". Dieser war für einen trivialen Cross-Site-Scripting-Angriff anfällig. Man konnte schlicht in die URL entsprechenden Javascript-Code einfügen, der direkt ausgeführt wurde.

Damit hätte ein Angreifer, der einen Nutzer der Anwendung auf eine bösartige Seite lockt, jederzeit die komplette Kontrolle über die Webanwendung übernehmen können.

An dieser Lücke ist vor allem bemerkenswert, wie trivial sie zu finden war. Eine Suche nach Cross-Site-Scripting-Lücken in Variablen gehört üblicherweise zum Ersten, was man ausprobiert, wenn man die Sicherheit einer Webseite beurteilt.

Veraltete Software

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 ä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.

Interessant ist in diesem Zusammenhang auch die Dokumentation von BeA. In der Liste der unterstützen Betriebssysteme findet man ausschließlich nicht mehr aktuelle Versionen. An Linuxsystemen wird offiziell nur OpenSUSE 13.2 unterstützt - dessen Support endete im Januar 2017. Windows wird demnach von Vista bis 8.1 unterstützt, Windows 10 findet man nicht, und auch von OS X wird nur die schon etwas ältere Version El Capitan unterstützt.

Weitere Probleme verweisen auf wenig Sicherheitsbewusstsein

Eine ganze Reihe von kleineren Problemen, die für sich genommen keine großen Sicherheitslücken darstellen, lassen zumindest Zweifel daran aufkommen, wie ernst man es bei der Entwicklung von BeA mit der Sicherheit genommen hat.

Neben der BeA-Webanwendung gibt es eine Informationsseite der Bundesrechtsanwaltskammer unter bea.brak.de - und die ist nur mittels unsicherer HTTP-Verbindungen erreichbar. Damit sind SSL-Stripping-Angriffe denkbar, da sicher viele Anwender zunächst diese Informationsseite aufrufen und sich von dort zum BeA-Login durchklicken. Auch die HTTPS-Konfiguration der eigentlichen BeA-Webanwendung ist nicht optimal, so kommt beispielsweise kein HSTS zum Einsatz.

Auf dem eigentlichen BeA-Server kann man mittels spezieller URLs Meldungen erhalten, die einem verraten, mit welchen Filterregeln diese gerade blockiert wurden. Auf der dort angezeigten Seite wird man an eine Helpdesk-Mailadresse und Telefonnummer verwiesen, diese sind jedoch nur Platzhalter.



Hat SEC Consult all das übersehen?

Bei all den Problemen stellt sich die Frage, ob jemals jemand die BeA-Software auf Sicherheitslücken geprüft hat. Auf eine Anfrage nach dem Informationsfreiheitsgesetz hatte die Bundesrechtsanwaltskammer Markus Drenger vom CCC Darmstadt mitgeteilt, dass im Jahr 2015 ein Sicherheitsaudit von der Firma SEC Consult durchgeführt worden sei. Den Audit-Report könne man ihm aber nicht zur Verfügung stellen - dieser sei ein Geschäftsgeheimnis der Herstellerfirma Atos.

SEC Consult hat uns das auch bestätigt - demnach wurde ein Blackbox-Test der BeA-Webanwendung durchgeführt. Doch zu Details des Tests darf SEC Consult nach eigenen Angaben nichts sagen.

Die Firma SEC Consult hat durchaus keinen schlechten Ruf in der IT-Sicherheitscommunity. Auch Golem hat schon mehrfach über die Arbeit der Firma berichtet. Interessanterweise hat SEC Consult im Jahr 2015 ausführlich über ein Problem mit privaten Schlüsseln in der Firmware von Embedded-Geräten berichtet - eine Lücke, die dem Zertifikatsproblem von BeA sehr ähnlich ist.

Im Juni 2017 hat SEC Consult Sicherheitslücken in der Software OSCI aufgedeckt. OCSI ist für den sicheren Datenaustausch zwischen Regierungsanwendungen entwickelt - und stammt von der Firma Governikus. Governikus wiederum ist auch an der Entwicklung von BeA beteiligt. BeA selbst kommuniziert ebenfalls nach dem OCSI-Standard, ob dabei allerdings dieselbe Softwareimplementierung zum Einsatz kommt konnten wir nicht herausfinden.

Ein Vertreter des von der Bundesrechtsanwaltskammer inzwischen eingeschalteten Kommunikationsbüros Johanssen + Kretschmer teilte uns telefonisch mit, dass in der Anwendungsversion, die 2015 von SEC Consult untersucht wurde, das grundsätzliche Problem mit dem Zertifikat und dem privaten Schlüssel bereits bestand. SEC Consult habe demnach die Sicherheit dieser Anwendung bestätigt.

Welche Rolle die Firma Governikus spielt, hätten wir auch gerne herausgefunden. Doch das Kommunikationsbüro der Bundesrechtsanwaltskammer teilte uns dazu mit, dass Governikus von Atos beauftragt wurde und man nicht wisse, wie die genaue Aufgabenverteilung war. Governikus selbst wiederum verwies uns an das Kommunikationsbüro der Bundesrechtsanwaltskammer.

Wie geht es weiter?

Wie es mit dem Anwaltspostfach weitergeht, ist im Moment nicht abzusehen. Eigentlich sind Rechtsanwälte seit dem 1. Januar verpflichtet, mittels BeA Nachrichten zu empfangen. Aber selbstverständlich ist dies momentan nicht möglich.

Laut dem Kommunikationsbüro der Rechtsanwaltskammer befindet man sich im Kontakt mit dem Bundesamt für Sicherheit in der Informationstechnik (BSI). An der Entwicklung der bisherigen BeA-Software war das BSI demnach nicht beteiligt.

Angesichts der Vielzahl von teils sehr grundlegenden Problemen scheint es fragwürdig, ob die BeA-Software überhaupt zu retten ist. Sie hat die Rechtsanwälte wohl bislang 38 Millionen Euro gekostet.

Der Präsident der Bundesrechtsanwaltskammer, Ekkehart Schäfer, wandte sich mit einem Brief an die betroffenen Anwaltskanzleien. Darin bedankt sich Schäfer bei Markus Drenger für das Aufdecken der Sicherheitslücken und geht davon aus, dass das BeA im Januar abgeschaltet bleiben wird.  (hab)


Verwandte Artikel:
BeA: So geht es mit dem Anwaltspostfach weiter   
(29.01.2018, https://glm.io/132430 )
Bundesrechtsanwaltskammer: Anwälte sollen BeA sofort deinstallieren   
(26.01.2018, https://glm.io/132421 )
Anwaltspostfach: Die unnötige Ende-zu-Mitte-Verschlüsselung von BeA   
(26.01.2018, https://glm.io/132394 )
Atos: Hersteller von Anwaltspostfach will keine Fragen beantworten   
(24.01.2018, https://glm.io/132365 )
Gerichtspostfach: EGVP-Client kann weiter genutzt werden   
(21.01.2018, https://glm.io/132277 )

© 1997–2019 Golem.de, https://www.golem.de/