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.
- BeA: Noch mehr Sicherheitslücken im Anwaltspostfach
- Verwundbar für simple Cross-Site-Scripting-Lücke
- Hat SEC Consult all das übersehen?
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 |
Genau so schauts aus. Auf eine perverse Art hat Atos nämlich alles richtig gemacht und...
Davon abgesehen, dass De-Mail eigentlich ein Flopp sondergleichen ist, funktioniert es...
Finde auch, der Name passt perfekt :D
Die Audits an den Zertifizierungsstellen sind oft der letzte Mist. Mich würde es nicht...