Log4j-Sicherheits-Meldungen (28.12.2021)

Sicherheit (Pexels, allgemeine Nutzung)[English]Es sieht so aus, als ob die große Welle an Hacks über die log4j-Schwachstelle über Weihnachten ausgeblieben ist. Aber es gibt Fälle, wie beim belgischen Verteidigungsministerium, die über log4j angegriffen wurden. Die Angriffe werden aber möglichweise im Januar 2022 folgen. Microsoft hat für den Defender 365 eine Statusanzeige erstellt, die die angreifbaren Geräte in einem Netzwerk auflistet. Hier ein kurzer Überblick über die Informationslage zum 28.12.2021.


Anzeige

Microsoft listet log4j-Gefährdung auf

Microsoft hat gerade ein neues konsolidiertes Log4j-Dashboard für das Bedrohungs- und Schwachstellenmanagement im Microsoft 365 Defender-Portal eingeführt. Dieses soll Kunden bei der Identifizierung und Behebung von Dateien, Software und Geräten unterstützen, die von den Log4j-Schwachstellen betroffen sind.

Microsoft Log4j-Dashboard

Zusätzlich zu Windows und Windows Server werden diese Bedrohungs- und Schwachstellenfunktionen auch unter Linux unterstützt, erfordern jedoch ein Update des Microsoft Defender for Endpoint Linux-Client auf Version 101.52.57 (30.121092.15257.0) oder höher.  Inzwischen entdeckt der Microsoft Defender for Containers Images, die von der Log4j-Schwachstelle betroffen sind. Wie Defender for Containers, Bedrohungs- und Schwachstellenmanagement und andere Microsoft-Sicherheitslösungen vor damit verbundenen Bedrohungen schützen, hat Microsoft im Beitrag Guidance for preventing, detecting, and hunting for exploitation of the Log4j 2 vulnerability zusammen getragen.

CISA veröffentlicht log4j-Scanner

Das US-CISA hat auf Github einen Scanner für die Log4j-Schwachstelle veröffentlicht. Das Repository bietet eine Scan-Lösung für die log4j-Remote-Code-Execution-Schwachstellen (CVE-2021-44228 & CVE-2021-45046). Die Informationen und der Code in diesem Repository werden auf Basis As-Is mit Hilfe der Open-Source-Community zusammengestellt und von CISA in Zusammenarbeit mit der breiteren Cybersicherheits-Community aktualisiert. Es handelt sich hierbei nicht um eine 100%ig positive Lösung; es können auch falsch negative Ergebnisse auftreten.

Belgisches Verteidigungsministerium log4j-Opfer

Im Blog-Beitrag Log4j-Infos, belgisches Verteidigungsministerium betroffen? hatte ich am 20. Dezember 2021 darüber berichtet, dass das belgische Verteidigungsministerium hat seine Netzwerke nach einem schweren Cyberangriff wohl abgeschaltet habe. Es wurde ein Zusammenhang mit der log4j-Schwachstelle CVE-2021-44228 vermutet.

Jetzt hat das belgische Verteidigungsministerium laut diesem Bericht von The Register wohl eingestanden. Der  Sprecher des belgischen Verteidigungsministeriums, Olivier Severin, sagte in einer vorbereiteten Erklärung, die The Register vorliegt:

Das Verteidigungsministerium hat am Donnerstag einen Angriff auf sein Computernetzwerk mit Internetzugang entdeckt. Es wurden schnell Quarantänemaßnahmen ergriffen, um die betroffenen Teile zu isolieren. Die Priorität liegt darin, das Verteidigungsnetz betriebsbereit zu halten.

Dieser Angriff folgt auf die Ausnutzung der Log4j-Schwachstelle, die letzte Woche bekannt wurde und für die IT-Spezialisten in aller Welt in die Bresche springen.

Also (neben dem Bundesfinanzhof, siehe Links am Artikelende) das nächste bestätigte prominente Opfer der Schwachstelle log4j.

Weitere Erkenntnisse und Infos zu log4j

Von Sicherheitsanbietern sind mir weitere Informationen rund um die log4j-Schwachstelle zugegangen. Der Anbieter Check Point hat mir Mitte Dezember 2021 beispielsweise bereits folgende Zahlen über Angriffe für Deutschland zukommen lassen.


Anzeige

  • In Deutschland wurden 45 Prozent aller von Check Point erfassten Firmen-Netzwerke attackiert.
  • In Österreich beläuft sich die Zahl auf 46 Prozent, in der Schweiz auf 40 Prozent.
  • Weltweit liegt der Schnitt bei 40 Prozent. In Europa bei 42,2 Prozent.
  • Einmal registrieren die Sicherheitsforscher sogar 100 Attacken in der Minute.
  • Mittlerweile hat Check Point rund 846 000 Angriffe registriert, 72 Stunden nach der ersten Attacke.
  • 46 Prozent der Attacken gingen von bekannten Hacker-Gruppen aus.
  • Nach 72 Stunden gab es bereits über 60 neue Varianten der Attacke.

Check Point hat die wichtigsten Erkenntnisse in diesem Beitrag veröffentlicht und das Ganze zum 20.12.2021 nochmals aktualisiert. Sicherheitsanbieter Tenable hat mir am 23.12.2021 eine Mitteilung geschickt, dass 30 Prozent der Unternehmen noch keine Vorkehrungen gegen Log4j-Angriffe unternommen haben. Amit Yoran erklärt dazu:

Den Telemetriedaten von Tenable zufolge haben bis zum 21. Dezember 2021 nur 70 Prozent der Unternehmen überhaupt nach der Schwachstelle gescannt! Von den untersuchten Assets wurde Log4Shell in etwa zehn Prozent gefunden, darunter eine Vielzahl von Servern, Webanwendungen, Containern und IoT-Geräten. Log4Shell ist in allen Branchen und Regionen weit verbreitet.

Ich bin besorgt, dass sich die Geschichte wiederholt, aber dieses Mal könnte der Schaden unkontrollierbar sein. Während vor Jahren EternalBlue weitreichende Angriffe wie WannaCry verursachte, ist das Potenzial hier viel größer, weil Log4j sowohl in der Infrastruktur als auch in Anwendungen weit verbreitet ist. Keine einzige Schwachstelle in der Geschichte hat so eklatant nach Abhilfe gerufen.

Log4Shell wurde als eines der größten Cybersicherheitsrisiken identifiziert, die wir je gesehen haben, aber viele Unternehmen ergreifen immer noch keine ausreichenden Maßnahmen. Unseren Daten zufolge haben 30 Prozent der Unternehmen noch nicht einmal damit begonnen, ihre Umgebungen auf Log4Shell zu überprüfen, geschweige denn mit dem Patchen.

Log4Shell wird die Datenverarbeitung, wie wir sie kennen, neu definieren. Es wird diejenigen, die sich die Mühe machen, sich zu schützen, von denjenigen trennen, die es sich bequem machen, nachlässig zu sein."

Der Anbieter OTORIO hat folgende Hinweise zur Behandlung der Sicherheitsschwachstelle für Netzwerke zusammen gestellt:

  1. Schnelle Härtung – Blockieren Sie IOCs (Indication of Compromise) in Perimeter-Lösungen wie Firewalls, IDS, IPS, WAFs usw.). Ein Beispiel für Microsofts IoC-Liste finden Sie hier. Es ist wichtig, sicherzustellen, dass Ihre WAFs automatisch aktualisiert und mit Log4j-Erkennungs- und Präventions-Updates geladen werden (dies garantiert keine Exploit-Prävention, da sie auf Verhalten und Signaturen basiert).

2. Identifizierung

a. Verringern Sie Ihre globale Angriffsfläche durch Scannen mit einem Tool wie ReconOT von OTORIO, das automatisch und passiv OT-IoT-IT-Aufklärung betreibt, um Assets zu entdecken, sobald sie von einem potenziellen Angreifer entdeckt werden. Kürzlich hat OTORIO ReconOT mit der nicht-invasiven Fähigkeit ausgestattet, Anwendungen zu erkennen, die für Log4j anfällig sein könnten.

b. Verwenden Sie Ihr Asset-/Softwareinventar, um bekannte Anwendungen zu identifizieren, die als anfällig für Log4j veröffentlicht wurden. Es wird empfohlen, https://github.com/cisagov/log4j-affected-db#software-list zu folgen, da es eine gepflegte Liste anfälliger Software enthält. Die Technologie von OTORIO (sowohl RAM2 als auch spOT) kann Sie bei diesem Prozess optimal unterstützen.

c. Scannen Sie Pakete. Tools, wie das von CERTCC (veröffentlicht von cisa), könnten ebenfalls nützlich sein, sowohl für Linux als auch für Windows, wenn es kein anderes SBOM-Tool gibt.

3. Entschärfung und Patching – Aktualisierung auf die neueste Log4j-Version (https://logging.apache.org/log4j/2.x/download.html). Wenn ein Patching nicht möglich ist, isolieren Sie das betroffene System so weit wie möglich. Wenn es sich um OT-Anlagen handelt, vergewissern Sie sich, dass die oben genannten Schritte mit dem Hersteller des Systems abgestimmt sind.

  1. Überwachung
  1. Erkennung von Ausbeutungsversuchen auf Linux-Hosts durch Durchsuchen der log4j jndi-Protokolle: sudo egrep -i -r '\$\ jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log/
  2. Snort-Regeln für IDS/IPS-Systeme – https://rules.emergingthreatspro.com/open/
  3. Suchen und Blockieren von IOCs bekannter Angreifer, die Systeme in freier Wildbahn ausnutzen:

https://s3.amazonaws.com/talos-intelligence-site/production/document_files/files/000/095/702/original/IOCs_20211217.txt?1639778427

https://s3.amazonaws.com/talos-intelligence-site/production/document_files/files/000/095/701/original/IOCs_20211216.txt?1639690764

https://s3.amazonaws.com/talos-intelligence-site/production/document_files/files/000/095/700/original/Dec1521IOCs.txt?1639683730

  1. Wenn Sie EDR auf DMZ-Systemen einsetzen, überwachen Sie diese auf verdächtige curl-, wget- oder ähnliche Befehle.

Darüber hinaus wird Unternehmen dringend empfohlen, die Apache Log4j Security Vulnerabilities- Webseite auf Aktualisierungen und Hinweise zur Schadensbegrenzung zu überprüfen und eng mit ihren Providern und Lieferanten zusammenzuarbeiten, um alle Aktualisierungen auf den betroffenen Systemen zu überwachen.

Ä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
log4j FAQ und Repository
Log4j-News: New Schwachstelle, Bundesfinanzhof-Webseite down, viele Firmen ungepatcht


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

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

6 Antworten zu Log4j-Sicherheits-Meldungen (28.12.2021)

  1. Klaus451f sagt:

    was ich nicht ganz verstehe: Betrifft es nur Server-BS?
    Angeblich wäre das KBV-Prüfmodul zur Prüfung der Quartalsabrechnungen in Arztpraxen auch betroffen. Das Prüfmodul läuft aber nur auf Windows-Clientrechner 1x zum Quartalsende. Wo ist das Problem? Außerdem sind alle nicht benötigten Ports am Router inaktiv.

    • 1ST1 sagt:

      Log4j ist in erstaunlich vielen Anwendungen enthalten, wir haben verschiedene Versionen auf Clients und Servern gefunden, teils an Stellen wo wir nicht damit gerechnet haben, es ist in (Java-)Anwendungen drin, Webservern (Apache, Tomcat, XAMP, …), je nach installierten Optionen auch in IIS, MS-SQL und Exchange (dort aber nur 1er Versionen), auch in diversen Management-Tools für die IT-Infrastruktur (Dell Compellent/EMX, Netapp, …), VMWare, Netzwerkappliances (Dell hat kurz vor Weihnachten das Open Management Enterprise – OME – aktualisiert, auf die immernoch DoS empfängliche log4j 2.16) und vieles mehr. Ich vermute auch, dass Log4j auf Netzwerkdruckern läuft, habe aber noch keine Zeit gefunden, das mal näher zu recherchieren – die Druckernetze sind zum Glück einigermaßen abgeschottet. Es lohnt sich wirklich, den Cisa-Scanner oder diverse andere Scanner für Log4j (siehe auf kitploit seit kurz vor Weihnachten) durchs eigene Netz laufen zu lassen!

      • Michael sagt:

        Die Pauschalaussage, dass der Apache Webserver, XAMP, SQL Server, Exchange betroffen sind, sind defintiv falsch. Log4j ist eine Java Anwendung für Java Applikationen. Der Apache Webserver hat mit Java perse nichts zu tun…..Log4j ist aber unter der Apache License, die leider genauso heißt wie der Webserver.

        • 1ST1 sagt:

          Na dann schau mal z.B. in C:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars

          Bei der DTS Option wird ein Log4J 1.x Jar mit installiert.

          Ob es benutzt wird, ob es angreifbar ist, ist eine andere Frage, aber es ist da, sobald du im MS-SQL DTS aktivierst.

  2. Anonymous sagt:

    Nein, es betrifft nicht nur Server Betriebssysteme. Es kann "alles" sein. Server, Client, Hardware, … – Ports sind am Router inaktiv? Ggf. reichen die, die offen sind, um die Schwachstelle bereits auszunutzen…?! Und – je nach Router – kann selbst dieser ggf. angreifbar sein, weil der Router selbst von seiner eigenen Firmware her log4j nutzt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

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.