Mögliche Auswirkungen der log4j-Sicherheitslücke?

[mahatma]

Weis jemand genaueres über mögliche Auswirkungen dieser log4j Sicherheitslücke für die Kryptowelt?

https://www.spiegel.de/netzwelt/web/log4j-sicherheitsluecke-wie-loescht-man-ein-brennendes-internet-a-27729847-8e28-4187-b4a2-468a45137fb4

In wieweit sind/könnten Börsen u.ä. betroffen sein? Gibts irgendwelche (Vorsichts)massnahmen sie man treffen könnte/sollte?

Hab keine Ahnung von IT, der Spiegel Artikel liest sich ja so als wär das recht ernst, und es könnten praktisch sämtliche Server auf denen Java-Skript ausgeführt wird gekapert oder kompromittiert werden...

[Jokin]

vor 13 Minuten schrieb mahatma:

In wieweit sind/könnten Börsen u.ä. betroffen sein?

Wären sie betroffen, dann wären sie jetzt nicht mehr betroffen.

Entweder gehackt oder gefixt.

 

[¯\_(ツ)_/¯]

42 minutes ago, mahatma said:

Java-Skript

Es geht um Java, nicht JavaScript. Und wenn ein bestimmte (log4j2) Library eingesetzt wird. Glücklicherweise ist die Sicherheitslücke relativ einfach zu beheben. Was nicht heißt, dass es auch überall gemacht wird. Bei größeren Firmen, kann der Entwickler eben nicht mal eben sich auf nen Server einloggen, was ändern und alles ist gut. Da sind oft komplexe Prozesse im Spiel, wo sich das dann seeeehr ziehen kann.

Das ganz ist ernst, weil es so unfassbar einfach ist, es auszunutzen und es eben keine Komplexen Exploit benötigt. 

[skunk]

Das Problem ist auch weniger die Börse an sich. Die Entwickler werden die Kritischen Prozesse als erstes auf dem Schirm haben und diese Patchen. Problematisch werden dann die Prozesse an die keiner denkt. Nehmen wir einfach mal den nächtlichen Backup Job. Der wird in solchen Situationen schnell mal vergessen und schon hat der Angreifer einen Zugang zum Server über den er dann weiteren Schaden anrichten kann. Es ist teilweise überraschend über welchen Prozess der Angreifer Zugriff bekommt.

[Rikki77]

vor einer Stunde schrieb mahatma:

Hab keine Ahnung von IT, der Spiegel Artikel liest sich ja so als wär das recht ernst, und es könnten praktisch sämtliche Server auf denen Java-Skript ausgeführt wird gekapert oder kompromittiert werden...

Ich habe schon recht viel Ahnung von vielen Dingen im IT-Bereich.

Aber noch habe ich nicht verstanden was eigentlich das Problem ist und wer davon betroffen ist. 

[Cricktor]

https://xkcd.com/2347/ passt leider wirklich wie die Faust auf's Auge.

Soweit ich die Lücke verstehe, ist es aber auch wieder ein klassischer Fall von absolutem No-Go in einer externen Bibliothek: da werden externe Daten, die man als prinzipiell unsicher und gefährlich einstufen muss, quasi ungefiltert evaluiert, was hier dazu führt, daß externe Daten wie Code ausgeführt werden können. Unfassbar, wie fahrlässig das implementiert ist.

[skunk]

Gerade eben schrieb Rikki77:

Aber noch habe ich nicht verstanden was eigentlich das Problem ist und wer davon betroffen ist. 

Das Problem ist log4j. Das ist eigentlich fürs logging zuständig. Anwendung läuft fröhlich vor sich hin und die ganze Zeit wird etwas in eine Logdatei geschrieben. Nun ist log4j schon etwas komplexer. Es kommt mit einigen Konfigurationsmöglichkeiten daher. Unter anderem kann man log4j wohl auch eine URL geben. Es lädt dann artig runter was auch immer sich hinter der URL verbirgt und was viel schlimmer ist, es führt den Spaß sogar aus. So kann einfach den eigenen Trojaner in eine fremden Anwendung zu Laufzeit einschleusen.

[Rikki77]

vor 15 Minuten schrieb skunk:

Nun ist log4j schon etwas komplexer. Es kommt mit einigen Konfigurationsmöglichkeiten daher. Unter anderem kann man log4j wohl auch eine URL geben. Es lädt dann artig runter was auch immer sich hinter der URL verbirgt und was viel schlimmer ist, es führt den Spaß sogar aus. So kann einfach den eigenen Trojaner in eine fremden Anwendung zu Laufzeit einschleusen.

