Die weit verbreitete Open Source Bibliothek Apache Log4j, die in vielen Softwarepaketen verwendet wird, um Anwendungsmeldungen zu protokollieren, enthält eine kritische Zero Day Sicherheitslücke (CVE-2021-44228). Die auch Log4Shell genannte Schwachstelle ist trivial ausnutzbar und kann weitreichende Folgen nach sich ziehen: Laut CERT.at ist die vollständige Kompromittierung des betroffenen Systems möglich.[1]

Breite Scans nach verwundbaren Systemen und aktives Ausnützen der Log4j-Schwachstelle

Nicht nur ein Proof-of-Concept für das Ausnutzen der Sicherheitslücke ist öffentlich verfügbar. Es kursieren auch Beispielskripte, die Systeme stichprobenartig auf diese Schwachstelle scannen. Diese sind zwar nicht geeignet, um Sicherheit über die Verwundbarkeit der eigenen Systeme zu schaffen, helfen Kriminellen jedoch beim Auffinden geeigneter Opfersysteme.

Log4Shell könnte Auswirkungen auf alle aus dem Internet erreichbaren Anwendungen haben, die Log4j einsetzen, um Nutzeranfragen protokollieren. Dementsprechend wurde vom BSI (Bundesamt für Sicherheit und Informationstechnik) die höchste Warnstufe für eine extrem kritische IT-Bedrohungslage vergeben. Das BSI bestätigt außerdem breite Scan-Aktivitäten nach verwundbaren Systemen sowie Kompromittierungen mit Kryptominern, durch Botnetze sowie das Nachladen von Cobalt Strike-Beacons.[2] Ebenso wurden Versuche beobachtet, Systeme mit Khonsari, eine neue Ransomware-Familie, zu infizieren.[3] Durch den Zugriff auf vertrauliche Daten kann die Lücke aber auch ohne den Einsatz von Malware ausgenutzt werden.

Maßnahmen und Möglichkeiten, um das Ausnützen der Schwachstelle zu verhindern

Das BSI empfiehlt allgemein, nicht zwingend benötigte betroffene Systeme abzuschalten sowie Netzwerke zu segmentieren, um verwundbare Systeme zu isolieren. Bei kritischen Systemen sollten Angriffsmuster auf WAF (Web Application Firewalls), IPS (Intrusion Prevention Systems) und Proxys unmittelbar abgewiesen oder nicht zwingend benötigte HTTP-Header auf statische Werte gesetzt werden. Ausgehende Verbindungen, die nicht zwingend benötigt werden, sollten blockiert werden. Alle Verbindungen sind für eventuelle spätere Incident Response Maßnahmen mitzuloggen und zu protokollieren. Es empfiehlt sich, die Rechtvergabe betroffener Dienste zu prüfen und ggf. zu reduzieren, Verbindungen zu anderen Systemen zu trennen und Hosts auf Anomalien zu überwachen.

Abhilfe gegen Log4Shell sollte ein Patch auf die Log4j-Version 2.16 schaffen. Vorherige Versionen lösten das Problem nur unzureichend oder waren selbst von Sicherheitsmängeln betroffen.[4]

Für Updates zur Sicherheitsmaßnahmen verfolgen Sie bitte den Betrag auf CERT.at: https://cert.at/de/warnungen/2021/12/kritische-0-day-sicherheitslucke-in-apache-log4j-bibliothek.

Das nationale CERT der Niederlande (NCSC-NL) hat zudem eine Liste von Gegenmaßnahmen veröffentlicht: https://github.com/NCSC-NL/log4shell/tree/main/mitigation.

Auch die folgende Darstellung des nationalen CERT der Schweiz skizziert verfügbare Abwehrmaßnahmen.

Quelle: https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/

Risikobetrachtungen bei der Absicherung industrieller Anlagen gegen Sicherheitslücken

Industrielle Anlagen sollten unabhängig von der akuten Bedrohungslage nie von extern erreichbar und mit zwei DMZ (Demilitarisierten Zonen) vor Zugriffen aus dem Internet geschützt sein. Hier liegt ein häufiger Fehler darin, dass VLANs nicht korrekt über Cluster Firewalls geschützt werden, sodass abgetrennte Bereiche wieder erreichbar sind. Abhilfe verschaffen eine dezidierte Perimeter DMZ und eine IT/OT DMZ.

Systemausfälle haben in der OT weitreichendere Folgen als in der IT, weshalb hier eine gesonderte Risikobetrachtung der empfohlenen Maßnahmen – Sytemhärtung, Abschaltung von der Schwachstelle betroffenen Funktionen oder Patch der betroffenen Systeme etc – zu treffen ist. Auch eine Mitigation mit Ersatzmaßnahmen, im Idealfall kombiniert mit einer strengen Reglementierung der Zugriffsmöglichkeiten über das OfficeNet, kann ein gangbarer Weg sein.

Ein gepflegtes aktuelles Hardware und Software Inventory samt verwendeter Bibliotheken hilft sehr viel, um ausgehende Risiken von Zero Day Schwachstellen einschätzen zu können. Für aktuelle Informationen über Verwundbarkeiten und Patches empfiehlt sich die aktive Zusammenarbeit mit System Integratoren und Hardware Herstellern.

Softwarelösungen und Security Services für Präventions- und Akutmaßnahmen

Grundsätzlich gilt es bei der Systemabsicherung zu beachten, dass es nicht reicht, die Log4j über die Softwareverwaltung von Betriebssystemen zu aktualisieren, wenn eine Software die Bibliothek in ihre eigenen Auslieferungsdateien integriert hat oder eine verwundbare Java-Anwendung im Einsatz ist. Hersteller-Updates sollten sofort installiert werden.

Die Services von IKARUS und Nozomi Networks sind von der Log4j-Schwachstelle nicht betroffen. IKARUS unterstützt Sie bei der Absicherung Ihrer IT-Systeme mit den Intrusion Detection Systemen von FireEye. Die FireEye Produkte sind ebenfalls nicht betroffen bzw. wurden anfällige Produkte frühzeitig gepatched.

FireEye NX erkennt Versuche, die Schwachstelle auszunutzen, und verhindert diese im IPS Modus. Auch FireEye Helix hat bereits ein eigenes Regelwerk, um in indizierten Logs Exploitversuche zu erkennen. FireEye HX kann für das Hunting bei kompromittierten Systemen benutzt werden. Entsprechende OpenIOC Files stehen für FireEye Kund*innen über das Customer Portal zur Verfügung.

Speziell für den OT-Bereich ermöglicht IKARUS mit den Technologien von Nozomi Networks vollständiges Netzwerk-Monitoring (vgl. IDS/IPS) und Anomalie-Erkennung. Die Nozomi Guardian Threat Intelligence wurde bereits für die Erkennung und Abwehr der Log4Shell-Angriffe aufgerüstet[5]. Eine detaillierte Analyse der Schwachstelle und weitere Informationen zu vorhersehbaren Angriffen finden Sie im Nozomi Blogbeitrag Critical Log4Shell (Apache Log4j) Zero-Day Attack Analysis.

Kontaktieren Sie uns jetzt unter +43 1 58995-500 oder sales@ikarus.at zur Abwehr von Cyberangriffen sowie für Ihr professionelles Incident Response Management!

Weiterlesen:

IKARUS 24/7 incident.reponse: Notfallplan für Sicherheitsvorfälle in IT, OT oder IoT Umgebungen

Quellen: