Die Apache Log4J-Schwachstelle: Fragebogen & VRM-Tipps

Apache Log4j 2, eine Java-basierte Logging-Bibliothek, war am 9. Dezember 2021 von einer Zero-Day-Schwachstelle betroffen. Die Schwachstelle, die als Log4Shell bekannt ist und vom National Institute of Standards and Technology (NIST) als CVE-2021-44228 identifiziert wurde, ermöglicht es Cyberkriminellen, die Kontrolle über anfällige Systeme und Server zu übernehmen.

Viele Webanwendungen, Open-Source-Cloud-Plattformen und Dienstanbieter verwenden Log4j. Diese weit verbreitete Nutzung könnte die interne Angriffsfläche Ihres Unternehmens und das Ökosystem von Drittanbietern der Log4Shell-Schwachstelle aussetzen. Um kritische Systeme und Daten effektiv zu schützen, muss Ihr Unternehmen die interne Nutzung von Log4j und die Nutzung der Protokollierungsbibliothek durch den Anbieter bewerten.

Lesen Sie weiter, um 11 Fragen zu erfahren, anhand derer Ihr Vendor Risk Management-Team ermitteln kann, wie Anbieter Log4j in Ihrer Lieferkette von Drittanbietern einsetzen und wie sich dies auf die Sicherheitslage Ihres Unternehmens auswirken könnte.

Erfahren Sie mehr über UpGuard Vendor Risk: die weltweit #1 Lösung für das Risikomanagement von Lieferanten>

Zusammenfassung der Log4Shell-Schwachstelle

Im Dezember 2021 gaben Sicherheitsforscher eine kritische Sicherheitslücke im Apache Log4j-Framework bekannt, die es böswilligen Hackern ermöglicht, anfällige Systeme durch eine einzige Code-Injektion zu kompromittieren.

In den ersten Tagen des Aufpralls identifizierten Sicherheitsforscher stündlich etwa 10 Millionen Log4Shell-Exploit-Versuche. Verschiedene Branchen sind anfällig für Log4Shell, da viele digitale Produkte und Software, einschließlich Microsoft- und IOS-Anwendungen, Java verwenden.

Der Einzelhandel war am stärksten von der Log4Shell-Schwachstelle betroffen, aber auch andere Sektoren, darunter Technologie, Finanzdienstleistungen, Fertigung und Gesundheitswesen.

Patchen der Log4J-Schwachstelle

Apache begann schnell mit der Entwicklung eines Patches für Log4Shell, nachdem es im Dezember 2021 auf die Schwachstelle aufmerksam geworden war. Log4j birgt jedoch aufgrund seiner weit verbreiteten Verwendung immer noch erhebliche Sicherheitsrisiken.

Jede Version von Log4j 2 vor 2.17.1 ist anfällig für die Log4Shell-Schwachstelle. Um sich effektiv vor dieser Schwachstelle zu schützen, müssen Unternehmen alle anfälligen Versionen von Log4j 2 angehen, die in ihrer internen Infrastruktur und in Ökosystemen von Drittanbietern verwendet werden.

Sicherheitsteams können das folgende Protokoll befolgen, um die Sicherheitslücke zu beheben:

  1. Update auf die neueste Version von Log4j 2
  2. Führen Sie Schwachstellenscans mit einem Scanner durch
  3. Aktualisieren von Java-Systemeigenschaften
  4. Deaktivieren von JNDI
  5. Senden eines Apache Log4j-Fragebogens an Anbieter
  6. Verwenden Sie eine Multi-Faktor-Authentifizierung

Lesetipp: Log4Shell: Die Log4J-Schwachstelle übersichtlich erklärt

Verwandte Log4J-Schwachstellen

Während Apache daran arbeitete, die Log4Shell-Schwachstelle zu beheben, entdeckten Forscher und Bedrohungsakteure zusätzliche Fehler in verschiedenen Versionen von Log4j. NIST hat diese Fehler mit den folgenden Codes identifiziert:

  • CVE-2021-45046: Ermöglicht Cyberkriminellen das Senden bösartiger JNDI-Lookups, die in Log4j 2.15 und niedriger vorhanden sind
  • CVE-2021-45105: Ermöglicht Cyberkriminellen die Durchführung von Denial-of-Service-Angriffen über bösartige Nachrichten, die in Log4j 2.16 und niedriger vorhanden sind

CVE-2021-44832: Eine Schwachstelle bei der Remotecodeausführung (Remote Code Execution, RCE), die es Hackern ermöglicht, Systeme mit beliebigem Code auszunutzen, wenn sie über erhöhte Berechtigungen verfügen, vorhanden in Log4j 2.17 und niedriger

11 Apache Log4J Fragen, die Sie Ihren Anbietern stellen sollten

Sicherheitsfragebögen sind eine der effektivsten Methoden, mit denen ein Unternehmen die Sicherheitslage seiner Drittanbieter bewerten kann. Ihr Unternehmen kann die folgenden 11 Fragen verwenden, um einen Sicherheitsfragebogen zu erstellen, um veraltete Versionen von Log4j im gesamten Anbieter-Ökosystem zu identifizieren.

Entdecken Sie die robuste Sicherheitsfragebogen-Bibliothek von UpGuard>

1. Verwendet Ihr Unternehmen eine Version von Log4j 2?

  • Ja
  • Nein
  • [Offenes Textfeld für Lieferantenkommentare]

2. Hat Ihr Unternehmen auf Log4j 2.17.1 aktualisiert, wie von der Apache Software Foundation und der CISA empfohlen?

  • Ja, die Organisation hat auf Log4j 2.17.1 aktualisiert.
  • Nein, die Organisation ist nicht in der Lage, auf Log4j 2.17.1 zu aktualisieren (bitte unten erklären)
  • Die Organisation hat noch nicht auf Log4j 2.17.1 aktualisiert
  • [Offenes Textfeld für Lieferantenkommentare]

3. Wenn nein, welche Version von Log4j 2 wird derzeit in Ihrem Unternehmen ausgeführt?

  • Die Organisation verwendet eine Version von Log4j 2 zwischen 2.7 und 2.14.1 (weiter zu Frage 3)
  • Die Organisation verwendet eine Version von Log4j 2 zwischen 2.0-beta9 und 2.10.0 (weiter zu Frage 4)
  • Die Organisation verwendet Log4j 2.17.1

4. Wenn Ihre Organisation eine Version von Log4j2 zwischen 2.7 und 2.14.1 verwendet, sollten Sie die folgenden Maßnahmen zur Risikominderung ergreifen:

a) Entweder die Systemeigenschaft log4j2.formatMsgNoLookups oder die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true gesetzt wurden

UND

b) Alle PatternLayout-Muster wurden in %m{nolookups} statt nur %m geändert

  • Die Organisation hat Vorsichtsmaßnahmen ergriffen a)
  • Die Organisation hat die Vorsichtsmaßnahme b)
  • Die Organisation hat Vorsichtsmaßnahmen a) und b) getroffen
  • [Offenes Textfeld für Lieferantenkommentare]

5. Wenn Ihre Organisation eine Version von Log4j2 zwischen 2.0-beta9 und 2.10.0 verwendet, sollten Sie die folgenden Maßnahmen zur Risikominderung ergreifen:

a) Entweder die Systemeigenschaft log4j2.formatMsgNoLookups oder die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true gesetzt wurden

UND

>

b) Die JndiLookup-Klasse wurde aus dem Pfad zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class entfernt.

  • Die Organisation hat Vorsichtsmaßnahmen ergriffen a)
  • Die Organisation hat die Vorsichtsmaßnahme b)
  • Die Organisation hat Vorsichtsmaßnahmen a) und b) getroffen
  • [Offenes Textfeld für Lieferantenkommentare]

6. Hat Ihr Unternehmen das GitHub-Repository von CISA verwendet, um Assets zu identifizieren, die für Log4Shell anfällig sind?

  • Ja
  • Nein
  • [Offenes Textfeld für Lieferantenkommentare]

7. Hat Ihr Unternehmen Indicators of Compromise (IOCs) identifiziert, die sich aus der Log4Shell-Schwachstelle ergeben?

  • Ja (bitte unten auflisten)
  • Nein
  • [Offenes Textfeld für Lieferantenkommentare]

8. Wie hat sich die Log4Shell-Schwachstelle auf Ihr Unternehmen ausgewirkt?

  • Die Schwachstelle betraf das Unternehmen nicht, und wir waren keinen Cyberangriffen oder Sicherheitsproblemen ausgesetzt, die sich aus der Schwachstelle ergaben
  • Die Schwachstelle wirkte sich nur mäßig auf das Unternehmen aus, aber es waren keine kritischen Systeme, Infrastrukturen, Dienste oder Daten betroffen (siehe unten).
  • Die Schwachstelle betraf direkt die kritischen Systeme, Infrastrukturen, Dienste und/oder Daten des Unternehmens (bitte erläutern Sie unten)
  • [Offenes Textfeld für Lieferantenkommentare]

9. Verfügt Ihr Unternehmen über einen Incident-Response-Plan, um auf Cyberbedrohungen zu reagieren?

  • Ja, das Unternehmen verfügt über einen Incident-Response-Plan
  • Das Unternehmen ist dabei, einen speziellen Incident-Response-Plan fertigzustellen
  • Nein, das Unternehmen verfügt nicht über einen Incident-Response-Plan
  • [Offenes Textfeld für Lieferantenkommentare]

10. Wie oft führt Ihr Unternehmen eingehende Risikobewertungen durch, um interne Sicherheitslücken zu bewerten?

  • Jährlich
  • Alle sechs Monate
  • Bei Bedarf, oder wir haben keinen geplanten Rhythmus für Risikobewertungen
  • [Offenes Textfeld für Lieferantenkommentare]

