[English]Die log4j-Schwachstelle CVE-2021-44228 verursacht immer neue Schockwellen. Neueste Berichte besagen, dass ein Großteil der Firmen die Schwachstelle in ihrer Software nicht gepatcht hat. Die Webseite des Bundesfinanzhofs ist wegen eines log4j-Angriffs gerade offline genommen worden. Zudem ist eine neue DoS-Schwachstelle in der Bibliothek gefunden worden, gegen die es noch keinen Patch gibt. Derweil laufen die Angriffe zu immer neuen Höchstständen. Hier ein Überblick zum Wochenabschluss.
Anzeige
100.000 blockierte Angriffe/Minute
Für die Welt der Cyberkriminellen ist die log4j-Schwachstelle CVE-2021-44228 ein gefundenes Fressen. Binnen weniger Stunden wurden die Exploits zur Infektion von verwundbaren Systemen eingesetzt. Gemäß folgendem Tweet haben die Scans am 16. Dezember 2021 neue Höchststände erreicht. Es wurden über 100.000 Lock4Shell-Angriffe pro Minute blockiert.
Von CheckPoint habe ich aktuelle Zahlen über Angriffe bekommen. In weniger als einer Woche hat Check Point mehr als 1,8 Millionen Versuche verzeichnet, die Log4J-Schwachstelle auszunutzen.
- In Deutschland wurden mittlerweile 53 Prozent aller von Check Point erfassten Firmen-Netzwerke attackiert.
- In Österreich beläuft sich die Zahl schon auf 57 Prozent, in der Schweiz auf 47 Prozent.
- Weltweit liegt der Schnitt jetzt bei 46 Prozent, in Europa bei 51.
- Händler und Systemintegratoren sind mit 59 Prozent weltweit am stärksten betroffen.
Gemäß diesem Tweet, der auf einen Juniper-Blog-Beitrag verweist, ändern die Angreifer ihre Strategie. Statt log4j-Angriffe per LDAP (Lightweight Directory Access Protocol) durchzuführen, versuchen Sie Angriffe über RMI (Remote Method Invocation). RMI ist ein Mechanismus, der es einem Objekt, das sich in einer Java Virtual Machine (JVM) befindet, ermöglicht, auf ein Objekt zuzugreifen, das auf einer anderen JVM läuft, oder es aufzurufen.
Anzeige
Keine log4j-Patches in vielen Firmen
Obwohl die Schwachstelle bereits seit einer Woche bekannt ist, haben viele größere Firmen es noch nicht geschafft, ihre Software mit Patches zum Schließen der log4j-Schwachstelle zu schützen. Das geht aus diesem Reuters-Artikel hervor, auf den folgender Tweet hinweist.
Cisco Systems, IBM, VMware und Splunk gehörten zu den Unternehmen, die am Donnerstag mehrere fehlerhafte Softwareprodukte im Einsatz hatten, für die keine Patches für die Log4j-Schwachstelle verfügbar waren, wie eine von der US-Behörde für Cybersicherheit und Infrastruktursicherheit veröffentlichte Übersicht zeigt. Kevin Beaumont, Analyst für Sicherheitsbedrohungen, der für die CISA an der Erstellung der Liste mitwirkte, sagt dazu:
Viele Anbieter haben keine Sicherheits-Patches für diese Schwachstelle. Software-Anbieter müssen bessere und öffentlich zugängliche Verzeichnisse über die Nutzung von Open-Source-Software führen, damit es einfacher ist, das Risiko einzuschätzen – sowohl für sie selbst als auch für ihre Kunden.
Mit Stand vom Donnerstag enthielt die CISA-Liste etwa 20 Cisco-Produkte, die ohne einen verfügbaren Patch angreifbar sind. Darunter befinden sich Cisco WebEx Meetings Server und Cisco Umbrella, ein Cloud-Sicherheitsprodukt.
Bei VMware werden die Sicherheitshinweise ständig aktualisiert, es gibt Dutzende betroffene Produkte. Hat mit log4j zwar nichts zu tun, aber wer VMware Workspace ONE UEM einsetzt, sollte sich den Sicherheitshinweis VMSA-2021-0029 vom 16.12.2021 ansehen. Dort gibt es einen SSRF-Schwachstelle CVE-2021-22054, die mit dem CVSSv3-Wert 9.1 versehen ist. Angreifer können ohne Authentifizierung sensitive Informationen abgreifen (siehe auch).
Webseite des Bundesfinanzhofs offline
Ein log4j-Angriff auf den Webauftritt des Bundesfinanzhofs hat dazu geführt, dass die Webseite heute offline gegangen ist. Das berichtet heise in diesem Beitrag, auf den dieser Tweet verweist.
Der Angriff sei erfolgreich abgewehrt und gestoppt worden. Das interne Intranet noch Daten aus Steuerverfahren seien betroffen, heißt es.
CISA-Anleitung zur Analyse
Von der US Sicherheitsbehörde CISA gibt es diese Anleitung für Firmen und Behörden, wie bei der Analyse der log4j-Schwachstelle CVE-2021-44228 umzugehen sei. Will Dormann weist in nachfolgendem Tweet auf dieses Dokument hin.
Abhilfemaßnahmen wurden auch hier von CheckPoint beschrieben. Mittlerweile greifen auch staatliche Akteure verwundbare Systeme an. Cyberkriminelle versuchen Ransomware oder Cryptominer in die Systeme einzuschleusen.
Sicherheitsanbieter Vectra sieht in Sicherheitslücken wie Log4j einen weiteren drastischer Beleg, dass Prävention und Patches nicht ausreichen. Andreas Riepen von Vectra argumentiert:
- Es ist unmöglich, alles mit Dringlichkeit zu patchen: Die Angriffsfläche ist sehr groß. Das betroffene Modul von Log4j wird von einer Vielzahl von Software und Produkten verwendet. Es ist schon schwierig, herauszufinden, wo es verwendet wird! Ganz zu schweigen von dem Versuch, es zu patchen. Außerdem sind Unternehmen von den Herstellern abhängig, die ihnen Patches für ihre Produkte zur Verfügung stellen. Bei einigen werden sie sehr lange warten müssen und wahrscheinlich nie 100 Prozent erreichen.
- 2. EDR (Endpoint Detection & Response) kann weder den ersten Exploit stoppen, noch kann es eine vollständige Abdeckung bieten: Alle EDR-Anbieter sprechen davon, nach dem Download oder dem Verhalten nach der Ausnutzung zu suchen. Außerdem betrifft dies eine Vielzahl von Tools und Produkten, auf denen kein EDR installiert werden kann – Router, Switches, Sicherheitsprodukte, Linux-Server etc.
- 3. SIEM () ist nicht geeignet, um danach zu suchen: Es ist nicht garantiert, dass jede Anwendung die Felder protokolliert, in denen der Exploit-String zu sehen ist. Außerdem gelangen nicht alle Protokolle von jeder Anwendung in das SIEM. Man kann nicht suchen, was man nicht sehen kann.
- 4. Schnelle Entwicklung: Der Angriff entwickelt sich schnell weiter. Angreifer werden dies auf vielerlei Weise nutzen. Es gibt bereits Versuche der Verschleierung, die an grundlegenden Signaturen vorbeigehen, um nach dem Exploit-String zu suchen.
Riepen rät Unternehmen daher: „Gehen Sie davon aus, dass Systeme kompromittiert sind, und seien Sie darauf vorbereitet, den Angriff in Echtzeit zu erkennen und darauf zu reagieren. Schließen Sie die EDR-Lücke und überwachen Sie zuverlässig jede Verbindung vom Netzwerk zur Cloud. Recall- und Stream-Daten können dabei helfen, jeden Versuch, dies auszunutzen, schnell zu erkennen. Moderne KI-Modelle für Cybersicherheit sind so konzipiert, dass sie die Methoden erkennen, die Angreifer nach einer Kompromittierung anwenden würden. Darüber hinaus kann ein KI-basierter Überwachungsansatz die Bedrohung durch die Ausnutzung dieser Schwachstelle am schnellsten erkennen und entschärfen. Aus den oben genannten Gründen ist dies weder mit Prävention noch mit Patching zu leisten. Für Unternehmen, die sich absichern und das Risiko mindern wollen, ist eine automatisierte und kontinuierliche Überwachung des Datenflusses die beste Investition, die sie tätigen können." Hier gibt es noch einen Blog-Beitrag dazu.
Täglich neue Erkenntnisse, neue Schwachstelle
Die Halbwertszeit bestehender Erkenntnisse liegt oft bei Stunden. Hieß es ursprünglich, dass ältere JAVA-Versionen der log4j nicht betroffen seien, ist das durch neue Exploit überholt. Die Kollegen von Bleeping Computer haben diesen Artikel veröffentlicht, der erklärt, warum man die log4j Version 2.15.0 nicht mehr verwenden soll und auf die log4j version 2.16.0 setzen muss.
Gerade noch auf obigen Tweet gestoßen, der eine neue Schwachstelle für log4j reklamiert, die DoS-Angriffe erlaubt. Hier ist aber unklar, ob das ausnutzbar ist. Ergänzung: Inzwischen hat apacheLog4j 2.17.0 für Java 8 und höher freigegeben.
Ä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
Anzeige
Und so sieht das log4j-Geschehen im Netzwerk da draußen bspw aus, hier mit wenig agiler Software:
Knapp 100 Produkte geprüft. Etwa 15 hart betroffen. Davon in kritischer, direkt von außen angreifbarer Position: 5. Bis jetzt aktualisiert: 10, dabei 4 direkt angreifbare Systeme. Offen: 5, Updates fehlen noch. Abgeschaltet: 1.
Unklar sind außerdem etwa 10 Systeme.
Seit letztem Samstag geht das und seitdem gab es:
3 kommunizierte Änderungen von "not vuln" zu "vuln", 2 kommunizierte Änderungen von "not vuln" zu "trotzdem ultradringendes Update", eine Änderung von "vuln" zu "vielleicht doch nicht vuln", etliche Nachfragen der Art "aber uns betrifft das doch nicht, oder?", sowie eine Nachfrage dazu, warum wir Software einsetzen, wo die Hersteller nicht wissen, was drin ist. Äh, ja. War halt nicht Ausschreibungskriterium.
Die 10 noch unklaren Systeme und die ohne Update sind nicht von Hinterhofbuden.
Bei zwei Systemen werden externe Komponenten verlangt, laufen nicht ohne. Halten sich aber nicht dafür verantwortlich, gibt keine Auskünfte.
Ein weiterer Hersteller hat die Kommunikation nach Rückfrage zu einer nicht korrekten Mitteilung eingestellt.
Die letzten beiden Punkte sind komplett vertragswidrig, aber die scheinen andere Sorgen zu haben. Faszinierend.
Es konnten genau zwei Auskünfte und Patches bis Montag Nachmittag verzeichnet werden, das war wirklich gut. Dienstag waren zwei weitere, kritische Systeme durch. Gestern war Großkampftag für Updates.
Heute haben sich wohl alle eingebunkert und hoffen, es übers Wochenende zu schaffen. Keine Antworten mehr.
Nebenher voller Betrieb und ohne Ende kritische Patche wegen anderer Sachen. Und "wir müssen aber noch bis Jahresende" dies oder jenes schnell machen.
Krankenstand gefühlt 50%, der Rest rotiert sich kaputt.
Ist aber interessant, dass mir das gerade Spaß macht.
Es amüsiert mich beinahe.
Während die meisten sonst mit den Nerven fertig sind.
Ist vielleicht doch hilfreich, keine Illusionen über das Business mehr zu pflegen.
Ich werde keine Firmennamen nennen.
Alle Zahlen ohne Gewähr, hab die Doku gerade nicht bei der Hand.
Bei uns ist die Menge an Prüfungen etwas weniger. Sind gute 40 Produkte auf der Liste. Alles was von außen erreichbar ist, ist entweder nach letztem Stand nicht betroffen oder bereits von uns gepatched. Ich rechne allerdings damit, dass der erste Fix nicht der letzte Patch gewesen sein wird.
Das größte Problem ist für uns ist die Verfügbarkeit von Patches. Es gibt zwar zum Beispiel von VMware nette Advisories, aber häufig kein Update.
https://www.vmware.com/security/advisories/VMSA-2021-0028.html
"Patch pending" heißt es dann so schön. Alternativ gibt es dann seitenweise Workarounds, welche auch nicht immer ganz trivial in der Umsetzung sind. Und VMware lässt sich auch gerne reichlich Zeit, was die folgende Lücke in vCenter Server demonstriert:
https://www.vmware.com/security/advisories/VMSA-2021-0025.html
Hier arbeitet man seit einem Monat an einem Update. Auch hier gibt es natürlich wieder tolle Workarounds.
Sehr unterschiedlich waren auch unsere Erfahrungen was den Umgang der Hersteller mit dem Thema anging. Während z.B. die Störungsstelle der Telekom zur Verwundbarkeit der NetPhone Telefonanlage innerhalb von 20 Minuten eine Auskunft über die Technik erteilen konnte, hat uns Mobotix (wir verwenden Kameras) erstmal kalt abgewimmelt, da unser Vertriebspartner zuständig sei. Bei einer Lücke dieser Schwere ist das ein sehr unglückliches Vorgehen. Inzwischen gibt es aber auch dort ein offizielles Statement:
https://www.mobotix.com/de/keine-bedrohung-durch-log4j-fuer-alle-mobotix-produkte
Es bleibt auf jeden Fall spannend und so warten drei Produkte unser Liste noch auf „Zuwendung" durch die IT. Diese wollen wir Ihnen auch gerne zukommen lassen, sofern der Hersteller uns dazu befähigt. Das Päckchen "Log4J" wird wohl leider auch Weihnachten noch unterm Baum liegen.
Gruß Singlethreaded
Was hat workspace one damit zu tun? Diese andere Schwachstelle von VMware ist bereits länger als log4shell bekannt und deshalb wurde von vSphere das Update 3 komplett zurück gezogen.
Das liest sich alles sehr sehr besorgniserregend. Man muss sich hier sehr grundsätzliche Fragen stellen, was die Softwareentwicklung angeht. Nicht nur Windows ist kaputtgespielt.
Mit diesem kurzen Statement ist eigentlich alles gesagt! Dachte das Gleiche beim Lesen.
Man beachte zum Thema Bundesfinanzhof: "Der Angriff sei erfolgreich abgewehrt und gestoppt worden. Das interne Intranet noch Daten aus Steuerverfahren seien betroffen, heißt es." Schön, dass der Angriff "erfolgreich" (sollen wir uns dafür nun auch noch bedanken und froh sein…???) abgewehrt werden konnte. Was wäre mit unseren Steuerdaten ansonsten evtl. passiert, wenn nicht erfolgreich abgewehrt worden wäre? Und: Wir reden hier "nur" von Steuerdaten… So langsam geht es echt ans Eingemachte! Das Schlimme daran ist allerdings, dass das scheinbar nur einen sehr kleinen Teil der maßgeblichen Entscheider und auch der Bevölkerung wirklich zu interessieren scheint. Die ganze Welt ist inzwischen zu einem kompletten "Digitalisierungs-Irrenhaus" mutiert! Keiner hat (oder besser hatte) so recht einen Plan, aber alle machen lustig mit und immer weiter – wie die Lemminge. Es brennt an allen Ecken und Enden und anstatt mal grundlegend zu löschen, gibt man noch diverse Brandbeschleuniger hinzu…
Gerade auch beim Friseur gelesen: Eine weitere neue und wohl mehr oder weniger unnötige "Errungenschaft" diesbzgl.: "In-Car-Payment" von Mercedes, in Kooperation mit zunächst "nur" Visa – Damit man(n) und auch Frau seinen/ihren Parkschein direkt aus dem Auto bezahlen kann, um auch ja keinen unnötigen Schritt zu viel durch ein dreckiges, dunkles Parkhaus tun zu müssen… Der berechtigte Fahrer wird dann "einwandfrei über biometrische Sicherheitsmerkmale identifiziert werden können". Natürlich (!) alles super-duper sicher und nicht zu missbrauchen!!!
So wird es sein…
> Der berechtigte Fahrer wird dann "einwandfrei über biometrische Sicherheitsmerkmale identifiziert werden können".
Praktisch, diese Art Identifizierung könnte man doch auch für die derzeit lt. Medien nicht besonders fälschungssicher geltenden Impfausweise einführen. Das könnte vieles erleichtern und so viel sicherer machen. Warum macht man das eigentlich nicht?
Naja, ein großer Teil der Kunden erwartet einfach auch einen möglichst hohen Digitalisierungsgrad. Sieht man alleine schon daran, dass heute kein Mensch mehr mit irgendwelchen Bestell-Zetteln aus dem Otto Katalog bestellt. Das läuft heute eben alles digital und online ab. Wenn ich heute ein neues Auto zulassen möchte, dann möchte ich auch nicht stundenlang auf der Zulassungsstelle verbringen sondern die notwendigen Schritte digital im Internet erledigen.
Das kannst du jetzt theoretisch alles selber programmieren. Da können sich zwar auch Fehler und damit Sicherheitslücken einschleichen. Von so einer Lücke bist du dann aber nur selber betroffen und nicht die "ganze Welt". Der Impact so einer Sicherheitslücke wäre damit viel kleiner und für Hacker eher uninteressant.
Aber wer programmiert schon alles selber. Im Normalfall greift man eben auf irgendwelche existierenden Frameworks oder Komponenten zurück. So wie in dem Fall auf die Log4j Komponente für das Logging. Ist eben einfacher, schneller und günstiger als alles selber zu entwickeln. Was dabei rauskommt, sehen wir. Wenn da eine Sicherheitslücke entdeckt wird, sind auf einen Schlag sehr viele Nutzer verwundbar was für Hacker natürlich sehr viel interessanter ist.
So ist eben der Lauf der Zeit. Man könnte meinen, dass man daraus lernt und wieder mehr selbst entwickelt und sich so von globalen Sicherheitslücken entkoppelt. Wird aber nicht passieren…. Wie oben erwähnt ist es einfach bequemer, schneller und günstiger, wenn man auf existierende Komponenten zurückgreift. Und das hat eben leider oftmals einen höheren Stellenwert als ein möglichst hoher Sicherheitsgrad.
Hat schon jemand Infos von DormaKaba bezüglich deren Matrix-Server bekommen? Einige benutzen entsprechend nach „Außen" durchgereicht das Mitarbeiter-Portal zum Fern-Zeitstempeln aus dem Home Office.
Ja, habe den Support angeschrieben und heute eine offizielle Stellungnahme erhalten. Dort heißt es, dass Matrix PRO/ ONE nicht betroffen ist, weil in der aktuell gepflegen Version Log4J in der Version 1.2.13 verwendet wird.
Zusätzlich gab es noch den Hinweis, dass mit Matrix das SHC Data Collector Tool mitgeliefert wird. Dort ist tatsächlich Log4j in der Version 2.12.x enthalten. Allerdings ist dieses Tool für den Betrieb wohl nicht erforderlich. Es wird empfohlen das Verzeichnis SHC DataCollector einfach zu löschen.
Leider kann ich die PDF hier nicht einbinden. Am besten einfach eine Mail an service.ead.de@dormakaba.com schreiben und nach dem Dokument "
PMM Info_dormakaba Stellungnahme log4j_Update 1.pdf" fragen.
Gruß Singlethreaded
Log4j ist ja primär erst mal für Java-Grütze gedacht. So weit, so gut. Gibt aber auch etliche Ableger für PHP und Konsorten (log4cxx, log4php, log4Net): Sind die ähnlich angreifbar?
Das BSI schweigt sich, wie üblich, wieder mal über Details aus und bläst minimale Informationshäppchen zu Buchseiten dicken Textballen auf, die sie den CVEs entnommen haben.
Log4j ist Bestandteil vom Microsoft SQL-Server, wenn man DTS (Data Transformation Service) mitinstalliert, siehe c:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars\ – dort findet man die JAR Dateien. Auch in Exchange und Visual Studio kann man darüber stolpern.