Le vulnerabilità di sicurezza CVE-2021-44228 e CVE-2021-45046 sono state rese note nella libreria Apache Log4j nelle versioni da 2.0 a 2.15. L'utilità Apache Log4j è un componente di uso comune 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 forniti per raccogliere i log dalle applicazioni di terze parti, ma se utilizzi Log4j 2, i tuoi servizi potrebbero essere interessati.
Puoi utilizzare Cloud Logging per identificare possibili attacchi. Questo documento descrive come:
- Esegui query sui log utilizzando Esplora log per rilevare eventuali tentativi di sfruttamento della vulnerabilità Log4j 2.
- Verifica che le tecniche di mitigazione abilitate, come i criteri di sicurezza di Google Cloud Armor e 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 un messaggio di possibile exploit viene scritto nei log.
Consulta l'avviso di sicurezza Log4j 2 di Google Cloud per informazioni sulla nostra attuale valutazione 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 che sono già stati archiviati nei bucket di log e che rientrano anche nei limiti di conservazione specificati dall'utente. Sebbene la maggior parte dei servizi Google Cloud abbia i log attivati per impostazione predefinita, i log disattivati o escludenti non sono inclusi nelle query. Ti consigliamo di attivare i log nell'ambiente per ampliare la visibilità.
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 di logging, i log non saranno accessibili in Cloud Logging.
Esegui 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 i campi httpRequest con contenuti generati dagli utenti per rilevare potenziali exploit.
I valori nei campi httpRequest potrebbero avere token di stringa come
${jndi:ldap://,
ma esistono molte varianti di come viene sfruttata questa vulnerabilità.
Ad esempio, esistono molti modi per utilizzare l'escapismo 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:-:}
Puoi creare query in Esplora log che cercano alcune
delle possibili stringhe di exploit. Ad esempio, la seguente query tenta di trovare corrispondenze tra varie varianti offuscate della stringa ${jndi: nei campi httpRequest nei 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 portare a 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 indica che è stato eseguito un compromesso. Se viene rilevato un problema, ti consigliamo di seguire la procedura di risposta agli incidenti della tua organizzazione. Una corrispondenza potrebbe indicare che qualcuno sta tentando di sfruttare la vulnerabilità all'interno del tuo progetto o del tuo carico di lavoro. In alternativa, potrebbe trattarsi di 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 vuoi aggregare in base agli indirizzi IP remote 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 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 analisi delle vulnerabilità delle applicazioni che potresti aver configurato, ad esempio Web Security Scanner. Se utilizzi Web Security Scanner da Security Command Center, prendi nota delle 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 le tecniche di mitigazione utilizzando i criteri di sicurezza di Google Cloud Armor o controllo dell'accesso di 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 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 dalle ricerche di exploit 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 sapere se la richiesta è stata proxy al backend o bloccata correttamente da servizi 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 vedere un'analisi dettagliata della modalità di gestione delle richieste nel riquadro Campi log:
In questo esempio, la maggior parte delle richieste è stata bloccata dall'IAP
che, se abilitato in un servizio di backend, verifica l'identità e il contesto di utilizzo dell'utente
prima di consentire l'accesso. Per queste richieste bloccate dall'IAP, statusDetails
è impostato su 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 informazioni dettagliate su come applicare la nuova regola WAF preconfigurata cve-canary ai criteri di sicurezza di Google Cloud Armor, consulta Regola WAF di Google Cloud Armor per 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 attivare l'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 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 utilizzarla per creare un avviso basato su log che ti invia una notifica 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 utilizzare la query per la stringa dell'exploit anziché la query specificata nell'esempio.
Creare 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 contatore.
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 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: