Quelle: Pixabay
Am 10. Dezember 2021 wurde eine überaus kritische, da trivial auszunutzende, Sicherheitslücke (Log4Shell) in der Standardbibliothek Log4J bekannt. Seit deren Bekanntwerden liefern sich Hacker*innen und Sicherheitsfachleute ein Wettrennen um die Zeit. „Eine erfolgreiche Ausnutzung der Schwachstelle ermöglicht eine vollständige Übernahme des betroffenen Systems“, lautet die eindringliche Warnung von Arne Schönbohm, Präsident des Bundesamtes für Sicherheit in der Informationstechnik (BSI).
Die Liste derer, die Log4j einsetzen und damit potenzielle Ziele sind, ist lang und umfasst wegen der Verwendung in weitverbreiteten kommerziellen Software-Produkten neben globalen Unternehmen wie Apple, Google, Tesla und Amazon, auch mehrere deutsche Bundesbehörden und Hochschulen. Grund genug für Bundesamt für Sicherheit in der Informationstechnik die Warnstufe Rot auszurufen: es handelt sich um eine „extrem kritische IT-Sicherheitslage“, denn „diese kritische Schwachstelle hat demnach möglicherweise Auswirkungen auf alle aus dem Internet erreichbaren Java-Anwendungen, die mithilfe von Log4j Teile der Nutzeranfragen protokollieren“. Das Internet wird automatisiert und umfassend von Cyber-Kriminellen nach Servern und Anwendungen durchsucht, die Log4j nutzen und somit der Gefahr der feindlichen Übernahme ausgesetzt sind. Erste erkannte Attacken bestanden in der Installation von Programmen auf Servern, deren Rechenleistungen zur Vermehrung von Kryptowährungen dienten.
Besonders tückisch ist die Möglichkeit der Ausführung späterer Angriffe. So kann die Sicherheitslücke als Vorbereitung des eigentlichen Angriffs dienen. In diesem Fall nisten Cyber-Kriminelle sich durch noch nicht gesicherte Lücken in Servern ein und schlagen gegebenenfalls später überraschend zu, um die Kontrolle über größere Teile eines Netzwerks oder Systems zu übernehmen. Somit wird das Ausmaß dieser Sicherheitslücke erst viel später sichtbar.
Aber was genau ist eigentlich Log4J?
1996, in einer Zeit als Java-Standardbibliotheken noch keine Protokollfunktion (Logging) hatten, entstand das Log4J – J für Java. Heutzutage ist es aufgrund der Konfigurierbarkeit für viele Entwickler*innen und Administrator*innen das Protokollsystem zu einem De-facto-Standard geworden. Mit dem Erfolg des Projektes fand es auch Anwendung in weiteren Programmiersprachen und auf unzähligen Plattformen statt.
Dabei handelt es sich um eine so genannte Open-Source-Software. Dies bedeutet, dass der Quellcode offen liegt und somit Fachleute ihn prüfen und frei nutzen können. Allerdings werden Open-Source-Projekte häufig von Nutzergemeinschaften in deren Freizeit programmiert und weiterentwickelt. Daher fehlt es bisweilen an regelmäßigen professionellen Sicherheitschecks. So kam es 2014 zu einer Schwachstelle der weitverbreiteten Open-Source-Softwarekomponente OpenSSL zur Absicherung von Internetverbindungen. Die unter dem Namen Heartbleed bekannt gewordene Schwachstelle ermöglichte Cyber-Kriminellen den Zugriff auf Login-Daten und sensible Informationen. Diese Schwachstelle wurde erst nach 27 Monaten entdeckt.
Log4Shell auch an der RWTH Aachen
Die Zero-Day-Sicherheitslücke Log4Shell in der Java-Logging-Bibliothek Log4j hat auch einige Systeme der RWTH Aachen betroffen. Dazu gehören grundlegende Services im Bereich der Lehre und Kollaboration, die insbesondere in Zeiten von Homeoffice und Online-Lehre elementar sind. Als erste Sofortmaßnahme nach Bekanntwerden des Sicherheitslecks am 10. Dezember 2021 wurden die entsprechend gefährdeten Systeme des IT Centers überprüft und geeignete Maßnahmen eingeleitet. Dazu gehörte auch die Abschaltung einzelner Systeme, wie etwa Coscine, DigitalArchiv, GigaMove, GitLab, und der RWTH-Streamingserver (Opencast).
Nach Bereitstellung von Informationen zu sicherheitsrelevanten Java-Einstellungen sowie Patches zur Schließung der Sicherheitslücke von den Herstellern, wurden diese unmittelbar im Produktivsystem eingespielt. In allen Fällen ging dem zunächst eine erfolgreiche Prüfung im Testsystem voraus. Aufgrund der hohen Aktualität und Brisanz haben sich allerdings nicht alle Konfigurationen und Patches als hinreichend wirksam erwiesen, so dass regelmäßig neue Updates dieser kamen.
Die derzeit gültigen Aktualisierungen wurdenauf alle betroffenen Systemen eingespielt und die entsprechenden Services konnten am 20.12.2021 bzw. 21.12.2021 reaktiviert werden. Grundlage für die Entscheidung zur Reihenfolge der Inbetriebnahme der Systeme war neben der Priorität für Lehre und Hochschulbetrieb auch die Verwundbarkeit des jeweiligen Systems sowie die Verfügbarkeit der nötigen Patches.
Eine Chronologie der Ereignisse
- 21.12.2021 Reaktivierung des RWTH-Streamingservers (Opencast)
- 20.12.2021 Wiederinbetriebnahme von Coscine, DigitalArchiv, GigaMove und GitLab
- 16.12.2021 Abschaltung des RWTH-Streamingservers (Opencast)
- 14.12.2021 Teil-Inbetriebnahme vom GitLab
- 13.12.2021 Abschaltung von Coscine, DigitalArchiv, GigaMove, GitLab
- 11.12.2021 Gewährung des vollen Zugriffs auf RWTHonline
- 10.12.2021 Bekanntwerden der Sicherheitslücke Log4Shell: Start der Überprüfung gefährdeter Systeme am IT Center und Einschränkung des Zugriffs auf RWTHonline
Nähere Informationen zur Zero-Day-Sicherheitslücke Log4Shell könnt ihr der Webseite vom BSI entnehmen.
Verantwortlich für die Inhalte dieses Beitrags sind Anastasios Krikas und Nicole Kaminski.
