Wie Sie Ihre Organisation am besten vor Log4j, einem Java-basierten Exploit, schützen können

Die Weihnachtszeit steht vor der Tür und die Organisationen beginnen, sich auf die Feierlichkeiten zum Jahresende vorzubereiten. Administratoren auf der ganzen Welt erwartet in diesen Tagen viel Arbeit, während Bösewichte, die auf die Ausnutzung von Systemen aus sind, mit der Log4j-Schwachstelle ein vorzeitiges Geschenk erhalten haben. Eines, das eine weit verbreitete Komponente vieler Softwareanwendungen und -dienste betrifft. Es handelt sich dabei nicht um ein einzelnes Unternehmen, sondern es können Hunderte oder Tausende von Produkten betroffen sein. Von Netzwerkausrüstungen über Serververwaltungssoftware bis hin zu Verbraucher- und Unternehmensanwendungen (um nur einige zu nennen) müssen sich die Anbieter bemühen, anfällige Software zu aktualisieren, um die aufgedeckten Schwachstellen mit entsprechenden Patches zu schließen.

In diesem Blog möchte Jamf Benutzern, die mit dieser (und allen weiteren) kritischen Schwachstellen nicht vertraut sind, Einblicke gewähren, und denjenigen, die bereits mit dem Problem vertraut sind, Anleitungen auf der Grundlage bewährter Sicherheitspraktiken bieten, um diese Schwachstellen zu entschärfen.

• Was ist Log4j, und warum ist es ein solches Problem?
• Welche Produkte von Jamf sind von der Sicherheitslücke betroffen, und welche Maßnahmen ergreift Jamf, um sie zu beheben?
• Wie können Jamf Produkte Ihrer Organisation helfen, diese Bedrohungen abzuschwächen?

Canto I: Was ist Log4j?

Ausgesprochen „Log Forge“, ist die kritische Schwachstelle ein Fehler in der beliebten Log4j, Java-basierte Logging-Bibliothek, dass es anfällig für eine Remote Code Execution (RCE) Exploit ist. Die Schwachstelle, der zunächst die CVE-ID CVE-2021-44228 zugewiesen wurde, bezieht sich auf einen Fehler in der Apache-Software, Log4J, einer Bibliothek, die von verschiedenen Anwendungen zur Protokollierung von Informationen während der Ausführung von Java-Anwendungen verwendet wird. Sie ist eine der, wenn nicht sogar die am häufigsten verwendete Bibliothek, die Entwickler sowohl für Open-Source- als auch für kommerzielle Software verwenden.

Canto II: Warum ist das so eine große Sache?

Aufgrund der weit verbreiteten Nutzung und Implementierung auf verschiedenen Geräten und bei verschiedenen Anbietern lassen sich die tatsächlichen Auswirkungen dieser ernsthaften Bedrohung nicht beziffern. Es ist bekannt, dass Schwachstellen vom Typ RCE als kritisch eingestuft werden. Die Ausnutzung der Schwachstelle ermöglicht es Bedrohungsakteuren, Code auf den betroffenen Systemen aus der Ferne auszuführen, ohne unbedingt dazu autorisiert zu sein. Diese Arten von Angriffen ermöglichen es Angreifern, Geräte und möglicherweise auch die darin enthaltenen Daten zu nutzen. Die ursprüngliche Schwachstelle erlaubte es einem Angreifer, die log4j-Bibliothek aufzufordern, beliebigen Code von einem vom Angreifer kontrollierten Server herunterzuladen und ihn so auszuführen, als ob er Teil der Anwendung selbst wäre. Ein Angreifer könnte jede Anwendung, die log4j verwendet, übernehmen, auch wenn er sich nie bei dem Service, den die Bibliothek verwendet, authentifizieren musste.

Darüber hinaus handelt es sich bei dem Wort „Schwachstellen“ nicht um einen Tippfehler. Vielmehr bezieht sich die Mehrzahl auf eine zweite Sicherheitslücke (CVE-2021-45046 ), die entdeckt wurde, weil die Behebung der ursprünglich entdeckten Sicherheitslücke aufgrund bestimmter nicht standardmäßiger Einstellungen unvollständig war. Positiv zu vermerken ist, dass es sich bei der zusätzlichen Schwachstelle offenbar eher um einen Denial-of-Service-Angriff (DoS) als um einen Angriff zur Übernahme des Services handelt.

Sie fragen sich jetzt bestimmt, was bedeutet das für die Lösung von Log4j? Nun, es ist zwar immer noch schlimm, aber es wird besser. In solchen Fällen ist es nicht ungewöhnlich, dass mehrere Aktualisierungsstufen erforderlich sind, um die Bedrohung vollständig zu beseitigen. Diese zweite identifizierte Schwachstelle erlaubt zwar keine RCE-Exploits mehr, ermöglicht es Angreifern aber immer noch, Eingabedaten böswillig zu manipulieren, was zu einem DoS-Angriff führt.

Canto III: Wie wirkt sich das auf Jamf aus?

Wie viele andere Anbieter, darunter Apple, Google und Microsoft, waren leider auch einige Jamf Produkte von der Log4j-Schwachstelle betroffen. Aufgrund der Art der Schwachstellen CVE-2021-44228 und CVE-2021-45046, ihres kritischen Schweregrads und ihrer potenziellen Auswirkungen auf die Services, hat Jamf schnell Maßnahmen ergriffen. Aaron Kiemele, CISO von Jamf, hat einen speziellen Jamf Nation-Beitrag erstellt, der Jamf-Benutzer mit den neuesten Informationen darüber versorgt, wie sich Log4j auf Jamf Services auswirkt. Darüber hinaus gibt er Auskunft über die Strategien, die Jamf derzeit einsetzt, um diese Bedrohung für seine Services zu entschärfen.

• Jamf Pro (vor Ort): Release mit Patch verfügbar
• Jamf Pro (cloudbasiert): Entschärft und gepatcht
• Jamf Connect: Nicht betroffen
• Jamf Now: Nicht betroffen
• Jamf Protect: Nicht betroffen
• Jamf School: Nicht betroffen
• Jamf Threat Defense: Nicht betroffen
• Jamf Data Policy: Nicht betroffen
• Jamf Private Access: Nicht betroffen
• Health Care Listener: Nicht anfällig
• Jamf Infrastructure Manager: Nicht anfällig

Laut Matthias Wollnik, Product Marketing Manager bei Jamf mit dem Schwerpunkt Sicherheit, „protokolliert der Jamf Infrastructure Manager (JIM) nur interne Betriebsdaten und keine nicht vertrauenswürdigen oder vom Kunden gelieferten Informationen. Infolgedessen hat ein Angreifer keine Möglichkeit, eine Nachricht an Log4j zu übermitteln, die es ihm ermöglichen würde, die jüngsten Schwachstellen auszunutzen.

… und welche Abhilfemaßnahmen hat Jamf ergriffen?

Für Jamf Pro-Instanzen, die vor Ort sind oder von Ihrer Organisation selbst gehostet werden, ist das Problem ab Version 10.34.2, die log4j 2.16 enthält, vollständig behoben. Eine frühere Version (10.34.1) wurde mit log4j 2.15 veröffentlicht. Die neuesten Informationen weisen darauf hin, dass log4j 2.15 eine zusätzliche Konfiguration erfordert, um gegen CVE-2021-45046 sicher zu sein. Jamf rät Administratoren von Systemen vor Ort, so bald wie möglich auf die Version 10.34.2 zu aktualisieren.

Wenn Organisationen zu diesem Zeitpunkt nicht auf die neueste Version aktualisieren können, besteht alternativ die Möglichkeit, einen Workaround zu implementieren: Manuelle Aktualisierung der Log4j-Instanz auf den betroffenen Systemen und Einstellung der entsprechenden Konfiguration, wie in den technischen Unterlagen von Jamf beschrieben. Der Workaround hat keine negativen Auswirkungen auf zukünftige Aktualisierungen.

Die in der Cloud gehosteten Jamf Pro-Instanzen sind durch entsprechende Sicherheitskontrollen geschützt und derzeit nicht anfällig. Aus Gründen der Vorsicht wird Jamf Pro 10.34.2 jedoch auch an diese Kunden ausgerollt.

