München, Starnberg, 16. Dez. 2021 - Überblick zur Bedrohungslage mit Hintergrundkommentaren, Risikobewertungen & verschiedenen Analysen mit Handlungsempfehlungen...
Zum Inhalt: Die folgenden Beiträge sind eine Auswahl von Hinweisen-/Kommentaren zur aktuellen Bedrohungslage und auch zur Rolle von open source, um ein Bild zur Lage zu vermitteln. Um was geht es? Log4j ist ein Java-basiertes Logging-Audit-Framework innerhalb von Apache. Apache log4j <=2.14.1 JNDI-Funktionen, die in der Konfiguration, den Protokollnachrichten und den Parametern verwendet werden, bieten keinen Schutz gegen von Angreifern kontrollierte LDAP- und andere JNDI-bezogene Endpunkte. Ein Angreifer, der die Kontrolle über die Protokollnachrichten oder die Parameter der Protokollnachrichten hat, kann beliebigen Code ausführen, der von LDAP-Servern geladen wird, wenn der Ersatz der Nachschlagefunktion für Nachrichten aktiviert ist.
Die Schwachstelle betrifft Standardkonfigurationen mehrerer Apache-Frameworks, darunter Apache Struts2, Apache Solr, Apache Druid und Apache Flink, die zahlreiche Unternehmen darunter auch sehr bekannte Namen Apple, Amazon, Cloudflare, Twitter, Steam usw. nutzen. Die Schwachstelle wird danach durch das Senden einer bestimmten Zeichenkette an die log4j-Software ausgelöst, und sie ist deswegen einfach auszunutzen. Was ist dagegen zu tun?
Dazu Jonathan Tanner, Senior Security Researcher bei Barracuda Networks: „Da diese Sicherheitslücke die Ausführung von Remotecode ermöglicht, sind die Risiken ziemlich hoch.“ Wie können Unternehmen diese Schwachstelle in ihrer Technologie erkennen, und welche Risiken drohen, wenn sie nicht behoben wird?
-
„Zuerst sollten sie prüfen, ob eine Version von log4j vor 2.15.0 verwendet wird, auch in den Abhängigkeiten. Sowohl Maven als auch Gradle – beides auf Java basierende Build-Management-Tools - bieten die Möglichkeit, den gesamten Abhängigkeitsbaum für ein Projekt auszudrucken. So lässt sich feststellen, ob eine verwundbare Version von log4j verwendet wird oder nicht. Auch mit Version 2.15.0 oder höher sollte man sicherstellen, dass die Systemeigenschaft formatMsgNoLookups auf ‚true‘ gesetzt ist. Wenn die Anwendung LDAP nicht als Teil ihrer legitimen Nutzung benötigt wird, ist es auch möglich, den gesamten LDAP-Verkehr mit einer Firewall oder einem Web Application Filter zu blockieren, um zu verhindern, dass Remote-Code erreicht wird, falls die Schwachstelle ausgenutzt wird.
-
Diese prüfen jedoch nur, ob log4j in der Lage ist, diese RCE-Schwachstelle auszunutzen oder nicht. Ob ein System wirklich anfällig für einen Angriff ist oder nicht, ist eine viel kompliziertere Angelegenheit ohne einen einzigen Test, wie ihn Schwachstellen wie HeartBleed hatten. Um diese Schwachstelle auszunutzen, müsste ein Angreifer einen Log-Injection-Angriff durchführen. Diese zu finden ist ein sehr viel komplexerer Prozess, aber im Grunde genommen kann jeder Ort, an dem Eingaben eines Benutzers (oder eines potenziellen Angreifers) protokolliert werden, für diesen Angriff anfällig sein. Um einen tatsächlichen RCE zu testen, müsste man also versuchen, einen Weg zu finden, eine JNDI-LDAP-Anfrage innerhalb der Protokolle aus dem Benutzerkontext selbst zu stellen (z. B. über die Website oder die API, wenn die potenziell betroffene Anwendung eine Webanwendung ist). Da diese Sicherheitslücke die Ausführung von Remotecode ermöglicht, sind die Risiken ziemlich hoch. Ein Angreifer könnte möglicherweise in das Netzwerk eindringen und von dort aus versuchen, auf wichtige Ressourcen und Daten zuzugreifen.“
Welche Rolle spielte Open Source bei dieser Sicherheitslücke, und was sind die wichtigsten Sicherheitsüberlegungen für Unternehmen, die Tools wie log4j verwenden?
-
„Da es sich bei log4j um eine sehr beliebte Open-Source-Bibliothek handelt, war die Zahl der verwundbaren Anwendungen sicherlich höher. Generell kann jede Software anfällig für Angriffe sein, und bei populärer Open-Source-Software gibt es oft ein großes Ökosystem, das nach Sicherheitsbedrohungen sucht und diese behebt. Auch wenn Open-Source-Software die meisten Schlagzeilen macht, wenn größere Sicherheitslücken gefunden werden, bedeutet dies nicht, dass sie verhältnismäßig weniger sicher ist (und in der Tat ist sie wahrscheinlich viel sicherer als proprietärer Code oder weniger populäre Bibliotheken). Die weite Verbreitung erhöht lediglich die Wahrscheinlichkeit, dass Schwachstellen gefunden werden, nicht unbedingt die Wahrscheinlichkeit, dass sie existieren.
-
Bei der Suche nach Open-Source-Bibliotheken sollten Unternehmen aus den oben genannten Gründen große, seriöse und gut gewartete Projekte wie log4j wählen. Natürlich kann es immer noch Schwachstellen geben, aber es ist wahrscheinlicher, dass die Community diese Schwachstellen findet und ausbessert und auch überprüft, dass der Code frei von Fehlern ist, die überhaupt erst Schwachstellen verursachen könnten, als bei kleineren Projekten.
-
Selbst für diejenigen, deren Anwendungen nicht für CVE-2021-44228 anfällig sind oder die log4j gar nicht für die Protokollierung verwenden, ist diese Schwachstelle definitiv ein Weckruf, dahingehend, dass Log-Injection eine potenzielle Methode ist, die Angreifer nutzen könnten. Es lohnt sich, zu überprüfen, ob alle Benutzereingaben, die protokolliert werden, in jeder Anwendung ordnungsgemäß bereinigt werden, unabhängig davon, welches Protokollierungssystem oder sogar welche Programmiersprache verwendet wird. Auch wenn andere Formen der Injektion weitaus verbreiteter sind und im Mittelpunkt des Interesses stehen, handelt es sich bei der Log-Injection immer noch um eine Form des Injektionsangriffs und fällt daher unter die OWASP Top 10 Schwachstellen.“
Querverweis: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
UPDATE (Stand 21. Dez.)
Genereller IBM-Update zu allen (IBM-)Produkten, die von der Sicherheitslücke betroffen sind (Stand 21.12.):
LINK > https://www.ibm.com/blogs/psirt/an-update-on-the-apache-log4j-cve-2021-44228-vulnerability/
IBM hat mit Stand vom 17. Dez. 2021 korrigierte Versionen für den Backup/Archive Client und Operations Center veröffentlicht. Folgende Versionen sind danach gefixt:
- IBM Spectrum Protect WebClient und Spectrum Protect for VE können über den 8.1.13.1 oder 7.1.8.13 Backup/Archive Client aktualisiert werden:
-
LINK > https://www.ibm.com/support/pages/ibm-spectrum-protect-downloads-latest-fix-packs-and-interim-fixes
- IBM Operations Center wurde mit Version 8.1.13.100 korrigiert:
IBM hat die Security Bulletins aller betroffenen IBM Spectrum Protect Komponenten veröffentlicht:
Betroffen davon sind der Spectrum Protect Web Client und die Web GUI von Spectrum Protect for VE:
- Security Bulletin: Vulnerability in Apache Log4j affects IBM Spectrum Protect Client Web User Interface and IBM Spectrum Protect for Virtual Environments (CVE-2021-44228)
Im obigen Security Bulletin ist auch der Local Fix enthalten, er besteht darin, die Log4j Binaries auszutauschen. Folgende Produkte aus der Spectrum Protect Familie sind laut den Experten des Stuttgarter Dienstleisters** Empalis ebenfalls betroffen:
- Security Bulletin: Vulnerability in Apache Log4j affects IBM Spectrum Protect Operations Center (CVE-2021-44228)
- Security Bulletin: Vulnerability in Apache Log4j affects IBM Spectrum Protect Plus Container Backup and Restore for Kubernetes and OpenShift (CVE-2021-44228)
Hinweis: Empalis hat zu Beginn entgegen der IBM Dokumentation empfohlen, direkt auf Version 2.16.0 zu gehen, da dort auch CVE 2021-45046 mit gefixt ist. Vermutlich ist inzwischen laut Empalis bei Spectrum Protect auch bei Version 2.16 eine Sicherheitslücke vorhanden: In der neuen Version 2.17 wird CVE-2021-45105 gefixt. Hintergrund: Obwohl in Version 2.16 die kritischen Lücken geschlossen wurden, die Remote Code Execution und Local Code Execution ermöglichten, ist dieses Release nach Ansicht von Empalis** noch immer anfällig. Ein Angreifer kann mittels eines manipulierten Strings einen Puffer Überlauf in der Context Lookup-Funktionalität von log4j und damit letztlich eine Denial of Service erzeugen. Version 2.17 behebt laut Empalis dieses Problem. Eine detaillierte Erklärung finden Sie hier:
Lothar Hänsler, COO bei Radar Cyber Security: „Die Schwachstelle lässt sich verhältnismäßig einfach auszunutzen, Angriffe können leicht verschleiert werden.“
„Vergangenes Wochenende wurde eine Schwachstelle im log4j2-Modul von Apache.org erkannt und diese sehr schnell mit einem CVSS Score von 10, der höchsten Kritikalitätsstufe, versehen. Auch Behörden, wie das Bundesamt für Sicherheit in der Informationstechnik (BSI) haben ihre Risikoeinschätzung, die anfangs noch auf Orange stand, zügig auf Rot angehoben.“
Was macht diese Schwachstelle so besonders?
- „Die Schwachställe lässt sich verhältnismäßig einfach auszunutzen, Angriffe können leicht verschleiert werden (Obfuscation). Zudem sind Verteidigungsmaßnahmen nicht einfach umzusetzen. Dies liegt unter anderem daran, dass alle Mitigationsstrategien Risiken und Nebenwirkungen auf die Applikationen haben können, die von der Schwachstelle betroffen sind. Die Einschätzungen in den Expertenkreisen stellen sich allerdings sehr dynamisch dar. Dadurch liegen auch unterschiedliche Sichtweisen zu den Mitigationsstrategien vor.“
Was hat Radar Cyber Security konkret unternommen?
-
„Wir haben am Wochenende zunächst die Datenlage mit einem Incident Response analysiert, den Impact abgeschätzt, diverse Informationsquellen von internationalen Plattformen, wie Computer Emergency Response Teams (CERTs), herangezogen und eine Strategie für den Umgang mit dieser Bedrohung entworfen. Montagfrüh haben wir schließlich ein Security Advisory an all unsere Kunden verschickt. Unser Cyber Defense Center (CDC) wurde auf den High-AlertModus gesetzt. Es richtet nun ein besonderes Augenmerk auf das Auftreten der Schwachstelle im log4j2-Modul, ohne dabei die Gesamtsicherheitslage zu vernachlässigen. Dafür haben wir die Erkennungsmodule aktualisiert, um die Ausnutzung dieser Schwachstelle verifizieren und an unsere Kunden melden zu können. Dies reicht vom Schwachstellenmanagement über klassische SIEM-Dienste bis zu den einzelnen Netzwerkanalyse-Tools. Parallel dazu haben wir eine Analyse unserer eigenen Systeme gestartet. Nach dem ersten Scan bei einem ersten Kunden, wurden innerhalb kürzester Zeit zwei kritische Vorkommnisse erkannt. Weitere Sonderservices analysieren, ob Kunden konkret von dieser Schwachstelle betroffen sind. In Extremfällen kann ein Abschalten von Systemen erforderlich sein.“
Paul Smit, Director Professional Services bei ForeNova: „Die Zero-Day-Lücke in log4j ist hochgefährlich, da sie ohne explizites Nachladen von Schadcode direkt ausnutzbar ist.“
-
„Die Zero-Day-Lücke in der weit verbreiteten Java-Bibliothek log4j ist hochgefährlich, weil die Schwachstelle auch ohne explizites Nachladen von Schadcode direkt ausnutzbar ist. Ob dies allerdings sofort erfolgt oder nicht, lässt sich erst sehen, wenn es zu spät ist. Ein Endpunkt mag kompromittiert sein, aber noch nicht im Blickfeld der Hacker. Gerade jetzt zeigt sich auch für kleine und mittlere Unternehmen die Notwendigkeit, Network Detection and Response und Endpoint Detection and Response gemeinsam als umfassende Abwehrstrategie zu denken. EDR sieht, ob die Malware installiert wurde und organisiert die Abwehr auf dem Endpunkt.
-
Mit NDR kann man in Logging-Daten auch rückwirkend sehen, auf welche Systeme von außen Hacker zuzugreifen versuchten. NDR sieht auch typischen Datenverkehr, der aus einem solchen Zugriffsversuch resultiert, wie etwa die Kommunikation mit den C2C-Servern, Port Scanning und spezifischer Datenverkehr. NDR erlaubt auch das Blocken und Segmentieren von Netzwerken oder die Quarantäne von Systemen – eine im Zweifelsfall unbedingt zu treffende Maßnahme. Eine NDR-Lösung wie NovaComand analysiert auch Telemetriedaten von Endpunkten. NovaCommand hat einen Patch veröffentlicht und die Regeln zur Erkennung einer solchen Attacke aktualisiert. NovaCommand triggert auch andere Lösungen von Drittanbietern an, betroffene Systeme und Netzwerkabschnitte zu blocken und zu segmentieren.“
Bitdefender entdeckt laufende Attacken auf die Log4j-Schwachstelle: Experten der Bitdefender Labs beobachten zahlreiche aktuelle Angriffe, die die Log4j-Schwachstelle ausnutzen. Bestätigen lassen sich erfolgreiche Angriffe zum Einbetten von Kryptominern sowie versuchte Ransomware-Attacken. Die wichtigsten Ergebnisse einer ersten Bestandaufnahme von Bitdefender im Überblick:
-
Die Cyberkriminellen versuchen eine neue Ransomware-Familie, Khonsari, einzubetten. Sie attackieren jetzt auch Microsoft-Windows-Systeme, nachdem zunächst Linux-Server im Visier der Hacker waren.
-
Angreifer versuchen auch über die Schwachstelle den Remote Access Trojaner (RAT) Orcus zu implementieren. Sie versuchen Shellcode von hxxp://test.verble.rocks/dorflersaladreviews.bin.encrypted herunterzuladen und im Speicher des conhost.exe-Prozesses zu injizieren. Dieser Shellcode entschlüsselt und lädt andere bösartige Payload in den Speicher nach, der Orcus an die Command-and-Control-Server anbindet.
-
Mit Reverse Bash Shells versuchen Cyberkriminelle, einen Zugriff in Systeme für spätere Folgeaktionen zu erhalten. Das ist relativ einfach. In der Folge sind mit hoher Wahrscheinlichkeit umfassendere Angriffe zu erwarten.
-
Die Bitdefender-Experten beobachten bereits zahlreiche Botnetze, die die Schwachstelle ausnutzen, um Backdoors in neuen Opfernetzen zu installieren und ihre Netzwerke zu erweitern. Ein erstes Beispiel dafür ist Muhstik. Botnetze leben von ihrer Größe. Das Wachstum dieser Netze ist ein guter Indikator für die Gefahr von Schwachstellen.
Einen vollständigen Überblick bietet Bitdefender in seinem aktuellen Report: Link > https://businessinsights.bitdefender.com/technical-advisory-zero-day-critical-vulnerability-in-log4j2-exploited-in-the-wild
Das US-Unternehmen Mandiant hat identifiziert, dass chinesische und iranische Regierungsakteure die Schwachstelle in log4j bereits ausnutzen. Kommentar John Hultquist, VP of Intelligence Analysis bei Mandiant, zu den neuesten Erkenntnissen:
-
„Wir wissen, dass chinesische und iranische Regierungsakteure diese Schwachstelle ausnutzen, und wir gehen davon aus, dass andere staatliche Akteure dies ebenfalls tun oder sich darauf vorbereiten. Wir glauben, dass diese Akteure schnell handeln werden, um in begehrten Netzwerken Fuß zu fassen. Mit dem Fuß in der Tür können sie dann Folgeaktivitäten unternehmen, die einige Zeit andauern können. In einigen Fällen werden sie eine Wunschliste von Zielen abarbeiten, die schon lange vor dem Bekanntwerden dieser Schwachstelle existierte. In anderen Fällen werden erstrebenswerte Ziele nach einer breit angelegten Zielbestimmung ausgewählt werden. Die iranischen Akteure, die wir mit dieser Schwachstelle in Verbindung gebracht haben, sind besonders aggressiv. Sie haben an Ransomware-Operationen teilgenommen, die in erster Linie zu Schädigungszwecken und nicht zum finanziellen Vorteil durchgeführt werden. Sie werden zudem mit eher traditioneller Cyberspionage in Verbindung gebracht.“
-
Mandiant hat auf GitHub kostenlose Tools veröffentlicht, mit denen Unternehmen Regeln für die systematische Suche nach Deserialisierungs-Exploits und anderen Arten von Zero-Day-Exploits erstellen können. Dazu gehören auch Regeln für die Suche nach dem JNDI Code Injection Zero-Day, der letzte Woche für log4j veröffentlicht wurde.
In einem neuen Blogbeitrag beschreibt Mandiant die Verbreitung und die Auswirkungen von Deserialisierungsschwachstellen auf eine Vielzahl von Diensten, darunter Exchange und Jira. Hackergruppen wie APT41 nutzen diese seit Jahren aus. Sie nutzen die Schwachstellen, um Dateien hochzuladen, auf nicht autorisierte Ressourcen zuzugreifen und bösartigen Code auf den Zielservern auszuführen. Bloglink > https://www.mandiant.com/resources/hunting-deserialization-exploits
Die neuen Tools mit den Namen „HeySerial.py“ und „CheckYoself.py“ helfen laut Anbieter den Unternehmen schnell und in großem Umfang künftige Such- und Erkennungsregeln zu erproben. Die Experten von Mandiant betonen jedoch nachdrücklich, dass Unternehmen diese Regeln vor dem Einsatz gründlich testen sollten. Mandiant hat außerdem Simulationen einiger beispielhaften Exploits, die im Blogbeitrag vorgestellt werden, auf seine Mandiant Security Validation Plattform hochgeladen, um seinen Kunden zu helfen, die Tests zu beschleunigen. Den vollständigen Blogbeitrag können Sie hier einsehen: https://www.mandiant.com/resources/hunting-deserialization-exploits
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die höchste Warnstufe für die vor wenigen Tagen aufgedeckte Sicherheitslücke in der weit verbreiteten Java-Bibliothek log4j vergeben. Dazu Udo Schneider, IoT Security Evangelist Europe bei Trend Micro:
- „Unternehmen können als unmittelbare Reaktion detaillierten Empfehlungen folgen und vorhandene Patches aufspielen sowie Best Practices anwenden. Doch in einem zweiten Schritt sollten sie einen generellen Blick auf Prozesse rund um Software-Lieferketten werfen. Denn letztendlich ist auch Log4Shell, so sicherheitsrelevant die Lücke auch sein mag, „nur“ ein fehlerhafter Baustein in der Software-Lieferkette“. Das BSI spricht von einer „extrem kritischen Bedrohungslage“ https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2021/211211_log4Shell_WarnstufeRot.html, denn die angreifbare https://logging.apache.org/log4j/2.x/ - Bibliothek ist gewissermaßen „der“ Log-Standard in Java-Umgebungen. Dementsprechend wird sie auch in tausenden von Applikationen und Internet-Diensten genutzt. Hinzu kommt, dass die Lücke einfach zu missbrauchen ist und in vielen Fällen aus der Ferne ausgenutzt werden kann, wobei sie letztendlich die Ausführung beliebiger Kommandos erlaubt..."
Anlage: BSI Whitepaper V.1.4.pdf
