Log4Shell und Spring4Shell

Last night I slept like a log. I woke up in the fireplace. 
- Tommy Cooper 

Wenn es regnet, dann so richtig. Diese beiden Sicherheitslücken traten innerhalb weniger Monate auf und sorgten für viele Schlagzeilen. Welche Gemeinsamkeiten und Unterschiede haben sie, und was sollten wir von ihnen lernen?

Log4j ist ein Java-basiertes Framework, das für die Protokollierung verwendet wird. Im Dezember 2021 wurde eine Sicherheitslücke bekannt, die die Ausführung von beliebigem Code auf den betroffenen Servern ermöglichte. Die Sicherheitslücke erhielt den Namen Log4Shell, weil sie dem Angreifer Shell-Login gewähren konnte. Apache stufte sie mit dem höchsten CVSS-Schweregrad von 10 ein und mehrere Experten bezeichneten sie als die kritischste Sicherheitslücke aller Zeiten. Schätzungen zufolge waren Hunderte Millionen von Geräten sowie mehrere beliebte Cloud-Hosting- und Cloud-Service-Anbieter betroffen.

Ende März 2022 meldete das Java-basierte Spring-Framework eine Sicherheitslücke für die Ausführung von Remote-Code in bestimmten Installationen, die aufgrund einiger Ähnlichkeiten mit Log4Shell als Spring4Shell bezeichnet wurde. Sie wurde ebenfalls als kritisch eingestuft. Da jedoch weit weniger Systeme betroffen waren, war das Ausmaß zum Glück viel geringer und die dadurch ausgelöste Panik legte sich schnell.

Was hatten beide gemeinsam, mal abgesehen davon, dass sie Java-basierte Software betrafen und ähnliche Namen trugen? Beide zielten auf die Protokollierung, d.h. die Software, mit der Systemdiagnoseinformationen in Dateien auf dem Server geschrieben werden. Dies ist eine wichtige Funktion für die Entwicklung, das Debugging und die Statistik. Aber was macht die Protokollierung potenziell gefährlich und für Angreifer und Verteidiger gleichermaßen interessant?

Zunächst einmal: Wenn ein Angreifer beeinflussen kann, was in die Protokolldateien geschrieben wird, kann er zum Beispiel die Protokollierung verhindern, um Spuren seiner Aktivitäten zu verwischen. Oder er kann falsche Protokolle schreiben, um jemand anderem die Schuld zu geben. Oder er kann die Protokolle bei einem (D)DOS-Angriff einfach mit endlosem Müll überfluten. Das kann für die Betroffenen schlimm sein, aber nicht katastrophal. Es klingt nicht so, als wäre es „die kritischste Sicherheitslücke aller Zeiten“. Nein: Das, worüber wir hier reden, ist viel schlimmer als das.

Was die Protokollierung für den Angreifer so interessant macht, ist die einfache Tatsache, dass dabei Daten in Dateien auf dem Server geschrieben werden. Das muss so sein, das ist ja gerade der Sinn der Funktion, und die meisten Teile des Systems tun dies nicht. Sie kann auf zwei Arten ausgenutzt werden: Erstens könnte der Angreifer beeinflussen, was geschrieben wird. Dies kann, wie bereits erwähnt, zur Irreführung oder Überflutung genutzt werden. Wenn die Protokolle vom Administrator in einer Weboberfläche eingesehen werden können, dann könnte injiziertes JavaScript ausgewertet werden – ein XSS-Angriff. Eingeschleuste PHP-Skripte könnten ebenfalls ausgelesen werden, wenn es dem Angreifer gelingt, den Webserver so zu manipulieren, dass er die Protokolldatei so ausgibt, als wäre sie eine PHP-Datei. Dies ist in der Regel schwieriger, aber wenn es gelingt, ermöglicht es die Ausführung von Remote-Code.

Zweitens könnte der Angreifer beeinflussen, in welche Datei die Daten geschrieben werden. An dieser Stelle wird es besonders kritisch. Er könnte damit den Inhalt des Protokolls in eine ausführbare Datei des Systems schreiben, was das System zum Absturz bringen würde (DOS-Angriff). Wenn der Angreifer jedoch sowohl die Datei als auch die geschriebenen Daten kontrollieren könnte, könnte er jeden beliebigen Programmcode schreiben und ihn vom Server ausführen lassen. Das gibt ihm mehr oder weniger vollständige Kontrolle über das anfällige System. Er könnte zum Beispiel ein Programm schreiben, das ihm Zugriff auf die Befehlszeile gibt: eine Shell. Daher auch der Name dieser Sicherheitslücken.

Es gibt noch ein paar andere Teile eines typischen Websystems, die Daten in Dateien schreiben. Dazu gehören zum Beispiel Caching, Datei-Uploads und Dateiexporte. All diese Bereiche könnten von Angriffen auf die Remote-Codeausführung in verschiedener Software betroffen sein und sind es auch. Es liegt auf der Hand, dass wir Schreibvorgänge in Dateien mit der nötigen Sorgfalt behandeln müssen. Die bewährten Sicherheitsempfehlungen zum Filtern von Eingaben und zum Maskieren von Ausgaben sind ein guter Ausgangspunkt, ebenso wie die Verwendung seriöser Abhängigkeiten und deren ständige Aktualisierung.

Log4Shell hatte keine direkten Auswirkungen auf die Ibexa DXP. Es gab keine Berichte über Exploits, die auf Produkte oder Dienste von Ibexa abzielen. Das ist nicht überraschend, da die Ibexa DXP auf PHP basiert. Sie verwendet jedoch die Java-basierten Suchlösungen Solr oder Elasticsearch, die wiederum Log4j nutzen. Aus diesem Grund haben wir den Sicherheitshinweis zu CVE-2021-44228 veröffentlicht, in dem wir Schritte zum Upgrade von Log4j, Java JDK, Solr oder Elasticsearch oder zur Umgehung des Problems beschreiben, falls ein Upgrade nicht möglich ist.

Spring4Shell hatte keinerlei Auswirkungen auf die Ibexa DXP. Spring wird in der DXP nicht verwendet, daher wurde kein Warnhinweis hierzu veröffentlicht. Einige interne Ibexa-Systeme und -Dienste waren möglicherweise betroffen, die wir umgehend gepatcht haben. Es ist kein Angriff auf unsere Dienste bekannt, und wir haben keinen Grund, einen Verstoß zu vermuten.

Bitte beachten Sie unsere Richtlinien für die sichere Meldung von Sicherheitsproblemen bei Ibexa-Produkten und verfahren Sie ebenso bei anderen Anbietern. Danke für Ihre Aufmerksamkeit, und bleiben Sie sicher!