Verstehe ich nicht.

Downloads von bösen Server können doch wohl vom Firewall oder dem Anti-Virus geblockt werden.

Ansonsten ist doch wohl seit 20 Jahren klar daß Java ein Sicherheitsrisiko von der Größe eines Scheunentors ist.

Wer so etwas benutzt ist selber schuld.

[skunk]

vor einer Stunde schrieb Rikki77:

Ansonsten ist doch wohl seit 20 Jahren klar daß Java ein Sicherheitsrisiko von der Größe eines Scheunentors ist.

Wollen wir jetzt den guten alten Glaubenskrieg eröffnen?

vor einer Stunde schrieb Rikki77:

Downloads von bösen Server können doch wohl vom Firewall oder dem Anti-Virus geblockt werden.

Ich kenne kein Antivirus Programm, dass eine Trefferquote von 100% hätte. Das wäre mir dann schon etwas zu riskant mich darauf zu verlassen.

[Rikki77]

vor 5 Minuten schrieb skunk:

Wollen wir jetzt den guten alten Glaubenskrieg eröffnen?

Nur falls du Java gut findest. 

[skunk]

vor 1 Minute schrieb Rikki77:

Nur falls du Java gut findest. 

Wenn du einen Glaubenskrieg für notwendig hältst dann lass dich von deiner Mission nicht abhalten. Stell dir doch einfach vor jemand hier im Thread findet Java gut und hat nur auf dich gewartet um bekehrt zu werden.

[Rikki77]

vor 2 Minuten schrieb skunk:

Wenn du einen Glaubenskrieg für notwendig hältst dann lass dich von deiner Mission nicht abhalten. Stell dir doch einfach vor jemand hier im Thread findet Java gut und hat nur auf dich gewartet um bekehrt zu werden.

Ich halte das gar nicht für notwendig, Wozu auch?

Jeder soll doch machen was er will. Mir doch egal.

Wer sich sich mit Java einlässt muß eben damit leben. 

[fox42]

vor 12 Minuten schrieb Rikki77:

Wer sich sich mit Java einlässt muß eben damit leben. 

Blöd nur, dass in meiner Branche ein Großteil schon damit umgesetzt ist. Muss ich mir was anderes suchen, um nicht damit leben zu müssen. Holzarbeiten z.B. machen auch Spaß 😉

Aber irgendwie habe ich das Gefühl, dass andere Sprachen auch ihre Lücken haben. Und auch eine Firewall hilft eben nicht in allen Fällen. Da müssen wir wohl weiterhin darauf gefasst sein, Updates zu fahren.

[Cricktor]

Das Problem mit der Firewall beim log4j-Fail ist, daß die tödliche Anfrage von Innen nach Außen kommt und nicht wie sonst nur von Außen geblockt werden muss, wenn ein Bösewicht anzuklopfen versucht. Es muss natürlich eine Java-Applikation oder Service sein, mit dem von Außen irgendwie kommuniziert werden kann. Diese externen Daten enthalten dann "Trigger-Zeichenketten", die log4j so blöd und ungefiltert auswertet und zum Exploit führen, wo von Innen eine Anfrage nach Außen erfolgt, die als Payload zu evaluierendem Code auf einfachste Art und Weise einschleuen kann.

Das, woran sich log4j "verschluckt" lässt sich auch nicht so leicht rausfiltern, weil es auf beliebig vielfältige Art verschleiert werden kann. Das kann man wohl mit Regeln und regulären Ausdrücken nicht sicher vollständig erfassen, um Zeit zu gewinnen, um die eigentliche Wurzel des Übels zu fixen.

Bearbeitet 14. Dezember 2021 von Cricktor

[mahatma]

vor 10 Stunden schrieb Rikki77:

Verstehe ich nicht.

Downloads von bösen Server können doch wohl vom Firewall oder dem Anti-Virus geblockt werden.

Ansonsten ist doch wohl seit 20 Jahren klar daß Java ein Sicherheitsrisiko von der Größe eines Scheunentors ist.

Wer so etwas benutzt ist selber schuld.

Oh Mann, Crusader... Hast echt immer so deinen eigenen Zugang zu Sachen...

So wie ich das (mit meinem limitierten Verständnis) verstanden habe, sind das Problem weniger die privaten PCs und Enduser, sondern grosse Server etc die befallen sein KÖNNTEN, also denen zB Trojaner hätten untergejubelt werden können, die erst in Wochen/Monaten zum tragen kommen und beliebigen Schaden anrichten können.

