news image

Ein Wochenende im Dezember 2021 aka log4jshell

Am 9.12.2021 wurde eine kritische Sicherheitslücke in Java-Bibliothek Log4j bekannt (CVE-2021-44228, Base Score 10 CRITICAL CVSS3.x)1. Das BSI stufte diese am 11.12.2021 als extrem kritische Bedrohungslage ein und veröffentlichte eine Cyber-Sicherheitswarnung der Warnstufe Rot2. Diese Einschätzung ergibt sich aus folgenden Faktoren:

  • Java und Java Bibliotheken sind sehr weit verbreitet3
  • Ein Angreifer kann remote ohne Authentifizierung auf einem System eigenen Code ausführen und damit das System übernehmen
  • Die Ausnutzung der Schwachstelle ist relativ einfach
  • Proof-of-Concept POC lag bereits vor4
  • Massen Scans suchten nach verwundbaren Systemen5

Viele Unternehmen und Behörden mussten sich ab Samstag, dem 11.12.2021, die Frage stellen, ob sie von dieser Sicherheitslücke betroffen sind. Insbesondere wenn die Unternehmung Teil der KRITIS ist oder personenbezogene Daten verarbeitet werden, gewinnt diese Fragestellung an Bedeutung. In beiden Fällen könnte eine Meldepflicht6 7 gegenüber den Behörden bestehen.

Vorgehensweise
Entsprechend dem Incident Response Prozess8 (Preparation, Detection & Analysis, Containment und Post Incident Activity) beginnt man nach Bekanntwerden der Sicherheitslücke mit der Detection & Analysis Phase. Hier ist die Geschwindigkeit der Reaktionen elementar wichtig. In einem Wettlauf gegen die Zeit müssen die notwendigen Gegenmaßnahmen rechtzeitig umgesetzt werden9.

Be fast
Auch ohne eigene Softwareentwicklung in Java war bereits am Freitag klar, dass eine Vielzahl von Unternehmen mit hoher Wahrscheinlichkeit von dieser Sicherheitslücke betroffen ist. Die Analyse der Angriffsoberfläche zeigte, dass es nicht nur mit dem Internet verbundene Systeme betrifft, sondern die Problematik auch weit in den Backend hineinreichen kann. Grund hierfür ist, dass die Sicherheitslücke auf einer Funktion von Log4j basiert, die Einträge in Logdateien interpretiert, um dann ggf. einen externen Code auszuführen. Damit war klar, dass es auch Industrial Systeme, Embedded Systeme, Desktop Anwendungen und Insellösungen wie Hotspots betreffen wird.

Defence in depth
Mit dem Wissen um die Angriffsvektoren und zur Reduzierung der Angriffsoberfläche wurden die Outbound Firewall Regeln geprüft, um sicherzustellen, dass kein internes System den Verbindungsaufbau in das Internet durchführen kann.
Im nächsten Schritt sucht man nun nach Anzeichen einer Kompromittierung (Indicator of Compromise (IoC)) in den Systemen. Hier stellt sich zunächst die Frage, welche Hard- und Software-Systeme überhaupt relevant sind und mit welcher Priorität betrachtet werden sollen.

Asset Management
Zu Beginn des Wochenendes lagen nur wenige Herstellermeldungen vor, sodass nach einer möglichen Verwendung von Java eine manuelle Prüfung von Asset Datenbanken und von Vulnerability Scans (die die Vulnerabilität noch nicht erkannten) notwendig wurde. Sehr hilfreich erwies sich hier der Abgleich von Listen der betroffenen Systeme, die seit Sonntag auf GitHub zusammengetragen werden10.

Herstelleranfrage
Zusätzlich wurden am Wochenende Anfragen an Hersteller und Lieferanten gestellt, insbesondere wenn es sich um kritische Systeme oder um kleine Anbieter handelte. Der Rücklauf dieser Anfragen war überwiegend schnell und aussagekräftig.

Patches
Für die Java-Bibliothek Log4j liegen bereits seit Montag, dem 13.12.2021, Patches11 vor. Dies ist jedoch in erster Linie nur für Unternehmungen interessant, die diese Bibliothek für ihre Produkte oder Services nutzen. Ist ein Produkt (Router, End-Point-Security, Hotspot, etc.) von der Sicherheitslücke betroffen, muss auf den Patch des Herstellers gewartet werden. Hier müssen ggf. zusätzliche Sicherheitsmaßnahmen wie Monitoring, Einschränkung der Kommunikationsverbindungen oder das Abschalten des Dienstes ergriffen werden.

