Inhaltsverzeichnis[Ausblenden][Zeigen]
Log4Shell, eine Internet-Schwachstelle, betraf kürzlich Millionen von Computern. Log4j, eine obskure, aber fast allgegenwärtige Software, verursacht es.
Log4j wird verwendet, um alle Aktionen zu protokollieren, die hinter den Kulissen in einer Vielzahl von Computersystemen stattfinden.
Es basiert auf einer Open-Source-Logging-Bibliothek, die von Unternehmen und sogar Regierungsorganisationen in den meisten Anwendungen verwendet wird.
Da es sich um eine der schlimmsten Cyber-Sicherheitslücken handelt, die jemals aufgedeckt wurden, ist es wichtig, Ihre Systeme vor dieser Schwachstelle zu schützen. Aber wie?
Lassen Sie uns die Log4j-Schwachstelle im Detail und alle möglichen Lösungen dafür untersuchen.
Was ist Log4j?
Log4j ist ein Open-Source Protokollierungsframework, das es Softwareentwicklern ermöglicht, verschiedene Daten innerhalb ihrer Anwendungen aufzuzeichnen. Es ist eine Komponente des Apache Logging Services-Projekts, das von der betrieben wird Apache Software Foundation.
Hunderte von Websites und Apps verwenden Log4j, um kritische Vorgänge wie das Protokollieren von Daten zum Debuggen und für andere Zwecke durchzuführen.
Wenn Sie einen schlechten Online-Link eingeben oder darauf klicken und eine 404-Fehlermeldung erhalten, ist dies ein häufiges Beispiel für die Arbeit von Log4j. Der Webserver, der die Domäne des Weblinks ausführt, auf den Sie zuzugreifen versuchten, informiert Sie, dass keine solche Webseite existiert. Es protokolliert das Ereignis auch in Log4j für die Systemadministratoren des Servers.
In allen Softwareprogrammen werden ähnliche Diagnosesignale verwendet. Beim Online-Spiel Minecraft beispielsweise verwendet der Server Log4j, um Aktivitäten wie den gesamten verwendeten Arbeitsspeicher und an die Konsole gesendete Benutzeranweisungen zu protokollieren.
Wie tritt die Schwachstelle auf?
Lookups sind eine neue Funktion, die in Log4j 2.0 eingeführt wurde und hilft, zusätzliche Informationen in Protokolleinträge aufzunehmen. Eine dieser Suchen ist die JNDI-Suche (Java Naming and Directory Interface), die eine Java-API für die Kommunikation mit einem Verzeichnisdienst ist.
Mit diesem Ansatz können interne Benutzer-IDs tatsächlichen Benutzernamen zugeordnet werden. Diese Abfrage deckt die neu entdeckte RCE-Schwachstelle auf, da einer der vom LDAP-Server bereitgestellten Datentypen ein URI ist, der auf eine Java-Klasse verweist, die dann in den Speicher geladen und von der Log4j-Instanz ausgeführt wird.
Aufgrund einer Schwachstelle in der Eingabevalidierung der Log4j-Bibliothek ist es möglich, einen beliebigen LDAP-Server aus einer nicht vertrauenswürdigen Quelle einzuschleusen. Da Entwickler davon ausgehen, dass an Protokolle gesendete Daten als Klartext behandelt werden, wird keine zusätzliche Eingabevalidierung durchgeführt, und gefährliche Benutzereingaben gelangen in die Protokolle.
Eine Log-Anweisung könnte so aussehen:
Ein böswilliger Benutzer würde nun eine JNDI-Suche in einen URL-Parameter einfügen, die auf einen Rogue-LDAP-Server verweist. Die JNDI-Suche würde wie folgt aussehen:
Die Log4j-Bibliothek kommuniziert dann mit diesem LDAP-Server auf attacker.com, um Verzeichnisinformationen abzurufen, darunter Werte für die Java Factory und die Java Codebase.
Diese beiden Werte beinhalten die Java-Klasse des Angreifers, die dann in den Speicher geladen und von der Log4j-Instanz ausgeführt wird, wodurch die Codeausführung abgeschlossen wird.
Wer ist gefährdet?
Die Log4j-Schwachstelle ist unglaublich umfassend und betrifft Geschäftsanwendungen, eingebettete Geräte und deren Subsysteme. Zu den betroffenen Apps gehören Cisco Webex, Minecraft und FileZilla FTP.
Dies ist jedoch keineswegs eine vollständige Liste. Der Fehler betrifft sogar die Chopper-Mission Ingenuity Mars 2020, die Apache Log4j für die Ereignisaufzeichnung verwendet.
Die Sicherheitsgemeinschaft hat eine zusammengestellt Liste anfälliger Systeme. Es ist wichtig zu beachten, dass diese Listen ständig aktualisiert werden. Wenn also ein bestimmtes Programm oder System nicht enthalten ist, gehen Sie nicht davon aus, dass es nicht betroffen ist.
Die Exposition gegenüber dieser Sicherheitsanfälligkeit ist sehr wahrscheinlich, und selbst wenn es sich um eine spezifische handelt Tech Stack Java nicht anwendet, sollten Sicherheitsverantwortliche damit rechnen, dass kritische Lieferantensysteme, SaaS-Anbieter, Cloud-Hosting-Anbieter und Webserver-Anbieter dies tun.
Wie kann ich nach einer Log4j-Schwachstelle suchen?
Im ersten Schritt wird festgestellt, ob bereits ein Angriff stattgefunden hat. Überprüfen Sie dazu die Systemprotokolle auf RCE-Nutzlastfragmente.
Wenn eine Suche nach Begriffen wie „jndi“, „ldap“ oder „$::“ Protokolle ergibt, sollten Sicherheitsforscher weiter untersuchen, ob es sich um einen legitimen Angriff oder lediglich um Fingerabdrücke handelt.
Viele Angriffe in freier Wildbahn wurden entdeckt, die keine schädlichen Nutzlasten lieferten. Dennoch wurden sie von Sicherheitsexperten durchgeführt, um festzustellen, wie viele Apps für diesen Angriff anfällig sind.
Der nächste Schritt besteht darin, die Log4j-Bibliothek zu verwenden, um alle Projekte zu identifizieren. Wenn Versionen zwischen 2.0-beta9 und 2.14.1 verwendet werden, kann das Projekt anfällig sein.
Angesichts der Schwierigkeit, festzustellen, wo diese Schwachstelle existiert, kann es vorzuziehen sein, davon auszugehen, dass das Projekt anfällig ist und dass das Aktualisieren der Bibliothek die beste Vorgehensweise ist, um die Gefahr der Codeausführung zu beseitigen.
Das Projekt ist nicht anfällig, wenn die verwendete Version kleiner als 2.0-beta 9 ist, obwohl die Log4j-Bibliothek trotzdem aktualisiert werden sollte, da Versionen im Bereich 1.x alt sind und keine Updates mehr erhalten.
Wenn ein anfälliges Projekt entdeckt wird, wird empfohlen, es zu überprüfen, um festzustellen, ob Informationen, die mit Log4j protokolliert werden, Informationen enthalten, die der Benutzer ändern kann. URLs, Anforderungsparameter, Header und Cookies sind Beispiele für diese Daten. Wenn einer davon protokolliert wird, ist das Projekt in Gefahr.
Dieses Wissen kann Ihnen helfen, tiefer in die Systemprotokolle einzutauchen und festzustellen, ob Ihre Webanwendung bereits angegriffen wurde.
Es gibt kostenlose Online-Tools, die erkennen können, ob eine Webanwendung anfällig ist. Eines dieser Programme ist Log4Shell-Jägerin. Es ist Open Source und verfügbar unter GitHub.
Wenn ein anfälliger Codebereich in der Online-Anwendung entdeckt wird, kann die vom offengelegten Tool bereitgestellte Nutzlast verwendet werden, um sie in die Webanwendung einzufügen. Das Testtool würde die Verbindungen aufdecken, die zwischen Ihrer Webanwendung und ihrem LDAP-Server hergestellt wurden, wenn die Schwachstelle ausgenutzt wurde.
Lösungen zur Behebung der Log4j-Schwachstelle
Der erste Schritt besteht darin, Log4j zu aktualisieren, was Sie tun können, indem Sie die normalen Paketmanager verwenden oder es direkt von diesem herunterladen Seite.
Es ist auch möglich, die Ausnutzbarkeit der Schwachstelle zu verringern, indem die Umgebungsvariable FORMAT MSG NO LOOKUPS auf true gesetzt wird. Diese Gegenmaßnahme gilt jedoch nur für Log4j-Versionen größer oder gleich 2.10.
Betrachten wir nun alternative Optionen.
1. Problemumgehungen für Log4j Version 2.17.0
Es wird auf jeden Fall dringend empfohlen, Log4j Version 2.15.0 zum Schutz vor Log4Shell zu verwenden, falls dies jedoch nicht möglich ist, stehen andere Lösungen zur Verfügung.
Versionen 2.7.0 und höher von Log4j: Es ist möglich, sich gegen jeden Angriff zu schützen, indem das Format der zu protokollierenden Ereignisse geändert wird, indem die Syntax "% m nolookups" für die vom Benutzer bereitgestellten Daten verwendet wird. Dieses Update erfordert die Bearbeitung der Log4j-Konfigurationsdatei, um eine neue Version des Programms zu generieren. Daher müssen vor der Bereitstellung dieser neuen Version die Phasen der technischen und funktionalen Validierung wiederholt werden.
Log4j-Versionen 2.10.0 und höher: Es ist auch möglich, sich vor jeglichen Angriffen zu schützen, indem der Konfigurationsparameter log4j2.formatMsgNoLookups auf true gesetzt wird, beispielsweise wenn die Java Virtual Machine mit der Option -Dlog4j2 gestartet wird.“ formatMsgNoLookups = true, Eine weitere Möglichkeit besteht darin, die JndiLookup-Klasse aus dem Klassenpfadargument zu entfernen, wodurch der Hauptangriffsvektor entfernt wird (die Forscher schließen die Möglichkeit eines anderen Angriffsvektors nicht aus).
Amazon Web Services bietet einen Hotpatch, der „auf eigenes Risiko verwendet werden sollte“. Andere „Techniken“ wie Logout4Shell, die „diese Schwachstelle gegen sich selbst ausnutzen“, wurden veröffentlicht. Der Sicherheitsexperte stellt die Rechtmäßigkeit dieses Schritts in Frage, bei dem es darum geht, „eine Maschine zu hacken, um sie zu reparieren“.
2. Das Problem wurde in Log4j v2.17.0 behoben.
Für Versionen größer als 2.10: Log4j2.formatMsgNoLookups sollte auf „true“ gesetzt werden.
Für die Versionen 2.0 bis 2.10.0: Führen Sie den folgenden Befehl aus, um die LDAP-Klasse aus Log4j zu entfernen.
Log4j2.formatMsgNoLookups sollte in den Systemeinstellungen auf true gesetzt werden.
Minderung in JVM
Mitigation mit JVM-Parametern ist keine Option mehr. Andere Minderungsmethoden sind weiterhin erfolgreich. Aktualisieren Sie nach Möglichkeit auf Log4j Version 2.17.0. Für Log4j v1 ist ein Migrationsleitfaden verfügbar.
Wenn eine Aktualisierung nicht möglich ist, stellen Sie sicher, dass für die clientseitigen und serverseitigen Komponenten die Systemeigenschaft -Dlog4j2.formatMsgNoLookups = true festgelegt ist.
Bitte beachten Sie, dass Log4j v1 sein Lebensende (EOL) erreicht hat und keine Fehlerbehebungen mehr erhält. Andere RCE-Vektoren sind ebenfalls anfällig für Log4j v1. Daher empfehlen wir dringend, so schnell wie möglich auf Log4j 2.17.0 zu aktualisieren.
3. Minderungsmaßnahmen
Aktuelle Exploits können nicht funktionieren, selbst wenn Log4j in einigen Fällen anfällig ist, z. B. wenn auf dem Hostcomputer eine Java-Version höher als 6u212, 7u202, 8u192 oder 11.0.2 ausgeführt wird.
Dies ist auf den besseren Klassenladeschutz von Java Naming and Directory Interface (JNDI) in aktuellen Versionen zurückzuführen, der für das Funktionieren des Angriffs erforderlich ist.
Darüber hinaus kann das Problem bei Log4j-Versionen größer als 2.10 vermieden werden, indem der Systemwert formatMsgNoLookups auf true gesetzt wird, das JVM-Argument -Dlog4j2.formatMsgNoLookups = true bereitgestellt wird oder die JndiLookup-Klasse aus dem Klassenpfad gelöscht wird.
In der Zwischenzeit, bis die anfälligen Instanzen behoben sind, kann die Schwachstelle mit den folgenden Techniken behoben werden:
- Setzen Sie die Systemeigenschaft log4j2.formatMsgNoLookups für >=2.10 auf true.
- Setzen Sie die Umgebungsoption LOG4J FORMAT MSG NO LOOKUPS für >=2.10 auf true.
- Entfernen Sie JndiLookup.class aus dem Klassenpfad für 2.0-beta9 bis 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Eine empfohlene Best Practice besteht darin, den ausgehenden Datenverkehr zum Internet nur auf die entsprechenden Ports zu beschränken.
Obwohl die meisten Angriffe in diesem Bereich über HTTP erfolgen, kann die Schwachstelle über jedes Protokoll ausgenutzt werden, das Benutzereingabedaten mit Log4j protokolliert.
Das Update auf log4j 2.17.0 ist jedoch die beste Abhilfe, da jemand einen zusätzlichen Ansatz für das Problem entdecken kann. Darüber hinaus haben viele Verlage und Hersteller Verbesserungen ihrer Dienste oder Apps angekündigt.
4. Log4Shell-Sicherheitspatch
Log4j ist allgegenwärtig, besonders jetzt, wo die Schwachstelle ausgenutzt wird. Zusammenfassend müssen Sie lediglich die folgenden Zeichen in die von Log4j überprüften Protokolle aufnehmen.
Dadurch wird die Java-Datei am Ende der URL heruntergeladen und ausgeführt. Es ist so einfach wie dramatisch.
Wie Sie wissen, ist es wichtig, log4j auf Version >= 2.17.0 zu aktualisieren, um diese Log4Shell-Schwachstelle (CVE-2021-44228) zu schließen.
Falls dies nicht möglich ist:
Für Anwendungen, die die Log4j-Bibliotheksversionen 2.10.0 und höher verwenden, ist es auch möglich, sich gegen jeden Angriff zu schützen, indem Sie den Konfigurationsparameter log4j2.formatMsgNoLookups auf true setzen, während Sie beispielsweise die Java Virtual Machine mit -Dlog4j2.formatMsgNoLookups = true starten Möglichkeit.
Eine andere Möglichkeit besteht darin, die JndiLookup-Klasse aus dem Klassenpfad-Argument zu löschen, wodurch der primäre Angriffsvektor entfernt wird (die Forscher schließen die Existenz eines anderen Angriffsvektors nicht aus).
Note
Organisationen, die zögern oder nicht bereit sind, Anpassungen an anfälligen Systemen vorzunehmen (oder die zusätzliche Sicherheitsvorkehrungen installieren möchten), sollten Folgendes in Betracht ziehen:
- Stellen Sie sicher, dass der gesamte Datenverkehr über einen iSensor/WAF/IPS. Dies kann verhindern, dass der Angriff Zugriff auf das System erhält.
- Begrenzung des Datenverkehrs, der das anfällige System erreichen kann Wenn das System nicht mit dem Internet verbunden sein muss, beschränken Sie den Zugriff auf nur wesentliche und vertrauenswürdige IPS und Bereiche.
- Reduzieren des autorisierten ausgehenden Datenverkehrs des Hosts. Da dieser Angriff über eine Verbindung zu einem Rogue-Server erfolgt, sollten alle überflüssigen IP-Adressen und Ports auf einer Firewall blockiert werden.
- Wenn der Dienst nicht mehr benötigt wird, sollte er deaktiviert werden, bis ein Fix bereitsteht.
Zusammenfassung
Die Log4j-Fehler haben unsere Community schockiert und uns alle daran erinnert, wie abhängig wir von Open-Source-Software sind.
Log4j ist einzigartig. Es ist weder ein Betriebssystem, noch ein Browser, noch eine Software. Es ist vielmehr das, was Programmierer als Bibliothek, Paket oder Codemodul bezeichnen. Es dient nur einem Zweck, nämlich aufzuzeichnen, was auf einem Server passiert.
Menschen, die Code schreiben, konzentrieren sich lieber auf das, was ihre Software auszeichnet. Sie sind nicht daran interessiert, das Rad neu zu erfinden. Infolgedessen verlassen sie sich auf eine Vielzahl bestehender Codebibliotheken wie Log4j.
Das Log4j-Modul ist von Apache abgeleitet, der am weitesten verbreiteten Webserver-Software. Deshalb kann es auf Millionen von Servern entdeckt werden. Daher die Erhöhung der Sicherheitsbedrohungen.
Ich hoffe, die oben genannten Lösungen helfen Ihnen, Ihre Geräte zu schützen.
Bleiben Sie bei HashDork auf dem Laufenden, um weitere hilfreiche Informationen aus der Tech-Welt zu erhalten.
Hinterlassen Sie uns einen Kommentar