Esempio: rilevare gli exploit di sicurezza di Log4Shell

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.

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:

Aggiungi "remoteIp" nel campo "Campi log" per determinare l'IP
che inviano il maggior numero di richieste corrispondenti.

Ora puoi vedere i principali indirizzi IP remoti che inviano richieste corrispondenti nel riquadro Campi log:

I principali indirizzi IP rimossi vengono visualizzati nella
Esplora 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:

I servizi di backend più scelti come target vengono visualizzati in Esplora 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:

  1. 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.

  2. 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