Ein Wochenende?
Diese Sicherheitslücke ist wohl die gravierendste des Jahres 2021 und wird uns sicherlich noch mehrere Wochen in 2022 beschäftigen. Hintergrund ist zum einen, dass neue Sicherheitslücken hinzukommen (CVE-2021-45105, CVE-2021-45046 und CVE-2021-44832)12 und dass Hersteller bzw. Softwareentwickler ihre Systeme und Dienste erst überprüfen müssen und mit weiteren betroffenen Systemen zu rechnen ist. Neben der klassischen IT ist auch der industrielle Bereich betroffen. So berichtete das BSI, dass auch Hersteller im industriellen Umfeld betroffen sind (Siemens, Schneider Electric und Rockwell Automation)13.
Inzwischen (03.01.2022) gibt es über 750 Meldungen von Herstellern, die von der Sicherheitslücke betroffen sind14. Auch der Bereich IoT ist von dieser Sicherheitslücke betroffen. So berichtete Bosch am 14.12.2021, dass die Bosch IoT Suite betroffen sei15.

Lessons learned
Auch wenn es nicht wirkliche neue Erkenntnisse sind, so hat sich doch gezeigt, dass wesentliche Erfolgsfaktoren für eine Bewältigung des Indicents die Bereitstellung bzw. das Vorhandensein von

  • qualifiziertem Personal
  • einem etablierten Incident Response Prozess
  • Geschwindigkeit bei der Analyse
  • der Fähigkeit, Entscheidungen schnell zu treffen,
  • einem aktuellen und vollständigen Asset Management System und
  • Audit Reports

sind. Für Unternehmungen mit eigener Softwareentwicklung hat diese Sicherheitslücke gezeigt, wie wichtig ein unternehmensinternes Software Repository ist, das ausschließlich für die Entwicklung genutzt werden darf. Nur so lässt sich nachvollziehen, welche Bibliothek und Programme in welcher Version wo genutzt werden. Diese wird durch den zunehmenden Einsatz von Container- und Microservice basierenden Anwendungen weiter an Bedeutung gewinnen, da die Funktionsweise des Container- und Microservice (welche Programme und Bibliotheken werden innerhalb des Container- und Microservice verwendet) oftmals nicht transparent ist. Insbesondere bei der Nutzung von Open Source Software bietet sich an, kritische Komponenten einem Code Review zu unterziehen und dies den Entwicklern zurückzumelden.

Ausblick 2022
Die Untersuchungen von Systemen und Anwendungen in Unternehmen werden wie beschrieben noch anhalten. Da die Sicherheitslücke auch für die Ausweitung von Privilegien bzw. der seitlichen Bewegung (engl. lateral movement16) nach einem Angriff geeignet ist, sollten in der Post Incident Activity Phase entsprechende weitergehende Untersuchungen stattfinden.

Weitere Informationen
BSI: Arbeitspapier Detektion und Reaktion Log4j Schwachstelle, Version 1.4
tagesschau live: BSI informiert über IT-Sicherheitslücke

Nationaal Cyber Security Centrum (NCSC-NL):

by Bernd Kohler @ dainox 26-01-2022

 


[1] nvd.nist.gov/vuln/detail/CVE-2021-44228

[2] www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2021/211211_log4Shell_WarnstufeRot.html

[3] security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html

[4] github.com/tangxiaofeng7/apache-log4j-poc (gelöscht)

[5] CEO of Cloudflare twitter.com/eastdakota/status/1469800951351427073

[6] §8b Abs. 4 BSIG

[7] Art. 33 DSGVO

[8] nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf

[9] B. Schneier, “The Future of Incident Response,” in IEEE Security & Privacy, vol. 12, no. 5, pp. 96-96, Sept.-Oct. 2014, doi: 10.1109/MSP.2014.102.

[10] https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

[11] logging.apache.org/log4j/2.x/changes-report.html

[12] logging.apache.org/log4j/2.x/

[13] www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549177-1032.pdf

[14] gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

[15] https://bosch-iot-suite.com/news/apache-log4j-rce-vulnerability/

[16] https://www.ncsc.gov.uk/guidance/preventing-lateral-movement

Bits And Splits/ stock.adobe.com ©