Log4Shell: Eine Bestandsaufnahme (Feb.2022)

Sicherheit (Pexels, allgemeine Nutzung)Im Dezember 2021 wurde eine kritische Schwachstelle in der zum Logging benutzen Java Bibliothek log4j öffentlich bekannt. Diese Software ist in vielen anderen Produkten integriert. Tausende Dienste von Apple, Amazon, Twitter, Minecraft etc. sind über diese Schwachstelle anfällig.  Obwohl die Bibliothek in vielen Produkten enthalten ist, sind bisher nur wenige Fälle bekannt geworden, wo die Log4Shell-Schwachstellen ausgenutzt wurde. Der große Knall ist bisher aber ausgeblieben. Hier nochmals eine kurze Zusammenfassung einiger Informationen zu Log4Shell, die mir die letzten Tage so untergekommen sind.


Anzeige

Die Log4Shell-Schwachstelle

Im Dezember 2021 wurde eine kritische Schwachstelle (Log4Shell) in der zum Logging benutzen Java Bibliothek log4j öffentlich bekannt. Diese Software ist in vielen anderen Produkten integriert. Tausende Dienste von Apple, Amazon, Twitter, Minecraft etc. sind über diese Schwachstelle anfällig. Ich hatte ja Anfang Dezember 2021 im Artikel 0-day CVE-2021-44228 in Java log4j-Bibliothek tangiert zahlreiche Anbieter über eine kritische Schwachstelle in der JNDI-Lookup-Funktion der zum Logging benutzen Java Bibliothek log4j berichtet.

Die JNDI-Lookup-Funktion von log4j ermöglicht den Abruf von Variablen über das JNDI – Java Naming and Directory Interface. Dabei handelt es sich um eine API, die Java-Anwendungen Namens- und Verzeichnisfunktionen zur Verfügung stellt. Es gibt zwar viele Möglichkeiten, aber log4j unterstützt (AFAIK) LDAP und RMI (Remote Method Invocation).

Am 9. Dezember 2021 wurde ein Proof of Concept (PoC) für die Remote Code Execution-Schwachstelle CVE-2021-44228 in log4j veröffentlicht. Der PoC benötigt nur wenige Zeilen Code mit dem eine Zeichenkette in Form einer URL in die Protokolldatei schreibt. Der Verzeichnisdienst JNDI kontaktiert darauf hin den im Protokoll aufgeführten LDAP-Server, um von diesem Daten anzufordern. Das kann auch Java-Klassen umfassen, die dann ausgeführt werden. Gelingt es einem Angreifer die URL auf einen von ihm kontrollierten Server in der Protokolldatei anzugeben, kann er einen Server über das Logging kapern (Log4Shell).

Die Schwachstelle CVE-2021-44228 wird  als kritisch bewertet und hat den CVE-Index 10 (von 10 möglichen Punkten) erhalten. Die Pen-Testing-Gruppe 0x0021h, die den PoC-Exploit entwickelte, gibt an, dass dieser für Apache Struts2, Apache Solr, Apache Druid, Apache Flink und funktioniert. Auf dieser GitHub-Seite werden betroffene Dienste aufgelistet – da ist alles dabei, was Rang und Namen hat. Neben Apple iCloud, Amazon, CloudFlare, Steam, Twitter und selbst das populäre Mindcraft ist alles dabei. Laut Bleeping Computer wurde Minecraft aber bereits per Notfall-Patch über die Version Minecraft: Java Edition 1.18.1 geflickt.

Bisher war aber nicht klar, ob das (trotz des CVE-Werts von 10) der "big bang" der IT zum Ende des Jahres 2021 werden könnte. Zwar wurden Angriffe auf Mindcraft-Server gesichtet, und auch den Bundesfinanzhof sowie das belgische Verteidigungsministerium hat es getroffen (siehe Links am Artikelende). Aber die richtig große Welle an Hacks blieb bisher aus.

Angriffe auf Schwachstelle CVE-2021-44228

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 obige Grafik mit den sprunghaft steigenden Angriffszahlen publiziert.

Trend Micro zu Log4Shell

Richard Schneider vom Sicherheitsanbieter Trend Micro meint dazu: "Profi-Cyberkriminelle nutzen die Lücke, um ein Netzwerk zu infiltrieren und sich von dort auszubreiten, bis sie ihr Ziel erreicht haben – ohne dabei aufzufallen. Dies braucht Zeit – je nach System und Unternehmensgröße kann das Wochen bis Monate dauern. Es steht deshalb zu erwarten, dass es ab Januar wieder zu vermehrten Ransomware-Vorfällen kommen wird." Die Leute bei Trend Micro haben sich einige Gedanken zum Thema gemacht und folgende Informationen bereitgestellt.


Anzeige

Log4Shell – War der Vorfall einzigartig?

