Alles Wissenswerte über die Sicherheitslücke Log4j

  • Fabian Sinner
  • Dezember 14, 2021

Inhalt

Alles Wissenswerte über die Sicherheitslücke Log4j

Am Wochenende wurde eine kritische Sicherheitslücke mit dem Namen Log4j in einer weltweit stark verbreiteten Server-Software gefunden, die schlimme Folgen für Nutzer haben kann.

Der Fall ist sogar so ernst, dass das Bundesamt für Sicherheit und Informationstechnik (BSI) die Warnstufe von „Orange“ auf „Rot“ hochsetzte – ein deutliches Zeichen, wie ernst die Situation wirklich ist.

Um welche Schwachstelle handelt es sich genau?

Ausgangspunkt der Sicherheitslücke ist eine Java-Bibliothek namens Log4j. Mit ihrer Hilfe können Anwendungsmeldungen protokolliert und festgehalten werden. Über die Protokollierung hinaus, verfügt Log4j verschiedene Mechanismen, um übermittelte Zeichenketten zu interpretieren. Durch die bekannt gewordene Schwachstelle in Log4j kann ein Angreifer diesen Mechanismus ausnutzen, um Befehle von einem externen System auszuführen.

Das heißt: Ein Angreifer nutzt die Schwachstelle, sendet den Befehl Kontakt mit einem Server des Angreifers aufzunehmen, um von dort einen schadhaften Java-Code einzuschleusen. Das würde im Extremfall bedeuten, dass der Server komplett übernommen werden kann und der eigentliche Besitzer ausgesperrt wird. Ein absolutes Katastrophen-Szenario.

Wer ist von der Log4j-Schwachstelle betroffen?

In der Theorie ist jeder betroffen, der einen Server mit der Java-Sprache betreibt und dort die Versionen von 2.0 bis 2.14.1 von Log4j als Bibliothek benutzt. Es wird daher dringend empfohlen, die Version auf den aktuellen Stand 2.16.0 zu updaten.

Die Liste der Unternehmen und öffentlichen Einrichtungen, die von dieser Sicherheitslücke betroffen sind, wächst, darunter Apple, Tencent, Twitter, Baidu, Steam, Minecraft, Cloudflare, Amazon, Tesla, Palo Alto Networks, IBM, Pulse Secure, Ghidra, ElasticSearch, Apache, Google, Webex, LinkedIn, Cisco und VMware. Die Auswirkungen gehen weit über große Unternehmen hinaus, da jeder Dienst, der benutzerkontrollierte Zeichenketten (User Agents, Referrer usw.) protokolliert, für diesen Exploit anfällig ist.

Dem BSI wurden bereits Server-Kompromittierungen gemeldet und ersten Schätzungen zufolge, wird es dabei nicht bleiben. Weltweit wurden bereits „Massenscans“ entdeckt, die darauf hindeuten, dass Angreifer auf der Suche nach potenziellen Zielen sind. Für eine umfassende Einschätzung ist es laut BSI allerdings noch bedeutend zu früh, da das ganze Ausmaß der Situation nach wie vor nicht klar ist.

Wer nutzt Angriffe mit Log4j?

Die Log4j-Sicherheitslücke wurde bereits im November/Dezember 2021  von Entwicklern und Forscher entdeckt und der Apache-Stiftung gemeldet. Zu diesem Zeitpunkt scheint es alleridngs schon zu spät gewesen zu sein, denn die Schwachstelle wurde bereits von Cyberkriminellen entdeckt und ausgenutzt. Zuerst ging man davon aus, dass einzelne Gruppierungen aus verschiedenen Ländern sich einen Vorteil verschafften, doch dabei handelte es sich nur um die Spitze des Eisbergs.

Da die Schwachstelle recht leicht auszunutzen ist, wurde auch Gruppen des Cyberdrime recht bal auf das Problem aufmerksam und nutzten diese aus. Die Zahl der kriminellen Übergriffe ist offiziell nicht bekannt – es ist aber davon auszugehen, dass die Attackenzahl aufgrund der Einfachheit äußerst hoch gewesen sein muss.

Offizielle Behebung der Log4j-Lücke

Natürlich sind sich auch die Entwickler von Apache über den Log4j-Exploit im Klaren und arbeiten stetig an der Verbesserung, um das Problem endgültig zu lösen. Sicherheitsexperten sahen besonders die Versionen 2.0 bis 2.14.1 von dem Sicherheitsleck betroffen. Daher sollten neue Updates die kritische Lücke schließen:

Version 2.15.0
Die Patch-Version 2.15.0 erschien relativ zügig nach dem Bekanntwerden und sollte das Problem rasch lösen. Doch stattdessen war der Patch unvollständig und schloss nur einen Teil des Lecks – der andere Teil war nach wie vor noch für Hacker nutzbar.

Version 2.16.0
Mit dieser Version wollte man die offengelassenen Punkte aus dem zuvor hastig veröffentlichten Patch schließen. Zwar gelang dies über weite Strecken, Version 2.16.0 war aber nach wie vor nicht die Lösung für alle Probleme. Der Sicherheitsstandard konnte dennoch massiv erhöht werden.

Version 2.17.0
Version 2.17.0 konnte die Sicherheitslücke dann größtenteils lösen und ein wenig Ruhe in die Situation bringen. Allerdings häuften sich die Gerüchte, dass auch in diesem Patch noch die Hintertür für Denial-of-Service Angriffe offen wären. Hier stellte sich aber heraus, dass das Risiko nicht so hoch sei, wie zuerst angenommen.

Kann mich Link11 vor der Log4j-Schwachstelle schützen?

Die Systeme und Services von Link11 sind von der aktuellen Situation nicht betroffen, da wir selbst nicht mit der entsprechenden Java-Bibliothek arbeiten. Wären unsere Sicherheitslösungen kompromittiert gewesen, so hätten wir sofort mit einem Software-Update reagiert, um für den reibungslosen Einsatz unserer Schutzlösungen zu garantieren.

Für Kunden-Systeme bzw. deren Services bieten wir unsere hauseigene WAF (Web Application Firewall) an, die für umfassende Sicherheit sorgt. Hierfür haben wir am Wochenende eine neue Regel implementiert, die die dahinterliegenden Systeme vor einem Angriff über das Log4j-Protokoll schützt. Sollten Sie also Kunde unseres Web DDoS Services sein, können Sie diese neu bereitgestellte Regel jederzeit aktivieren, um für eine maximale Schutzleistung zu sorgen.

[vc_btn title=“Die Link11 Zero-Touch-WAF“ link=“url://www.link11.com/de/services/zero-touch-waf/“ el_class=“banner-blue-btn commen-btn“]

Sollten Sie Fragen haben oder sich für die Zero-Touch WAF von Link11 interessieren, können Sie sich gerne bei uns melden. Auch im Falle eines Notfalls stehen wir Ihnen natürlich jederzeit mit Rat und Tat zur Seite. Unser Team wird sich schnellstmöglich um die Anfrage kümmern.

[vc_btn title=“Jetzt Kontakt aufnehmen“ link=“url://www.link11.com/en/contact/“ el_class=“banner-green-btn commen-btn“]

Link11 in Gartners Market Guide for DDoS Mitigation Services gelistet
Verhinderung von Account-Takeover-Angriffen (ATO), Teil 4: Ratenbegrenzung
X