Ausnutzung von Schwachstellen
Patch Now: Apache Log4j Vulnerability Called Log4Shell Actively Exploited
Log4Shell, also known as CVE-2021-44228, was first reported privately to Apache on November 24 and was patched on December 9. It affects Apache Struts, Apache Solr, Apache Druid, Elasticsearch, Apache Dubbo, and VMware vCenter.
Save to Folio
Originalartikel von Ranga Duraisamy, Ashish Verma, Nikko Tamana, Miguel Carlo Ang
In Apache Log4j, einem weit verbreiteten Logging-Paket für Java, ist eine Schwachstelle (CVE-2021-44228) gefunden und mit dem Namen Log4Shell versehen worden. Sie ermöglicht es einem Angreifer, beliebigen Code auszuführen, indem er speziell bearbeitete Log-Nachrichten sendet. Die Sicherheitslücke wurde Apache erstmals am 24. November privat gemeldet und am 9. Dezember mit Version 2.15.0 von Log4j gepatcht. Betroffen sind Apache Struts, Apache Solr, Apache Druid, Elasticsearch, Apache Dubbo und VMware vCenter. Derzeit beobachten wir, dass Bedrohungsakteure Mirai-Varianten und Kinsing-Coin-Miner auf anfälligen Servern ablegen. Wir haben ein webbasiertes Tool, Log4j Vulnerability Tester, entwickelt, mit dem angreifbare Serveranwendungen identifiziert werden können. Wir haben die Einzelheiten zu den jetzt schon bekannten Angriffen sowie Patch- und weitere Empfehlungen zum Schutz zusammengestellt. Eine komplette Liste unserer Lösungen finden Sie hier.
Während ein Teil dieses Netzwerkverkehrs einfach zu monitoren ist, verwenden andere Akteure eine Verschleierungstaktik, um ihren Verkehr zu verbergen.
Infektionsablauf
Wir zeigen einen möglichen Infektionsablauf von Angriffen, die Log4Shell missbrauchen könnten:
Bild 1. Möglicher Log4Shell-Infektionsablauf
Die Schwachstelle wird vom „Lookup“-Mechanismus in log4j 2.x verursacht. Es werden mehrere JNDI-Lookup-Protokolle unterstützt, die Lookups aus der Ferne ermöglichen, wie etwa LDAP und RMI. Sobald der Exploit erfolgreich durchgeführt wurde, interpretiert der Server je nach Inhalt der URL im Lookup die Zeichenfolge. Dies kann dann zu beliebigen Shell-Befehlen in verschiedenen Formen wie Java Class, JavaScript und Unix-Shell führen, um nur einige zu nennen. Auch konnten wir das Herunterladen von Komponenten beobachten, die laterale Bewegungen ermöglichen und zu einer eventuellen Ransomware-Infektion führen. Die Schwachstelle kann auch zum Herunterladen von Malware führen, die Anmeldedaten stehlen kann, wie z. B. Kirabash. Technische Einzelheiten liefert der Originalbeitrag.
Auswirkungen
Derzeit scheint es nur das Mirai botnet und den Kinsing.Coinminer als Payload zu geben. Zwei Auswirkungen sind denkbar:
- Kapern von Ressourcen. Coinminer verbrauchen Ressourcen für das Mining von Kryptowährungen, während Mirai die betroffenen Systeme als Teil seines Botnetzes für Aktivitäten wie Distributed Denial of Service (DDoS) oder Spamming nutzen könnte.
- Netzwerk-Denial-of-Service (DoS). Mirai kann das betroffene System dazu nutzen, im Rahmen seiner Routine DDoS/DoS-Angriffe zu starten.
Patch und Schadensbegrenzung
Obwohl die Angriffe im Moment überwiegend über HTTP erfolgen, könnte die Schwachstelle über jedes beliebige Protokoll ausgenutzt werden, bei dem Benutzereingabedaten mit Log4j protokolliert werden. Wir empfehlen daher jedem dringend, auf Log4j 2.15.0 zu aktualisieren. Bis die angreifbaren Instanzen gepatcht sind, kann die Sicherheitslücke durch die folgenden Schritte entschärft werden:
- For >=2.10, set system property log4j2.formatMsgNoLookups to true.
- For >=2.10, set environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
- For 2.0-beta9 to 2.10.0, remove JndiLookup.class from class path: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Eine empfohlene Best Practice besteht darin, den ausgehenden Datenverkehr ins Internet nur auf die erforderlichen Ports zu beschränken.
Es ist wichtig zu beachten, dass die oben genannten Schritte vor allem in Fällen nützlich sind, in denen Log4j direkt verwendet wird. Andere Patches für Anwendungen, die Log4j indirekt nutzen, können ebenfalls erforderlich sein. Wie die folgende Liste zeigt, haben mehrere Softwarehersteller Produkte, die diese Sicherheitslücke aufweisen.
Anleitung zur Erkennung
Applikationslogs sollten auf das Vorhandensein von diesen Mustern überwacht werden: ${jndi:ldap:/}, ${jndi:ldaps:/}, ${jndi:rmi:/}, ${jndi:dns:/ und ${jndi:iiop:/}.
Angreifbare Produkte, Anwendungen und Plug-ins
Einige der Pakete nutzen die angreifbare Version von Log4j: Eine Liste mit den betroffenen Produkten beinhaltet der Originalbeitrag.
Product/Application/Plug-ins |
Description |
Details |
RedHat |
Nicht alle RedHat-Pakete sind angreifbar, doch sind einige von Openshift und JBoss betroffen. |
|
Jenkins |
Obwohl Jenkins Core standardmäßig nicht betroffen ist, können in Jenkins installierte Plug-ins die anfällige Version verwenden. Es gibt eine Methode, um zu überprüfen, ob eines der installierten Plug-ins Log4j verwendet. Der zweite Link enthält eine Liste der angreifbaren Versionen des Plug-ins, die bislang gefunden wurden. |
https://www.jenkins.io/blog/2021/12/10/log4j2-rce-CVE-2021-44228/ |
Apache Solr |
Apache Solr Releases vor 7.4 sind betroffen. |
https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228 |
VMWare |
Mehrere Produkte sind betroffen. |
https://www.vmware.com/security/advisories/VMSA-2021-0028.html |
Citrix |
Untersuchung im Gange |
|
Atlassian |
Ist angreifbar, wenn die Standdardkonfiguration geändert wurde. |
https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html |
NetApp |
Mehrere Produkte sind angreifbar. |
Empfehlungen
Hersteller-Patches sollten eingespielt werden. Darüber hinaus hat Trend Micro zusätzliche Regeln, Filter und Erkennungsschutz veröffentlicht, die zusätzlichen Schutz vor und Erkennung von bösartigen Komponenten in Verbindung mit solchen Angriffen bieten können.
Weitere Techniken auch aus dem MITRE ATT&CK-Framework sowie die Indicators of Compromise bietet der Originalbeitrag.