Liste der gefährdeten Unternehmen und ihren Anwendungen: https://github.com/YfryTchsGD/Log4jAttackSurfaceWer sein iPhone mit einer entsprechenden Ziffernfolge umbenannte, konnte zeitweise in Apples iCloud-Systeme vordringen.
Nützt Dir nichts, wenn Spyware oder Ransomware schon darauf installiert, aber noch nicht aktiv ist.Frank Glencairn hat geschrieben: ↑Mo 13 Dez, 2021 12:31Nein, System Spiegeln und im Notfall zurückspielen, fertig.
Hier nochmal das Beispiel aus dem Heise-Forum:
Ihr habt einen Rechner und dieser betreibt ein Programm, das in irgendeiner weise Log4j nutzt. Das können auch Programme sein, welche ihr erst einmal gar nicht mit Apache in Verbindung bringen würdet. Z. B. ihr macht am Wochenende schöne 3D Modelle in Blender.
Euch schickt ein guter Freund oder ihr ladet herunter ein schöne 3D Modell und innerhalb dieses Modells ist einfach ein Objekt betitelt mit dem Angriffsausdruck.
In dem obigen Bild seht ihr den Ausdruck, der dazu führt, das Blender über Log4j beginnt, neue Komponenten nachzuladen.
Euer Problem ist das ihr gar nicht wisst das Blender überhaupt mit Log4j arbeitet.
Durchsucht ihr den Ordner nach "Log4j", findet ihr "nichts".
Ihr müsstet in den Code einsteigen, um die Lücke zu entdecken und das überfordert die meisten Anwender und Admins.
Doch was macht dieser Angriff überhaupt?
Im Prinzip ist es trivial, der Aufruf animiert den Logger dazu, eine andere Internet oder IP Adresse aufzurufen und von dort nachzuladen, was eben dort angeboten wird.
Es passiert also folgendes:
Das Programm "loggt", die Zeichenkette und Log4j beginnt darauf hin, die Zeichenkette anstatt zu loggen, einen entfernten Server anzutelefonieren und dessen Daten herunterzuladen.
Somit kann dann Software nachgeladen werden, die halt danach richtig viel Ärger auf den Systemen ermöglicht.
Daher ist der Angriff so kritisch. Nicht weil man den Logger umschiffen kann, sondern das man entspannt und sehr einfach! Code nachladen kann und dieser direkt ausgeführt wird.
Hab das Linux-spezifische Script laufen lassen - und gleich einen schönen Schreck bekommen:Alex T hat geschrieben: ↑Mo 13 Dez, 2021 22:57 log4j im eigenen System finden (für Fortgeschrittene):
https://forum.golem.de/kommentare/secur ... sg-6130692
ja -- mit closed source ist das natürlich immer fürchterlicher krampf, weil man weder eine ahnung hat, was sich im inneren der entsprechenen auslieferung verbirgt, noch die systemeigenen update- und schutzmechanismen greifen!:(
dort klingt's natürlich plausibel...
Bei Open Source machen sich aber dank Docker, Snap, AppImage & Co. dieselben Unsitten breit, und man kann sich auch nicht mehr sicher sein, wieviele Exemplare und Versionen ein und derselben Bibliothek auf dem eigenen System installiert sind...
edit:mash_gh4 hat geschrieben: ↑Mo 13 Dez, 2021 23:27 aber grade für die bei heise erwähnte blender-betroffenheit, hab ich bisher noch keinen greifbaren anhaltspunkt in der debian-auslieferung gefunden. es gibt dazu auch keine entsprechenden eintrag auf packages.debian.org bzw. den dortigen entwicklerinformationen...
da muss ich dir leider recht geben. ich finde diese entwicklung auch aussgesprochen bedauerlich.
das ist im grunde nichts ganz ungewöhnliches.
in dem fall betrifft das ja weniger die weitaus komplizierteren probleme, die mit solchen virtualisierungslösungen verbunden sind, und ständig unerwartet in neuer form wieder irgendwo gefunden werden, sondern wohl eher nur das drum herum, das halt leider im kommerzumfeld noch immer gerne in java abgewickelt wird.
ja, das ist denke ich ein großes Problem.
Konsole starten und folgende Befehl ausführen:Da offenbar Linux auch betroffen ist, schauts eher nach worstcase und SuperGAU aus.
Code: Alles auswählen
sudo find / -name "*log4j*"Code: Alles auswählen
dpkg -l | grep -i log4jCode: Alles auswählen
sudo apt-get purge *log4j* ich denke, dass ist höchstens ein problem für die banken, aber nicht auf deiner seite als normaler endanwender, wo du ja vermutlich nur den webbrowser für die bedienung nutzt.
nein -- linux ist natürlich in wahrheit sehr oft von solchen betroffen, weil man es halt gerne auf servern nutzt, wo derartige angriffe auf der tagesordnung stehen.Da offenbar Linux auch betroffen ist, schauts eher nach worstcase und SuperGAU aus.
das ist leider nur eine sehr unzureichende lösung, weil einerseits unbedingt auch die verschieden komprimierten archivformate danach durchsucht werden sollten, anderseits aber im falle von closed source software auch gerne obfuscation-mechanismen genutzte werden, die eine derartige erkennung der ingredienzien an hand von klartext-namen u.u. verunmöglichen.roki100 hat geschrieben: ↑Di 14 Dez, 2021 11:30 Konsole starten und folgende Befehl ausführen:Code: Alles auswählen
sudo find / -name "*log4j*"
naja -- updaten der betroffenen shared library auf >=2.15 halte ich für sinnvoller, weil danach alles in gleicher weise weiter funktionieren sollte wie davor.roki100 hat geschrieben: ↑Di 14 Dez, 2021 11:30 wird etwas mit log4j gefunden? Wenn nicht, dann ist alles gut. Falls doch:und schau nach welche Pakete das genau sind, mit:Code: Alles auswählen
dpkg -l | grep -i log4j....wird alles mit log4j deinstalliert/entfernt.Code: Alles auswählen
sudo apt-get purge *log4j*
nein, das passt schon bzw. ist ausreichend da bei Linux log4j auch so benannt werden....wie hier z.b. für Ubuntu (eigentlich bei allen Debian Derivative distros...) zu sehen: https://packages.ubuntu.com/search?keyw ... ourcenames
nein! -- die betroffenen komponenten könnten durchaus auch in einem beibigen .jar-archiv stecken -- werden also bei deiner oberflächlichen suche, die nur nach einem derartigen filenamen ausschau hält, leider nicht entdeckt!roki100 hat geschrieben: ↑Di 14 Dez, 2021 12:06nein, das passt schon bzw. ist ausreichend da bei Linux log4j auch so benannt werden....wie hier z.b. für Ubuntu zu sehen: https://packages.ubuntu.com/search?keyw ... ourcenames
ja -- darum habe ich ja weiter oben ein paar gründe angeführt, warum sich die sache in der praxis ein bisserl problematischer gestalten kann.
Das hat Dir mash_gh4 die ganze Zeit zuvor zu erklären versucht - so funktionieren nämlich jar-Dateien... (D.h. ähnlich wie Appimages und Docker-Container).roki100 hat geschrieben: ↑Di 14 Dez, 2021 12:44 Das alleinige Aktualisieren der Bibliothek über die Softwareverwaltung von Betriebssystemen reicht zur Schließung der Schwachstelle nicht aus. Die Bibliothek wird häufig von Softwareherstellern in die Auslieferungsdateien der eigenen Software direkt integriert und ist daher unabhängig von der auf dem Betriebssystem allgemein installierten Bibliotheksversion.
https://www.heise.de/news/Roter-Alarm-L ... 92863.html"Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die am Freitag bekannt gewordene Zero-Day-Lücke in der weit verbreiteten Java-Bibliothek Log4j nachträglich hochgestuft. Es gilt nun die höchste Warnstufe Rot. Man habe beobachtet, dass die Schwachstelle ohne explizites Nachladen von Schadcode ausgenutzt werden könne, womit ein Großteil der zuvor empfohlenen Gegenmaßnahmen ins Leere läuft. Maliziöser Code könne direkt in der Abfrage enthalten seien, sodass auch Grundschutz-konforme Systeme gefährdet seien, die keine Verbindung ins Internet aufbauen können. Als akute Maßnahmen empfiehlt das BSI, nicht zwingend benötigte Systeme abzuschalten, Netzwerke zu segmentieren, um verwundbare Systeme zu isolieren und soweit wie möglich etwa durch den Einsatz von Proxies in HTTP-Headern Inhalte durch statische Werte überschreiben zu lassen."
https://www.heise.de/meinung/Kommentar- ... 94476.html"Die IT-Welt ruft "Warnstufe Rot" aus – weil offenbar der log4j-Code JNDI-Variablenexpansion vornehmen kann.
Doch was ist JNDI? Jindi al Dap ist der Name eines alten arabischen Philosophen und Mathematik-Pioniers, der für Sun/Oracle gearbeitet hat, um ein System von Directory Lookups in Java zu entwickeln. Dieses System lädt irgendwie Code aus dem Internet nach. Aber selbst, wenn man länger auf das Systemdiagramm starrt, erkennt man nicht unbedingt sofort, an welcher Stelle sich der Java CLASSPATH so erweitert, dass er das gesamte Internet umfasst [...].
Das ist so, weil in Java nichts jemals simpel ist. Java Code ist unstrukturierter trockener Staub von Codefragmenten in Klassendateien, die inert in keiner Weise miteinander interagieren. Erst mit den passenden Factories, Delegates, Generators und ClassLoaders werden sie instanziiert und zusammengesetzt. Der entstehende Haufen an Querverweisen führt dann nur zufällig irgendwann einmal tatsächlich wirksamen Code aus.
Man könnte jetzt auf die Idee kommen, eine IDE mit integrierter syntaktischer Codesuche zu verwenden, um diesen Quelltexthaufen in Form zu bringen und zu verstehen. Aber das ist vergebens: Auch mit der gesamten Codebasis und einem Index darauf kann man nicht vorhersagen, was eine gegebene Java Codebase tun wird, wenn man sie startet. Es braucht auch noch Konfigurationsdateien. Diese sind ein weiterer Haufen, Properties-Dateien, in einem vorsintflutlichen Vorläufer von YAML geschrieben: XML.
Oder jedenfalls ist das, was wir denken sollen: Mit den Properties und der Codebasis können wir endlich versuchen zu verstehen, was Java tut. Und das wäre auch beinahe so, aber JNDI ist genau angetreten, dieses Problem zu beheben: Directory Lookups!
Statt also die Anwendung und ihre Konfiguration zu paketieren und dann die Pakete in Produktion zu installieren, können wir nun mit JNDI die Konfiguration vom Netz lesen. Das heißt, die eigentlichen Konfigurationsdateien, die uns sagen, was die Anwendung tut, sind... nicht mehr da. Fortschritt!
Das stellt sicher, dass uns niemand mehr hacken kann, weil niemand den Code mehr versteht: Wichtige, zum Verständnis der Codebasis notwendige Informationen sind versteckt in einem Verzeichnisdienst, und wir wissen nicht mal welcher. Aber wir können das noch einen Schritt weiterspielen: Der Code, der den Directory Lookup vornimmt, ist auch nicht da, nur ein Bootstrap: Event and Service Provider Packages.
Dank JDNI SPI können wir also Java Classfiles von einem LDAP-Server ausliefern lassen, die angeblich ein Printer-Object generieren, wenn wir nach einem Printer fragen – dann aber stattdessen Doom installieren. Oder einen Kryptominer oder Verschlüsselungstrojaner. So geht Enterprise Security.
Der Java-Slogan ist ja "Write Once, Run Everywhere". Wir haben da viele Witze drüber gemacht, weil Java so oft gecrashed ist – die meisten Java-Anwendungen liefern inzwischen ja die gesamte Ausführungsumgebung einschließlich der JRE mit, damit überhaupt etwas funktioniert. Jetzt funktioniert endlich mal alles – und die Leute sind wieder unglücklich.
Aber im Ernst: Viele behandeln den log4j-Exploit wie einen Bug, einen Programmierfehler, eine Verletzung einer Spezifikation. Genau das ist jedoch nicht der Fall: Es funktioniert – wortwörtlich – endlich einmal alles wie spezifiziert und dokumentiert: All die Modularität und dynamische Erweiterbarkeit von Java hat ganz wunderbar und genau wie geplant zusammengearbeitet und funktioniert. Darauf haben wir dekadenlang hingearbeitet!"
ja, habe ich auch erst später erfahren. Das ist in der tat ein großes Problem!cantsin hat geschrieben: ↑Di 14 Dez, 2021 18:43Das hat Dir mash_gh4 die ganze Zeit zuvor zu erklären versucht - so funktionieren nämlich jar-Dateien... (D.h. ähnlich wie Appimages und Docker-Container).roki100 hat geschrieben: ↑Di 14 Dez, 2021 12:44 Das alleinige Aktualisieren der Bibliothek über die Softwareverwaltung von Betriebssystemen reicht zur Schließung der Schwachstelle nicht aus. Die Bibliothek wird häufig von Softwareherstellern in die Auslieferungsdateien der eigenen Software direkt integriert und ist daher unabhängig von der auf dem Betriebssystem allgemein installierten Bibliotheksversion.
dem kommentar kann ich wirklich einiges abgewinnen, da ist viel wahres dran! :)
Ich kann mich ja noch daran erinnern, wie man in den 90er Jahren Java für prinzipiell und konstruktionsbedingt sicher hielt, weil sein Code in einer virtuellen Maschine ("abgekapselt vom Betriebssystem") lief...mash_gh4 hat geschrieben: ↑Di 14 Dez, 2021 19:48 und irgendwie hat man ja bei der ganzen geschichte das gefühl, als würde man da mit einem historischen vermächtnis aus dem sun-umfeld konfrontiert, dass in anderen bereichen längst so weit zurückgedrängt wurde, dass man oft gar nicht mehr daran denkt, während es im trägen enterprise-umfeld offenbar bis heute den ton angibt od. zumindest nicht wegzudenken ist...
ja -- aber dieser apkapselung durch die JVM war nur ein teil des sichheitskonzepts, ganz viel ist damals noch in ählicher weise wie bei NFS/NIS/rlogin u.ä. über die netz- bzw. domainzugehörigkeit des gegenübers geregelt worden.
