Die Update-Problematik des Governikus Communicator

Im IT-Umfeld werden Fehler gemacht, solange Menschen noch die Software erstellen. Im Umfeld des elektronischen Rechtsverkehrs (ERV) hat das gerade die Problematik um das besondere elektronische Anwaltspostfach (beA) gezeigt. Aber auch andere Programme sind vor sicherheitsrelevanten Anfälligkeiten nicht geschützt. Im Rahmen einer Fehlerkultur muss man mit diesem Problem dann verantwortungsbewusst umgehen. Diese Verantwortung kann zum Beispiel durch eine schrittweise Veröffentlichung des Problems übernommen werden: Zuerst wird der Hersteller informiert und erst nach dem Eintritt einer von zwei Bedingungen die Öffentlichkeit: a. Wenn das Problem behoben ist. b. Wenn der Hersteller sich nach einer Frist nicht meldet oder das Problem nicht anerkennt.

Dieses als „responsible disclosure“ bezeichnete Verfahren stellt einen angemessenen Interessensausgleich zwischen dem Recht zur Information der Öffentlichkeit vor IT-Gefahren und dem sicheren Weiterbetrieb einer IT-Infrastruktur her. Im Gegensatz dazu steht das sogenannte „full disclosure“-Verfahren, nach dem sofort alle vorhandenen Informationen zu einem IT-Problem preisgegeben werden. Mit diesem Vorgehen kann man ein (gewünschtes) Chaos verursachen, dass z.B. im Falle des beA zu einer notwendigen Diskussion geführt hat, die zuvor von den Akteuren erfolgreich unterbunden wurde.

Die folgende Problematik wurde von jurmatix Legal Intelligence entdeckt, dem Hersteller der Software vorab mitgeteilt und binnen kurzer Zeit behoben.

Governikus Communicator Update-Funktion

Der Governikus Communicator dient zur Bereitstellung einer Sende- und Empfangskomponente im Rechtsverkehr für das elektronische Gerichts- und Verwaltungspostfach (EGVP). Er kann von jedermann auf seinem PC installiert werden, um mit an den elektronischen Rechtsverkehr angeschlossenen Gerichten und Behörden zu kommunizieren. Die Software steht zum Download bereit und dient nach Ausfall des beA-Client zur Kommunikation der Rechtsanwälte mit den Gerichten.

Der Communicator wird von Governikus hergestellt und ist dementsprechend szenetypisch ein Java-Dropper. Das heißt, es wird ein Java-Stack auf dem PC installiert, der nach dem Start die auszuführenden Java-Dateien von einem Server des Anbieters lädt. Hauptsächlich wird die Dropper-Technik in der Schadsoftwareszene verwendet. Dropper verursachen keinen direkten Schaden, können aber eine Malware-Nutzlast ohne Erkennung durch Antviren-Software auf eine Zielmaschine übertragen. Genau dieses Szenario ließ sich auch mit der gegenständlichen Software bis Version vom 31.01.2018 mit wenigen Manipulationen realisieren.

a. Nachladen der Java-Dateien

Welche Java-Dateien der Communicator zu laden hat, steht in einer XML-Datei, auf die nach dem Start des Programms zuerst zugegriffen wird: http://appl.governikus-communicator.de/produktiv/installer/justiz_client.xml. In ihr sind die Dateien aufgezählt, ihre Dateilänge und ein Zeitstempel hinterlegt. Die XML-Datei wird mit einer XML-Signatur gegen Manipulationen geschützt.

Diese Implementierung zum Nachladen der Dateien war aber ungenügend gegen die Veränderung der zu übertragenden Daten geschützt.

b. HTTP-Verbindung

Die Java-Dateien und die XML-Datei werden über HTTP auf den Client geladen. HTTP ist als unverschlüsseltes Übertragungsprotokoll ungenügend gegen das Mitschneiden oder Verändern des Datenverkehrs geschützt. Manipulationen sind einfach durchzuführen. Zudem wird bei jedem Start des Communicators erneut überprüft, ob geänderte Dateien auf dem Server vorliegen. Es findet also eine regelmäßige Abfrage statt und nicht nur eine für einen Angreifer schwerer einzusehende einmalige Abfrage.

c. Dateilängenüberprüfung

Nach dem Download der Java-Dateien wurden diese überprüft, ob die Dateilänge mit der in der XML-Datei angegebenen Größe übereinstimmt. Diese Überprüfung der Dateilängen als Validitätsmerkmal ist als unzureichend anzusehen. So können von einem Angreifer manipulierte Java-Klassen erstellt werden, die dieselbe Dateilänge haben, aber einen komplett anderen Code enthalten. Die Dateilängenüberprüfung war aufgrund von d. aber sowieso zwecklos.

d. XML-Signatur

Zur Absicherung wurde die XML-Datei mit einer Signatur versehen, die den Teil, in dem die zu ladenden Dateien beschrieben werden, gegen Manipulationen schützen sollte. Diese XML-Signatur wurde aber nur bei ihrem Vorhandensein in der XML-Datei überprüft. Entfernte man den Signatur-Code aus der XML-Datei, so wurde die Datei trotzdem verarbeitet und es wurden beliebige manipulierte Werte akzeptiert.

Schwere

Die Schwere des Problems war als hoch einzuschätzen. Das Problem stellt die erste dokumentierte Code-Injection-Lücke im ERV dar, mit der sich schlimmstenfalls die Nachrichten aus dem Communicator auslesen oder andere Schadsoftware installieren ließen. Angriffe, die sich nur in lokalen Netzen durchführen lassen, werden regelmäßig als „mittel“ in ihrer Schwere eingestuft. So lässt sich ein Angriff einfach im lokalen Netz ausführen, indem die Namensauflösung durch ARP-Spoofing manipuliert wird, um den Zugriff auf eine manipulierte XML-Datei umzuleiten. Allerdings ist der Angriff von außerhalb eines lokalen Netzes nicht ausgeschlossen. Es finden sich immer wieder Wege die Namensauflösung im Internet mittels DNS-Spoofing zu manipulieren, wenn man über die Möglichkeiten eines entsprechenden Ressourceneinsatzes verfügt.

In der aktuellen Version des Governikus Communicators ist das Problem behoben. Auch artverwandte Software desselben Herstellers war von dem Problem betroffen. Die Programme sollten auf jedem PC erneut installiert werden.

Links zu weiteren Problemen im elektronischen Rechtsverkehr (ERV):