Log4J e la memoria che sapeva troppo

Di Trellix · 19 gennaio 2022

Di Guilherme Venere, Ismael Valenzuela, Carlos Diaz, Cesar Vargas, Leandro Costantino, Juan Olle, Jose Luis Sanchez Martinez, AC3 Team

Collaboratori: Steve Povolny, Douglas McKee, Mark Bereza, Frederick House, Dileep Kumar Jallepalli

Il settore della sicurezza informatica è in continua evoluzione. Non aspettare oltre per approfittarne e dare slancio alla tua attività.

Oggi, gli esperti di sicurezza di tutto il mondo stanno lavorando duramente per combattere le minacce contro le aziende. Nessun settore è immune. Abbiamo osservato l'aumento dell'analisi e della correzione della vulnerabilità di Log4Shell nella libreria di registrazione Java Apache Log4j. E per una buona ragione: Log4j è una delle applicazioni di registrazione più popolari tra gli sviluppatori, se non la più utilizzata. Tuttavia, le aziende non dovrebbero accontentarsi delle patch, soprattutto quando sappiamo che Log4Shell tende a diventare quella che di solito chiamiamo una superficie di attacco.

Il rischio che questa vulnerabilità proliferi e causi danni significativi è elevato. È quindi importante prendere sul serio questo impatto per anticipare e proteggersi meglio dalla prossima vulnerabilità.

Sebbene l'applicazione di patch sia essenziale, non può essere una soluzione statica o una tantum per garantire la sicurezza dell'infrastruttura. Al contrario, è necessario implementare un approccio continuo che combina monitoraggio, valutazione, analisi e indagini forensi approfondite per rispondere con agilità alle minacce avanzate.

In questo articolo mostreremo come una soluzione per gli endpoint con potenti funzionalità di analisi della memoria possa rilevare efficacemente scenari di exploit attivi e rafforzare le capacità di sicurezza della rete dell'azienda. Potrai così godere di un nuovo tipo di resilienza.

Il contesto

Come tutti i protagonisti del settore della sicurezza sanno, è stata rivelata l'ennesima nuova vulnerabilità rivolta a una nota libreria, giusto in tempo per le festività natalizie del 2021. La vulnerabilità segnalata con il riferimento CVE-2021-44228 riguarda la libreria Java Log4j e interessa applicazioni e siti Web che la utilizzano per eseguire la registrazione.

Consente a un criminale informatico di forzare il sito o l'applicazione vulnerabile a caricare codice Java dannoso da un sito remoto non attendibile ed a eseguirlo. I vettori di attacco sono vari. Molto spesso, il criminale informatico sfrutta un protocollo di rete per inviare stringhe di caratteri modificate al dispositivo di destinazione, ad esempio un'intestazione HTTP modificata inserita in una richiesta POST.

Questo è il motivo per cui un gran numero di esperti di sicurezza sta lavorando per rilevare queste stringhe dannose nel traffico di rete, consapevoli che la proattività è essenziale per ottenere risultati positivi. Tuttavia, è possibile aggirare le firme di rete e, secondo alcuni osservatori, i criminali informatici utilizzano tecniche di offuscamento per orchestrare i loro attacchi ed eludere l’analisi della rete. L'immagine seguente mostra alcune delle tecniche di offuscamento osservate o segnalate in relazione a questo attacco.

Fonte: https://github.com/mcb2Eexe/Log4j2-Obfucation

Questo non significa che le soluzioni di protezione della rete siano inefficaci contro questo attacco. In effetti, Log4j sta dimostrando quanto sia fondamentale che gli esperti di sicurezza dimostrino la stessa adattabilità dei criminali informatici. Devono impegnarsi nella sicurezza evolutiva, adottando una mentalità e un approccio più dinamici. Come primo livello di difesa, le piattaforme di sicurezza di rete dovrebbero far parte di un'architettura di sicurezza incorporata (strategia di gestione del rischio di sicurezza), arricchita con altri livelli che forniscono protezione, rilevamento, visibilità e risposta.

Perfetti alleati, le moderne soluzioni per endpoint aumentano la funzionalità di rete con una visibilità approfondita basata su host dei processi di sistema, come la scansione in memoria e l'orchestrazione di risposte rapide. Questa combinazione di strumenti fornisce una difesa contro le minacce simili a Log4Shell e ripristina la fiducia aziendale grazie a una sicurezza end-to-end.

La visibilità prima di tutto, ovvero l’analisi della memoria alla riscossa

L’analisi della memoria è un ulteriore vantaggio nel supportare le piattaforme di sicurezza di rete quando una minaccia raggiunge l'endpoint dopo aver aggirato i livelli presi di mira dalle tecniche di offuscamento. Il diagramma seguente mostra il flusso di esecuzione di un tipico attacco Web Log4j.

Prendiamo in esame il suo modus operandi:

• Fase #1: un criminale informatico invia una stringa speciale al server Web che ospita l'applicazione vulnerabile. Come abbiamo visto, questa stringa può essere offuscata per aggirare le firme della rete.
• Fase #2: l'applicazione procede alla rimozione dell’offuscamento di questa stringa per caricarla in memoria. Una volta che la stringa è in memoria, l'applicazione stabilisce una connessione LDAP per richiedere l'indirizzo del file di classe dannoso.
• Fase #3: il server LDAP controllato dal criminale informatico invia in risposta il percorso del file di classe dannoso, indicando l'indirizzo URL HTTP del luogo che lo ospita.
• Fase #4: l'applicazione vulnerabile avvia il download del file di classe dannoso.
• Fase #5: l'applicazione vulnerabile carica ed esegue il file di classe dannoso dalla fase 4. In quel momento, il criminale informatico riesce ad eseguire del codice sull’obiettivo. Così facendo lascia tracce di attività che possono allertare l'esperto di sicurezza. Questo potrebbe generare altri processi o modificare file e chiavi di registro dopo l'exploit.

Non sarebbe interessante sventare queste tattiche di offuscamento? Ciò è possibile ed è anche raccomandato per anticipare minacce come Log4j. L'avvio della scansione della memoria, a un certo punto del flusso di esecuzione, può rilevare la presenza del file di codice dannoso. Si avrebbe quindi un'alta probabilità di trovare la stringa non offuscata utilizzata nella memoria del processo in quel momento. Se la memoria fosse analizzata dopo aver scaricato il file di classe dannoso, questo contenuto sarebbe disponibile per l’analisi nella sua forma non offuscata.

Con questa tattica, la firma della memoria è efficiente ed efficace, poiché i tempi del rilevamento dipendono principalmente dall’innesco utilizzato per avviare l’analisi della memoria.

Le regole avanzate di Endpoint Security soddisfano l’analisi della memoria

Questo è precisamente lo scopo della nostra soluzione: offrire alle aziende la possibilità di attivare un’analisi della memoria sulla base di una regola avanzata.

Si tratta di regole di controllo dell'accesso personalizzabili che gli utenti utilizzano per individuare attività sospette che altri strumenti di analisi in genere non rilevano. Pubblichiamo anche le regole avanzate della comunità associate alla matrice MITRE ATT&CK sul nostro GitHub pubblico.

Con queste funzioni possiamo indirizzare le applicazioni vulnerabili a Log4j e identificare quando viene sfruttata la falla. Prendiamo in considerazione la seguente regola:

Questa è una sezione che definisce gli “attori” (nella sezione Process {…}) e gli “obiettivi” (nella sezione Target {…}). Con “attore” (ACTOR) indichiamo qualsiasi processo vulnerabile all'exploit Log4j. In questo caso specifico, si tratta di JAVA.EXE per applicazioni Java standalone e TOMCAT?.EXE per applicazioni web Apache. Ciascuno di questi processi deve caricare sia JAVA.DLL che JVM.DLL per attivare Java Runtime.

La sezione Target incorpora qualsiasi potenziale carico utile dell'attacco. Poiché le regole avanzate non hanno come obiettivo il traffico di rete, dobbiamo concentrarci sull'ultimo passaggio del flusso di esecuzione, ovvero l'esecuzione del carico utile. Ulteriori inneschi, come chiavi di registro o file a cui si accede, possono essere aggiunti man mano che le informazioni sugli exploit diventano disponibili. Possiamo anche includere qualsiasi esclusione di comportamento valida, come nell'esempio precedente, utilizzando il parametro della riga di comando “Exclude”. I clienti possono adattare questa esclusione al loro ambiente per prevenire falsi positivi e quindi migliorare l'efficienza nella lotta contro le minacce.

Questa regola avanzata viene attivata non appena un processo ACTOR genera uno qualsiasi dei carichi utili TARGET. Va notato che alcune sfumature possono alterare i risultati e dare falsi positivi. Esaminiamo questa riga di comando all'inizio della regola:

Questa istruzione avvia un’analisi della memoria sul processo ACTOR che ha attivato la regola avanzata. Ora disponiamo si un innesco affidabile per un’analisi della memoria ad alte prestazioni che evita potenziali problemi di prestazioni dovuti a un’analisi cieca della memoria. Quest’analisi avviene in un momento molto vicino al tentativo di sfruttamento iniziale, garantendo così che la stringa de-offuscata sia presente in memoria.

Successivamente, analizziamo la memoria del processo che ha attivato la regola avanzata, eseguita dal motore AV DAT. Una volta che la stringa è stata rilevata, avviene il rilevamento sul processo in questione e viene applicata l'operazione configurata nella riga REACTION della regola avanzata. Consigliamo di utilizzare l'azione REPORT finché non si è determinato quali processi monitorare.

Il primo evento sopra evidenziato è l'attivazione della regola avanzata per un processo sospetto generato da JAVA.EXE. Il secondo mostra il rilevamento di AV DAT che indica che la memoria di questo processo conteneva le firme dell'exploit.

Nota:

Se viene trovato solo il rilevamento eseguito dalla regola avanzata, SENZA l'evento Java Naming and Directory Interface (JNDI)/Log4j-Exploit, questa è un'indicazione che un programma ha eseguito processi figli sospetti. I clienti dovrebbero quindi esaminare l'evento e modificare di conseguenza la regola avanzata.

Tuttavia, se per lo stesso programma vengono attivati sia la regola avanzata che gli eventi JNDI/Log4j-Exploit, allora il processo sfruttato è stato rilevato.

Forniamo ulteriori informazioni sulla nostra attuale copertura della vulnerabilità Log4j nell'articolo KB95901 della Knowledge Base “Copertura per l'esecuzione di codice remoto di Apache Log4j CVE-2021-44228.” Questo articolo include dei link per scaricare la regola avanzata e un file EXTRA.DAT aggiornato, nonché dettagli su come configurare ePO da utilizzare nel tuo ambiente.

Se desideri implementare questa soluzione, fai riferimento alla Knowledge Base e alla documentazione fornita. Consigliamo vivamente di rivedere la regola avanzata e di adattarla al proprio ambiente, non solo per neutralizzare i rischi attivi o porvi rimedio, ma anche per adattarsi e proteggersi dinamicamente dalle minacce in continua evoluzione.

Conclusioni

La protezione di un ambiente dagli attacchi di tipo Log4j richiede una strategia integrata a più livelli che combini la sicurezza della rete con scansioni mirate della memoria degli endpoint. Ciò consente agli esperti di sicurezza di rilevare e bloccare efficacemente il flusso di esecuzione degli attacchi contro i sistemi vulnerabili esposti tramite i vettori di rete. Le analisi personalizzate e le regole avanzate della soluzione ENS sono progettate per fornirti queste funzionalità. Questo ti consente di implementare contromisure precise contro queste minacce emergenti, ottenere un vantaggio e acquisire fiducia per sostenere e far crescere la tua attività.