Sono state divulgate le vulnerabilità di sicurezza CVE-2021-44228 e CVE-2021-45046 nelle versioni della libreria Apache Log4j 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 che esegue Apache Log4j versioni da 2.0 a 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 tuoi servizi potrebbero essere interessati.
Puoi utilizzare la registrazione per identificare possibili attacchi. Questo documento descrive come:
- Esegui query sui log utilizzando Esplora log per i tentativi esistenti di sfruttare la vulnerabilità Log4j 2.
- Verifica che le tecniche di mitigazione abilitate, come i criteri di sicurezza di Cloud Armor e controllo dell'accesso di Identity-Aware Proxy, siano configurate correttamente e funzionino come previsto bloccando questi tentativi di sfruttamento di Log4j 2.
- Crea una criterio di avviso per ricevere una notifica quando nei log viene scritto un messaggio di possibile exploit.
Consulta l'avviso di sicurezza Log4j 2 di Google Cloudper la nostra valutazione attuale di prodotti e servizi. Google Cloud Puoi valutare la tua esposizione leggendo il report sulle vulnerabilità del National Institute of Standards and Technology (NIST) per CVE-2021-44228.
Rilevamento della registrazione
I risultati della query di 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 esclusi non sono inclusi nelle query. Ti consigliamo di attivare i log nel tuo ambiente per ampliare la visibilità.
Se utilizzi un bilanciatore del carico HTTP(S), devi aver attivato la registrazione affinché i log delle richieste siano disponibili in Logging. Allo stesso modo, se hai server web come Apache o NGINX in esecuzione su una VM, ma non hai installato Ops Agent o Logging agent, questi log non saranno accessibili in Logging.
Eseguire query sui log
Puoi utilizzare Esplora log per rilevare potenziali attacchi
al tuo servizio che sfruttano la vulnerabilità Log4j 2. Se utilizzi
Logging per registrare le richieste al tuo servizio, puoi controllare
i campi httpRequest con contenuti generati dagli utenti per potenziali exploit.
I valori nei campi httpRequest potrebbero contenere token stringa come
${jndi:ldap://,
ma esistono molte varianti di sfruttamento di questa vulnerabilità.
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
nei confronti 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:-:}
Puoi creare query in Esplora log che analizzano alcune delle possibili stringhe di exploit. Ad esempio, la seguente query tenta di trovare corrispondenze con 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 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 analizzare i 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 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 di voci di log corrispondenti non significa che si è verificato 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 eseguendo il probing per sfruttare la vulnerabilità all'interno del tuo progetto o
del tuo workload. Oppure 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 pattern non faccia parte del normale comportamento dell'applicazione.
Perfeziona la query in modo che sia adatta al tuo ambiente.
Cercare gli indirizzi IP incriminati
Se trovi risultati corrispondenti e vuoi eseguire l'aggregazione sugli 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 Campi log, come mostrato nello screenshot seguente:
Ora puoi visualizzare gli indirizzi IP remoti principali che inviano richieste corrispondenti nel riquadro Campi log:
In questo modo, puoi visualizzare un'analisi dettagliata dell'origine di queste scansioni di exploit della 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 degli intervalli di indirizzi IP statici utilizzati da Web Security Scanner.
Cercare applicazioni mirate e verificare le tecniche di mitigazione
Potresti anche voler eseguire l'aggregazione sulle applicazioni di destinazione e identificare se le richieste dannose hanno effettivamente raggiunto le tue applicazioni. Se hai attivato tecniche di mitigazione utilizzando criteri di sicurezza di 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 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 seleziona Aggiungi campo al riquadro Campi log.
Ora puoi vedere le tue applicazioni o i tuoi servizi di backend più importanti presi di mira dalle scansioni 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 scoprire se la richiesta è stata sottoposta a proxy al backend o bloccata correttamente da servizi come IAP o Cloud Armor. Fai clic sul valore del campo jsonPayload.statusDetails nel risultato della voce di log e seleziona Aggiungi campo al riquadro Campi log.
Ora puoi visualizzare una suddivisione di come sono state gestite le 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à e il contesto
di utilizzo dell'utente prima di consentire l'accesso. Queste richieste bloccate per gli acquisti in-app hanno
statusDetails impostato come handled_by_identity_aware_proxy. Inoltre
(o in alternativa), se utilizzi Cloud Armor con la policy di sicurezza corretta collegata a un servizio di backend, tutte le richieste bloccate da Cloud Armor hanno statusDetails impostato come denied_by_security_policy. Per informazioni dettagliate su come
applicare la nuova regola WAF cve-canary preconfigurata alle tue norme di sicurezza 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 IAP per questi servizi di backend e di applicare
una policy di sicurezza di Cloud Armor con la regola WAF cve-canary preconfigurata
per bloccare questi tentativi di exploit.
Crea un criterio di avviso basato su log
Dopo aver progettato una query che trova i log interessati nel tuo servizio, puoi utilizzarla per creare un criterio di avviso basato su log che ti avviserà quando le nuove voci di log corrispondono alla query. Gli incidenti creati dai criterio di avviso possono essere inoltrati al Centro operativo per la sicurezza (SOC) della tua organizzazione o al team di risposta agli incidenti appropriato.
Per informazioni sulla creazione di un criterio di avviso basato su log, consulta Creare un criterio di avviso basato su log (Esplora log). Quando crei i criterio di avviso, assicurati di utilizzare la query per la stringa di exploit anziché quella specificata nell'esempio.
Creare un criterio di avviso per una metrica basata su log
Per monitorare quali endpoint o servizi 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 saperne di più 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 saranno disponibili nuove informazioni.
Per ulteriori informazioni sulla vulnerabilità Log4j 2 e sui tuoi serviziGoogle Cloud , consulta le seguenti risorse: