News Log4Shell: Sicherheitslücke in log4j für Java hält die IT-Welt in Atem

Jan

Chefredakteur
Teammitglied
Registriert
Apr. 2001
Beiträge
15.150
Eine gravierende Sicherheitslücke in log4j Version 2.x hält seit dem Wochenende die IT-Welt in Atem und das nicht ohne Grund: log4j ist heute der De-facto-Standard zum Loggen von Anwendungsmeldungen (z.B. Fehlermeldungen) in Java, die Liste der betroffenen Apps ist entsprechend groß. Sicherheitsbehörden weltweit sind alarmiert.

Zur News: Log4Shell: Sicherheitslücke in log4j für Java hält die IT-Welt in Atem
 
  • Gefällt mir
Reaktionen: wexoo, linuxxer, Brian.Griffin und 26 andere
Ich habe mich schon gewundert, dass hier keine Meldung zu dem Thema kommt.
Aber das Wochenende sei euch natürlich ebenso gegönnt wie allen anderen (Entwickler dieses WE mal ausgenommen).^^
 
  • Gefällt mir
Reaktionen: Slayher666, Ernie75, aid0nex und 16 andere
  • Gefällt mir
Reaktionen: foo_1337
Erstmal den eigenen Minecraft Server offline genommen und geschaut welche Dienste darauf zurückgreifen.
Ist gar nicht so einfach das herauszufinden, aber bei mir waren es soweit nur Solr und eben Minecraft.
Wobei Solr bei mir nicht betroffen war, Paper MC hat auch schon ein passendes Update bekommen.

Das Problem wird nun viel eher sein, dass viele Schlafmützen gar nichts tun werden, bzw. sich gar nicht bewusst sind dass sie von so einer gravierenden Sicherheitslücke betroffen sind ...
 
  • Gefällt mir
Reaktionen: Ernie75, Fra993r, DeepBlue23 und 10 andere
die es dem Angreifer ermöglichen, die Exploit-Zeichenfolge zu übermitteln (z.B. via HTTP, TCP etc.)

Es wird in allen Berichten die ich gelesen habe immer nur von LDAP geredet. die JNDI soll ja auch primär dafür gedacht sein, Daten aus LDAP auszulesen.
Stimmt das oder kann wirklich Code über beliebige Protokolle nachgeladen werden?
 
  • Gefällt mir
Reaktionen: --Q-- und Kazuja
sikarr schrieb:
Find ich auch merkwürdig das so eine Wichtige Meldung erst Tage später kommt.
Es soll tatsächlich Menschen geben, die auch in der Weihnachtszeit mal einen ganz normalen Anspruch auf Erholung am WE haben.
 
  • Gefällt mir
Reaktionen: Slayher666, nikky, Powl_0 und 46 andere
Gefühlt nimmt die Dichte an kritischen und gleichzeitig weit verbreiteten Lücken immer weiter zu. Ich bin gespannt, ob wir uns einfach damit arrangieren müssen in einer Welt, die immer vernetzter wird und immer mehr auf Bibliotheken aufbaut oder ob es irgendwann ein Umdenken gibt.
Aktuell ist halt niemand für sowas haftbar, daher hat auch niemand Interesse an besseren Kontrollen. Den Entwicklern von log4j selbst mache ich das auch gar nicht zum Vorwurf, die machen das kostenlos in ihrer Freizeit. Aber kommerzielle Anbieter bauen dann halt tausendfach auf diesen Bibliotheken auf und niemanden kümmert es.

d4nY schrieb:
Stimmt das oder kann wirklich Code über beliebige Protokolle nachgeladen werden?
Die Abfrage zum kompromittierenden Server selbst geht meines Wissens nach über LDAP, aber den Code in das Log einschleusen geht über alle möglichen Wege, die die Software so anbietet. Die simpelste Art der Ausnutzung ist einfach nur eine HTTP-Anfrage mit dem passende String im User Agent Feld.
 
  • Gefällt mir
Reaktionen: d4nY, nosound, mental.dIseASe und 6 andere
SmooTwo schrieb:
Es soll tatsächlich Menschen geben, die auch in der Weihnachtszeit mal einen ganz normalen Anspruch auf Erholung am WE haben.
Wenn man sich als "Unabhängiges Tech-Magazin. News und Tests zu Smartphones, Tablets, PC-Hardware, Software und IT." bezeichnet erwarte ich sowas.

Unabhängig davon ist CB kein Ein Mann Betrieb und man sollte Prioritäten setzten können.
 
  • Gefällt mir
Reaktionen: Lemiiker, Mar1u5, Departet und 7 andere
Auf den ComputerBase-Servern kommen Java und log4j übrigens ausschließlich für das Such-Backend Elasticsearch zum Einsatz, welches sowohl das CMS als auch die Forumsoftware XenForo nutzen. Die empfohlenen Maßnahmen gegen die log4j-Sicherheitslücke habe ich am frühen Samstagmorgen umgesetzt. Es gibt keine Anzeichen dafür, dass die Sicherheitslücke auf ComputerBase ausgenutzt wurde.

Man vermutet aktuell, dass unser Setup ohnehin nicht verwundbar ist, weil Nutzer und somit auch ein potenzielle Angreifer auf Elasticsearch nicht direkt zugreifen können, sondern dies nur indirekt über die Suchfunktionen des CMS oder XenForo geschieht (Ankündigung von XenForo).
 
  • Gefällt mir
Reaktionen: Linuxfreakgraz, dister1, Tagesmenu und 28 andere
Und ich hab mich gestern schon gewundert, was das für ein Beitrag (ohne wirklichen Informationsgehalt) in der Tagesschau war.
 
sikarr schrieb:
Wenn man sich als "Unabhängiges Tech-Magazin. News und Tests zu Smartphones, Tablets, PC-Hardware, Software und IT." bezeichnet erwarte ich sowas.

Unabhängig davon ist CB kein Ein Mann Betrieb und man sollte Prioritäten setzten können.
Ich hoffe du wendest diese Erwartung an Perfektion auch auf dich selbst an.
 
  • Gefällt mir
Reaktionen: bullit1, Hardware_Junkie, 4badd0n und 35 andere
db7ade1a4f1a46d6.png
 
  • Gefällt mir
Reaktionen: bullit1, Ernie75, smashbrot und 56 andere
Conqi schrieb:
Gefühlt nimmt die Dichte an kritischen und gleichzeitig weit verbreiteten Lücken immer weiter zu.
Das ist nicht nur gefühlt so. Code wird immer komplexer, viele greifen auf fertige CodeTemplates und Bibliotheken zurück und haben gleichzeitig weniger Zeit für die Qualitätskontrolle.
SmooTwo schrieb:
Ich hoffe du wendest diese Erwartung an Perfektion auch auf dich selbst an.
Immer.
Spass bei Seite, andere Magazine, Blogs etc. kriegen das auch hin. Ich erwarte keine wissenschaftliche Abhandlung aber eine kleine News hätte gereicht und den Rest hätte man mit Updates nachschieben können.
Wir reden immerhin nicht von der besten Gamermaus mit Lensflare sondern von einer fundamentalen Sicherheitslücke.
 
  • Gefällt mir
Reaktionen: bullit1, Ernie75, Lemiiker und 14 andere
Interessant: Aber wo steckt log4j alles drinnen und wie finde ich es als Privatnutzer heraus? Router? Switches? IOT?

Auf GitHub existiert eine Liste betroffener Anwendungen, die inzwischen über 100 Einträge zählt. Ob ein System betroffen ist, lässt sich beispielsweise über ein auf GitHub veröffentlichtes Python-Script für Rechner mit HTTP-Server testen.


So ganz schlau werde ich nicht daraus, kann ja auch sein, dass ich kein Pythin auf dem System ausführen kann? (Router) - die Liste der Unternehmen klingt echt scary - und noch mehr, dass man vermutlich selber schauen muss, ob bspw. Technik von A in produkt B steckt...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: MGFirewater und mrhanky01
Grimba schrieb:
Frage aus Neugier: Was stellst du dir da genau vor?
Genau kann ich es schlecht sagen, weil es eh immer tausend Ausnahmen oder zusätzliche Überlegungen gibt, aber in keiner anderen Branche ist es üblich, dass Hersteller einfach keinerlei Haftung übernehmen müssen. Mit der DSGVO kann es Strafen geben für Anbieter, denen Daten abhanden kommen (und selbst da wird viel, viel zu lasch vorgegangen), aber für Software-Hersteller existiert sowas schlicht nicht. Egal wie trivial und dumm die Lücke auch sein mag, die da gerade die Admins der Welt in Atem hält.

Ein erster Schritt wäre schon mal, wenn Hersteller zu besseren Meldewegen verpflichtet wären. Das heißt, keine Artikel mehr hinter Logins oder gar Paywalls verstecken. Außerdem hat eine Meldung spätestens nach x Stunden/Tagen zu erfolgen.
Es gibt immer noch Hersteller, die sind sich nicht sicher, welche ihrer Produkte betroffen sind, weil ihre Software auf anderer Software basiert, die auf Bibliotheken aufbaut, die auf... und so weiter. Sowas zu klären sollte für kommerzielle Anbieter eine Frage von Minuten sein, nicht Tagen. Hier läuft offensichtlich etwas fundamental falsch.
 
  • Gefällt mir
Reaktionen: KadmosIII, iron-man, nosound und 2 andere
Steffen schrieb:
Man vermutet aktuell, dass unser Setup ohnehin nicht verwundbar ist, weil Nutzer und somit auch ein potenzielle Angreifer auf Elasticsearch nicht direkt zugreifen können, sondern dies nur indirekt über die Suchfunktionen des CMS oder XenForo geschieht (Ankündigung von XenForo).
Wenn die Suchbegriffe der User geloggt werden, dann sollte das doch verwundbar sein, oder? Oder enthalten die Log Messages keine Inhalte die von den Benutzern stammen?

Mein Verständnis war das alles verwundbar ist bei dem die Nutzer den Inhalt der Log Messages teilweise bestimmen können. Was halt schon sehr häufig der Fall ist. Kann aber auch sein das ich hier falsch verstehe wie genau diese Lücke ausgenutzt wird.
 
Zurück
Oben