Esempio: rilevare gli exploit di sicurezza di Log4Shell

Le vulnerabilità di sicurezza CVE-2021-44228 e CVE-2021-45046 sono state divulgate nella libreria di Apache Log4j versioni da 2.0 a 2.15. L'utilità Apache Log4j è un componente di uso comune per le richieste di logging. Questa vulnerabilità, chiamata anche Log4Shell, può consentire la compromissione di un sistema che esegue Apache Log4j dalla versione 2.0 alla versione 2.15 e consentire a un utente malintenzionato di eseguire codice arbitrario.

Questa vulnerabilità non influisce su Cloud Logging o sugli agenti che fornisce per raccogliere i log da applicazioni di terze parti, ma se utilizzi Log4j 2, i servizi potrebbero essere interessati.

Puoi utilizzare Cloud Logging per identificare possibili attacchi. Questo documento descrive come:

  • Esegui una query sui tuoi log utilizzando Esplora log per cercare tentativi esistenti di sfruttare la vulnerabilità di Log4j 2.
  • Verifica che le tue tecniche di mitigazione abilitate come i criteri di sicurezza di Google Cloud Armor e controllo dell'accesso Identity-Aware Proxy siano configurati correttamente e funzionino come previsto bloccando questi tentativi di exploit di Log4j 2.
  • Crea un criterio di avviso per ricevere una notifica quando nei log viene scritto un possibile messaggio di exploit.

Esamina l'Advisory sulla sicurezza di Log4j 2 di Google Cloud per la nostra attuale valutazione dei prodotti e dei servizi Google Cloud. Puoi valutare la tua esposizione leggendo il report sulle vulnerabilità del National In Institute of Standards and Technology (NIST) per CVE-2021-44228.

Rilevamento di Cloud Logging

I risultati delle query di Cloud Logging includono solo i log già archiviati nei bucket di log e che rientrano nei limiti di conservazione specificati dall'utente. Sebbene la maggior parte dei servizi Google Cloud abbia log abilitati per impostazione predefinita, i log che sono stati disattivati o esclusi non sono inclusi nelle query. Ti consigliamo di attivare i log in tutto l'ambiente per aumentare la tua visibilità nell'ambiente.

Se utilizzi un bilanciatore del carico HTTP(S), devi abilitare il logging affinché i log delle richieste siano disponibili in Cloud Logging. Allo stesso modo, se hai server web come Apache o NGINX in esecuzione su una VM, ma non hai installato l'Ops Agent o l'agente Logging, questi log non saranno accessibili all'interno di Cloud Logging.

Puoi utilizzare Esplora log per rilevare potenziali attacchi al servizio che sfruttano la vulnerabilità di Log4j 2. Se utilizzi Cloud Logging per registrare le richieste al tuo servizio, puoi controllare i campi httpRequest con contenuti generati dagli utenti per individuare potenziali exploit.

I valori nei campi httpRequest potrebbero avere token stringa come ${jndi:ldap://, ma esistono molte variazioni nel modo in cui questa vulnerabilità viene sfruttata. Ad esempio, esistono molti modi per utilizzare l'escape o Unicode per evitare il rilevamento. Le seguenti stringhe mostrano alcuni esempi comuni che indicano tentativi di sfruttamento del tuo 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 che analizzano alcune delle possibili stringhe di exploit. Ad esempio, la seguente query cerca di trovare corrispondenze con varie varianti offuscate della stringa ${jndi: nei campi httpRequest dei log delle richieste del bilanciatore del carico HTTP(S). Tieni presente che le espressioni regolari utilizzate 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 scansionare i log delle richieste in altri servizi modificando il valore resource.type.

Il completamento della query precedente può richiedere molto tempo quando esegui l'analisi di grandi volumi di log. Per velocizzare l'esecuzione delle query, puoi utilizzare campi indicizzati come resource.type, resource.labels o logName per restringere la query a un insieme di servizi o flussi di log specifici.

Il rilevamento delle voci di log corrispondenti non significa che è stato commesso un compromesso. Se viene rilevato qualcosa, ti consigliamo di seguire la procedura di risposta agli incidenti della tua organizzazione. Una corrispondenza potrebbe indicare che qualcuno sta esplorando per sfruttare la vulnerabilità all'interno del tuo progetto o carico di lavoro. Oppure potrebbe essere un falso positivo se l'applicazione utilizza pattern come ${jndi: nei campi delle richieste HTTP. Controlla i log per assicurarti che questo pattern non faccia parte del normale comportamento dell'applicazione. Perfeziona la query in modo che abbia senso per il tuo ambiente.

Cercare indirizzi IP in violazione

Se trovi risultati corrispondenti e vuoi aggregare gli indirizzi IP remoti che inviano queste richieste, aggiungi il campo remoteIp al riquadro Campi log in 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 dei campi dei log, come mostrato nello screenshot seguente:

Aggiungi il campo "remoteIp" al riquadro "Campi del log" per determinare gli indirizzi IP che inviano il maggior numero di richieste corrispondenti.

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

Gli indirizzi IP rimossi più in alto vengono visualizzati in Esplora log.

Questo ti offre una suddivisione della provenienza di queste analisi degli exploit di vulnerabilità Log4j 2. Alcune di queste potrebbero essere scansioni legittime da uno strumento di analisi delle vulnerabilità delle applicazioni che potresti aver configurato, come Web Security Scanner. Se utilizzi Web Security Scanner di Security Command Center, prendi nota degli intervalli di indirizzi IP statici utilizzati da Web Security Scanner.

Cerca applicazioni mirate e verifica le tecniche di mitigazione

Puoi anche aggregare i dati in base alle applicazioni target e identificare se le richieste dannose hanno effettivamente raggiunto le tue applicazioni. Se hai abilitato le tecniche di mitigazione utilizzando 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 nei log del bilanciatore del carico HTTP(S).

Innanzitutto, per aggiungere l'applicazione scelta come target al riquadro Campi log, scegli uno dei risultati voce di log, espandi resource.labels, fai clic sul valore del campo resource.labels.backend_service_name e seleziona Aggiungi campo al riquadro dei campi di log.

Ora puoi vedere le tue applicazioni o i tuoi servizi di backend principali presi di mira dalle analisi degli exploit di Log4j 2. Per determinare se questi tentativi di exploit hanno raggiunto il tuo servizio di backend, utilizza il campo jsonPayload.statusDetails compilato dal bilanciatore del carico HTTP(S) per scoprire se la richiesta è stata inviata tramite proxy al backend o bloccata correttamente da servizi come IAP o Google Cloud Armor. Fai clic sul valore del campo jsonPayload.statusDetails nel risultato della voce di log e seleziona Aggiungi campo al riquadro dei campi di log.

Ora puoi vedere un'analisi dettagliata della modalità di gestione delle richieste nel riquadro Campi log:

I servizi di backend più mirati 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. Per le richieste bloccate da IAP, statusDetails è impostato su handled_by_identity_aware_proxy. Inoltre, se utilizzi Google Cloud Armor con il criterio di sicurezza corretto associato a un servizio di backend, per tutte le richieste bloccate di Google Cloud Armor viene impostato il valore statusDetails su denied_by_security_policy. Per i dettagli su come applicare la nuova regola WAF cve-canary preconfigurata ai criteri di sicurezza di Google Cloud Armor, consulta Regola WAF di Google Cloud Armor per mitigare la vulnerabilità di Apache Log4j.

Per filtrare in base alle 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 di applicare un criterio di sicurezza di Google Cloud Armor con la regola WAF cve-canary preconfigurata per 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 utilizzarla per creare un avviso basato su log che ti avvisi quando nuove voci di log corrispondono alla query. Questo avviso può essere inoltrato al centro operativo per la sicurezza (SOC) della tua organizzazione o al team di risposta agli incidenti appropriato.

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 usare la query per la stringa dell'exploit anziché la query specificata nell'esempio.

Crea un criterio di avviso per una metrica basata su log

Per monitorare quali endpoint o servizi stanno registrando possibili tentativi di exploit, crea un criterio di avviso su una metrica basata su log:

  1. Creare una metrica basata su log per contare 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 viene raggiunto un numero selezionato di occorrenze. Per informazioni sulla configurazione di un criterio di avviso, consulta Creare un criterio di avviso su una metrica dei contatori.

Passaggi successivi