Log4Shell ist sicherlich nicht einzigartig, auch wenn die Auswirkungen der Log4Shell-Schwachstelle ungewöhnlich sind. Aber Remote Code Execution (RCE) Schwachstellen sind keine Seltenheit. Das zeigte auch der Angriff im Frühjahr 2021, der unter dem Namen „Hafnium" bekannten Gruppe auf Microsoft Exchange Server. Auch Software-Bausteine, wie die aktuell betroffene Bibliothek, die in vielen Applikationen parallel eingesetzt werden und damit eine breite Angriffsfläche bieten, gehören zum IT-Alltag.

Das Besondere an dem Log4Shell-Vorfall besteht darin, dass all diese Faktoren zusammenkommen. Das zumindest passiert eher selten, und es wird vermutlich (hoffentlich) etwas dauern, bis sich ein ähnlicher Vorfall wiederholt. Die Wahrscheinlichkeit steigt allerdings. Dies liegt vor allem daran, dass immer mehr Software entwickelt wird. Diese soll schnell verfügbar sein, weshalb Entwickler gezwungen sind, Bausteine wie Log4j zu implementieren. Wird dann eine Sicherheitslücke innerhalb eines solchen Bausteins entdeckt, ist eben nicht nur der Entwickler selbst betroffen (wie z.B. Microsoft bei „Hafnium"), sondern alle Hersteller, die diesen Baustein implementieren. Und das kann die individuelle Firma z.B. mit einem eigens gebauten Kundenportal sein, aber auch der Anbieter einer weit verbreiteten Applikation. Weil immer mehr Bausteine benötigt werden, steigt damit zwangsläufig die Wahrscheinlichkeit, dass bei dem einen oder anderen auch mal eine Software-Lücke bekannt wird.

Wie gefährlich ist Log4Shell denn nun?

Für Log4Shell hat das britische National Cyber Security Center (NCSC) eine interessante Liste an Fragen vorbereitet. Diese richtet sich an Unternehmensleiter und soll eine Richtlinie bieten, wie Vorstände mit der Situation umgehen können. Hintergrund ist, dass eine derartige Sicherheitslücke das Potenzial hat, existenzbedrohlich zu sein. Dies liegt daran, dass es für kriminelle Akteure auf diese Weise einfach ist, Systeme zu infiltrieren.

Andererseits hat dies auch etwas „Gutes", denn wenn die Schwachstelle „so" einfach zu attackieren ist, tun dies auch viele Hobbykriminelle, um Coin Miner zu platzieren und machen damit oft auf verwundbare Systeme aufmerksam, ohne enormen Schaden zu verursachen. Profi-Cyberkriminelle nutzen dagegen die Lücke, um ein Netzwerk zu infiltrieren und sich von dort auszubreiten, bis sie ihr Ziel erreicht haben – ohne dabei aufzufallen. Dies braucht Zeit – je nach System und Unternehmensgröße kann das Wochen bis Monate dauern. Es steht deshalb zu erwarten, dass es ab Januar wieder zu vermehrten Ransomware-Vorfällen kommen wird.

Ist Log4Shell Spezialfall?

Die weite Verbreitung von Software und die vielfältigen Einsatzzwecke sorgen dafür, dass in jeder Firma irgendwo immer ein Fenster oder eine Tür für den Dieb offensteht. Es stellt sich daher eigentlich nur die Frage, wer die Schwachstelle zuerst entdeckt und in seinem Sinne damit umgeht. Auch Log4Shell zeigt wieder, genau wie Hafnium, Kaseya und andere Cybersecurity-Vorfälle, die sich 2021 ereigneten, dass ein rein proaktiver Ansatz, bei dem versucht wird, Schäden abzublocken, nur noch schwer realisierbar ist.

Wir müssen heute davon ausgehen, dass irgendwo, irgendwer ein Fenster findet durch das er einsteigen kann. Die Fähigkeit eines Unternehmens diesen „Dieb" zu identifizieren und erfolgreich zu jagen, entscheidet über das Schadensausmaß, welches dadurch erzeugt wird. Organisatorisch spricht man im Ernstfall von „Tiger Teams" oder im Allgemeinen vom „Security Operations Center (SOC)". Technologisch lassen sich viele der zugehörigen Aktivitäten jedoch schon extrem vereinfachen, wenn moderne Technologie wie XDR eingesetzt wird.

Die Kollegen von heise haben Ende Januar 2022 noch eine Bestandsaufnahme der Log4Shell-Schwachstelle veröffentlicht, die man ggf. lesen könnte. Auch dort wird auf den "Rattenschwanz", der noch kommen könnte, hingewiesen.

Log4Shell-Infektionen erkennen

Für IT-Verantwortlich stellt sich die Frage, wie man eventuell erkennt, ob sich bereits Schadsoftware über die Log4Shell-Schwachstelle in einem System eingenistet hat und ausbreitet. Der Sicherheitsanbieter LogPoint hat dazu den Beitrag Die Erkennung von Log4Shell erfordert mehr als nur SIEM veröffentlicht, der sich ebenfalls mit dem Thema und der Erkennung einer Infektion befasst.

Auf Twitter hat Craig Rowland diesen Tweet mit einem Linux forensics cheatsheet veröffentlicht, welches Hinweise auf eine Kompromittierung auflistet. Und dieser Tweet verlinkt auf eine Webseite Apache Log4j Vulnerability Guidance der CISA.

VMware und das zähe Patchen

Der Hersteller VMware ist mit seinen Produkten von der Log4Shell-Schwachstelle betroffen (siehe auch Angriffe auf VMWare Horizon-Server mit log4j-Schwachstelle). Blog-Leser Der Eine hat Ende Januar 2021 mit folgendem Kommentar darauf hingewiesen, dass VMware wohl langsam Updates bereitstellt:

Guten Morgen Günter,

VMware hat es endlich geschafft Update 7.03c zu releasen.

Das Update schließt u. A. die Log4j Lücke und es behebt das völlig kaputte vCenter Appliance Backup.

Beim Lesen der Release Notes kann einem anders werden. Dort erkennt man recht gut was alles verbockt wurde.

Z.B. "The supported upgrade sequence for vSphere systems is first to upgrade vCenter Server and then ESXi. However, in certain environments with ESXi hosts of version 7.0 Update 2c and later, you need to update ESXi first to 7.0 Update 3c"

oder

"Due to the name change in the Intel i40en driver to i40enu and back to i40en, vCenter Server 7.0 Update 3c adds an upgrade precheck to make sure that ESXi hosts affected from the change are properly upgraded."

WTF?

Der Blog-Leser meinte, dass das bestimmt einen Artikel wert sei – nun ja, ich habe es hier einfach mal mit rein gepackt. Damit können VMware-Nutzer sich mittels dieser Quelle informieren.

Ähnliche Artikel:
log4j FAQ und Repository
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
Log4j-News: New Schwachstelle, Bundesfinanzhof-Webseite down, viele Firmen ungepatcht
Log4j-Sicherheits-Meldungen (28.12.2021)
Windows Defender: Fixes, Probleme und Log4j-Scanner-Fehlalarme
RCE-Schwachstelle – ähnlich wie log4j – in H2 (Java) Datenbanksystem entdeckt
Angriffe auf VMWare Horizon-Server mit log4j-Schwachstelle
Log4j in Embedded-Geräten (Connected Cars, Ladestationen etc.)


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

3 Antworten zu Log4Shell: Eine Bestandsaufnahme (Feb.2022)

  1. Singlethreaded sagt:

    Das Update für die 6.5 & 6.7 Appliance kam auch vor ein paar Tagen. Wir haben das auf der 6.7 installiert und haben bisher keine Probleme festgestellt. Auf der Appliance hatten wir zuvor den von VMware genannten Workaround ausgeführt. Siehe auch:

    https://www.vmware.com/security/advisories/VMSA-2021-0028.html

    Gruß Singlethreaded

  2. Michel Py sagt:

    VMware war ein der erste Software Hersteller der schnell sehr offen dokumentiert hat, was zu tun ist wegem Log4J2 Sicherheitsloch. Die haben sogar auf die vmware.com Homepage ganz oben seit Anfang der Krise ein Link platziert "VMware veröffentlicht Security Advisory VMSA-2021-0028 bezüglich Schwachstelle Log4j+"
    Die haben leider sehr lange "nur" ein sehr effektives Workaround für vCenter publiziert. Dieser Workaround war am Anfang ein bisschen mühsam zu implementieren (SSH aktivieren, Putty, viele Command Lines). Dann haben die ein Python Script zu verfügung gestellt, der mindestens Tippfehler vermeidet.

    Es gibt aber keine Zusammenhang zwischen Log4J und den ESX 7.0u3, 3a und 3b Probleme die VMware sich selbst gemacht hat: https://kb.vmware.com/s/article/2143832

    Hoffentlich wurde jetzt ESX 7.0u3c gut getestet…
    ESX 6.7 hat sowieso support bis am 15. Oktober 2022

  3. DerEine sagt:

    Ich habe unsere Umgebung inzwischen von 7.0.2 auf 7.0.3 U3c gehoben.
    Beim vCenter gab es keine Probleme und das Appliance-Backup funktioniert wieder.

    Bei den Hosts ist es etwas anders.
    Bei den Fujitsu PRIMERGY RX2450 M1 (sind umgelabelte Supermicro mit AMD EPYC) laufen seit dem Update die SNMP-Dienste nicht mehr und im vCenter wird regelmäßig eine Warnung zur Spannung der Hosthardware ausgeworfen.
    Die älteren PRIMERGY RX2540 M2 (Intel) hingegen laufen tadellos.

    Alles in allem laufen die Kisten aber seit 10 Tagen stabil durch.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.