Die Sicherheitslücken CVE-2021-44228 und CVE-2021-45046 wurden in den Bibliotheksversionen 2.0 bis 2.15 von Apache Log4j offengelegt. Das Apache Log4j-Dienstprogramm wird häufig für Logging-Anfragen verwendet. Diese Sicherheitslücke, auch Log4Shell genannt, kann dazu führen, dass ein System, auf dem Apache Log4j-Versionen 2.0 bis 2.15 ausgeführt werden, manipuliert werden und ein Angreifer beliebigen Code ausführen kann.
Diese Sicherheitslücke wirkt sich nicht auf Cloud Logging oder die Agents aus, die Logs zum Erfassen von Anwendungen von Drittanbietern bereitstellen. Wenn Sie Log4j 2 verwenden, sind Ihre Dienste jedoch möglicherweise betroffen.
Sie können mit Cloud Logging mögliche Angriffe identifizieren. In diesem Dokument wird Folgendes beschrieben:
- Fragen Sie Ihre Logs über den Log-Explorer ab, um vorhandene Versuche der Log4j 2-Sicherheitslücke auszunutzen.
- Prüfen Sie, ob die aktivierten Abschwächungstechniken wie die Sicherheitsrichtlinien von Google Cloud Armor und die Zugriffssteuerung von Identity-Aware Proxy richtig konfiguriert sind und wie erwartet funktionieren, indem Sie diese Log4j 2-Ausnutzungsversuche blockieren.
- Erstellen Sie eine Benachrichtigungsrichtlinie, die Sie benachrichtigt, wenn eine mögliche Exploit-Nachricht in Ihre Logs geschrieben wird.
Lesen Sie die Log4j 2-Sicherheitswarnungen von Google Cloud für unsere aktuelle Bewertung der Google Cloud-Produkte und -Dienste. Sie können Ihre Gefährdung anhand des Berichts zu Sicherheitslücken vom National Institute of Standards and Technology (NIST) für CVE-2021-44228 bewerten.
Cloud Logging-Erkennung
Die Abfrageergebnisse für Cloud Logging umfassen nur Logs, die bereits in Log-Buckets gespeichert wurden und auch innerhalb der vom Nutzer angegebenen Aufbewahrungsdauer liegen. Während die meisten Google Cloud-Dienste standardmäßig Logs aktiviert haben, sind Logs, die deaktiviert oder ausgeschlossen sind, nicht in den Abfragen enthalten. Wir empfehlen, Logs in Ihrer gesamten Umgebung zu aktivieren, um die Sichtbarkeit der Umgebung zu erweitern.
Wenn Sie einen HTTP(S)-Load-Balancer verwenden, muss Logging aktiviert sein, damit die Anfragelogs in Cloud Logging verfügbar sind. Wenn Sie Webserver wie Apache oder NGINX auf einer VM ausführen, den Ops-Agent oder den Logging-Agent jedoch nicht installiert haben, gelten diese Logs für ist in Cloud Logging nicht zugänglich.
Logs abfragen
Mit dem Log-Explorer können Sie potenzielle Angriffe auf Ihren Dienst erkennen, die die Log4j 2-Sicherheitslücke ausnutzen. Wenn Sie Cloud Logging verwenden, um Anfragen an Ihren Dienst zu protokollieren, können Sie die httpRequest
-Felder mit nutzergenerierten Inhalten auf potenzielle Exploits prüfen.
Die Werte in den Feldern httpRequest
können String-Token wie ${jndi:ldap://
enthalten. Es gibt jedoch viele Variationen der Ausnutzung dieser Sicherheitslücke.
Es gibt beispielsweise viele Möglichkeiten, Escapezeichen oder Unicode zu verwenden, um die Erkennung zu vermeiden.
Die folgenden Strings zeigen einige gängige Beispiele, die auf Explorationsversuche mit Ihrem System hinweisen. Diese Liste ist jedoch nicht vollständig.
${jndi: $%7Bjndi: %24%7Bjndi: ${jNdI:ldAp ${jndi:${lower:l}${lower:d}${lower:a}${lower:p}: ${${lower:j}${lower:n}${lower:d}i: ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}: ${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}
Sie können im Log-Explorer Abfragen erstellen, die nach einigen möglichen Exploit-Strings suchen. Die folgende Abfrage versucht beispielsweise, verschiedene verschleierte Varianten des Strings ${jndi:
in Feldern des Typs httpRequest
in HTTP(S)-Load-Balancer-Anfragelogs abzugleichen. Die in der Abfrage verwendeten regulären Ausdrücke erkennen nicht alle Varianten und können zu falsch positiven Ergebnissen führen:
resource.type="http_load_balancer" httpRequest.requestUrl=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR httpRequest.userAgent=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR httpRequest.referer=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)"
Sie können die vorherige Abfrage verwenden, um Anfragelogs in anderen Diensten zu scannen. Ändern Sie dazu den Wert von resource.type
.
Die vorherige Abfrage kann sehr lange dauern, wenn Sie ein großes Logvolumen scannen. Um Ihre Abfragen schneller auszuführen, können Sie indexierte Felder wie resource.type
, resource.labels
oder logName
verwenden, um Ihre Abfrage auf eine Gruppe bestimmter Dienste oder Logstreams zu beschränken.
Die Erkennung übereinstimmender Logeinträge bedeutet nicht, dass der Vorgang erfolgreich manipuliert wurde. Wenn etwas erkannt wird, empfehlen wir, den Reaktionsprozess Ihrer Organisation zu befolgen. Eine Übereinstimmung kann darauf hinweisen, dass jemand versucht, die Sicherheitslücke in Ihrem Projekt oder Ihrer Arbeitslast auszunutzen. Oder es kann ein falsch-positives Ergebnis sein, wenn Ihre Anwendung Muster wie ${jndi:
in den HTTP-Anfragefeldern verwendet. Prüfen Sie Ihre Logs darauf, dass dieses Muster nicht Teil des normalen Anwendungsverhaltens ist.
Verfeinern Sie die Abfrage so, dass sie für Ihre Umgebung sinnvoll ist.
Nach fehlerhaften IP-Adressen suchen
Wenn Sie übereinstimmende Ergebnisse finden und die Remote-IP-Adressen zusammenfassen möchten, die solche Anfragen senden, fügen Sie das Feld remoteIp
dem Bereich Logfelder in den Log-Explorer hinzu. Klicken Sie auf den Feldwert in einem übereinstimmenden Logeintrag und wählen Sie Feld zum Logfeld hinzufügen aus, wie im folgenden Screenshot gezeigt, um das Feld remoteIp
hinzuzufügen:
Sie können jetzt die wichtigsten Remote-IP-Adressen sehen, die übereinstimmende Anfragen im Bereich Logfelder senden:
Hier sehen Sie, woher diese Scans stammen. Einige davon können legitime Scans von einem von Ihnen konfigurierten Tool zum Scannen von Anwendungslücken sein, z. B. Web Security Scanner. Wenn Sie Web Security Scanner über Security Command Center verwenden, notieren Sie sich die Bereiche mit statischen IP-Adressen, die von Web Security Scanner verwendet werden.
Nach anvisierten Anwendungen suchen und Maßnahmen zur Risikobewältigung überprüfen
Sie können auch die betroffenen Anwendungen zusammenfassen und feststellen, ob schädliche Anfragen Ihre Anwendungen tatsächlich erreicht haben. Wenn Sie Minderungstechniken mithilfe von Sicherheitsrichtlinien von Google Cloud Armor oder der Zugriffssteuerung von Identity-Aware Proxy (IAP) aktiviert haben, können Sie anhand der Informationen in den HTTP(S)-Load-Balancer-Logs prüfen, ob sie wie erwartet funktionieren.
Um die Zielanwendung dem Bereich Logfelder hinzuzufügen, wählen Sie zuerst einen der Logeintragsergebnisse aus, maximieren Sie resource.labels
, klicken Sie auf den Feldwert resource.labels.backend_service_name
und wählen Sie dann Feld in Bereich „Logfelder“ einfügen aus.
Sie können jetzt sehen, welche Ihrer wichtigsten Anwendungen oder Backend-Dienste von Log4j 2-Exploit-Scans betroffen sind. Um festzustellen, ob diese Exploit-Versuche Ihren Back-End-Dienst überhaupt erreicht haben, können Sie das Feld jsonPayload.statusDetails
verwenden, das vom HTTP(S) Load Balancer ausgefüllt wird. So sehen Sie, ob die Anfrage an das Backend weitergeleitet oder von Diensten wie IAP oder Google Cloud Armor blockiert wurde. Klicken Sie im Ergebnis des Logeintrags auf den Feldwert jsonPayload.statusDetails
und wählen Sie Feld in Bereich „Logfelder“ einfügen aus.
Im Bereich Logfelder sehen Sie jetzt eine Aufschlüsselung der Anfragebearbeitung:
In diesem Beispiel wurden die meisten Anfragen von IAP blockiert. Wenn IAP in einem Back-End-Dienst aktiviert ist, werden die Identität des Nutzers und der Nutzungskontext geprüft, bevor der Zugriff gewährt wird. Bei diesen von IAP blockierten Anfragen ist statusDetails
auf handled_by_identity_aware_proxy
festgelegt. Wenn Sie Google Cloud Armor mit der richtigen Sicherheitsrichtlinie verwenden, die an einen Back-End-Dienst angehängt ist, wird für alle von Google Cloud Armor blockierten Anfragen statusDetails
auf denied_by_security_policy
festgelegt.
Weitere Informationen dazu, wie Sie die neue vorkonfigurierte cve-canary
-WAF-Regel auf Ihre Google Cloud Armor-Sicherheitsrichtlinien anwenden, finden Sie unter Google Cloud Armor-WAF-Regel zur Bewahrung vor der Apache Log4j-Sicherheitslücke.
Wenn Sie nach zulässigen Anfragen filtern möchten, die tatsächlich einen Backend-Dienst erreichen, wählen Sie im Bereich Logfelder unter statusDetails
die Option response_sent_by_backend
aus. Sie können IAP für diese Back-End-Dienste aktivieren und/oder eine Google Cloud Armor-Sicherheitsrichtlinie mit der vorkonfigurierten cve-canary
-WAF-Regel anwenden, um diese Ausnutzungsversuche zu blockieren.
Logbasierte Benachrichtigung erstellen
Nachdem Sie eine Abfrage entwickelt haben, die betroffene Logs in Ihrem Dienst findet, können Sie mit dieser Abfrage eine logbasierte Benachrichtigung erstellen, die Sie benachrichtigt, wenn neue Logeinträge mit der Abfrage übereinstimmen. Diese Benachrichtigung kann an das Security Operations Center (SOC) Ihrer Organisation oder das entsprechende Incident-Response-Team weitergeleitet werden.
Informationen zum Erstellen einer logbasierten Benachrichtigung finden Sie unter Logbasierte Benachrichtigung erstellen (Log-Explorer). Verwenden Sie beim Erstellen der Benachrichtigung Ihre Abfrage für den Exploit-String anstelle der im Beispiel angegebenen Abfrage.
Benachrichtigungsrichtlinie für einen logbasierten Messwert erstellen
Erstellen Sie eine Benachrichtigungsrichtlinie für einen logbasierten Messwert, um zu überwachen, welche Endpunkte oder Dienste mögliche Exploit-Versuche protokollieren:
Logbasierten Messwert zum Zählen der Vorkommen möglicher Exploit-Strings in den Logs erstellen. Sie können beispielsweise mit der Google Cloud CLI einen solchen Messwert erstellen:
gcloud logging metrics create log4j_exploits \ --description="Detect log4j exploits" \ --log-filter='httpRequest.requestUrl=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR httpRequest.userAgent=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR httpRequest.referer=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)"'
Weitere Informationen zum Erstellen logbasierter Messwerte finden Sie unter Zählermesswerte konfigurieren.
Erstellen Sie eine Benachrichtigungsrichtlinie, um Sie zu benachrichtigen, wenn eine ausgewählte Anzahl von Vorkommen erreicht ist. Informationen zum Einrichten einer Benachrichtigungsrichtlinie finden Sie unter Benachrichtigungsrichtlinie für einen Zählermesswert erstellen.
Nächste Schritte
Prüfen Sie dieses Dokument auf Updates, sobald neue Informationen verfügbar sind.
Weitere Informationen zur Log4j 2-Sicherheitslücke und Ihren Google Cloud-Diensten finden Sie hier: