Aus Entwicklersicht: BSI ruft höchste Warnstufe für Server in Deutschland aus
Neben der höchsten Warnstufe wurde auch per Twitter vom BSI zur Mithilfe aufgerufen unsere IT Infrastruktur in Deutschland zu sichern. Was sagt ein Entwickler dazu?
Unter dem Namen log4Shell oder Log4j wurde am 10.12.2021 eine schwere Sicherheitslücke in der Java Programmiersprache offengelegt. Besonders schwerwiegend dabei war die Verbreitung von Log4j und die Art des Zugriffs für Angreifer. Eine enorm große Anzahl an Firmen hat Log4j im Einsatz und die Sicherheitslücke erlaubt Angreifern Shell bzw. root Zugriff auf Server, was bedeutet, dass man beliebigen Code auf einem fremden Server ausführen kann - das ist das Wunschziel eines jeden Hackers. Somit war es verwunderlich, dass vom BSI (Bundesamt für Sicherheit in der Informationstechnik) zunächst nur eine sehr geringe Einstufung des Problems ausgegeben wurde. Anscheinend wurden die Rufe von Sicherheitsexperten aber lauter und man hat kurz darauf einen erneuten Tweet mit Sicherheitsstufe Orange getätigt. Einen Tag später, am 11.12.2021 wurde dann die Sicherheitsstufe auf Rot hochgesetzt und um Mithilfe aufgerufen, dass betroffene Systeme möglichst schnell geupdated werden.
Worum handelt es sich aber bei Log4j wirklich? Dabei geht es nicht direkt um ein Problem mit der Programmiersprache selbst, sondern mit einem von Apache, der Firma hinter Java, zur Verfügung gestelltes Stück Software zum Loggen von Informationen im Code. Logging bedeutet, dass Aktionen vom Code, Probleme oder Fehler oder einfache Hinweise gespeichert werden, damit die Entwickler:innen eine nachvollziehbare Liste haben falls Bugs auftreten. So etwas ist für Entwickler:innen wichtig und auch in allen anderen Programmiersprachen neben Java sehr gängige Praxis. Wenn bei einem Benutzer von einer App ein Problem auftritt sitzt nicht der:die Entwickler:in vor dem Bildschirm und sieht den Fehler, aber er kann zumindest hinterher an Hand von der Log Datei nachvollziehen was passiert ist und somit ein Problem finden und beheben.
Üblicherweise bestimmt der:die Entwickler:in was in eine Log Datei gespeichert wird und auch wo diese abgelegt wird. Üblicherweise werden dort möglichst viele Informationen abgelegt, die zum Finden eines Fehlers behilflich sein können. Standardmäßig wird das Datum mit sekundengenauer Anzeige gespeichert, sowie ein Fehlercode oder wo im Code der Fehler aufgetreten ist. So wird es auch bei Log4j gemacht mit sogenannten Lookups, die Informationen zur Java Version, Benutzer und mehr enthalten können. Aber, es gibt hier noch mehr Features wie zum Beispiel den Versand von Logs bzw. Benachrichtigungen per Email. Sowas ist auch sehr praktisch, da man als Entwickler:in nicht ins Log schauen muss, sondern benachrichtigt wird falls Probleme auftreten. Eines dieser Features nennt sich JNDI (Java Naming and Directory Interface), was es erlaubt Lookups auf anderen Systemen übers Internet auszuführen. Das kann nützlich sein wenn man mehrere Server für seine App betreibt und eine einheitliche Konfiguration für Logging nicht auf jedem System ablegt und ggfs. ändern muss, sondern zentral gespeichert hat.
Genau dieses Feature wurde zum Problem für Log4shell, denn somit konnten nicht nur Konfigurationen von extern geladen werden, sondern auch ganze Java Objekte mit eigenen Funktionen, die schädlichen Code enthalten können. Zusätzlich waren Lookups und JNDI standardmäßig auf allen Systemen aktiv, wenn sie nicht explizit deaktiviert wurden. Dadurch war es plötzlich so ein großes Problem als die Sicherheitslücke am 10.12.2021 öffentlich gemacht wurde.
Jetzt wissen wir wo das Problem liegt und wie es genutzt wird, aber was bedeutet es für Entwickler:innen? Grundsätzlich ist wie weiter oben bereits erwähnt ein Logging Mechanismus in jeder Programmiersprache üblich. Auch die darin enthaltenen Features sind gängige Szenarien, die in der Software Entwicklung so genutzt werden. Was hätte man als Entwickler:in also besser oder anders machen können? Aus unserer Sicht gibt es hier wenig Verbesserungspotenzial, denn Entwickler:innen arbeiten auf einer anderen Ebene als Hacker. Als Entwickler:in ist Log4j und jedes andere Logging Tool ein Werkzeug, dass vom Hersteller der Programmiersprache zur Verfügung gestellt wurde, um saubere und fehlerfreie Anwendungen zu programmieren. Der Fokus von Entwickler:innen liegt auch genau darauf, ein möglichst einfaches, intuitives und produktives User Experience in seiner App zu schaffen. Natürlich ist Sicherheit immer ein Aspekt den man berücksichtigen muss, aber im Alltag als Programmierer:in bezieht sich das meist nur auf selbst programmierte Software und nicht vom Hersteller zur Verfügung gestellte Programme.
Schwachstellen und Fehler in solchen frei verfügbaren Anwendungen zu finden ist Aufgabe von Hackern und Sicherheitsexperten. Diese haben den eigentlichen Fehler von Log4j bereits 2016 auf der Black Hat USA Konferenz öffentlich gemacht: A journey from JNDI/LDAP Manipulation to Remote Code Execution Dream Land. Das bedeutet ausserdem, dass seit JNDI Lookups in 2013 eingeführt wurden, die Sicherheitslücke schon seit 8 Jahren besteht und zumindest seit 2016 öffentlich bekannt ist. Es ist immer sinnvoll, wenn sich ein:e Entwickler:in mit Sicherheit beschäftigt und die Grundprinzipien von sicherer Programmierung berücksichtigt, aber in diesem Fall wäre es am Hersteller gewesen, dieses Problem früher zu erkennen und zu beheben.
Abschliessend wollen wir noch zusätzlich erwähnen, dass alle Server mit Java Anwendungen möglichst schnell geupdated werden sollten, damit dieses Problem nicht weiter ausgenutzt werden kann. Für Leute mit Interesse an IT Sicherheit auf jedem Level bieten wir entsprechende Kurse an, die wir auch online über Zoom durchführen. Schaut dafür einfach unter unsere Kurse Sektion.