Was ist betroffen? Und was hilft gegen Log4Shell?

Bereits in der vergangenen Woche schrieb die Sicherheitsfirma Luna Sec, dass es zum Ausnutzen der Lücke nur irgendeine Art Endpunkt brauche, der per Protokoll-Aufruf (HTTP, TCP u.a.) verfügbar ist und Strings entgegennimmt, die letztlich geloggt werden. Wie beschrieben kann es sich dabei auch um Nutzernamen oder ähnliches handeln. Einzige weitere Voraussetzung ist, dass eine verwundbare Version von Log4J auf der JVM eingesetzt wird.

Erschwerend kommt für die weltweite IT-Security nun hinzu, dass Log4J extrem weit verbreitet ist und sich nicht ohne Weiteres sagen lässt, ob Log4J auf den eigenen Systemen läuft. Immerhin wird das Open-Source-Werkzeug von zahlreichen weiteren Anwendungen integriert oder als Abhängigkeit genutzt. Auf Github findet sich inzwischen eine von der Community gepflegte Liste mit Sicherheitsmeldungen von Herstellern und Open-Source-Projekten, die betroffen sein könnten. Die Liste hat inzwischen mehr als 100 Einträge.

Die Liste auf Github ist zwar zunächst ein guter Anhaltspunkt, aber wahrscheinlich nicht abschließend oder vollständig. Aufgrund der großen Verbreitung des Werkzeugs ist davon auszugehen, dass Log4J wahrscheinlich auf den eigenen Systemen irgendwo genutzt wird, wenn auch nur als Abhängigkeit. Um mögliche Log4J-Instanzen zu suchen, hat etwa Cloudflare sämtliche seiner JVM-Instanzen systematisch untersucht und ist dabei auch fündig geworden.

Laut dem Magazin Spiegel (Paywall) sind auch mehrere Bundesbehörden betroffen. Demnach hat das BSI eine einstellige Zahl an Stellen in der Bundesverwaltung ausgemacht, die Log4J eingesetzt haben sollen. Hinweise, dass die Sicherheitslücke tatsächlich ausgenutzt wurde, liegen derzeit jedoch nicht vor.

Auch beim ITZ-Bund, dem zentralen IT-Dienstleister der Bundesverwaltung, wird Log4J eingesetzt. Auch dort gibt man jedoch vorsichtig Entwarnung. Alle bisherigen Überprüfungen hätten gezeigt, dass es keinerlei unberechtigte Zugriffe durch die Sicherheitslücke auf die Netze der Bundesverwaltung gegeben habe. Betroffen ist unter anderem das besondere elektronische Anwaltspostfach (BeA) und Teile der Gematik-Infrastruktur sind derzeit präventiv vom Netz genommen worden. Darüber hinaus heißt es: "Aktensysteme der ePA-Apps einiger Krankenkassen wurden in den Wartungsmodus versetzt."

Am Samstag hatte das BSI die höchste Warnstufe wegen der Sicherheitslücke ausgerufen. Im Krisenreaktionszentrum des BSI befassen sich seitdem mehrere Personen rund um die Uhr mit dem Problem. Auch mehrere Unternehmen aus dem Bereich der kritischen Infrastruktur sollen von der Sicherheitslücke betroffen sein.

Welche Gegenmaßnahmen gibt es? Und wie gut sind diese?

Als unmittelbare Gegenmaßnahme empfiehlt das Team von Log4J ein Update auf die aktuelle Version 2.15, in der das zugrunde liegende Problem behoben ist. Darüber hinaus sind aber auch weitere Versionen betroffen. Die offizielle Empfehlung ist hier für Versionen ab 2.10: Das Setzen der Eigenschaft log4j2.formatMsgNoLookups auf true oder der Variable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true.

Für die ebenfalls verwundbare Version 2.0-beta9 bis einschließlich 2.10 empfiehlt das Log4J-Team ein Vorgehen mit dem Holzhammer: das komplette Entfernen der JNDI-Lookup-Klasse aus der Anwendung:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class .

Das verhindert effektiv ein Ausnutzen der Lücke, da JNDI-Aufrufe dann nicht mehr ausgeführt werden können.

Anders als zunächst angenommen, gilt inzwischen auch die Version 1 von Log4J unter bestimmten Umständen als verwundbar für den Angriff, nicht nur Version 2. Die Version 1 wird jedoch seit einigen Jahren nicht mehr offiziell gepflegt und ist End-of-Life (EOL). Offizielle Gegenmaßnahmen werden hier nicht beschrieben, es ist aber sicher sinnvoll, auf ähnliche Weise wie oben beschrieben zu versuchen, den Aufruf von JDNI zu unterbinden.

Damit all das erfolgreich funktioniert, müssen zuvor sämtliche Log4J-Instanzen im eigenen System gefunden werden. Zum Einspielen der Updates sind Nutzer darüber hinaus unter Umständen von ihren jeweiligen Software-Anbietern abhängig, die Log4J bündeln. Auch das macht die Lücke so gefährlich.