Und wenns heisst dass potentiell die iCloud, Amazon etc befallen sind... Naja, bist du sicher dass du keinen kritischen Dienst verwendest der seinerseits was mit Java macht?

Das ist ja auch die eigentliche Frage die ich hier im Thread stellen wollte, bei welchen Anwendungen mit Cryptobezug könnte es da Konsequenzen haben und was für Vorsichtsmassnahmen könnte man treffen...

Das die Börsen safe sein sollten ist schonmal beruhigend. 

[Rikki77]

Das Hauptproblem ist doch wohl daß man nicht weiß welche Anwendungen dieses Zeug benutzen.

Da ist dann der Hersteller gefragt.

Die Berichte die ich gesehen habe sind alle etwas reisserisch und oberflächlich.

Mir ist noch nicht klar wie nun so ein Angriff erfolgt.

Das muß ja wohl eine eingehende Verbindung sein.

[Rikki77]

vor 56 Minuten schrieb mahatma:

Das die Börsen safe sein sollten ist schonmal beruhigend. 

Bei den modernen Oberflächen kann ich mir schon Schwachstellen vorstellen.

Aber wenn dahinter ein gutes altes Backoffice in COBOL programmiert läuft dann kann da wohl nichts passieren. 

[Jokin]

vor 12 Stunden schrieb Rikki77:

Downloads von bösen Server können doch wohl vom Firewall oder dem Anti-Virus geblockt werden.

 

Angreifer werden die Daten wohl kaum zippen und durch die Gegend senden.

Wer als Angreifer so weit gekommen ist, dass er Zugang zu sensiblen Daten erlangen konnte, der wird den Datentransfer sehr gut im allgemeinen sonstigen Datenverkehr verstecken.

[skunk]

vor einer Stunde schrieb mahatma:

Das ist ja auch die eigentliche Frage die ich hier im Thread stellen wollte, bei welchen Anwendungen mit Cryptobezug könnte es da Konsequenzen haben und was für Vorsichtsmassnahmen könnte man treffen...

Sind die Vorsichtsmaßnahmen nicht die gleichen wie immer? -> Kapital vom Exchange runter und auf dem eigenen Hardware Wallet lagern.

vor 37 Minuten schrieb Rikki77:

Mir ist noch nicht klar wie nun so ein Angriff erfolgt.

Mal ganz im ernst. Wenn du nicht verstehst wie der Angriff funktioniert wie kommst du dann auf die Idee einen Glaubenskrieg starten zu wollen? Wie kommst du darauf, dass eine Firewall oder ein Virenscanner universell gegen alles hilft?

vor 21 Minuten schrieb Rikki77:

Aber wenn dahinter ein gutes altes Backoffice in COBOL programmiert läuft dann kann da wohl nichts passieren. 

Auch hier die Frage. COBOL ist in der Lage jeden Angriff abzuwehren? Bitte einfach mal die ganzen Vorurteile beiseite legen. Java ist nicht sicherer oder unsicherer als andere Programmiersprachen. Das größte Sicherheitsrisiko sitzt immer noch vor dem PC und bedient diesen. Das größte Sicherheitsrisiko sind vor allem Mitarbeiter, die glauben sie würden auf gewisse Tricks nicht reinfallen weil ihr Setup (COBOL, Firewall, Virenscanner) sowieso über jeden Zweifel erhaben ist. Besser immer davon ausgehen, dass das eigene Arbeitsgerät bereits infiziert wurde und man es nur noch nicht mitbekommen hat. Mit dieser gesunden Skepsis ist man deutlich sicherer unterwegs. 

Edit: Zum Angriff selbst. Die Java Anwendung benötigt keine Oberfläche. Alles was der Angreifer machen muss ist einen speziellen String vergleichbar mit SQL Injektion an die Java Anwendung zu senden. Die Java Anwendung sieht das als Befehl an jetzt meinen Trojaner aus dem Internet runter zu laden und diesen auszuführen. Herzlich willkommen in meinem Botnet. Mehr passiert erstmal nicht. Für den gängigen alles verschlüsseln und Lösegeld fordern Angriff bedarf es erstmal nur einen Zugangspunkt, der idealerweise mehrere Monate unentdeckt läuft. Damit hat der Angreifer genug Zeit seinen Code im Internen Netzwerk so weit wie möglich weiter zu verbreiten bis auch der letzte Backup Server ebenfalls infiziert wurde.

Bearbeitet 14. Dezember 2021 von skunk

[Rikki77]

vor 10 Minuten schrieb skunk:

