Diese Woche sprechen wir über die Entwicklung von Log4j2-Schwachstellen und einige nützliche Maßnahmen, mit denen Sie sich davor schützen können.
Die Entwicklung der Anfälligkeit
Die "Log4Shell"-Schwachstellen begannen mit der Entdeckung einer kritischen Schwachstelle bei der Remotecodeausführung in der Art und Weise, wie Log4j2 Lookups bei der Protokollierung von Ereignissen auf den betroffenen Systemen handhabt. Diese kritische Sicherheitslücke(CVE-2021-44228) wurde im CVSS mit 10 von 10 Punkten bewertet. Apache gab an, dass die Wahrscheinlichkeit, dass Log4j-Versionen 1.x für diese Schwachstelle anfällig sind, geringer ist, da JNDI absichtlich aktiviert werden muss. Apache veröffentlichte 2.15.0, um diese Schwachstelle zu beheben.
Nachdem Apache Entschärfungsmethoden für Benutzer veröffentlicht hatte, die Log4j2 nicht auf Version 2.15.0 aktualisieren konnten, wurde dank der Aufmerksamkeit, die dieses Open-Source-Projekt in der Öffentlichkeit erhielt, eine weitere Sicherheitslücke entdeckt. Diese Schwachstelle(CVE-2021-45046) war ursprünglich eine DOS-Schwachstelle, die mit 3,7 von 10 Punkten bewertet wurde. Später wurde sie jedoch auch als kritische Schwachstelle bei der Codeausführung eingestuft und die Bewertung auf 9 von 10 Punkten bei CVSS angehoben. Apache erklärte, dass die 1.x-Versionen nicht verwundbar seien und empfahl den Benutzern von Log4j2, auf Version 2.16.0 zu aktualisieren, um dieses zweite Problem zu beheben. Für Benutzer, die nicht aktualisieren konnten, wurde die Methode zur Entfernung der JNDI-Lookup-Klasse empfohlen.
Dann kam die dritte Sicherheitslücke. Obwohl (Stand 22. Dezember) auf der Sicherheitsseite von Log4j2 Version 2.16.0 kein Hinweis auf Remotecode-Ausführung zu finden ist, wurde diese Schwachstelle(CVE-2021-45105) von CVSS mit 7,5 von 10 Punkten bewertet und kann nur auf anfälligen Systemen einen Denial-of-Service-Angriff auslösen. Apache veröffentlichte Version 2.17.0 und empfahl seinen Benutzern ein Upgrade, um das Problem zu beheben. Außerdem wurden neue Abhilfemaßnahmen für Benutzer bekannt gegeben, die nicht aktualisieren können.
Es ist wichtig zu wissen, dass diese Schwachstellen während der Entdeckungs- und Eindämmungsphase ausgenutzt wurden oder versucht wurde, sie auszunutzen. Laut dem 360 Netlab Blog haben mehrere Malware-Familien versucht, sich über diese Sicherheitslücken zu verbreiten. Böswillige Akteure, die die Schwachstelle erfolgreich ausgenutzt haben, wurden dabei beobachtet, wie sie Münzschürfer implantierten und Ransomware installierten. Diese Berichte unterstreichen, wie wichtig es ist, diese Schwachstellen so schnell wie möglich zu beseitigen.
Offizielle Methoden der Schadensbegrenzung
Laut der Sicherheitsseite von Log4j2 entschärft ein Upgrade der Komponente auf 2.17 die drei bekannten Sicherheitsprobleme. Denjenigen, die ihr Log4j2 nicht aktualisieren können, empfiehlt Apache , die JNDI-Lookup-Klasse aus ihrer anfälligen log4j2-core-*.jar-Datei zu entfernen. Dies reicht jedoch nicht aus, um die kürzlich entdeckte Denial-of-Service-Schwachstelle(CVE-2021-45105) zu entschärfen. Sie können diese DOS-Schwachstelle entschärfen, indem Sie das PatternLayout in der Logging-Konfiguration ändern. Lesen Sie die am Anfang dieses Abschnitts verlinkte Log4j2-Sicherheitsseite Apache, um mehr über die Details dieser Entschärfungsmethoden zu erfahren.
Gefährdete Komponenten finden
Wenn Sie nach verwundbaren Komponenten suchen, können Sie die Log4j-Tools von jfrog verwenden. Die Tools in diesem Repository sind nützlich bei der Suche nach verwundbaren Log4j JNDI Lookup-Aufrufen in einer Codebasis, bei der Sie nicht sicher sind, ob ein Teil des Codes Log4j aufruft, um zu funktionieren. Es kann Ihnen auch helfen, den Verwundbarkeitsstatus von lokalen Dateien zu bestimmen. Sie können auch die Log4j Usage and Exploitation Rules von Cisco CX Security Labs ausprobieren, um Ihre lokalen Dateien mit YARA-Regeln zu scannen, um festzustellen, ob eine Datei die verwundbaren Java-Klassen enthält; obwohl diese Methode schnellere Ergebnisse liefern kann, kann sie zu mehr falsch-positiven Ergebnissen führen; allerdings können diese Regeln Ihnen auch helfen, von Log4j abhängige Komponenten zu finden.
Das Log4Shell Hashes Repository von mubix enthält MD5-, SHA1- und SHA256-Hashes der log4j2-core-Dateien, die für die erste kritische RCE-Schwachstelle(CVE-2021-44228) anfällig sind. Schließlich finden Sie in der CISA-Datenbank für anfällige Software (gilt nur für CVE-2021-44228) eine umfassende Liste anfälliger Software nach Hersteller.
Schutz vor Angriffen
Wenn Sie Ihre Log4j2-Installation nicht aktualisieren können und Fail2Ban auf Ihrem Server verwenden, kann die Fail2Ban-Regex gegen Log4Shell von Jay Gooby Ihnen beim Blockieren von Log4Shell-Versuchen helfen. Wenn Sie CloudFlare verwenden, können Sie deren WAF-Regeln zum Schutz vor diesen Angriffen einsetzen. Gemäß dem Rat der CISA wird jedoch empfohlen, auf Log4j 2.17.0 zu aktualisieren oder die empfohlenen Abhilfemaßnahmen sofort anzuwenden. Es ist auch wichtig, die Herstellerangaben zu anderer Software, die Log4j2 verwendet, zu beachten, da manche Software mit einer anfälligen Version von Log4j gebündelt werden kann, die möglicherweise beachtet werden muss.
Finden von IOCs & Scannen
Wenn Sie in Ihren Protokollen nach Indikatoren für eine Kompromittierung suchen, kann es schwierig sein, festzustellen, ob es Versuche gab, diese Sicherheitslücke auszunutzen, vor allem weil es viele verschiedene Nutzdaten gibt, die gesendet werden können, um den bekannten JNDI-Angriffsvektor auszunutzen. Ein Angreifer kann die Zeichenketten in der Nutzlast verschlüsseln, sie verschleiern oder es schwer machen, sie bei der Suche nach einfachen Nutzlasten zu erkennen. An dieser Stelle kann Log4Shell-Rex von back2root nützlich sein. Log4Shell-Rex ist ein regulärer Ausdruck, der erstellt wurde, um mögliche bösartige Nutzdaten, die mit verschiedenen Methoden verschlüsselt wurden, zu finden. Sie können ihn in Ihren lokalen Protokolldateien oder in Ihrem SIEM verwenden, um die Ergebnisse abzugleichen. Es sollte jedoch beachtet werden, dass die Suche mit diesem Regex (mit jedem Regex) zu falsch positiven oder falsch negativen Ergebnissen führen kann.
Sie können auch das Log4j-Scan-Tool von FullHunt ausprobieren, das bei der Erkennung und dem Fuzzing der RCE-Schwachstelle(CVE-2021-44228) helfen kann. Sie können dieses Tool auch verwenden, um auf WAF-Umgehungen zu testen, um umfassendere Scanergebnisse zu erhalten.
Wir hoffen, dass wir unseren Kunden mit diesen Sicherheitsberichten nützliche Informationen liefern können. Wie immer können Sie uns gerne Ihre Meinung mitteilen, indem Sie unten einen Kommentar hinterlassen.
Kommentare