11. Wer ist der Ansprechpartner Ihres Unternehmens, wenn Sie weitere Fragen und Anliegen beantworten können?

  • Name:
  • Titel:
  • E-Mail:
  • Telefon:
  • [Offenes Textfeld für Lieferantenkommentare]

So beheben Sie Lieferantenrisiken

Wenn Ihr Unternehmen einen Apache Log4j-Sicherheitsfragebogen einsetzt und feststellt, dass ein Anbieter eine anfällige Version von Log4j 2 ausführt, müssen Sie das Risiko sofort beheben. Ihre Organisation sollte die Behebungsmaßnahmen auf der Grundlage der Kritikalität des Anbieters priorisieren, wenn mehrere Anbieter verfügbar sind.

Abhängig vom Grad des Sicherheitsbewusstseins des Anbieters muss Ihr Unternehmen möglicherweise mit dem Sicherheitsteam des Anbieters zusammenarbeiten, um die erforderlichen Updates und Behebungsprotokolle bereitzustellen.

Ihr Team kann den folgenden Behebungsworkflow befolgen, wenn es einen exponierten Anbieter identifiziert:

  • Kommunizieren Sie mit dem identifizierten Ansprechpartner und fordern Sie Abhilfe an
  • Schlagen Sie Maßnahmen zur Risikominderung vor, z. B. das Entfernen von JNDI-Lookups, das Aktualisieren auf die neueste Version von Log4j, die Verwendung des GitHub-Repositorys von CISA zur Inventarisierung von Anbietern und andere, die von Apache und CISA empfohlen werden
  • Kommunizieren Sie Erwartungen, Zeitpläne und beratende Konsequenzen für das Scheitern der Behebung
  • Senden eines neuen Sicherheitsfragebogens, um zu überprüfen, ob das Risiko behoben wurde

Empfohlene Lektüre: Auswahl einer automatisierten Software zur Behebung von Lieferantenrisiken im Jahr 2024

UpGuard ist ein Cybersicherheitsunternehmen, das Sicherheitsteams beim Schutz ihrer internen Angriffsflächen und Angriffsflächen von Drittanbietern unterstützt. Die beiden Produkte von UpGuard, Vendor Risk und BreachSight, ermöglichen es Unternehmen, ihre Cybersicherheit zu verbessern, die Sicherheitslage einzelner Anbieter zu bewerten und ein robustes Lieferantenrisikomanagement und Cyber-Risikomanagementprotokolle einzusetzen.

Die Schwachstellenscan- und Schwachstellenbewertungsfunktionen von UpGuard ermöglichen es Unternehmen, verschiedene Schwachstellen zu identifizieren, die sich auf ihre Sicherheitslage auswirken und zu Cyberangriffen wie Malware oder Ransomware führen können.

UpGuard Vendor Risk und BreachSight umfassen die folgenden Funktionen:

  • Erkennung von Datenlecks: Schützen Sie den Ruf Ihrer Marke, das geistige Eigentum und die Kundendaten durch die rechtzeitige Erkennung von Datenlecks
  • Kontinuierliche Überwachung: Erhalten Sie Echtzeit-Updates und verwalten Sie Schwachstellen auf Ihrer gesamten Angriffsfläche, einschließlich Domains, IPs, Apps, Endpunkten, Plugins und Firewalls
  • Reduzierung der Angriffsfläche: Reduzieren Sie Ihre Angriffsfläche, indem Sie ausnutzbare Schwachstellen und Domänen entdecken, die durch Typosquatting gefährdet sind
  • Freigegebenes Sicherheitsprofil: Erstellen Sie ein freigegebenes UpGuard-Profil, um das lästige Beantworten von Sicherheitsfragebögen zu vermeiden
  • Workflows und Verzichtserklärungen: Optimieren Sie Korrektur-Workflows, verzichten Sie schnell auf Risiken und reagieren Sie auf Sicherheitsanfragen
  • Berichte und Einblicke: Greifen Sie auf maßgeschneiderte Berichte für verschiedene Stakeholder zu und zeigen Sie Informationen über Ihre externe Angriffsfläche an.
  • Sicherheitsfragebögen für Anbieter: Automatisieren Sie Sicherheitsfragebögen, um einen tieferen Einblick in Ihre Lieferantenbeziehungen und die Sicherheitslage von Drittanbietern zu erhalten
  • Sicherheitsbewertungen: Bewerten Sie die Sicherheitslage einzelner Anbieter anhand unserer datengestützten, objektiven und dynamischen Sicherheitsbewertungen.
  • Risikobewertungen: Optimieren Sie Arbeitsabläufe bei der Risikobewertung, sammeln Sie Nachweise und fordern Sie schnell Abhilfemaßnahmen an

Verwandte Artikel