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 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 Gegenmaßnahmen wie Cloud Armor-Sicherheitsrichtlinien und Identity-Aware Proxy-Zugriffssteuerung richtig konfiguriert sind und wie erwartet funktionieren, indem Sie diese Log4j 2-Exploit-Versuche 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 Cloudfü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.
Protokollierungserkennung
Die Abfrageergebnisse für 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 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, sind diese Logs 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 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. 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:
So erhalten Sie eine Aufschlüsselung der Herkunft dieser Scans nach Exploits für Log4j 2-Sicherheitslücken. Einige davon sind möglicherweise legitime Scans von einem Tool zum Scannen von Anwendungssicherheitslücken, das Sie konfiguriert haben, z. B. Web Security Scanner. Wenn Sie Web Security Scanner über Security Command Center verwenden, beachten Sie die statischen IP-Adressbereiche, die von Web Security Scanner verwendet werden.
Nach gezielten Anwendungen suchen und Abhilfemaßnahmen überprüfen
Sie können auch die Zielanwendungen aggregieren und feststellen, ob schädliche Anfragen tatsächlich Ihre Anwendungen erreicht haben. Wenn Sie mit Sicherheitsrichtlinien von Cloud Armor oder mit der Zugriffssteuerung von Identity-Aware Proxy (IAP) Gegenmaßnahmen aktiviert haben, können Sie anhand der in den HTTP(S)-Load-Balancer-Logs protokollierten Informationen auch prüfen, ob sie wie erwartet funktionieren.
Um die Zielanwendung dem Bereich Logfelder hinzuzufügen, wählen Sie zuerst eines der Logeintragsergebnisse 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 können jetzt die wichtigsten Anwendungen oder Backend-Dienste sehen, die von Log4j 2-Exploit-Scans betroffen sind. Um festzustellen, ob diese Exploits überhaupt Ihren Back-End-Dienst erreicht haben, können Sie das Feld jsonPayload.statusDetails verwenden, das vom HTTP(S)-Load-Balancer ausgefüllt wird. So können Sie herausfinden, ob die Anfrage an das Back-End weitergeleitet oder von Diensten wie IAP oder 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 der Verarbeitung der Anfragen:
In diesem Beispiel wurde die Mehrzahl der Anfragen von IAP blockiert. Wenn IAP für einen Backend-Dienst aktiviert ist, wird die Identität des Nutzers und der Nutzungskontext überprüft, bevor der Zugriff gewährt wird. Bei diesen durch IAP blockierten Anfragen ist statusDetails auf handled_by_identity_aware_proxy festgelegt. Wenn Sie Cloud Armor mit der richtigen Sicherheitsrichtlinie verwenden, die an einen Back-End-Dienst angehängt ist, wird für alle von Cloud Armor blockierten Anfragen statusDetails auf denied_by_security_policy gesetzt. Weitere Informationen zum Anwenden der neuen vorkonfigurierten cve-canary-WAF-Regel auf Ihre Cloud Armor-Sicherheitsrichtlinien finden Sie unter Google Cloud Armor-WAF-Regel zur Bewahrung vor der Apache Log4j-Sicherheitslücke.
Wenn Sie nach allen 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.
Aktivieren Sie IAP für diese Back-End-Dienste und wenden Sie eine Cloud Armor-Sicherheitsrichtlinie mit der vorkonfigurierten cve-canary-WAF-Regel an, um diese Exploits zu blockieren.
Logbasierte Benachrichtigungsrichtlinie erstellen
Nachdem Sie eine Abfrage entwickelt haben, die betroffene Logs in Ihrem Dienst findet, können Sie mit dieser Abfrage eine logbasierte Benachrichtigungsrichtlinie erstellen, die Sie benachrichtigt, wenn neue Logeinträge mit der Abfrage übereinstimmen. Von der Benachrichtigungsrichtlinie erstellte Vorfälle können an das Security Operations Center (SOC) Ihrer Organisation oder das entsprechende Incident-Response-Team weitergeleitet werden.
Informationen zum Erstellen einer logbasierten Benachrichtigungsrichtlinie finden Sie unter Logbasierte Benachrichtigungsrichtlinie erstellen (Log-Explorer). Verwenden Sie beim Erstellen der Benachrichtigungsrichtlinie 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 IhrenGoogle Cloud -Diensten finden Sie hier: