Der Eintrag "offcanvas-col1" existiert leider nicht.

Der Eintrag "offcanvas-col2" existiert leider nicht.

Der Eintrag "offcanvas-col3" existiert leider nicht.

Der Eintrag "offcanvas-col4" existiert leider nicht.

Schutz vor schwerwiegender Log4j-Lücke - was hilft und was nicht
  • HARTMUT NAUJOK
  • Schutz vor schwerwiegender Log4j-Lücke - was hilft und was nicht
14.12.2021 16:21

Schutz vor schwerwiegender Log4j-Lücke - was hilft und was nicht

WICHTIGER HINWEIS ZUM NACHFOLGENDEN ARTIKEL

Ob bei den Herstellern, dem Dienstleister oder dem Rechenzentrum. Die Problematik ist, dass der Unternehmer, die Körperschaft oder die Kommune für diese Lücken haften.

Eine 100%-ige IT-Sicherheit gibt es nicht! Immer wieder werden neue Lücken ausgespäht, die Kommune, sprich die Bürgermeister und/oder Kämmerer, die Körperschaft oder aber das Unternehmen bzw. die Anteilseigner haften dann ggfs. mit dem gesamten Privatvermögen (losgelöst von der Rechtsform).

Von daher ist es so wichtig, dass man sich mit Lösungen für einen Risikotransfer beschäftigt.

Wie kann ich mich aber gegen etwas schützen, das ich nicht kenne!? Wenn die Hacker die Lücke vor dem Patch ausgenutzt haben, wird es sehr teuer und die Existenz des Unternehmens ist nachhaltig gefährdet. Das kann schon präventiv vermieden werden.

Hier bietet eine Cyberdeckung nicht nur durch umfangreiche Assistance-Leistungen Schutz, sie hilft auch bei diesen festgestellten Lücken.

SPRECHEN SIE UNS HIERZU GERNE AN!


"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.

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

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-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

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 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

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.

CanaryTokens erzeugt dazu einen String wie

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:

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.

Quelle: heise.de

Zurück

Über uns

Wir sind ein auf sachwertgebundene Investments spezialisiertes Unternehmen, das die gesetzlichen Rahmenbedingungen für betriebliche Versorgungen mit allen Durchführungswegen bis ins kleinste Detail nutzt.

Dabei nutzen wir Heilungs - und Sanierungsmöglichkeiten der 6a - Versorgung, damit insbesondere kleine Familien-GmbHs ihre Rückstellungen sachwertgebunden auflösen und der aktuellen Marktlage angepasst neu aufbauen können.

Insbesondere die Paragraphen 314 VAG und 163 VVG kommen in den Rückdeckungsprodukten auf den Prüfstand und werden im Sinne des Geschäftspartners faktisch überprüft und optional im Rahmen der Nullzinsfalle egalisiert. Dies greift natürlich ebenso beim privaten Vermögensaufbau und -erhalt.

Qualifikation und Beratungsspektrum

Serviceplattform für Cyberdeckungen und Haftungsrisiken
Serviceplattform für betriebliche Versorgungsmodelle

Zertifizierter Fachberater für Cyber-Risiken
Zertifizierter IT-Grundschutz Praktiker des BSI
Zertifizierter BU-Berater

Fachwirt für Finanzberatung

Experte Betriebliche Versorgungen DMA
Experte Betriebliche Haftpflicht DMA

Geprüfter Finanzanlagenfachmann
Bankkaufmann | Rentenberater | Finanzplaner

Kontakt

HARTMUT NAUJOK
Hauptstraße 69
D-27478 Cuxhaven

Filialniederlassung

Unterste Kamp 1
D-42549 Velbert