Log4j: Vor kritischer Schwachstelle wird gewarnt
von caschy | 7 Kommentare
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.“
Transparenz: In diesem Artikel sind Partnerlinks enthalten. Durch einen Klick darauf gelangt ihr direkt zum Anbieter. Solltet ihr euch dort für einen Kauf entscheiden, erhalten wir eine kleine Provision. Für euch ändert sich am Preis nichts. Partnerlinks haben keinerlei Einfluss auf unsere Berichterstattung.
Wird geladen ...
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.
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)
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.