Canto IV: Was können wir tun, um uns zu schützen?

Patching

Die Schwachstelle Log4j hat weltweit so weitreichende Auswirkungen, dass in den USA die Cybersecurity & Infrastructure Security Agency (CISA) eine Website und ein GitHub Repository eingerichtet hat, um die weit verbreitete Ausnutzung der Apache Log4j-Bibliothek zu verfolgen und darauf zu reagieren. Die CISA hat ein Dokument erstellt, das den Administratoren und Sicherheitsteams aktuelle Informationen zum Schutz der betroffenen Systeme bietet, mit fortlaufenden Quellen für Erkennungsregeln, die bei der Erkennung von Schwachstellen helfen, Log4Shell-Hashes, Leitfäden zur Schadensbegrenzung für verschiedene Softwareentwickler und -anbieter sowie zusätzliche Ressourcen für globale Behörden, beispielsweise in Nordamerika, Europa und Asien.

„Patche schnell und patche oft“ – Jamf

Abgesehen von der Behebung der notwendigen Log4j-Schwachstelle mit dem/den Patch(s), den/die Sie von der Website Ihres Softwareentwicklers erhalten haben, oder zumindest einer Umgehungslösung, die eine Möglichkeit bietet, die anfälligen Log4j-Bibliotheken zu aktualisieren, die möglicherweise in Komponenten eingebettet sind, aus denen die betroffene Anwendung oder der Service besteht, der darauf angewiesen ist.

Durch den Einsatz von Jamf Pro können IT-Administratoren nicht nur in kürzester Zeit feststellen, auf welchen Systemen ältere Versionen betroffener Anwendungen vorhanden sind, sondern auch Smart Groups erstellen, um diese dynamisch zu erfassen und die Softwarebereitstellungsfunktion zu nutzen, um betroffene Anwendungen direkt zu aktualisieren und/oder Patches bei Bedarf aus der Ferne bereitzustellen.

Darüber hinaus gibt es einige grundlegende Sicherheitsverfahren, die Administratoren befolgen können (und sollten), um die Gefährdung der Organisation durch Sicherheitsbedrohungen zu begrenzen oder potenzielle Risiken, die von Log4j-Schwachstellen herrühren, zu mindern.

Risikobewertung

Wie können Sie wissen, was gefährdet ist, wenn Sie nicht wissen, was Sie haben? Das ist der erste Schritt: Ermitteln Sie, welche Geräte, Anwendungen und Services die Infrastruktur Ihrer Organisation ausmachen. Mit einem aktualisierten Bestand wissen Sie genau, welche Ressourcen Ihre Organisation besitzt, wie sie genutzt werden und wofür genau sie eingesetzt werden. Mit diesem Wissen können Administratoren leicht feststellen, welche Bereiche gefährdet sind, und das Ausmaß der Gefährdung bestimmen, bevor sie Abhilfestrategien bereitstellen.

Software-Stückliste

Diese als SBOM abgekürzten Softwarekomponentenverzeichnisse bieten Organisationen und Entwicklern gleichermaßen genaue und leicht verständliche Beschreibungen der grundlegenden Bausteine der Komponenten, die in Softwareanwendungen und -diensten enthalten sind. Der Vorteil aus Unternehmenssicht besteht darin, dass Sicherheitsteams auf einfache Weise feststellen können, welche Komponenten in den verwendeten Anwendungen von Erst- und Drittanbietern für bestimmte Schwachstellen anfällig sein könnten.

Tiefgreifende Abwehr

Diese bewährte Sicherheitspraxis hat sich bewährt, um Ressourcen zu schützen, indem mehrere Sicherheitsmaßnahmen gestaffelt angewendet werden, wobei eine Lösung auf die nächste aufbaut. So wird die Sicherheit von Systemen, Anwendungen und Services insgesamt erhöht. Während tiefgreifende Abwehrstrategien die zugrundeliegende Schwachstelle nicht beheben, können sie einen Schutz gegen die Auswirkungen der Schwachstelle bieten, indem sie die Angriffsfläche einer betroffenen Anwendung begrenzen und/oder die Gefährdung eindämmen.

