Fataler Konstruktionsfehler im besonderen elektronischen Anwaltspostfach

Der Hörsaal im Piloty-Gebäude der Technischen Universität Darmstadt war bis auf den letzten Platz gefüllt: Die Bugs und Sicherheitslücken im besonderen elektronischen Anwaltspostfach (beA) stoßen offensichtlich auf großes Interesse. Verwunderlich war der rege Publikumszuspruch auch angesichts der Vortragenden nicht: Markus Drenger und Felix Rohrbach vom Chaos Darmstadt e.V. präsentierten ihre Erkenntnisse zum beA der interessierten Öffentlichkeit.

Drenger und Rohrbach haben keinen vollständigen Security Review des beA-Systems durchgeführt. Sie hatten weder Zugriff auf Sourcen noch zum Server. Sie hatten auch keine Benutzer-ID im System, keine Smartcard oder irgendwelche privilegierten Informationen. Sie haben lediglich die Linux-Version des öffentlich verfügbaren Clients heruntergeladen und diese installiert. Dabei zieht die Software zahlreiche weitere Bibliotheken aus dem Netz nach und installiert diese. Ein erster Blick auf diese Komponenten ergab bereits, dass einige davon seit Jahren veraltet sind und ungepatchte dokumentierte Sicherheitslücken aufweisen. Das ist ein lösbares Problem.

Keine Sicherheit auf unsicherem Grund

Schwerwiegender ist ein grundsätzliches Problem. beA versucht eine sichere Lösung auf unsicherem Untergrund aufzubauen. Die Software lädt einen Webserver als Hintergrundprozess und präsentiert die Benutzerschnittstelle in einem Browser. Da sie Verbindungen zum öffentlichen beA-Server per TLS unterhält, muss sie mit dem Hintergrundprozess ebenfalls per TLS kommunizieren, da sonst der Browser wegen unsicherer Seitenbestandteile Alarm schlägt. Und daraus folgt, dass dieser Hintergrundprozess ein gültiges Zertifikat vorweisen muss, das vom Browser akzeptiert wird.

Dieses Zertifikat mit öffentlichem und privaten Schlüssel war zusammen mit dem verschleierten Passwort in der Client-Software gespeichert. Da diese Lösung aus Sicherheitsgründen ausdrücklich verboten ist, zog die Zertifizierungsstelle das Zertifikat zurück, sobald diese Tatsache bekannt wurde. Die BRAK (Bundesrechtsanwaltskammer) sprach davon, das Zertifikat sei "abgelaufen", was nach einem Flüchtigkeitsfehler klang, und gab ein neues Zertifikat aus. Dieses neue Zertifikat war nicht von einer dem Browser bekannten Zertifizierungsstelle signiert, sondern von einer selbst erstellten eigenen Certificate Authority.

Das Problem hatte sich damit verdoppelt. Nicht nur war das Zertifikat unsicher gespeichert, sondern jetzt musste diese CA noch im Browser installiert werden. Auch hier wurde wieder das Zertifikat vollständig ausgeliefert und kompromittierte damit die Sicherheit des Browsers komplett. Nach Bekanntwerden wurde diese scheinbare Lösung umgehend zurückgezogen. Der gesetzlich vorgeschriebene Start des beA zum 1. Januar 2018 war gescheitert.

Spitze des Eisbergs?

Das grundlegende Problem liegt darin, dass der Client sowohl das Zertifikat als auch das Kennwort dazu kennt. Der Schlüssel liegt sozusagen unter der Fußmatte. Es spielt keine Rolle, unter welcher Ecke der Fußmatte man ihn versteckt, denn er ist stets präsent. Das lässt sich nur heilen, indem man den Client anders konzipiert. Unklar ist, wie diese Konstruktion überhaupt als sicher zertifiziert werden konnte.

Hinter diesem bekannten Problem lauert ein viel größeres. Drenger und Rohrbach haben diesen Fehler nur zufällig gefunden, weil man den Client einfach herunterladen konnte. Die Frage ist, wie viele andere eGovernment-Lösungen ähnlich angreifbar sind und nur noch nicht entdeckt wurden. Man denke etwa an das Notariatspostfach. Wegschauen dürfte keine Lösung sein.

Update 20.1.2018: Chaos Darmstadt hat einen Mitschnitt des Vortrags online gestellt:

(vowe)