[English]Seit dem Wochenende hält ja eine in der JAVA-Bibliothek log4j enthaltene Schwachstelle CVE-2021-44228 die IT-Szene in Atem. Die log4j-Bibliothek ist extrem verbreitet und wird in vielen Produkten verwendet. Zudem ist die Schwachstelle extrem einfach remote ausnutzbar und seit ca. 2 Wochen werden auch Angriffe beobachtet. Im Blog-Beitrag versuche ich in einer Art FAQ bzw. als Repository die wichtigsten Fragen/Antworten aufzugreifen und weiterführende Seiten zu verlinken.
Anzeige
Die log4j Schwachstelle CVE-2021-44228
Es gibt eine kritische Schwachstelle in der JNDI-Lookup-Funktion in der zum Logging benutzen Java Bibliothek log4j, über die Angreifer remote Code injizieren und ausführen lassen können. Log4j ist eine beliebte Protokollierungsbibliothek für Java-Anwendungen, die in vielen Produkten verwendet wird. Gelingt es einem Angreifer eine URL auf einen von ihm kontrollierten Server in der von log4j verwalteten Protokolldatei anzugeben, kann er einen Server über das Logging kapern (Log4Shell).
Seit ein Proof of Concept (PoC) für die Remote Code Execution-Schwachstelle in log4j am 9. Dezember 2021 veröffentlicht wurde, steht die IT-Welt Kopf. Die US CISA warnt (siehe), dass dies die größte Sicherheitslücke des Jahres sei und hunderte Millionen an Geräten und Programmen bedroht.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat für die kritische Schwachstelle (CVE-2021-44228) in log4j veröffentlicht die Warnstufe in dieser Sicherheitswarnung auf Rot erhöht (CSW-Nr. 2021-549032-1332, Version 1.3, 12.12.2021). Der Schwachstelle wurde nach Veröffentlichung des Blog-Posts ein CVSS-Wert von 10.0 (Maximum) zugewiesen. Im Gegensatz zur ursprünglichen Einschätzung kann die kritische Schwachstelle ggf. auch auf internen Systemen ausgenutzt werden, sofern diese externe Daten entgegennehmen oder verarbeiten.
Angriffe auf CVE-2021-44228 laufen
Es gibt bereits Meldungen, dass das Internet breitflächig nach verwundbaren Systemen gescannt wird. The Record-Media berichtet im Artikel Log4Shell attacks began two weeks ago, Cisco and Cloudflare say, dass bereits ab dem 1. Dezember 2021 Angriffe auf die Schwachstelle beobachtet wurden. Und die Sicherheitsforscher von Check Point haben in diesem Blog-Beitrag die nachfolgende Grafik mit den sprunghaft steigenden Angriffszahlen publiziert.
Anzeige
(Source: Check Point)
Die Kollegen von Bleeping Computer berichten in diesem Artikel ebenfalls, dass Angreifer beginnen, nach erfolgreichen Log4Shell-Angriffen Malware auf die Systeme zu installieren. Von den Bitdefender Labs liegen mir folgende ergänzende Informationen vor:
- 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.
- Die 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. Bitdefender hat eine Zusammenfassung der bisherigen Erkenntnisse im Advisory By Martin Zugec / Dec 13, 2021 veröffentlicht.
Sind meine Systeme anfällig
Der Ratschlag der Sicherheitsexperten an Administratoren lautet, sich einen Überblick zu verschaffen, welche Systeme die log4j-Bibliothek verwenden bzw. über die Schwachstelle angreifbar sind.
- Die erste Einschätzung, dass ältere JAVA-Versionen nicht angreifbar seien, hat sich leider als falsch erwiesen.
- Andere Implementierung der log4j-Bibliothek wie log4net, log4perl, log4php etc. scheinen nach dieser Diskussion über die Schwachstelle CVE-2021-44228 nicht angreifbar zu sein.
In einer direkten Mitteilung, die mir zugegangen ist, spricht Sicherheitsanbieter Tenable vom "Fukushima der IT" und schreibt, dass man jede Minute neue Anwendungen entdeckt, die Log4j auf die eine oder andere Weise nutzen. Das betrifft nicht nur den Code, den Unternehmen erstellen, sondern auch die Systeme von Drittanbietern, die sie im Einsatz haben. Alles, vom neuen Drucker, den sie für ihr Büro gekauft haben, bis hin zum Ticketing-System, das sie gerade eingerichtet haben, ist potenziell von dieser Schwachstelle betroffen. Einige der betroffenen Systeme befinden sich vielleicht lokal vor Ort, andere werden in der Cloud gehostet. Egal, wo sich die Systeme befinden, die Schwachstelle wird wahrscheinlich Auswirkungen haben.
Laut Tenable beobachtet man Kunden, die 1.000 Systeme pro Sekunde überprüfen und ein betroffenes System pro Sekunde identifizieren. Um Systeme online auf eine Verwundbarkeit bezüglich der Schwachstelle CVE-2021-44228 zu testen, hat Trend Micro einen Online-Scanner (Englisch)bereitgestellt.
Es reicht, im Formularfeld die URL der zu prüfenden Webseite einzugeben und ggf. Optionen zu spezifizieren, um einen Check auszuführen. Mein Problem: Ich habe einige URLs probiert, aber keine Rückmeldung bekommen, dass die angreifbar sind.
- Ein auf Python basierender Scanner für die Schwachstelle CVE-2021-44228 ist in diesem Blog-Beitrag sowie hier erwähnt.
- Detectify bietet hier einen Test auf die Schwachstelle an, wobei man sich aber anmelden muss.
LunaSec hat in diesem Artikel einen log4Shell-Scanner für diverse Plattformen (Linux, Windows, macOS) sowie diverse Abhilfemaßnahmen gegen die Schwachstelle beschrieben. Der Scanner kann heruntergeladen und dann lokal auf einem der betreffenden Systeme ausgeführt werden.
Die US-Sicherheitsbehörde CISA hat den US-Behörden laut diesem Artikel bis zum 24. Dezember 2021 Zeit gegeben, die log4j-Schwachstellen in ihren Systemen gegen Log4Shell zu schützen.
Liste betroffener/nicht betroffener Produkte
Auf Github findet sich auf dieser Seite des NCSC-NL (Nationaal Cyber Security Centrum der Niederlande) eine (nicht vollständige) Liste betroffener oder nicht betroffener Produkte, die ständig aktualisiert wird. Hier könnten Administratoren auf die Schnelle nachsehen, ob eine vielleicht eingesetzte Software-Lösung als angreifbar aufgelistet wird und beim Hersteller Patches anfordern.
Ich hatte zudem im Blog-Beitrag 0-day CVE-2021-44228 in Java log4j-Bibliothek tangiert zahlreiche Anbieter bereits erwähnt. Auf dieser GitHub-Seite werden betroffene Dienste aufgelistet – da ist alles dabei, was Rang und Namen hat. Zu Minecraft und VMware hatte ich separate Artikel hier im Blog veröffentlicht (siehe Linkliste am Artikelende). Ergänzung: Ich habe gelesen (Quelle, Quelle, dass vor allem die im Medizinbereich einzuführende Telematik-Infrastruktur heftig betroffen sein soll und teilweise abgeschaltet wurde.
Die Kollegen von Bleeping Computer haben in diesem Artikel ebenfalls eine kurze Zusammenstellung von betroffenden Produkten und ggf. Gegenmaßnahmen veröffentlicht.
Mich hat noch interessiert, ob mein Blog, der mit WordPress läuft, aber mit einem Webpaket bei Hosteurope gehostet wird, über die Schwachstelle CVE-2021-44228 angreifbar ist. Ich habe dann beim Support nachgefragt, und wurde auf diese FAQ verwiesen. Nach diesem Dokument ist mein Paket und die verwendete Software nicht betroffen.
Details zur Schwachstelle und zum Patchen werden von Trend Micro hier bereitgestellt. Anlaufstellen für weitere Informationen könnten auch folgende Webseiten sein.
- Diese Webseite des GOV-CERT Schweiz
- Der Blog-Beitrag von Huntress
- Schutz vor schwerwiegender Log4j-Lücke – was jetzt hilft und was nicht (heise-Beitrag)
- Log4j 2.16.0 verbessert Schutz vor Log4Shell-Lücke
- Schwere Sicherheitslücke „Log4Bash" in Log4j erklärt Ulabs-Beitrag
Ähnliche Artikel:
0-day CVE-2021-44228 in Java log4j-Bibliothek tangiert zahlreiche Anbieter
Gegenmittel für 0-day CVE-2021-44228 in Java log4j-Bibliothek
log4j-Schwachstelle CVE-2021-44228: Minecraft dringend patchen
VMware-Produkte durch log4j-Schwachstelle CVE-2021-44228 bedroht
Anzeige
Benutzt jemand die Software von APC – PowerChut?
ESET hat da ein Cmd-Snippet um grob zu suchen (https://www.welivesecurity.com/2021/12/13/log4shell-vulnerability-what-we-know-so-far/):
findstr /s /i /c:"JndiLookup.class" C:\*.jar
Mit obigen finde ich halt das von APC – kann das einer bestätigen, das dies die "böse" Version ist?
Hab im Sommer eine APC-USV mit PowerChute Business Edition in Betrieb genommen – der Ausgabe zufolge ist Log4J in Version 2.11.1 enthalten.
Ok, meine Version ist dann neuer – 2.13.x.
Habe ich entfernt – obwohl nicht mit dem Ar… nach draußen!
Moin,
das PowerChut bei uns ist die v2.10.0. Es sollen ja alle log4j Versionen bis v2.15.0 als "böse" angesehen werden. Da APC kein Update zur Verfügung stellt, haben wir PowerChut deinstalliert.
Gruß
Ich habe einfach die log4j-Dateien im PowerChute Ordner ausgetauscht und musste sie anschließend wie die alten umbenennen. Dazu musste der Dienst kurzzeitig beendeet werden.
Nach der Umbenennung lief der Dienst wieder und die Weboberfläche wurde auch problemlos erreicht.
Hallo Thimo,
kannst Du das genauer ausführen?
Wir haben einige APC Installationen und konfigurierte geregelte Shutdowns. Ein reines Deinstallieren der APC würde im Stromausfall unkontrollierte Shutdowns bedeuten. Da sich APC aber leider nicht bewegt, ist der manuelle Austausch der Datei sehr interessant.
Gruß
Dirk
Hey Dirk,
sorry, habe das nicht gesehen.
Jetzt gibt es einen Workaround von APC:
LG Thimo
Das Ding ist Fukushima, Tschernobyl, Harrisburg, Philipsburg, Hiroshima und Nagasaki zusammen. Wir sind auch auf der Arbeit noch am katalogisieren… Aber immerhin bisher kein Fund auf öffentlich zugänglichen Webservern. An Drucker haben wir noch garnicht gedacht.
"das Ding" sollte man umbenennen in Lock2You!
oh Mist – verschrieben:
Lock4You
;-)
CoinMarketCap ist gerade ebenfalls betroffen von einem Hackerangriff.
CoinMarketCap zeigt die Werte von Kryptowährungen an,
aber aktuell werden völlig falsche Werte angezeigt mit Steigerungen von mehreren Millionen Prozent.
CoinMarketCap bestätigt (Zitat):
Our website is currently undergoing Price Issues
The Engineering team is aware of incorrect price information appearing on CoinMarketCap[.]com
We are currently investigating and will update this status when we have more information.
twitter[.]com/CoinMarketCap/status/1470876283924094983
Ohje, hab grad obiges Snippet in Arztpraxen laufen lassen! Ganz böse!
Zum Glück hängen die nicht direkt am Netz – aber wer weiß, was sich da noch entwickelt!
Spielt das eine Rolle? Mir fallen vielfältige Möglichkeiten ein, Strings von Extern entgegenzunehmen und im internen Netzwerk weiterzuleiten. Dann haben auch deine Rechner ohne externe Netzanbindung den Salat. Es muss ja nicht zwingend eine Payload nachgeladen werden, der Code kann bereits im String enthalten sein und in dieser Konstellation auch für Sabotage auf den internen Maschinen sorgen.
Ja eben, das meine ich mit "aber wer weiß, was sich da noch entwickelt!".
Das Debakel nimmt seinen Lauf -> z.B. in Richtung Telematik-Infrastruktur!
Die Bombe tickt…
Zur Telematik-Infrastruktur im Medizinbereich habe ich oben im Text noch zwei Quellen verlinkt – hatte das im Hinterkopf, aber beim Schreiben vergessen.
Welches Snippet kann denn interne IPs scannen? Dachte die wären alle als externe Scanner
Sehr guter und informativer Artikel mit nütlichen Links!
Danke, Herr Born, weiter so!!!
Hallo Hr. Born und alle die das lesen.
Ich weiß nicht ob Sie es schon mitbekommen haben, aber log4j v2.15 ist nur unzureichend gepatcht (CVE-2021-45046). Eigentlich bräuchte man Version 2.16.
https://www.heise.de/news/Log4j-2-16-0-verbessert-Schutz-vor-Log4Shell-Luecke-6294053.html
https://nvd.nist.gov/vuln/detail/CVE-2021-45046
https://logging.apache.org/log4j/2.x/security.html
– Heiko
Ich hatte es am Rande gelesen.
Steht auch im Artikel als Link:
"Log4j 2.16.0 verbessert Schutz vor Log4Shell-Lücke"