Non si rammentava una vulnerabilità così grave dalla scoperta di Heartbleed (che permetteva di ottenere informazioni da protocollo sicuro come SSL/TLS) e Shellshock (che consentiva di eseguire codice su una macchina remota attraverso la Bash shell). 

Non solo per gravità, ma anche in termini di dimensione. 

La nuova vulnerabilità raggiunge infatti un Base CVSS Score tondo tondo di 10.0; si tratta della vulnerabilità censita come CVE-2021-44228 e che colpisce la libreria Log4j, software della Apache Foundation per la gestione dei messaggi di log nelle applicazioni Java. 

Ma la dimensione del fenomeno è straordinaria vista anche la condizione di utilizzo di questa libreria: si tratta infatti della libreria più utilizzata in assoluto dalle applicazioni web per la gestione delle registrazioni eventi (log) in questo contesto, pertanto il numero di implementazioni concrete è certamente esplosivo. 

Inizialmente individuata sui server del gioco Minecraft, è stata poi individuata su server di altri giochi come Steam, ma anche più minacciosamente sui server di Apple iCloud, e chissà dove altro ancora. 

Mentre è chiaro lo sfruttamento possibile sui server Minecraft (in cui l’uso della semplice chat del gioco ha consentito agli attaccanti di eseguire l’attacco), meno chiara è la condizione di sfruttamento o possibilità negli altri casi. Ignoto è ovviamente il destino di milioni di applicazioni di cui nessuno parla, proprietarie, meno note, ma comunque potenzialmente esposte all’attacco. 

In che consiste l’attacco ovvero la vulnerabilità? 

L’attacco consiste nella semplice capacità dell’avversario di forzare la scrittura di una specifica stringa di caratteri nei file di log dell’applicazione attraverso Log4j; la vulnerabilità è dunque la più classica delle convalide improprie dell’input. 

In particolare viene sfruttata una particolare capacità nelle ricerche (lookup) di Log4j quando questa libreria si relazioni ad un endpoint mediante il servizio di nomi e directory JNDI (quindi un endpoint LDAP o simili, come DNS). Questa capacità è detta lookup substitution e consente la sostituzione di parametri con il loro valore (es. variabili d’ambiente). Ma quando l’attaccante può indicare arbitrariamente la sua sostituzione, questa porta ad una esecuzione di codice arbitrario ottenuto dal servizio LDAP contattato. Questa esecuzione remota (RCE) può naturalmente concretizzarsi nell’impianto di un malware o altro. 

Esiste anche un rischio secondario derivante da questa sostituzione, ossia la possibilità di esfiltrazione dati operabile mediante la medesima vulnerabilità. La tecnica in questo caso è quella di richiedere espansione di parametri nella lookup JNDI operata verso un DNS nella disponibilità dell’agente di minaccia, espansione che deve comparire nella componente host della richiesta in modo che al DNS avverso giunga una richiesta di un host che in realtà è una parte delle informazioni che via via vengono richieste mediante espansione. Difficile individuare un simile traffico in uscita pur tracciando il traffico DNS. 

Le versioni di Log4j coinvolte in questa vulnerabilità sono quelle a partire dalla 2.10 fino alla 2.14.1: sono state proposte misure di contenimento (workaround) e una versione correttiva nella 2.15.0. 

In particolare le contromisure sono in termini di configurazione o di distribuzione software. Nel primo caso implementate disabilitando le ricerche nei messaggi di log: mediante la proprietà log4j2.formatMsgNoLookups=true oppure la variabile ambientale LOG4J_FORMAT_MSG_NO_LOOKUPS=true. Nel secondo caso rimuovendo la classe binaria JndiLookup.class dal pacchetto (.jar) della libreria. 

Possibili ulteriori contromisure possono essere intraprese mediante regole di IPS, WAF, firewall e altri strumenti di filtro, mirando ai danni in transito mediante JNDI, sia in ingresso che in uscita. 

Benché siano già disponibili dunque contromisure e correttivi, il numero di istanze da correggere ed il tempo e difficoltà di intervento rendono la minaccia particolarmente rischiosa. 

Tweet