Warnstufe Rot: Schwachstelle Log4Shell führt zu extrem kritischer Bedrohungslage

Das betrifft anscheinend "nur" Apache-Server: CVE-2021-44228 aka Log4Shell Explained (blumira.com)

Kritische Zero-Day-Lücke in Log4j gefährdet zahlreiche Server und Apps | heise online

Man kann echt nur hoffen, das da kein Szenario wie im Buch "Zero Day Code", das ich neulich gelesen hab, herauskommt.

Grundsätzlich ist die Lücke ja bereits gepatched. Es ist "nur" ein Update des JDKs bzw. der Log4j-Bibliothek nötig.
Allerdings könnte natürlich sein, dass einige Betroffene gar nicht merken, dass sie betroffen sind.

Entweder, weil sie die entsprechenden Nachrichten nicht verfolgen oder weil sie keine Ahnung haben,
dass ihre Software Log4j benutzt (Abhängigkeiten in Drittanbieterbibliotheken).

Ich hoffe natürlich, dass so ignorante Menschen keine kritische Infrastruktur betreiben, aber wundern würde es mich auch nicht.

... das kommt noch oben drauf:
Schadcode soll auch direkt ausführbar sein, nicht nur durch Nachladen aus dem Netz.

Warnstufe Rot: Log4j-Zero-Day-Lücke bedroht Heimanwender und Firmen | heise online

hier noch das .pdf vom BSI

Kritische Schwachstelle in log4j veröffentlicht (CVE-2021-44228) (bund.de)

Zitat von canuck

Das betrifft anscheinend "nur" Apache-Server: CVE-2021-44228 aka Log4Shell Explained (blumira.com)

Kritische Zero-Day-Lücke in Log4j gefährdet zahlreiche Server und Apps | heise online

Man kann echt nur hoffen, das da kein Szenario wie im Buch "Zero Day Code", das ich neulich gelesen hab, herauskommt.

es geht nicht um den Apache Web Server! Der ist zwar auch von der Apache Foundation, die betreiben aber zig Projekte, darunter eben auch log4j. Theoretisch ist auch eine Standalone Java Anwendung betroffen wenn diese Bibliothek genutzt wird oder auch ein System ohne direkte WWW Anbindung. Bei mir nutzte eine Serveranwendung die Bibliothek die über Nginx nach außen kommuniziert...

JAVA wäre ja an sich schön, aber wegen vielen Kompatibilitätsproblemen habe ich schon manche Software gesehen die ihr "eigenes" JAVA mitbringt. Wenn dann der Exploitcode meinetwegen über "Bemerkungen" bei einer Online Bestellung an die Warenwirtschaft durchrutscht kann es das schon gewesen sein. Gerade diese Programme sind mir in der Vergangenheit mit eigenen JAVA Versionen aufgefallen. Die sind oft schlecht gepatcht und wenn einer kein Abo hat weil die Funktionen noch reichen gibt es oft auch keine Updates.

Bei mir waren die Bibliotheken nur in Testinstallationen, da war löschen bzw plattmachen jetzt kein Problem. Wenn aber so moderne Docker Geschichten laufen wird es mit dem schnellen Überblick schwierig - und wehe ein Teilstück hat einen schlechten Support oder wird gar nicht mehr gepflegt.

Richtig huizhaecka , der Apache bringt nicht mal log4j mit.

So ziemlich alles, was log4j nutzt ist theoretisch angreifbar. Confluence/Jira in bestimmten Konstellationen, Eigenkreationen, ..

So wirklich unkritisch ist diese Lücke also überhaupt nicht. Ich habe das Wochenende damit verbracht, die Infrastruktur der Company zu durchsuchen und konnte zumindest zwei Callbacks provizieren. Glücklicherweise keine Dienste, die public erreichbar sind.

Es werden immer mehr Berichte das zwar Einfallstore für Schadcodes geöffnet wurden aber dies nicht genutzt wurde....

Siehe hier :

https://www.n-tv.de/politik/Me…iffe-article22994589.html

Da ich zu den Leuten gehöre die teilweise richtig schlecht denken können - im Sinne von gemein - drängt sich mir der Gedanke auf : Warum das ?

Hört sich fast nach einer Art "Probelauf" an, für was auch immer.

Auch die Art der Ausführung macht mir Sorgen,das hört sich eher nach etwas durch eine ganze Gruppe Angreifer an als nach einer Einzelperson.

AndreasH: Der Fuß in der Tür ist nur Phase 1, die aktuelle Lücke wird erstmal massenhaft automatisiert genutzt um sich nachhaltigen Zugang zu Systemen zu sichern. Erst in Phase 2 werden die Leckerbissen rausgesucht und direkt angegriffen, danach der "Beifang" abgegrast. Das selbe Vorgehen war auch bei Shitrix zu beobachten, einer Lücke im Gateway von Citrix-Systemen. Dort haben die Angreifer meist aber zusätzlich Crypto-Miner installiert wodurch die Attacke schnell zu erkennen war, entsprechendes System-Monitoring vorausgesetzt.

Das eigentlich schlimme ist, dass diese Art von Funden scheinbar immer häufiger auftritt.
Ist auch nicht weiter verwunderlich. Die Komplexität der Software hat inzwischen unbeherrschbare Größenordnungen angenommen.

Und es wird ja nicht weniger. Jede neue Software baut auf einer Unmenge an Frameworks, Plugins und 3rd-Party-Bibliotheken auf.
Die wiederum sind selbst genauso aufgebaut und bauen auf fremdem Code auf. Was da teilweise an Code läuft ist bereits Jahrzehnte alt und die ursprünglichen Entwickler und Wissensträger sind bereits in Rente oder leben nicht mehr.

Dazu kommt dann noch die schlechte Angwohnheit der meisten Software-Häuser ihre Produkte eher stiefmütterlich zu konzipieren und zu testen, um eine möglichst kurze Time-To-Market zu haben. Wenn dann wieder andere Entwickler auf deren, schlecht ausgearbeiteten, kaum getesteten, Software aufbauen und irgendwann eine konzeptionelle Sicherheitslücke auffällt, dann ist halt die Kacke am dampfen.

Leider steigt die Komplexität von Software halt nicht linear mit ihrer Größe, sondern im schlimmsten Fall exponentiell. Man kann das zwar mit guter Architektur einigermaßen in den Griff bekommen, aber wie viele Entwickler bekommen schon die Zeit das Thema vorher genau zu analysieren und die beste Architektur dafür zu finden? Vorher steigt ihnen jemand aufs Dach, dass das Budget nicht für sowas ausreicht

Mal abgesehen davon, ist gute/wartbare/weitsichtige Softwareentwicklung eher eine Kunst als ein Handwerk. Das beherrschen nur wenige in Perfektion. Aber ohne ausreichend Zeit könne selbst die das nicht.

So, mein Rant ist zu Ende.

Ich gehe davon aus, dass das Thema noch viel schlimmer wird, als es sowieso schon ist.

Ben: Es ist schon recht kritisch:

- Die Lücke ist relativ leicht auszunutzen. Man muss es nur schaffen, dass eine passend geformte Zeichenkette irgendwo von Log4j geloggt wird. Da Logging von Benutzerdaten bei eigentlich allen Serverdiensten gemacht wird, ist das finden von so einer Möglichkeit recht trivial. Im einfachsten Fall nutze ich hierfür das Login-Feld für den Benutzernamen oder ich passe den UserAgent-String des Browsers beim Zugriff auf eine Webseite an, der wird auch meistens mitgeloggt.

- Die Lücke kann dazu genutzt werden um weitere Daten aus dem Internet nachzuladen und auch direkt auszuführen. D.h. da kann sich auch ein nicht so versierter "Hacker" einfach ein TightVNC von der offiziellen Homepage auf deinen Server laden lassen und ausführen und kann deinen Server dann damit bequem fernsteuern.

- Log4j ist in der Java-Welt praktisch ein Pseudo-Standard, d.h. es ist extrem weit verbreitet. D.h. es gibt auch entsprechend viele Angriffsziele.

Alles zusammen bedeutet das, dass uns diese Lücke wohl noch ziemlich lange begleiten wird. Ich gehe nicht davon aus, dass alle Betroffenen überhaupt wissen, dass sie betroffen sind bzw. das Wissen und die Fähigkeiten haben die Lücke zu stopfen, selbst wenn sie wissen, dass sie betroffen sind.

Ben:

Es ist ein Totalschaden.

Fremden Code mit Serverrechten ausführen zu können, das ist das höchste, was man sich als Angreifer wünschen kann.

Ein Skriptkiddie könnte Reihenweise Server lahmlegen oder sie für weitere DOS-Attacken oder ähnliches nutzen.

Analogie zum Atomkraftwerk: Du hast eine Telefonnummer direkt zur Schaltzentrale, und die tun alles, was du ihnen sagst, ohne nachzufragen.

Das log4j ist in verschiedenen Geschmäckern überall drin. z.B. log4net ist eine Adaption auf .net-Umgebungen, und dort ist meines Wissens bisher noch nicht geguckt, ob sich da einer das gleiche erlaubt hat, und damit hättest Du vermutlich 90% aller Anwendungen, die irgend etwas loggen, also fast alles was es überhaupt gibt.

Wie kommt so eine Lücke zu Stande?

Ich hab selber auch schon solche "Sicherheitslücken" eingebaut. Du willst für ein kleines Programm, dass eigentlich nie für Produktivzwecke gedacht ist, kurz einen eingehenden String parsen, z.B. einen JSON-String? Saubere Lösung wäre, einen Parser zu schreiben, der genau das tut, was Du willst. Bequemerweise gibt es auch eine faule Lösung: Jage den JSON-String durch einen Java-Skript-Interpreter, den Du direkt schon im System hast. Eine Zeile. Fertig. Der Interpreter verhält sich wie ein Parser, so lange im String kein ausführbarer Code ist. Da ich das Programm nur für einen ganz bestimmten Zweck geschrieben habe, ist nicht zu erwarten, dass da was anderes als ein JSON-String drin steht. --> 10 Sekunden Arbeit statt 1 Tag Arbeit.

Ich selber programmiere keine Atomkraftwerke, weil ich mir im Klaren darüber bin, dass ich nicht gut genug und akribisch genug bin, um sicheren Code zu schreiben. Bleiben also zwei Gruppen: Die die das sicher können, und die Hipster die nicht wissen, dass ihr Code Lücken wie Scheunentore enthält. Jetzt kannst Du mal tippen, welcher von beiden teurer ist, und was das für Konsequenzen für den großen Softwarehaufen da draußen hat.

Nick

Zitat von Opa

log4net ist eine Adaption auf .net-Umgebungen

so auf die schnelle fällt mir nur das ein was bei log4net schiefgehen könnte:

wenn man beim "log4net.Appender.AdoNetAppender" den CommandText ohne Parameter verwendet, könnte es schon sein über "SQL-injection" die Log-Datenbank etwas zu irritieren, aber macht man ja ned

Hallo,

Zitat von Ben

Hier ein guter Artikel der einen Überblick über die Auswirkungen gibt. Das klingt überhaupt nicht gut. Privat kann man wohl bis auf folgendes nichts tun.

Was ich überhaupt nicht verstehe ist, wie da die Behörden so "ruhig" bleiben können. Für mich klingt das nach einem IT-SHTF Szenario.

Da sollte meiner Meinung nach eigentlich klar und transparent informiert werden was getan wird und was von Firmen und Institutionen getan werden muss.

Ben, meine Behörde ist bereits aktiv geworden. Der Fachbereich hat nach deren Angaben mindestens Anpassungen in der FW unserer Behörde vorgenommen. (Mehrstufige) Dadurch sollten Schadcodes fast nicht mehr durch kommen.

Ansonsten wurden diverse Verfahren schon von den Anbietern runter gefahren.

Und meine Kollegen sollten wissen was sie machen - so hoffe ich. Die sind für alle Land NRW Server (!) zuständig. Und das sind keine x.xxx tausend.

Waidmannsheil

Zitat von Ben

Was ich überhaupt nicht verstehe ist, wie da die Behörden so "ruhig" bleiben können. Für mich klingt das nach einem IT-SHTF Szenario.

Da sollte meiner Meinung nach eigentlich klar und transparent informiert werden was getan wird und was von Firmen und Institutionen getan werden muss.

Das BSI hat die Tragweite der Situation IMHO eigentlich sehr klar kommuniziert.
Was genau zu tun ist kann letzten Endes nur der Hersteller der Software (Log4j) sagen. Die haben die entsprechende Expertise. Alle anderen raten nur.

Eine ähnliche Situation hatten wir ja vor kurzem auch mit dieser bösen Exchange-Lücke.
Da muss man eben auf einen Patch warten und diesen dann installieren. In der Zwischenzeit kann man ein paar Workarounds einrichten,
z.B. anfällige Dienste abschalten bzw. deren Zugriff einschränken. Mehr geht nicht.

wo ist denn log4j gehostet, also der code und unter welcher lizenz?

rand00m: Ist ein Apache-Projekt, Lizenz ist Apache-Lizenz 2.0, siehe https://logging.apache.org/log4j/2.x/

Das macht die Sache umso blöder, weil Apache eine gute Reputation hat. Diese Bibliothek wird unter anderem auch von VMware und Oracle verwendet, beide haben schon Meldungen herausgegeben.

Man sollte also wohl eher davon ausgehen, dass man ein System hat das Log4j verwendet als dass man keines hat. In größeren Umgebungen jedes einzelne verwundbare Exemplar zu finden und zu aktualisieren, ohne negative Seiteneffekte, dürfte eine ordentliche Herausforderung werden.

Überall. Es ist ja kein zentraler Dienst auf einem Server. Es ist eine Programmfunktion, die dazu dient, z.B. auf einer Webseite in einem Eingabefeld in einer Eingabekonsole (shell) eingetippte Zeichen einzulesen (zu loggen). Daher der mittlerweile verbreitete Name "log4shell". Genauso wird sie genuzt, um z.B. bei einer Datenbankanfrage die eingetippten Zeichen einzulesen. Dummerweise "interpretiert" die Funktion die Zeichen dabei auch gleich. Interpretieren bedeutet, in der Zeichenfolge ausführbare Programmbefehle zu finden und sofern welche drin sind, diese gleich auszuführen. Das passiert dann auf dem System, auf dem diese Loggingfunktion im Programmcode verwendet wird und mit den Rechten, die das System besitzt, nicht mit den Rechten, die der anfragende User (der die Zeichenfolge eintippt). Und das ist das fatale daran. Man kann z.B. eine Zeichenfolge eintippen, die ausgeführt bedeutet, dass das Zielsystem sich selber von einem anderen Rechner Programmcode holt und dieses Programm installiert oder ausführt. Man braucht das Zielsystem nicht zu hacken. Man schreibt lediglich in ein frei zugängliches Eingabefeld z.B. einer Eingabemaske auf einer Webseite ausführbaren Java-Code rein und den Rest erledigt das Zielsystem selber, es hackt sich selbst.

Die Log4Shell-Funktion ist Open Source. D.h. lizenzfrei nutzbar. Mehr oder weniger gewartet wurde dieses Java-Konstrukt von zwei ehrenamtlich tätigen ITlern als Hobby. Denen kann man auch keinen Vorwurf machen, das Problem sind die kommerziellen Softwareanbieter, die frei verfügbare Funktionen ohne ein umfassendes Sicherheitsaudit einfach übernehmen und in ihren Produkten einsetzen.

Die Admins von Firmen-ITs machen gerade Überstunden, um Systeme zu patchen bzw. Software, für die es keinen Patch gibt, zu deinstallieren. Dummerweise sind das oft nützlliche Tools z.B. zur zentralen Wartung von Servern, um nicht persönlich vor jedem einzelnen von dutzenden oder hunderten von Servern sitzen zu müssen, um Updates und Konfigurationen durchzuführen. Hier ein Auszug der Maßnahmen unserer Firmen-IT von gestern:

"Bisher erkannte Softwarepakte mit Sicherheitslücke:
Jitsi auf dem meeting.xxx.de, extern erreichbar, gepatcht

Backup-Software von Dell-EMC, nur intern erreichbar, Patch in Arbeit

Verwaltungssoftware für Unifi-Accesspoints (WLAN), nur intern erreichbar, gepatcht

Verwaltungssoftware für Dell-Server, nur intern erreichbar, auf allen Servern deinstalliert"

Immerhin können aktuelle Virenscanner Angriffe über diese Lücke detektieren:

"Windows-PCs mit installierter Kaspersky-Software sollten zusätzlich Log4Shell-Angriffe erkennen und blockieren, und zwar unter folgender Kennung:
UMIDS:Intrusion.Generic.CVE-2021-44228.
PDM:Exploit.Win32.Generic"

Irgendwie habe ich bei Log4Shell ein Déja Vu Gefühl. Es erinnert mich fatal an das Auslöse-Szenario in Marc Elsbergs "Blackout"-Roman. Man stelle sich vor, landesweit sind SmartMeter in den Verteilerschränken sämtlicher Haushalte drin und sie haben alle diese Log4Shell-Schwachstelle. Über die Fernabfragefunktion kann man nun die SmartMeters dazubringen, z.B. den Haushalt vom Netz zu nehmen oder steuerbare Verbraucher wie Nachtspeicherheizungen, Wallboxen oder Luftwärmepumpen überall gleichzeitig auf Volllast zu schalten...

Grüsse

Tom