Ein Beispiel dafür ist die Verwendung von Jamf Protect zur Identifizierung von Angreifern, die die Schwachstelle ausnutzen. Seit gestern haben Kunden eine neue Erkennung mit dem Titel SuspiciousJavaActivity in ihrer Benutzeroberfläche. Dabei handelt es sich um eine Erkennung, die entweder nach curl oder bash -i – ausgeführt unter Java – sucht. Dieses Verhalten wird von vielen verschiedenen Angreifern im Zusammenhang mit der Log4j-Schwachstelle missbraucht. Eine solche Erkennung könnte ein Zeichen dafür sein, dass ein Log4j-Exploit stattgefunden hat. Einige legitime Java-App können diese Aktionen jedoch auch durchführen (hoffentlich selten).$ Die Entscheidung, was für die betreffende App normal ist und was nicht, obliegt dem Sicherheitsanalysten.

Eine wichtige Sache, die man sich merken sollte: Es ist unwahrscheinlich, dass private macOS Systeme viele, wenn überhaupt, aktive App haben, die Log4j verwenden und mit denen ein Angreifer aus der Ferne interagieren könnte. Analysten können dies berücksichtigen, wenn sie entscheiden, ob es sich lohnt, einer Warnmeldung nachzugehen.

Least-Privilege

Das Least-Privilege-Prinzip gilt weithin als Basiskomponente, die Administratoren in ihre Sicherheitsprozesse einbauen, um den Benutzerzugriff auf das zu beschränken, was für eine produktive Arbeit notwendig ist – nicht mehr und nicht weniger. Das Prinzip gilt für die Host-, App- und Netzwerkebene, die alle gehärtet werden können, um zu verhindern, dass Systeme, die Opfer des RCE-Exploits in Log4j sind, Verbindungen als eine Form der Egress-Kontrolle initiieren. Diese Art von Sicherheit hilft Administratoren, kompromittierte Systeme abzusperren und einzudämmen, bis die Schwachstelle behoben ist.

Web-App Firewall

WAFs haben sich als hervorragende Schutzsoftware erwiesen, die Kommunikationsversuche mit Services und Apps, die von der Log4j-Schwachstelle betroffen sind, wirksam blockiert. Kurz gesagt: Unverhüllte Zeichenketten sowie solche mit einfachen Umgehungstechniken sollten von einer fähigen WAF leicht gestoppt werden können. Wie Forscher jedoch festgestellt haben, passen Bedrohungsakteure ihre Verwendung der Log4j-Sprache zunehmend an, um verschlüsselte Schlüsselzeichenfolgen einzuschließen, die sich der Erkennung entziehen, indem sie komplexere Lookups verwenden, um kritische Zeichenfolgen zu verschleiern. Sicherheitsteams sollten darauf achten, ihre WAF-Regeln so weiterzuentwickeln, dass sie diese verschleierten Zeichenfolgen erkennen und blockieren, um Angriffe auf wichtige Systeme zu verhindern.

Überwachung und Berichterstattung

Die aktive Suche nach anfälligen Log4j-Systemen hat nach Berichten mehrerer Sicherheitsagenturen einen neuen Höchststand erreicht. Erschwerend kommen Hinweise hinzu, die darauf hindeuten, dass die Bedrohungsakteure von Nationalstaaten unterstützt werden, während sich die Angriffe weiterentwickeln. Die aktive Überwachung Ihrer Infrastruktur, um nicht nur anfällige Systeme und Anwendungen zu identifizieren, sondern auch den Gerätezustand zu bewerten, ist für den Sicherheitsstatus Ihrer Organisation unerlässlich. Darüber hinaus erhalten Administratoren durch die Überprüfung von Berichten auf Schlüsselindikatoren für eine Kompromittierung, einschließlich Hashes, die mit dem „Log4Shell“-Exploit in Verbindung stehen, die Bedrohungsdaten, die sie benötigen, um Schutzmaßnahmen wie WAFs anzupassen, um die laufenden Risiken zu mindern.