Log4j: Vor kritischer Schwachstelle wird gewarnt

Vermutung: Davon wird man noch einiges hören, selbst das Bundesamt für Sicherheit in der Informationstechnik warnt bereits. Eine kritische Schwachstelle in einer weit verbreiteten Java-Bibliothek (Log4j) führt zu einer unmittelbaren Erhöhung der IT-Bedrohungslage. Die Schwachstelle sei nach Einschätzung Experten trivial ausnutzbar, ein Proof-of-Concept ist zudem öffentlich verfügbar. Darüber hinaus hat das BSI bereits breit angelegte Scans nach verwundbaren Anwendungen beobachtet.

Die Ausnutzung der genannten Schwachstelle kann zu einer vollständigen Kompromittierung der Zielsysteme führen. Verwundbar sind zahlreiche Anwendungen und Spiele, zahlreiche Threads auf Hacker News und Reddit sprechen von Verwundbarkeiten bei Produkten von Steam, Amazon, Google, Microsoft und anderen und weiteren – auch Spiele wie Minecraft in der Java-Edition war betroffen, aber da hat man bereits einen Patch veröffentlicht.

Details zu CVE-2021-44228 finden sich hier. Apache hat bereits Log4j 2.15.0 veröffentlicht, um diese Sicherheitslücke höchsten Schweregrades zu schließen. Die Sicherheitsforscher von Lunasec unterstrichen die Schwere der Angriffe und erklärten, dass „viele, viele Dienste für diesen Exploit anfällig sind. „In Anbetracht der weiten Verbreitung dieser Bibliothek, der Auswirkungen des Exploits (vollständige Serverkontrolle) und der Leichtigkeit, mit der sie ausgenutzt werden kann, sind die Auswirkungen dieser Schwachstelle ziemlich schwerwiegend.“

In diesem Artikel sind Partner-Links enthalten. Durch einen Klick darauf ge­lan­gt ihr direkt zum Anbieter. Solltet ihr euch dort für einen Kauf entscheiden, erhalten wir ei­ne kleine Provision. Für euch ändert sich am Preis nichts. Danke für eure Unterstützung!

Gefällt dir der Artikel? Dann teile ihn mit deinen Freunden.

Hallo, ich bin Carsten! Ich bin gelernter IT-Systemelektroniker und habe das Blog 2005 gegründet. Seit 2008 ist es Beruf(ung). Baujahr 1977, Dortmunder im Norden, BVB-Fan und Vater eines Sohnes. Auch zu finden bei Twitter, Facebook, Instagram und YouTube. PayPal-Kaffeespende. Mail: carsten@caschys.blog

Neueste Beiträge

Mit dem Absenden eines Kommentars stimmst du unserer Datenschutzerklärung und der Speicherung von dir angegebener, personenbezogener Daten zu.

7 Kommentare

  1. therealThomas says:

    Hier eine wachsende Auflistung von betroffenen Anwendungen: https://github.com/YfryTchsGD/Log4jAttackSurface

    Für self-hoster stechen mir v.a. Redis, Solr und ELK ins Auge.

  2. Eine Lib, per default aktiviert, welche Code von beliebigen Servern nachladen kann, gestartet per Zuruf aus Logfiles. Was soll da schon passieren? Ach wäre Java doch nur eine Insel.

    • Logic Bugs kannst in jeder Programmiersprache einbauen…

    • Schlimmer ist eher das Versäumnis, dass per Programmcode das problematische Verhalten nicht unterbunden werden kann (ja, auch jetzt nicht – nur per System-Property-Settings) und das verkehrte Default-Verhalten!
      Und erst jetzt in Version 2.15.0 kamen die Verantwortlichen bei Apache Software Foundation auf die Idee, das Default-Handling zu ändern! Netterweise wurden die Einträge, die das Lookup-Verhalten kritisierten und das als Fehler per se meldeten, bis vor Kurzem einfach gelöscht (ja, gelöscht – denn auch meine 4 Meldungen sind fort! Die erste war für 2.0b3 – im November 2012! Aber bereits vorher haben andere Leute sich über diesen Unsinn aufgeregt.. und diese Meldungen wurden wie bei Apache Foundation üblich auch sofort entfernt)

  3. Also, so als daher gelaufenen Softwareentwickler, ne Bibliothek fürs Logging, das wäre auch das erste, wo ich potentielle Schwachstelle suchen würde. Nicht. Erwischt. Man kann gar nicht vorsichtig genug sein.

    Was ich aber gerade noch nicht verstehe: ausgenutzt wird das, indem man ein anzugreifendes System dazu bringt, etwas zu loggen, worin eine böse URL steht? Das wiederum ist ja ein bekanntes Szenario, gegen das Systeme getestet werden, also beispielsweise DB Anfragen in Loginnamen schreiben und so. Warum fällt das erst jetzt auf?

    • Das Problem tritt auf, wenn Zugriffe aufgezeichnet werden – und da ist es schlicht egal, ob die ${ } -Anweisung im HTTP-Header oder im URL oder sonst wo übergeben wird! Werden die Werte, die per HTTP übergeben wurden geloggt, schlägt das dumme Verhalten von log4j2 zu. Die alte Version (aktuell 1.2.17) hatte diesen Unsinn noch nicht eingebaut!

      Das Szenario wurde kaum getestet, da sich kaum jemand vorstellen konnte, dass so was überhaupt in einer Logging-Software zu Problem führen könnte – auch weil die meisten Software-Produkte ja eine gewisse Entwicklungszeit hinter sich haben und früher die alte log4j-Library genutzt wurde. Und die macht so was nicht! Und in der Doku muss man schon genau danach suchen um den Blödsinn zu finden.
      Denn wer bitte nimmt per default an, dass Log-Ausgaben statt ausgegeben interpretiert werden?
      Das Verhalten hat leider an vielen Orten Einzug gehalten – man sehe sich blos den Unsinn im Bereich NodeJS und den tausenden JS-Libraries an (viele davon Implementieren Dinge, die die Browser so wie so können, aber dabei nicht den oft wirren Ansichten und Wünschen im Bereich „Aussehen“ den Programmieren entsprechen und daher wird zigfach das selbe implement!! Heraus kommen „Produkte“, die zig hunderte Libraries direkt und tausende indirekt benötigen! Wer den Blödsinn/Unsinn darin erkennt…)

      • bofhl, so ist es. Oder um es anders zu sagen Time2Market. Schon Mark Zuckerberg hat an seine Mannschaft gesagt, macht schnell, egal ob was kaputt geht, hauptsache schnell.
        Also, rein mit den Bibliotheken und ab gehts mit feinsten nightmares.

Es werden alle Kommentare moderiert. Lies auch bitte unsere Kommentarregeln:

Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen. Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte - gerne auch mit Humor.

Du willst nichts verpassen?

Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den Hauptfeed abonnieren.