Sicherheitslücken CVE-2021-44228 und CVE-2021-45046 in den Apache Log4j Bibliotheksversionen 2.0 bis 2.15. Das Apache Log4j-Dienstprogramm wird häufig für Logging-Anfragen verwendet. Diese Sicherheitslücke, auch Log4Shell genannt, kann dazu führen, Apache Log4j-Versionen 2.0 bis 2.15 kompromittiert werden sollte, weil Angreifer 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 Ihre aktivierten Minderungstechniken wie Google Cloud Armor Sicherheitsrichtlinien und die Zugriffssteuerung für Identity-Aware Proxy richtig konfiguriert und erwartungsgemäß funktionieren, indem sie diese Log4j 2-Exploits 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
Cloud Logging-Abfrageergebnisse enthalten nur Logs, die bereits die in Log-Buckets gespeichert sind und sich auch in den vom Nutzer festgelegten Aufbewahrungsdauer. 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 sehen jetzt die Top-Remote-IP-Adressen, die übereinstimmende Anfragen senden im Bereich Logfelder:
Sie erhalten eine Aufschlüsselung, wo diese Log4j 2-Exploit-Scans auf Sicherheitslücken ausgeführt wurden. von denen Sie stammen. Bei einigen dieser Dateien kann es sich um legitime Scans von einer Anwendung handeln. Tool zum Scannen auf Sicherheitslücken, das Sie möglicherweise konfiguriert haben, z. B. Web Security Scanner Wenn Sie Web Security Scanner über Security Command Center verwenden, notieren Sie sich die statischen IP-Adressbereiche, die von Web Security Scanner verwendet werden.
Nach ausgewählten Anwendungen suchen und Techniken zur Schadensbegrenzung überprüfen
Sie können auch die Zielanwendungen aggregieren und ermitteln, dass schädliche Anfragen in Ihren Anwendungen angekommen sind. Wenn Sie mit Sicherheitsrichtlinien von Google Cloud Armor oder der Zugriffssteuerung durch Identity-Aware Proxy (IAP) können Sie auch anhand der in HTTP(S) protokollierten Informationen überprüfen, ob sie wie erwartet funktionieren. Load-Balancer-Logs.
Um die Zielanwendung dem Bereich Logfelder hinzuzufügen, wählen Sie zuerst eine der
Logeintragsergebnisse, maximieren Sie resource.labels und klicken Sie auf resource.labels.backend_service_name
Feldwert und wählen Sie dann Feld zum Bereich „Logfelder“ hinzufügen aus.
Sie können jetzt Ihre Top-Anwendungen oder Back-End-Dienste sehen,
Log4j 2-Exploit-Scans Um festzustellen, ob diese Exploit-Versuche Ihren
Back-End-Dienst verwenden, verwenden Sie das vom HTTP(S)-Load-Balancer ausgefüllte Feld jsonPayload.statusDetails, um
erfahren, ob die Anfrage an das Back-End weitergeleitet oder erfolgreich blockiert wurde
wie IAP oder Google Cloud Armor. Klicken Sie auf jsonPayload.statusDetails.
aus dem Ergebnis des Logeintrags und wählen Sie Feld zum Bereich „Logfelder“ hinzufügen aus.
Im Bereich Logfelder wird jetzt eine Aufschlüsselung der Verarbeitung der Anfragen angezeigt:
In diesem Beispiel wurden die meisten Anfragen von IAP blockiert.
die bei Aktivierung in einem Backend-Dienst die Identität des Nutzers überprüft und den Kontext verwendet
bevor du den Zugriff erlaubst. Bei diesen von IAP blockierten Anfragen ist statusDetails auf handled_by_identity_aware_proxy festgelegt. Zusätzlich (oder alternativ), falls
mit Google Cloud Armor mit der richtigen Sicherheitsrichtlinie,
die an einen Back-End-Dienst angehängt ist,
Für alle von Google Cloud Armor blockierten Anfragen ist statusDetails auf denied_by_security_policy festgelegt.
Weitere Informationen zum Anwenden der neuen vorkonfigurierten WAF-Regel cve-canary auf Google Cloud Armor
Sicherheitsrichtlinien finden Sie unter Google Cloud Armor-WAF-Regel zum Beheben der Apache Log4j-Sicherheitslücke.
Um nach zulässigen Anfragen zu filtern, die tatsächlich einen Backend-Dienst erreichen, wählen Sie response_sent_by_backend aus.
unter statusDetails im Bereich Logfelder. 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 Ihr das Security Operations Center (SOC) des Unternehmens oder eine entsprechende Reaktion auf Vorfälle Team.
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 Methode Google Cloud CLI, 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 Konfigurieren Sie Zählermesswerte.
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: