Die Sicherheitslücken CVE-2021-44228 und CVE-2021-45046 wurden in den Versionen 2.0 bis 2.15 der Apache Log4j-Bibliothek offengelegt. Das Apache Log4j-Dienstprogramm wird häufig für Logging-Anfragen verwendet. Durch diese Sicherheitslücke, die auch als Log4Shell bezeichnet wird, kann ein System mit den Apache Log4j-Versionen 2.0 bis 2.15 gefährdet werden und ein Angreifer kann beliebigen Code ausführen.
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 Abwehrtechniken wie Google Cloud Armor-Sicherheitsrichtlinien und die Identity-Aware Proxy-Zugriffssteuerung richtig konfiguriert sind und erwartungsgemäß funktionieren. Blockieren Sie diese Log4j 2-Exploitversuche.
- 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 Cloud Logging-Abfrageergebnisse enthalten nur Logs, die bereits in Log-Buckets gespeichert wurden und auch innerhalb der vom Nutzer angegebenen Aufbewahrungslimits 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 anstößigen 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. Wenn Sie das Feld remoteIp hinzufügen möchten, klicken Sie auf den Feldwert in einem übereinstimmenden Logeintrag und wählen Sie Feld zum Bereich „Logfelder“ hinzufügen aus, wie im folgenden Screenshot gezeigt:
Im Bereich Logfelder werden jetzt die Top-Remote-IP-Adressen angezeigt, die übereinstimmende Anfragen senden:
Dadurch erhalten Sie einen Überblick darüber, woher diese Exploit-Scans auf Log4j 2-Sicherheitslücken stammen. Bei einigen dieser Scans kann es sich um legitime Scans handeln, die über ein von Ihnen konfiguriertes Tool zum Scannen auf Sicherheitslücken in Anwendungen wie Web Security Scanner gesendet wurden. Falls Sie Web Security Scanner über Security Command Center verwenden, notieren Sie sich die von Web Security Scanner verwendeten statischen IP-Adressbereiche.
Nach Zielanwendungen suchen und Abwehrtechniken überprüfen
Vielleicht möchten Sie auch die Zielanwendungen aggregieren und ermitteln, ob schädliche Anfragen Ihre Anwendungen tatsächlich erreicht haben. Wenn Sie Abwehrtechniken mithilfe von Sicherheitsrichtlinien von Google Cloud Armor oder der Zugriffssteuerung durch Identity-Aware Proxy (IAP) aktiviert haben, können Sie auch anhand von Informationen, die in HTTP(S)-Load-Balancer-Logs protokolliert werden, prüfen, ob sie wie erwartet funktionieren.
Um die Zielanwendung dem Bereich Logfelder hinzuzufügen, wählen Sie eines der Ergebnisse des Logeintrags aus, maximieren Sie resource.labels, klicken Sie auf den Feldwert resource.labels.backend_service_name und wählen Sie dann Feld zum Bereich „Logfelder“ hinzufügen aus.
Sie sehen jetzt Ihre wichtigsten Anwendungen oder Back-End-Dienste, die von Log4j 2-Exploit-Scans angegriffen werden. Wenn Sie feststellen möchten, ob diese Exploit-Versuche überhaupt Ihren Back-End-Dienst erreicht haben, können Sie mithilfe des vom HTTP(S)-Load-Balancer gefüllten Feldes jsonPayload.statusDetails feststellen, ob die Anfrage an das Back-End weitergeleitet oder von Diensten wie IAP oder Google Cloud Armor erfolgreich blockiert wurde. Klicken Sie im Ergebnis des Logeintrags auf den Feldwert jsonPayload.statusDetails und wählen Sie Feld zum Bereich „Logfelder“ hinzufügen aus.
Im Bereich Logfelder sehen Sie jetzt eine Aufschlüsselung dazu, wie die Anfragen verarbeitet wurden:
In diesem Beispiel wurden die meisten Anfragen von IAP blockiert. Wenn dieses für einen Back-End-Dienst aktiviert ist, wird vor dem Zugriff die Identität des Nutzers überprüft und der Kontext verwendet. Bei diesen Anfragen, die von IAP blockiert sind, 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 außerdem statusDetails auf denied_by_security_policy festgelegt.
Informationen zum Anwenden der neuen vorkonfigurierten WAF-Regel cve-canary auf Ihre Google Cloud Armor-Sicherheitsrichtlinien finden Sie unter Google Cloud Armor-WAF-Regel zur Vermeidung von Apache Log4j-Sicherheitslücken.
Zum Filtern nach zulässigen Anfragen, die einen Back-End-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 WAF-Regel cve-canary anwenden, um diese Exploit-Versuche 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 an das zuständige Team für die Reaktion auf Vorfälle 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 die Google Cloud CLI verwenden, um einen solchen Messwert zu 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: