von Bhabesh Raj, Associate Security Analyst Engineer, und Kennet Harpsøe, Senior Cyber Analyst

Sie sollten die Log4Shell-Schwachstelle ernst nehmen, denn sie ist schwer zu erkennen, kann in vielen Software-Anwendungen auftreten, und ist das perfekte Mittel, um Malware in Ihr Netzwerk einzuschleusen. Es gibt aktuell kein einziges Cybertool, das Ihr Unternehmen vor Log4Shell schützen kann.

Mit einer Kombination aus verschiedenen Tools und einem Verständnis für Defense-in-Depth sind Unternehmen in der Lage, Aktivitäten nach der Kompromittierung zu erkennen und den Angriff zu stoppen.

Angenommen, es kam zu einer Sicherheitsverletzung – was dann?

 

Am 09. Dezember 2021 hat Apache eine kritische Remote-Code-Execution-Schwachstelle (CVE-2021-44228) offengelegt, die auch als Log4Shell bekannt ist und die Apache Log4j-Versionen 2.0-2.14.1 betrifft. Log4j ist eine weit verbreitete Logging-Bibliothek in Java und wird in mehreren Unternehmensanwendungen verwendet. Hierzu zählen Apache Struts, Flume, Kafka, Flink, Tomcat, Solr und VMware vCenter. Aufgrund der weiten Verbreitung von Log4j bemühen sich Sicherheitsexperten, herauszufinden, welche ihrer Anwendungen betroffen sind. Versuche, diese Schwachstelle auszunutzen, sind besonders schwer zu erkennen, da jede Zeichenfolge, die von Log4j protokolliert wird, die Sicherheitsverletzung auslösen kann – von User-Agent-Zeichenketten bis hin zu E-Mail-Betreffzeilen. Der Exploit könnte sogar im weiteren Verlauf von einem anfälligen SIEM-System ausgelöst werden, das log4j-Logdaten zu einem späteren Zeitpunkt speichert.

Die IT-Umgebung der meisten modernen Unternehmen ist sehr umfassend und komplex. Es ist unmöglich, alle schadhaften Aktivitäten am Perimeter abzuwehren oder gar zu erkennen. Einige werden unweigerlich in die Infrastruktur eindringen. Sicherheitsteams, die für große IT-Umgebungen verantwortlich sind, sollten in ihrem Security-Management auf Sicherheitsverletzungen vorbereitet sein. Irgendwo in Ihrem System wird sich Malware befinden. Das Ausmaß von Log4Shell sowie die Möglichkeiten, Sicherheitsmaßnahmen zu umgehen, veranschaulichen diesen Punkt perfekt. Alle Manager sollten sich fragen, ob sie Angreifer, die Malware nutzen, um in ihre Systeme einzudringen, erkennen können oder nicht. Eine Defense-in-Depth-Strategie ist die beste Art, auf Bedrohungen zu reagieren.

Defense-in-Depth wird oft anhand der Cyber-Kill-Chain von Lockheed Martin oder des Mitre ATT&CK-Frameworks dargestellt. Beide besagen im Wesentlichen, dass jeder erfolgreiche Cyberangriff eine Reihe von konzeptionell klar definierten Schritten durchläuft. Im Fall von Log4Shell bedeutet dies, dass Angreifer sich einen ersten Zugang verschaffen und Malware wie Cobalt Strike installieren. Höchstwahrscheinlich wird dieser erste Zugang über einen an das Internet angebundenen Rechner wie einen Apache-HTTP-Web-Server erfolgen. Die nächsten Schritte nach dem ersten Zugriff sind Persistenz und Ausbreitung im Netzwerk (Lateral Movement). Mit einer Defense-in-Depth-Strategie können Sicherheitsverantwortliche prüfen, wie gut sie diese Art von Aktivitäten erkennen können und wie gut sie geschützt sind. So könnte es beispielsweise sinnvoll sein, die Persistenz mit Host-Agents zu erkennen, die dies an das SIEM-System berichten. Ein Network-Detection-System könnte die Ausbreitung im Netzwerk aufdecken, an das SIEM-System melden, und grundlegende Richtlinien (Baselines) erstellen, welche Rechner mit welchen kommunizieren dürfen. Damit sind Sicherheitsteams in der Lage, einen Apache-Web-Server zu erkennen, der als Client für einen dahinter liegenden, mit der Domain verbundenen Host fungiert, was hinsichtlich Log4Shell höchst verdächtig wäre. Mit anderen Worten: Es zahlt sich aus, Zeit und Geld in das Logdaten-Management zu investieren und zu protokollieren, was wirklich erforderlich ist, und nicht nur das, was bereits existiert.

Mit einer Defense-in-Depth-Strategie und einem gut durchdachten Logging-System können Security-Verantwortliche ihre Sicherheitsmaßnahmen um zusätzliche Software erweitern. Sie können beispielsweise User and Entity Behavior Analytics (UEBA) nutzen, eine ML-basierte Software, die automatisch Baselines wie die im oben beschriebenen Beispiel erstellen kann. Teams können auch Lösungen für Security Orchestration, Automation and Response (SOAR) einsetzen, um automatisch eine Aktion einzuleiten, die die Reaktionszeit auf einen Angriff verkürzt und dazu beiträgt, die Auswirkungen zu verringern. Diese Reaktionsmaßnahme kann beispielsweise die automatische Trennung der Verbindung des Apache-Web-Servers von dem Domain-Host sein. SOAR kann den Analysten nach der Reaktionsmaßnahme auch benachrichtigen und ihm alle relevanten Informationen zur Verfügung stellen, um den Web-Server zu untersuchen und zu entscheiden, ob die Verbindung wiederhergestellt werden sollte oder nicht.

Alle LogPoint-Warnmeldungen werden dem MITRE ATT&CK-Framework zugeordnet. Dies unterstützt Sicherheitsanalysten dabei, die aktuelle Sicherheitslage zu verstehen und die Alerts zu priorisieren.

Was wissen wir über Log4Shell?

Chen Zhaojun, Mitarbeiter des Cloud-Security-Teams von Alibaba, meldete die Schachstelle CVE-2021-44228 (CVSS 10 von 10) am 24. November an die Log4j-Entwickler, woraufhin Apache am 06. Dezember einen Patch herausgab. Am 10. Dezember wurde ein PoC-Exploit veröffentlicht. Der CEO von Cloudflare erklärte, dass der früheste Beweis für einen Exploit, den sie bisher gefunden haben, vom 01. Dezember stammt. Dies deutet darauf hin, dass diese Schwachstelle schon mindestens neun Tage bekannt war.

Interessanterweise verwendet Log4Shell den JNDI-Angriffsvektor, der bereits auf der BlackHat USA 2016 bekannt gemacht wurde. Die Ausnutzung der Schwachstelle ermöglicht es einem Remote-Angreifer, Code in einer Anwendung auszuführen, wenn diese den vom Angreifer bereitgestellten String-Wert im JNDI-LDAP-Server-Lookup des Angreifers protokolliert. Um die Schwachstelle auszulösen, muss ein Angreifer eine bestimmte Zeichenfolge in seine Anfragen einfügen, beispielsweise in User-Agents, die die Anwendung, die die anfällige Log4j-Bibliothek verwendet, protokolliert. Der Server sendet dann über JNDI eine Anfrage an die Adresse des Angreifers. Der Server des Angreifers, beispielsweise LDAP, antwortet, indem er einen Pfad zu einer Remote-Java-Class-Datei sendet, die in den anfälligen Server-Prozess eingeschleust wird und den Payload-Code ausführt. Administratoren sollten sich zudem darüber im Klaren sein, dass Bedrohungsakteure vertrauliche Daten aus Umgebungsvariablen, wie beispielsweise geheimen AWS-Keys, auslesen und veröffentlichen können und dies auch getan haben, um Cloud-Umgebungen zu kompromittieren.

Das Deutsche Telekom CERT hat Exploit-Versuche aus dem Tor-Netzwerk gemeldet. Am 10. Dezember gab das Unternehmen Imperva bekannt, dass es mehr als 1,4 Millionen Angriffe auf die Schwachstelle CVE-2021-44228 beobachtet hat, mit Spitzenwerten von rund 280.000 Angriffen pro Stunde. Das Unternehmen Cloudflare meldete ebenfalls, dass es in Spitzenzeiten 20.000 Exploit-Requests pro Minute blockiert hat, wobei wohl zu jedem Zeitpunkt etwa 200 bis 400 IPs aktiv zu scannen schienen.

Große Anbieter wie Cisco, VMware, SonicWall, Okta und RedHat untersuchen derzeit, welche ihrer Produkte betroffen sind. LogPoint rät Administratoren, die Empfehlungen und Mitteilungen regelmäßig zu überprüfen, da sie von den jeweiligen Anbietern kontinuierlich aktualisiert werden. In der Zwischenzeit können Administratoren Canary-Tokens nutzen, um zu testen, ob die Log4Shell-Schwachstelle in ihren Anwendungen auftreten könnte.

Microsoft hat festgestellt, dass Angreifer Log4Shell ausnutzen und dabei Cobalt-Strike-Beacons verbreiten. Der Sicherheitsexperte Markus Neis hat getwittert, dass neben Coin-Minern auch Muhstik und Mirai als Payloads über Log4Shell-Exploits verbreitet werden. Administratoren können sich die von GreyNoise veröffentlichten base64-Payloads als Referenz ansehen, um sich über die Ausnutzung von Log4Shell zu informieren.

Erste Einschätzungen zeigen, dass die LogPoint-Lösungen nicht von der Schwachstelle betroffen sind. Wir werden unseren Blog entsprechend aktualisieren, während wir mit unseren Evaluierungen fortfahren.

So erkennen Sie Log4Shell-Exploits

Administratoren können die Sigma-Regel von Florian Roth nutzen, um generische Exploit-Versuche in den Web-Server-Logdaten zu erkennen.

(user_agent IN ['*${jndi:ldap:/*', '*${jndi:rmi:/*', '*${jndi:ldaps:/*', '*${jndi:dns:/*', '*/$%7bjndi:*', '*%
24%7bjndi:*', '*$%7Bjndi:*', '*%2524%257Bjndi*', '*%2F%252524%25257Bjndi%3A*', '*${jndi:${lower:*', '*${::-
j}${*', '*${jndi:nis*', '*${jndi:nds*', '*${jndi:corba*', '*${jndi:iiop*', '*${${env:BARFOO:-j}*', '*${::-l}${::
-d}${::-a}${::-p}*', '*${base64:JHtqbmRp*']
OR url IN ['*${jndi:ldap:/*', '*${jndi:rmi:/*', '*${jndi:ldaps:/*', '*${jndi:dns:/*', '*/$%7bjndi:*', '*%24%
7bjndi:*', '*$%7Bjndi:*', '*%2524%257Bjndi*', '*%2F%252524%25257Bjndi%3A*', '*${jndi:${lower:*', '*${::-j}${*',
'*${jndi:nis*', '*${jndi:nds*', '*${jndi:corba*', '*${jndi:iiop*', '*${${env:BARFOO:-j}*', '*${::-l}${::-d}${::-
a}${::-p}*', '*${base64:JHtqbmRp*']
OR referer IN ['*${jndi:ldap:/*', '*${jndi:rmi:/*', '*${jndi:ldaps:/*', '*${jndi:dns:/*', '*/$%7bjndi:*', '*%24%
7bjndi:*', '*$%7Bjndi:*', '*%2524%257Bjndi*', '*%2F%252524%25257Bjndi%3A*', '*${jndi:${lower:*', '*${::-j}${*',
'*${jndi:nis*', '*${jndi:nds*', '*${jndi:corba*', '*${jndi:iiop*', '*${${env:BARFOO:-j}*', '*${::-l}${::-d}${::-
a}${::-p}*', '*${base64:JHtqbmRp*'])"

Die Suche nach generischen Exploit-Versuchen in den Web-Server-Logdaten

Angreifer nutzen vorwiegend das User-Agent-Feld für die Ausnutzung von Log4Shell. Administratoren sollten jedoch beachten, dass die Muster, die die Schwachstelle auslösen, in jeglicher Zeichenfolge vorhanden sein können, die von log4j protokolliert wird. Deshalb sollte Abfrage entsprechend angepasst werden. Zudem gibt es zahlreiche Permutationen zur Umgehung der Signatur, die Administratoren bei der Erkennung berücksichtigen sollten.

Die ET Labs haben Signaturen für Log4Shell veröffentlicht, die Administratoren für ihr IDS/IPS nutzen können.

norm_id IN ["Snort", "SuricataIDS"] message="*CVE-2021-44228*"

Mehrere Anbieter veröffentlichen IoCs zu Log4Shell, die Administratoren für die Erkennung nutzen können.

(source_address IN LOG4SHELL_IPS OR destination_address IN LOG4SHELL_IPS)

In ähnlicher Weise können Sie die IoCs von NetLab für Mirai und Muhstik nutzen.

(domain IN ["nazi.uy", "log.exposedbotnets.ru"] OR query IN ["nazi.uy", "log.exposedbotnets.ru"]
OR url IN ["http://62.210.130.250/lh.sh", "http://62.210.130.250:80/web/admin/x86_64", "http://62.210.130.250:80
/web/admin/x86", "http://62.210.130.250:80/web/admin/x86_g", "http://45.130.229.168:9999/Exploit.class",
"http://18.228.7.109/.log/log", "http://18.228.7.109/.log/pty1;", "http://18.228.7.109/.log/pty2;", "http://18.
228.7.109/.log/pty3;", "http://18.228.7.109/.log/pty4;", "http://18.228.7.109/.log/pty5;", "http://210.
141.105.67:80/wp-content/themes/twentythirteen/m8", "http://159.89.182.117/wp-content/themes/twentyseventeen
/ldm"])

Die Erkennung von Aktivitäten nach der Kompromittierung ist entscheidend

Angesichts der aktuellen Bedrohungslandschaft reicht es nicht mehr aus, nur zu reagieren und sich auf Bedrohungsinformationen und die Bedrohungserkennungen zu verlassen. Sicherheitsverantwortliche in den Unternehmen sollten proaktiv handeln und nach verdächtigen Aktivitäten in ihrer Umgebung suchen. Selbst wenn es den Security-Teams nicht gelingt, den ersten Angriff zu erkennen, haben sie immer noch eine faire Chance, die Aktivitäten der Angreifer nach einer Kompromittierung aufzudecken. Für den Anfang können Administratoren nach den gängigen Tools von Bedrohungsakteuren Ausschau halten, wie beispielsweise Cobalt Strike, Tor und PsExec. Falls sie diese entdecken, können Sie die gesamte Kill Chain ermitteln.

LogPoint hat bereits einige Blog-Beiträge veröffentlicht, die detailliert beschreiben, wie Sie die gängigen Tools von Bedrohungsakteuren erkennen können:

Angreifer lieben es, einen Backdoor-Zugriff über OpenSSH zu Systemen einzurichten, indem sie ihren Public-Key der authorized_keys-Datei hinzufügen. Administratoren können „auditd“ nutzen, um Änderungen an der authorized_keys-Datei ihrer Server zu überwachen.

norm_id=Unix "process"=audit event_type=SYSCALL command=bash key="ssh_key_monitor"

Das Muhstik-Botnet kann Backdoors einrichten und ist, wie bereits erwähnt, bisher eines der wenigen Botnets, die Log4Shell ausgenutzt haben.

Schließlich können Sie noch nach anomalen Server-Aktivitäten suchen, wie beispielsweise der Ausführung ungewöhnlicher Prozesse wie „curl“ und „wget“. Administratoren sollten beachten, dass – abhängig von der Umgebung – die Erstellung von Allow-Listen erforderlich sein kann.

norm_id=Unix "process"=audit event_type=PROCTITLE command IN ["*curl*", "*wget*", "*chmod 777*", "*chmod +x*"]

Wir können den Wert eines richtig implementierten Defense-in-Depth-Ansatzes gar nicht oft genug betonen. Dieser Ansatz kann Sie dabei unterstützen, Bedrohungen zu erkennen, die in das Unternehmen eingedrungen sind und bei denen die anfänglichen Erkennungsmechanismen versagt haben.

Defense-in-Depth ist der Schlüssel zur Sicherheit für Unternehmen

Es ist wichtig zu beachten, dass die Log4Shell-Schwachstelle nicht so einfach ausgenutzt wie ihr Vorhandensein überprüft werden kann, da die erfolgreiche Ausnutzung von mehreren Faktoren wie der JVM-Version und der verwendeten Konfiguration abhängt. Dennoch sollten Unternehmen, die anfällige Anwendungen einsetzen, davon ausgehen, dass es zu einer Sicherheitsverletzung kommen kann, und die Logdaten der Anwendungen auf Artefakte einer Kompromittierung überprüfen. Administratoren sollten zudem auf jeden verdächtigen ausgehenden Netzwerkverkehr ihrer anfälligen Anwendungen achten.

Defense-in-Depth ist nach wie vor die bestmögliche Strategie zur Erkennung von Log4Shell-Exploits. Massen-Scans haben bereits begonnen, und Coin-Miner und Botnets haben sich bereits angeschlossen. Es ist nur eine Frage der Zeit, bis auch Ransomware-Akteure auf den Zug aufspringen. Sicherheitsverantwortliche in den Unternehmen sollten wachsam bleiben und sich nicht auf eine einzige Erkennungsmethode verlassen, um die Ausnutzung dieser kritischen Sicherheitslücke aufzudecken. Abschließend möchten wir Administratoren daran erinnern, regelmäßig die Mitteilungen und Empfehlungen der Hersteller zu prüfen, um sich über den aktuellen Stand der Abhilfemaßnahmen und Patches für anfällige Produkte, die in ihrem Unternehmen eingesetzt werden, zu informieren.

Discover More About Logpoint

Book a demo
Customer cases
Customer reviews