Wie erkenne ich Angriffe?

Da die Software so weit verbreitet ist und Updates beziehungsweise Gegenmaßnahmen im Zweifel nicht einfach umsetzbar sind, empfehlen viele Anbieter von Sicherheitssoftware oder Firewalls, entsprechende Filter und Regeln umzusetzen, mit denen Angriffe erkannt werden könnten. Wird dabei aber etwa nur nach dem Aufruf-Beginn "${jndi:ldap:" gefiltert, lässt sich dies wohl leicht verschleiern und so umgehen, wie Microsoft schreibt.

Das Team schreibt dazu: "Wir haben Dinge gesehen wie das Ausführen eines lower- oder upper-Kommandos innerhalb des Exploit-Strings ({jndi:${lower:l}${lower:d}a${lower:p}) und sogar noch kompliziertere Verschleierungsversuche (${${::-j}${::-n}${::-d}${::-i}), die alle versuchen, die String-Erkennung-Erkennung zu umgehen." Einige Sicherheitsforscher haben mit Blick auf die nahezu unendliche Anzahl an Möglichkeiten bereits aufgeben.

Seit wann laufen die Angriffe? Und wie gefährlich sind diese?

Doch für einige Server-Administratoren dürfte es schon vor dem Bekanntwerden der Sicherheitslücke zu spät für Patches gewesen sein. Laut dem CEO von Cloudflare, Matthew Prince, wurde die Lücke schon mehr als eine Woche vor ihrem öffentlichen Bekanntwerden ausgenutzt: "Der früheste Beweis, den wir bisher für den Log4J-Exploit gefunden haben, ist der 2021-12-01 04:36:50 UTC", schreibt Prince auf Twitter.

Beweise für eine massenhafte Ausnutzung der Lücke gebe es jedoch nicht, schränkt Prince ein. Auch die Sicherheitsfirma Talos hat Angriffe mit der Log4Shell-Lücke ab dem 2. Dezember beobachtet. Wer nach Anzeichen für eine Kompromittierung sucht, sollte den untersuchten Zeitraum also mindestens auf den kompletten Dezember ausweiten. Auch Microsoft warnt davor, dass die Lücke bereits aktiv für Malware-Kampagnen ausgenutzt wird, wie etwa für Cobalt-Strike.

Doch es könnte sogar noch viel schlimmer sein, denn die Lücke war über einen langen Zeitraum im Code von Apache Log4J ausnutzbar. Wer die Lücke bereits vor Monaten oder Jahren selbst entdeckt hat, konnte sie einfach ausnutzen. Hinweise darauf, dass die Lücke bereits vor Monaten gefunden worden ist, finden sich auf Github. Inzwischen wird sogar davor gewarnt, dass die Lücke zum Bau eines Wurms genutzt werde könnte.

Seit wann besteht die Lücke eigentlich?

Die entsprechende Funktionalität, die die Verwundbarkeit in Log4j eingeführt hat, wurde bereits im Jahr 2013 in den Code eingefügt. Nachvollziehbar ist das über den Bugtracker des Projekts. Auffällig dabei: Offenbar wurde das entsprechende Feature sehr schnell übernommen.

Bereits einen Tag, nachdem der entsprechende Patch bereitgestellt wurde, hatte ein Entwickler diesen in den offiziellen Code des Projekts aufgenommen. Damit erinnert die Entstehung der Lücke frappierend an einen anderen Vorfall: Der Heartbleed-Bug in OpenSSL. Auch da wurde ein potenziell gefährliches Feature von den Entwicklern ohne viel Nachfragen schnell in den eigenen Code eingepflegt - und dabei nicht erkannt, dass sich darin eine gefährliche Sicherheitslücke befand.

Und wie auch schon bei OpenSSL im Fall von Heartbleed arbeiten die Maintainer von Log4J bisher lediglich in ihrer Freizeit an der Anwendung.