Le vulnerabilità di sicurezza CVE-2021-44228 e CVE-2021-45046 sono state rese note nelle versioni della libreria Apache Log4j da 2.0 a 2.15. L'utilità Apache Log4j è un'applicazione per la registrazione delle richieste. Questa vulnerabilità, chiamata anche Log4Shell, può consentire la compromissione di un sistema con Apache Log4j 2.0-2.15 e consentire a un malintenzionato di eseguire codice arbitrario.
Questa vulnerabilità non interessa Cloud Logging o gli agenti che fornisce per raccogliere i log da applicazioni di terze parti, ma se usi Log4j 2, il problema potrebbe interessare i servizi.
Puoi utilizzare Cloud Logging per identificare possibili attacchi. Questo documento descrive come fare quanto segue:
- Query sui log utilizzando Esplora log per i tentativi di sfruttamento esistenti la vulnerabilità di Log4j 2.
- Verifica che le tecniche di mitigazione abilitate, come i criteri di sicurezza di Google Cloud Armor e il controllo dell'accesso di Identity-Aware Proxy, siano configurate correttamente e funzionino come previsto bloccando questi tentativi di exploit di Log4j 2.
- Crea un criterio di avviso per ricevere una notifica quando si verifica un possibile exploit viene scritto nei tuoi log.
Consulta l'avviso di sicurezza Log4j 2 di Google Cloud per la nostra valutazione attuale dei prodotti e servizi Google Cloud. Puoi valutare la tua esposizione leggendo il report sulle vulnerabilità del National Institute of Standards and Technology (NIST) relativo a CVE-2021-44228.
Rilevamento di Cloud Logging
I risultati delle query di Cloud Logging includono solo i log già stati archiviati in bucket di log e si trovano anche all'interno del percorso limiti di conservazione. Sebbene la maggior parte dei servizi Google Cloud abbia log attivi per impostazione predefinita, i log disattivati o esclusi non lo sono incluse nelle tue query. Ti consigliamo di attivare i log nell'ambiente per espandere la visibilità dell'ambiente.
Se utilizzi un bilanciatore del carico HTTP(S), devi abilitare il logging affinché i log delle richieste siano disponibili in Cloud Logging. Analogamente, se hai server web come Apache o NGINX in esecuzione su una VM ma non hai installato Ops Agent o l'agente Logging, questi log non saranno accessibili all'interno di Cloud Logging.
Eseguire query sui log
Puoi utilizzare Esplora log per rilevare potenziali attacchi sul tuo servizio che sfruttano la vulnerabilità Log4j 2. Se utilizzi
Cloud Logging per registrare le richieste al tuo servizio, puoi controllare
httpRequest campi con contenuti generati dall'utente per i potenziali exploit.
I valori nei campi httpRequest potrebbero avere token di stringa come
${jndi:ldap://,
ma esistono molte varianti nel modo in cui questa vulnerabilità viene sfruttata.
Ad esempio, esistono molti modi per utilizzare caratteri di escape o Unicode per evitare il rilevamento.
Le seguenti stringhe mostrano alcuni esempi comuni che indicano tentativi di sfruttamento contro il sistema, ma non si tratta di un insieme esaustivo di varianti:
${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:-:}
In Esplora log puoi creare query per analizzare
delle possibili stringhe di exploit. Ad esempio, la seguente query tenta di
corrisponde a varie varianti offuscate della stringa ${jndi: in httpRequest
nei log delle richieste del bilanciatore del carico HTTP(S). Tieni presente che gli attributi standard
espressioni usate nella query non rilevano tutte le varianti e
potrebbero generare falsi positivi:
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)"
Puoi utilizzare la query precedente per eseguire la scansione dei log delle richieste in altri servizi modificando il valore di resource.type.
Il completamento della query precedente può richiedere molto tempo quando esegui la scansione di un volume elevato di log. Per velocizzare l'esecuzione delle query, puoi utilizzare i campi indicizzati come resource.type, resource.labels o logName per restringere la query a un insieme di servizi o stream di log specifici.
Il rilevamento di voci di log corrispondenti non significa che è stato eseguito un compromesso. Se viene rilevato qualcosa, ti consigliamo di seguire
il processo di risposta agli incidenti della tua azienda. Una corrispondenza potrebbe indicare che qualcuno sta tentando di sfruttare la vulnerabilità all'interno del tuo progetto o del tuo carico di lavoro. Oppure potrebbe essere un falso positivo, se la tua applicazione utilizza
pattern come ${jndi: nei campi della richiesta HTTP. Esamina i log per assicurarti che questo modello non faccia parte del normale comportamento dell'applicazione.
Perfeziona la query in modo che abbia senso per il tuo ambiente.
Cerca gli indirizzi IP in violazione
Se trovi risultati corrispondenti e se vuoi aggregarli sulla base dell'IP remoto
indirizzi che inviano queste richieste, quindi aggiungi il campo remoteIp
nel riquadro Campi log di Esplora log. Per aggiungere il campo remoteIp,
fai clic sul valore del campo in una voce di log corrispondente e seleziona Aggiungi campo al riquadro Campi log, come mostrato nello screenshot seguente:
Ora puoi vedere i principali indirizzi IP remoti che inviano richieste corrispondenti nel riquadro Campi log:
In questo modo puoi vedere da dove provengono queste analisi di exploit di vulnerabilità Log4j 2. Alcune di queste potrebbero essere scansioni legittime di uno strumento di scansione delle vulnerabilità delle applicazioni che potresti aver configurato, ad esempio Web Security Scanner. Se utilizzi Web Security Scanner da Security Command Center, prendi nota degli intervalli di indirizzi IP statici utilizzati da Web Security Scanner.
Cerca le applicazioni target e verifica le tecniche di mitigazione
Potresti anche aggregare le applicazioni target e identificare se le richieste dannose hanno effettivamente raggiunto le tue applicazioni. Se hai attivato tecniche di mitigazione che utilizzano i criteri di sicurezza di Google Cloud Armor o il controllo dell'accesso tramite Identity-Aware Proxy (IAP), puoi anche verificare che funzionino come previsto dalle informazioni registrate in HTTP(S) Log del bilanciatore del carico.
Innanzitutto, per aggiungere l'applicazione di destinazione al riquadro Campi log, scegli uno dei risultati della voce di log, espandi resource.labels, fai clic sul valore del campo resource.labels.backend_service_name e poi seleziona Aggiungi campo al riquadro Campi log.
Ora puoi vedere le tue applicazioni o i tuoi servizi di backend principali scelti come target da
Scansioni di exploit Log4j 2. Per determinare se questi tentativi di exploit hanno persino raggiunto
utilizza il campo jsonPayload.statusDetails compilato dal bilanciatore del carico HTTP(S) per
scopri se la richiesta è stata inviata tramite proxy al backend o bloccata
come IAP o Google Cloud Armor. Fai clic sul valore del campo jsonPayload.statusDetails
del risultato della voce di log e seleziona Aggiungi campo al riquadro Campi log.
Ora puoi visualizzare un'analisi dettagliata della modalità di gestione delle richieste nel riquadro Campi log:
In questo esempio, la maggior parte delle richieste è stata bloccata da IAP
che, se abilitato su un servizio di backend, verifica l'identità dell'utente e utilizza il contesto
prima di consentire l'accesso. Queste richieste bloccate IAP hanno statusDetails
impostato come handled_by_identity_aware_proxy. Inoltre (o in alternativa), se utilizzi Google Cloud Armor con il criterio di sicurezza corretto associato a un servizio di backend, tutte le richieste bloccate da Google Cloud Armor hanno statusDetails impostato su denied_by_security_policy.
Per dettagli su come applicare la nuova regola WAF cve-canary preconfigurata a Google Cloud Armor
criteri di sicurezza, vedi Regola WAF di Google Cloud Armor per contribuire a mitigare la vulnerabilità di Apache Log4j.
Per filtrare le richieste consentite che raggiungono effettivamente un servizio di backend, seleziona response_sent_by_backend
in statusDetails nel riquadro Campi log. Valuta la possibilità di abilitare IAP per questi servizi di backend
e/o l'applicazione di un criterio di sicurezza di Google Cloud Armor con la regola WAF cve-canary preconfigurata per contribuire a bloccare questi tentativi di exploit.
Crea un avviso basato su log
Dopo aver progettato una query che trova i log interessati nel tuo servizio, puoi utilizzare la query per creare un avviso basato su log che quando nuove voci di log corrispondono alla query. Questo avviso può essere inoltrato al tuo il centro operativo di sicurezza (SOC) dell’organizzazione o la risposta agli incidenti appropriata dell'IA.
Per informazioni sulla creazione di un avviso basato su log, consulta Creare un avviso basato su log (Esplora log). Quando crei l'avviso, assicurati di utilizzare la query per la stringa exploit anziché la query specificata nell'esempio.
Crea un criterio di avviso per una metrica basata su log
Per monitorare gli endpoint o i servizi che registrano possibili tentativi di exploit, crea un criterio di avviso per una metrica basata su log:
Crea una metrica basata su log per conteggiare le occorrenze di possibili stringhe di exploit nei log. Ad esempio, puoi utilizzare Google Cloud CLI per creare una metrica di questo tipo:
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)"'Per ulteriori informazioni sulla creazione di metriche basate su log, consulta Configurare le metriche dei contatori.
Crea un criterio di avviso per ricevere una notifica quando un numero selezionato di di ogni occorrenza. Per informazioni sulla configurazione di un avviso consulta Creare un criterio di avviso per una metrica del contatore.
Passaggi successivi
Controlla questo documento per gli aggiornamenti man mano che vengono rese disponibili nuove informazioni.
Per ulteriori informazioni sulla vulnerabilità di Log4j 2 e sui tuoi servizi Google Cloud, consulta quanto segue: