[English]Die in Java ausnutzbare Log4Shell-Schwachstelle in der Log4j-Bibliothek steckt mutmaßlich in vielen Systemen bzw. Software-Paketen. Das Problem dürfte uns noch für Jahre tangieren, schätzen Experten und im deutschen Mittelstand ist das noch nicht angekommen. Auch das Department of Homeland Security (DHS) hat die Woche das Thema Log4j erneut in einer Empfehlung aufgegriffen.
Anzeige
Die Log4J-Schwachstelle
Log4j ist eine JAVA-Bibliothek, die in zahlreichen JAVA-Paketen verwendet wird. In der Bibliothek log4j wurde 2021 die Schwachstelle CVE-2021-44228 in der JNDI-Lookup-Funktion entdeckt. Die JNDI-Lookup-Funktion von log4j ermöglicht den Abruf von Variablen über das JNDI – Java Naming and Directory Interface. Ich hatte ja im Blog-Beitrag 0-day CVE-2021-44228 in Java log4j-Bibliothek tangiert zahlreiche Anbieter über die Schwachstelle, die zahlreiche Systeme betrifft, berichtet.
Am 9. Dezember 2021 wurde ein Proof of Concept (PoC) für die Remote Code Execution-Schwachstelle 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).
DHS warnt vor Log4j
Es gibt zwar seit 2021 Updates für die Schwachstelle CVE-2021-44228 und es wurden in den folgenden Wochen auch (erfolgreiche) Angriffe beobachtet. Aber viele Firmen und Behörden haben die Bedrohung durch die Schwachstelle noch nicht erkannt und betroffene Anwendungen oder Geräte nicht gepatcht.
Fachleute gehen daher davon aus, dass die Schwachstelle uns noch Jahrzehnte beschäftigen könnte (siehe z.B. Log4j in Embedded-Geräten (Connected Cars, Ladestationen etc.), sowie diesen Artikel von The Register sowie diesen Artikel aus obigem Tweet). Das Department of Homeland Security (DHS) hat die Woche das Thema Log4j in einem Review der Dezember 2021-Ereignisse erneut aufgegriffen und gibt Empfehlungen – die auch in obigem Tweet und den verlinkten Artikeln am Artikelende thematisiert werden.
Auch der Sicherheitsanbieter Horizon3AI erinnert in nachfolgendem Tweet an die Log4j-Schwachstelle und die Log4Shell-Angriffe, die beobachtet wurden.
Anzeige
Nachholbedarf bei Log4J im Mittelstand
Die unter dem Namen „Log4J" bekannt gewordene Sicherheitslücke könnte in zahlreichen deutschen Unternehmen noch zu Schäden führen. Darauf deuten Ergebnisse einer Umfrage im Auftrag des Gesamtverbands der Deutschen Versicherungswirtschaft (GDV) hin.
"Nur 40 Prozent der mittelständischen Unternehmen haben nach dem Bekanntwerden der Sicherheitslücke ihre Software überprüft", sagt GDV-Hauptgeschäftsführer Jörg Asmussen. Nur 28 Prozent der repräsentativ von Forsa befragten mittelständischen Unternehmen gaben an, zusätzlich die eigenen Systeme auf bereits eingedrungene Schadsoftware untersucht zu haben.
Warnung ist in weiten Teilen des Mittelstands ungehört verhallt
"Die Unternehmen dürfen eine solche Schwachstelle und die lauten und klaren Warnungen davor nicht einfach ignorieren", sagt Asmussen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hatte nach dem Bekanntwerden der Sicherheitslücke im Dezember 2021 die höchste Alarmstufe ausgerufen und von einer „extrem kritischen Bedrohungslage" gesprochen habe. „Wer darauf nicht reagiert, ist beim Thema IT-Sicherheit zu sorglos – oder hat zu wenig Know-how", so Asmussen. Im Zweifel könnten Unternehmen auch ihren Cyber-Versicherungsschutz verlieren, wenn Hacker über eine lange bekannte, aber dennoch nicht geschlossene IT-Sicherheitslücke angreifen. Roger Scheer, Regional Vice President für den Bereich Zentraleuropa bei Tenable kommentiert dazu:
Als Log4Shell (CVE-2021-44228) vor über sechs Monaten zum ersten Mal identifiziert wurde, erschütterte es die IT-Sicherheitscommunity. Die Tatsache, dass über ein halbes Jahr später mehr als die Hälfte der deutschen Mittelständler immer noch im Dunkeln darüber ist, ob es in ihrer Software betroffen und somit ein Sicherheitsrisiko ist, ist besorgniserregend.
Das Problem ist, dass, obwohl es wirklich schwierig ist, alle Anwendungen und Diensten zu durchforsten, welche die anfällige Bibliothek nutzen, es für Kriminelle zugleich einfach ist, sie gegebenenfalls auszunutzen. Im Dezember, als die Schwachstelle erstmals identifiziert wurde, stellte die Telemetrie von Tenable fest, dass 10 % aller bewerteten Assets anfällig waren – das sind nicht 10 % der Organisationen, aber 10 % der dort eingesetzten Anwendungen und damit verbundenen Devices – einschließlich einer Vielzahl von Servern, Webanwendungen, Containern und IoT-Geräten. Jedes zehnte Element unserer digitalen Infrastruktur hatte damals das Potenzial für den Missbrauch durch Log4Shell.
Angesichts der einfachen Ausnutzbarkeit und der breiten verfügbaren Angriffsfläche werden Angreifer die Schwachstelle weiterhin nutzen, um Fuß zu fassen, um gezielte Sicherheitsverletzungen auszulösen oder opportunistische Ransomware-Angriffe zu automatisieren, es sei denn, Unternehmen gehen Log4j nun endlich proaktiv an.
Cyberkriminelle könnten auch Monate nach der Erstinfektion zuschlagen
Cyberkriminelle hatten die Log4J-Schwachstelle bereits für unterschiedliche Angriffsformen ausgenutzt. Teilweise missbrauchten sie die Rechenleistung betroffener Systeme zur Errechnung von Krypto-Währungen wie Bitcoin, integrierten die Rechner in Bot-Netze für DDoS-Angriffe oder verschlüsselten Daten, um Lösegeld zu erpressen. Darüber hinaus besteht die Gefahr, dass die Schwachstelle bereits vor einem Sicherheitsupdate für eine Erstinfektion mit Schadsoftware genutzt wurde. Dann könnten Angreifer die IT-Systeme auch nach dem Schließen der Sicherheitslücke weiter attackieren. Um solche Angriffe zu verhindern, sollten die gesicherten IT-Systeme eingehend auf etwaige Schadsoftware überprüft werden.
Hintergrund: Die Initiative CyberSicher
Mit der Initiative CyberSicher nimmt der GDV die IT-Risiken des Mittelstandes unter die Lupe und zeigt, wie sich kleine und mittlere Unternehmen schützen können. In diesem Rahmen beauftragt der GDV die Forsa Gesellschaft für Sozialforschung und statistische Analysen mbH seit 2018 mit einer repräsentativen Befragung von 300 Entscheidern oder IT-Verantwortlichen von kleinen und mittleren Unternehmen. Die aktuellen Interviews fanden zwischen dem 16. März und dem 25. April 2022 statt.
Ä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
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.)
2015
Der Stand wundert mich ehrlich gesagt nicht.
Wir haben mehrere Tage gebraucht, um wirklich alle Systeme zu prüfen und dabei auch diverse Applikationen zum ersten Mal katalogisiert. Man sollte jedes einzelne, eingesetzte Programm kennen. Aber wer tut das schon, wenn Hinz und Kunz Aufträge für Installationen erhält.
Und eins wurde für mich erneut offensichtlich:
Die meisten Software- oder Consulting-Firmen dokumentieren nicht, was alles in ihren Installationen steckt. Und interessieren sich auch nicht für ihre Installationen, wenn der Auftrag erledigt ist. Nicht mal mit Pflegeauftrag.
Die mussten wir, teils mit Nachweis der Verwundbarkeit, zum Jagen tragen.
Der Großteil der kleinen und mittelständischen Unternehmen hat aber gar nicht das Personal für sowas. Und wenn, dann hat das eigentlich nie den Auftrag, den Installationen der Dienstleister auf den Zahn zu fühlen.
Es herrscht der große Vertragsglaube. Von Datenschutz über Sicherheit bis Compliance: Ein Vertrag, Haken dran und Thema ist gefälligst erledigt. Und dann hat da auch keiner mehr was zu sagen.
Davon kann ich ein Lied singen. Nicht nur wegen log4j. Dienstleister zum Thema angeschrieben. Erste Reaktion war eine Aufforderung zur Rechtfertigung an mich, was das soll. Ich solle mich doch nicht in deren Tanzbereich begeben. Nein, nicht vom Dienstleister. Vom Chef.
Das gab sich dann, als die Fakten (verwundbar) und die abwimmelnde Antwort (nicht verwundbar) von mir dokumentiert waren.
Das kann sehr eklig.werden, wenn man als interner Admin da nicht sehr standfest und nachweisfreudig ist.
Denn IT-Dienstleister versuchen gerne, die internen Admins zu diskreditieren und das auch außerhalb der Sachebene, so beim Managerplausch. Insbesondere, wenn sie in der Kritik stehen, kann das auch auf Existenzvernichtung ausgelegt sein.
Habe ich zweimal in hoher Intensität erlebt, wobei die eine Firma "nebenan" ihre eigenen Fehler durch eine so harte Kampagne gekontert hat, dass zum Schluss fast die ganze Abteilung gegangen war und die Firma einen Großauftrag an allen Regeln vorbei bekam.
Bei uns scheiterte das nur knapp, unser Track-Record sorgte für recht festen Stand. Aber, hängt auch vom Management ab.
Als interner Admin wirst du von vielen Dienstleistern gegenüber deinem Arbeitgeber als der dargestellt, der nicht gut genug für z.B. diese Dienstleister gewesen wäre. Und wenn du ein Störfaktor für die Erlangung von Aufträgen bist, dann musst du weg.
Wir sind schließlich das Land des Expertenglaubens, in dem sich jemand "Experte" nennt, dann irgendwelchen Unsinn erzählt und die Leute glauben das und schicken die mit dem realem Wissen und Erfahrung dann allzu gerne in die Wüste.
In diesem Umfeld bewegen sich auch viele Kleinunternehmen und Mittelstand und werden entsprechend immer wieder an ihrer eigenen Vertrags- und Expertengläubigkeit scheitern. Und dann massig Geld in die Hand nehmen, um alles zu retten und dann so tun, als wäre das eine erfolgreiche Transformation gewesen.
Ich bitte meinen Glaubensverlust zu entschuldigen, aber die tägliche IT "da draußen" wird zunehmend zur Bullshit-Bingo-Party auf Ballermann-Niveau. Der man sich übrigens nur entziehen kann, wenn man jenseits aller Zweifel den Nachweis über all das führen kann, was Pseudo-Experten und Marketing-Abteilungen nur zu behaupten brauchen.
Das ist unproduktiv, nervend und in Belangen der Sicherheit halt auch brandgefährlich.
Das Thema ist leider eine ziemlich lange Story geworden, weil die ersten Patches für Log4j immer wieder nachgebessert wurden. Vielen Produkte mussten also mehrfach gepatched werden und am Anfang war auch nicht ganz klar welche Software eigentlich genau betroffen ist. Dazu kamen z.B. bei VMware diverese Workarounds, welche das Problem erstmal umgangen, aber nicht gelöst haben.
Ich glaube gerne, dass dort einige den Überblick verloren haben, bzw. nach der ersten Runde an Updates davon ausgegangen sind, dass das Thema damit erledigt sei.
Gruß Singlethreaded
naja, da ist dann "learning auf die harte Tour" angesagt. Die Leute brauchen das und wenn dabei ein Klein-/Mittelstandsunternehmen (oder auch Großunternehmen) deswegen hops geht, sorry dann ist das kein Verlust! Lieber so als das Kunden die geschädigten sind! Wer Sicherheit nicht ernst nimmt, verdient genau das was ihm da dann passiert.
Keiner behauptet das es einfach ist, aber da zu schlampen ist nicht akzeptabel.
Wer nicht hören will muss eben fühlen!
Hi,
@Andy, uns in unserer IT-Abteilung gehts genau so.
Da muss der kleine Admin sich mit Geschäftsführern anlegen….
Und wir waren der Meinung, wir sind alleine mit diesem Problem.
Beste Grüße
Michael und Co
"Fachleute gehen daher davon aus, dass die Schwachstelle uns noch Jahrzehnte beschäftigen könnte (siehe z.B. Log4j in Embedded-Geräten (Connected Cars, Ladestationen etc.), …"
Das mag zwar sein, ich sehe gerade bei Embedded-Geräten allerdings kein extrem grosses Schadenpotenzial. Einerseits sind diese üblicherweise proprietär, andererseits ist der mögliche Nutzen eines Hackerangriffs eingeschränkt – die allfällige Verwendung als Bot für DDOS-Attacken einmal ausgenommen.
@Andy: Den Aussagen kann ich vollständig beipflichten.
Von meiner Position aus stehe ich irgendwo dazwischen; Unsere Firma ist zwar Dienstleister für die Systeme der Kunden, die meiste Software (insbesondere Branchenlösungen) werden aber von externen Dienstleistern installiert und gewartet. Weder weiss, ich was in deren Software enthalten ist, noch habe ich die Kompetenz oder Verantwortung, denen auf die Finger zu schauen bzw. etwas zu kritisieren, solange die Software läuft.
@Luzifer: Das Ernst nehmen von Sicherheit ist zwar sehr wichtig, es reicht aber eben oft nicht. Insbesondere dann nicht, wenn die Kenntnisse einer Person in dem Bereich nur rudimentär (oder gar nicht) vorhanden sind.