Edit: Zum Angriff selbst. Die Java Anwendung benötigt keine Oberfläche. Alles was der Angreifer machen muss ist einen speziellen String vergleichbar mit SQL Injektion an die Java Anwendung zu senden. Die Java Anwendung sieht das als Befehl an jetzt meinen Trojaner aus dem Internet runter zu laden und diesen auszuführen. Herzlich willkommen in meinem Botnet.

Das klingt ja sehr einfach.

Woher bekommt die Anwendung den Befehl?

Wie kann sie dann einfach etwas downloaden, installieren und ausführen - ohne Root-Rechte?

 

[skunk]

vor 6 Minuten schrieb Rikki77:

Woher bekommt die Anwendung den Befehl?

Vom Angreifer. So wie ein Angreifer sich einen tollen Befehl für die SQL Injektion ausdenkt und einfach auf gut Glück absetzt. Im Moment sind alle fleißig dabei an jeden denkbaren Prozess die Log4j Befehle zu senden und auf einen Treffer zu warten. Mein Arbeitskollege bekommt bereits unzählige Log4j Befehle an seine Server gesendet. Das ist wirklich ganz stumpf Try und Error was die Angreifer da machen. Einfach an alles und jeden die neuen Log4j Befehle senden dann gibt es irgendwann auch einen Treffer.

vor 10 Minuten schrieb Rikki77:

Wie kann sie dann einfach etwas downloaden, installieren und ausführen - ohne Root-Rechte?

Wget darf ich auch als normaler User ausführen. Um einen Zugangspunkt in das dahinterliegende lokale Netzwerk zu bekommen braucht man keine Root Rechte. Die fehlenden Root Rechte kann man sich später in aller Ruhe besorgen. Selbst ohne Root Rechte kann man mehr als genug Schaden anrichten.

[Jokin]

vor 13 Minuten schrieb Rikki77:

Das klingt ja sehr einfach.

Woher bekommt die Anwendung den Befehl?

Wie kann sie dann einfach etwas downloaden, installieren und ausführen - ohne Root-Rechte?

 

Naja, sooo dramatisch ist das dann auch wieder nicht:

https://www.picussecurity.com/resource/blog/simulating-and-preventing-cve-2021-44228-apache-log4j-rce-exploits

Man muss auch noch einen LDAP-Server laufen haben, der dann missbraucht wird.

 

 

[skunk]

vor 25 Minuten schrieb Jokin:

Naja, sooo dramatisch ist das dann auch wieder nicht:

https://www.picussecurity.com/resource/blog/simulating-and-preventing-cve-2021-44228-apache-log4j-rce-exploits

Man muss auch noch einen LDAP-Server laufen haben, der dann missbraucht wird.

Den LDAP Server brauchst du jetzt aber nur für einen spezifischen Exploit. Ohne LDAP Server ist es einfach ein anderer Schadecode, die der Angreifer ausprobieren würde.

[Theseus]

Problematisch bei Log4j ist die bedenkenlose Verbreitung.

Praktisch jedes größere Projekt aus der mache der Buden, die öffentliche Aufträge bekommen, verwendet Log4j wenn es Enterprise-Java ist. Selbiges gilt auch bei fast allen mir bekannten Industrie-J2EE-Projekten.

Ich würde es nicht an der Sprache fest machen, sondern einfach mal die blinde Framework-Gläubigkeit blamen. Oft genug sind mir frische Absolventen über den Weg gelaufen, die erstmal solide Boilerplate und Abhängigkeiten angesammelt haben, bevor das Hello World auch nur begonnen wurde.

Klar kommt man da schnell zu irgendwelchen Ergebnissen, aber schön ist was anderes.

Bearbeitet 14. Dezember 2021 von Theseus
Ein fehlendes Wort wurde von Tante Edith hinzugefügt

[PeWi]

17 hours ago, Rikki77 said:

Ansonsten ist doch wohl seit 20 Jahren klar daß Java ein Sicherheitsrisiko von der Größe eines Scheunentors ist.

Kann das sein, dass du dich auf die Java-Frühzeit beziehst, als man versuchte, Webinhalte dynamisch zu machen, indem man im  Browser Java-Applets ausführen ließ?

Meiner verschwommenen Erinnerung nach war das ob ständig neuer Lücken tatsächlich ziemlich unerfreulich, und man hat Java fallenlassen und stattdessen Javascript gepusht. Java wurde dann ins Backend verbannt (bzw browser-unabhängige Java-Applikationen geschrieben), und alle waren zufrieden. 😉