Apache Vulns. CVE-2021-44228, meglio nota come “log4shell” è una vulnerabilità con score CVSSv3: 10 ossia, il massimo livello Critical.
E’ critica non solo per l’impatto che può avere sul sistema, ma ovviamente sulla sua estrema diffusione.
Tanto per fornire un idea, parliamo di circa 1,2 miliardi di applicativi vulnerabili di ogni genere.

Attenzione all’evoluzione

Difatti CVE-2021-45046, secondo il NIST: “È stato rilevato che la correzione per l’indirizzo CVE-2021-44228 in Apache Log4j 2.15.0 era incompleta in alcune configurazioni non predefinite.”

Breve analisi della min

Log4shell affligge un componente specifico basato su Java, nello specifico di Log4j, nelle sue versioni 2.0 fino alla 2.14.1, che utilizza l’interfaccia JNDI (Java Naming and Directory Interface) per la gestione dei LOG. 
Nello specifico, durante la fase di generazione dei LOG, sono utilizzati tag ben specifici, e proprio grazie a  questo vettore che è possibile innescare l’esecuzione di codice arbitrario sfruttando queste stringhe non gestite.
Siamo quindi nel pieno della classificazione di minacce RCE, ovvero “remote code execution”.
Infatti log4shell non necessita di autenticazioni o interventi dall’interno del sistema bersaglio e siamo ben lontani dal phishing ed dagli attacchi mirati all’utente: qui infatti l’attaccante mira direttamente all’infrastruttura, sparando quasi a colpo sicuro.
Eseguire exploit di questa vulnerabilità apre scenari di attacco incredibilmente efficaci.
Difatti potrebbe essere sfruttati di Actor Threat impotranti per mettere a segno colpi nel giro di poco tempo, compromettendo il sistema prima che vengano patchati, con una facilità quasi disarmante.
Ad esempio, nulla vieta ad un malware ben progettato di sfruttare questa vulnerabilità in autonomia e procedere a generare reverse shell su altri server ed effettuare una proliferazione massiva di infezione ed accessi a livelli interni della rete, prima maggiormente raggiungibili.

Cosa fare

Direttamente si può provare su sistemi linux:

sudo egrep -I -i -r ‘$({|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^n]+’ /var/log

oppure qualora fosse offuscato:

sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i ‘\$\{jndi:(ldap[s]?|rmi)://[^\n]+’

Su sistemi Windows invece, riportiamo una guida:

https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/

LECS, grazie agli aggiornamenti rapidi e modulati pensati da Tiresia, permette di supportare attivamente ed efficacemente la mitigazione la minaccia sia in termini di detection e contro futuri prossimi pattern di attacco che possano sfruttare che in termini di proliferazione.

Andiamo nel dettaglio.
Di base la CVE infatti è relativa alla vulnerabilità, poi come viene sfruttata rimandiamo chiaramente è
all’abilità dell’attaccante ed al modo di muoversi all’interno di una rete compromessa.
Durante la kill-chain di un attacco, le minacce evolvono e lasciano tracce “laterali”.
Pertanto il sistema LECS, è efficace in due sensi contemporaneamente, sia nella detection diretta che in quella indiretta.
Difatti in ambienti LAN, durante la ricognizione, scansioni contro porte web e web ssl sono già un primo monito di ricognizione.
Questo perché ovviamente per innescare lg4s, è necessario avere servizio http ed https attivi.
Questo già innesca immediatamente allarmi.

Ora, l ‘attaccante trovando un server Apache tenterà l’invio della richiesta malformata.

Tale richiesta è generalmente identificabile tramite la regex (rif. GitHub – log4shell):


\${(\${(.?:|.?:.?:-)(‘|”|)*(?1)}*|[jndi:lapsrm]('|"|)}*){9,11}


al quale LECS rilevando tale pattern specifico, attiva immediatamente la contromisura.

Questo fa si che non solo si va a spezzare la kill-chain, ma evita che la minaccia si muova lateralmente, impendendo quindi proliferazione ed infezioni ulteriori.
Ricordiamo infatti che queste RCE possono essere pericolosissimi vettori di ulteriori malware come ransomware, in quanto permettono di aprire un canale diretta con la rete bersaglio e muoversi liberamente.
Con log4shell si potrebbe benissimo fare del pivot, ovvero sfruttare l’ host già compromesso per entrare ancora più all’interno della rete, muovendosi contro bersagli molto meno protetti come gli IoT e creando una pericolosissima persistenza difficilmente (se non impossibile) identificabile se non con una misura
come LECS, che agisce indistintamente anche contro le altre forme nella quale la minaccia cibernetica può trasformarsi nei casi più gravi e di difficile detection.

In blu le fasi dove LECS interviene automaticamente in caso di log4shell.

La mancanza di misure di controllo all’interno di un area, avrebbe quindi causato un danno devastante in quanto nessun sistema avrebbe identificato la minaccia, permettendogli quindi di agire in modo indisturbato in milioni di reti aziendali e private.

Threat Hunting Team