Zum Inhalt springen
BlogSicherheitLinode Security Digest Dezember 12-19, 2021

Linode Security Digest 12. bis 19. Dezember 2021

Linode Security Digest

Hinweis: Dieser Beitrag wurde am 15. Dezember 2021 und erneut am 20. Dezember 2021 aktualisiert.

Diese Woche werden wir über die Log4j2-Schwachstelle sprechen, die viele Unternehmen dazu veranlasst hat, ihre Systeme zu patchen, aber zunächst werden wir auf einige Bedenken unserer Kunden bezüglich der Schwachstelle eingehen.

Linode's Antwort auf Log4j2 

  • Wir haben das Ausmaß des Risikos und die Auswirkungen dieser kritischen Zero-Day-Schwachstelle auf unsere gesamte Infrastruktur innerhalb der ersten Stunden nach der Veröffentlichung am Freitag, den 10. Dezember, gründlich bewertet.
  • Wir haben mit Hilfe unserer tiefgreifenden Sicherheitskontrollarchitektur gescheiterte Angriffsversuche beobachtet.
  • Wir haben in unserer Umgebung keine Indikatoren für eine Kompromittierung im Zusammenhang mit dieser Schwachstelle beobachtet und wir überwachen unsere Infrastruktur kontinuierlich auf bekannte IoCs zu dieser und anderen Schwachstellen.

Log4j2 Kritische Sicherheitslücke bei der Ausführung von Remotecode (CVE-2021-44228)

Log4j2 ist der Nachfolger des weit verbreiteten Apache Logging Utility Log4j. Diese Komponente ist in Java geschrieben und ist Teil der Apache Logging Services. Nach Angaben von Oracle ist das Java Naming and Directory Interface (JNDI) eine Anwendungsprogrammierschnittstelle (API), die in Java geschriebenen Anwendungen Namens- und Verzeichnisfunktionen zur Verfügung stellt. 

Letzte Woche hat Apache auf seiner Log4j-Sicherheitsverwundbarkeitsseite veröffentlicht, dass log4j-core Versionen zwischen 2.0-beta9 und 2.14.1 eine ernsthafte Verwundbarkeit enthalten. Diese Schwachstelle erlaubt es Angreifern, die Logmeldungen oder Logmeldungsparameter kontrollieren können, beliebigen Code auszuführen, der von LDAP-Servern geladen wird. In der Praxis ist dies durch externe Angreifer ausnutzbar. Diese Sicherheitslücke wurde mit einem CVSS-Score von 10 von 10 bewertet, da sie einem Angreifer die Ausführung von beliebigem Code auf jedem betroffenen System ermöglicht. Dieses Problem wird durch das Update 2.15 entschärft, mit dem das JNDI-Lookup-Verhalten aufgrund von zwei Jira-Problemen Anfang Dezember und Ende November deaktiviert wurde. Apache hat außerdem die Version 2.17 veröffentlicht, um weitere Probleme zu beheben, die später in der Komponente gefunden wurden.

Auswirkungen der Anfälligkeit

Log4j2 ist ein beliebtes Java-Protokollierungs-Framework , das von mehreren Anbietern in zahlreichen Produkten verwendet wird. Diese Schwachstelle kann leicht ausgenutzt werden, indem die User-Agent-Zeichenfolge der HTTP-Anfrageheader manipuliert und die Anfrage an anfällige Systeme gesendet wird. Obwohl der User-Agent nicht der einzige Header ist, der bei dieser Art von Angriff verwendet werden kann, führt eine bösartige Nutzlast dazu, dass die anfällige Log4j2-Komponente eine JNDI-Abfrage auf dem bösartigen Server auslöst. Wenn die in den HTTP-Headern eingebettete bösartige URI den Pfad zu einer bösartigen Java-Klassendatei enthält, wird diese Datei in den Prozess des Servers injiziert und ermöglicht dem Angreifer den Zugriff auf das betroffene System. Derzeit werden mehrere Payloads und Umgehungen in freier Wildbahn beobachtet, was den Schutz mit gängigen Abwehrmechanismen erschwert.

Ein Diagramm des Angriffs

Das folgende Diagramm des Computer Emergency Response Teams der Schweizer Regierung hilft zu verstehen, wie der Angriff funktioniert und wie man ihn abwehren kann.


"Log4j JNDI-Angriff" von SGCERT ist lizenziert unter CC BY-SA 4.0.

Betroffene Produkte

Viele Hersteller haben Erklärungen veröffentlicht, um die Schwachstelle zu entschärfen, und diese Erklärungen könnten eine nützliche Ressource für unsere betroffenen Kunden sein. Unter den nachstehenden Links finden Sie weitere Informationen zu den betroffenen Produkten der einzelnen Hersteller. Dies ist keine vollständige Liste aller betroffenen Produkte. Eine vollständige Liste der betroffenen Hersteller und ihrer Produkte finden Sie in der von SwitHak kuratierten Liste auf Github oder in einer anderen von TechSolvency bereitgestellten Liste.

Offizielle Methoden der Schadensbegrenzung

Auf der Sicherheitsseite von Log4j gibt Apache an, dass es mehrere Methoden zur Behebung dieser Schwachstelle gibt. Es ist jedoch zu beachten, dass diese Methoden möglicherweise nicht bei allen anfälligen Produkten gleich funktionieren. Weitere Informationen finden Sie in der Sicherheitserklärung des Herstellers zu dieser Sicherheitslücke.

  • Benutzer von Java 8 (oder höher) sollten auf Version 2.17.0 aktualisieren, um diese und andere kürzlich gefundene Sicherheitslücken zu schließen.
  • Benutzer, die Java 7 benötigen, sollten auf die Version 2.12.2 aktualisieren.
  • Wenn diese beiden Schritte nicht möglich sind, besteht die Abhilfe darin, die Klasse JndiLookup aus dem Klassenpfad zu entfernen (angezeigt als log4j-core-*.jar), indem Sie einen Befehl ähnlich dem folgenden verwenden:
zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class

Wir sind stolz darauf, unser Wissen mit unserer Community zu teilen, um sie dabei zu unterstützen, Schwachstellen zu entschärfen, egal ob sie so kritisch sind wie diese oder weniger schwerwiegend. Hinterlassen Sie unten einen Kommentar, um Ihre Gedanken und Vorschläge mitzuteilen.


Kommentare

Kommentar abgeben

Ihre E-Mail Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit *gekennzeichnet