Log4j: aggiornamenti sulla vulnerabilità di Apache
Non è passato molto tempo dall’annuncio della vulnerabilità di Log4j che ha scosso l’intero mondo IT ma nel frattempo tanti sono stati gli aggiornamenti che si sono susseguiti a ritmo serrato. Primo fra tutti il rilascio di una nuova patch visto che la precedente era sfruttabile per una nuova vulnerabilità. Inoltre, le prime notizie di attacchi che sfruttano movimenti laterali fra i sistemi per riuscire a colpire le organizzazioni. Un quadro inquietante e che desta parecchia preoccupazione data l’enorme diffusione della libreria di Java in tutto il mondo e in qualsiasi sistema. Procediamo per gradi, partendo dalle vulnerabilità seguenti all’originale.
Le patch successive alla prima vulnerabilità di Log4j
La vulnerabilità originale, chiamata CVE-2021-44228, è stata scoperta il 10 dicembre scorso. La sua presenza permette, in alcune versioni della libreria Log4j, di eseguire codice remoto. La causa è una configurazione errata in JNDI, una componente di Java necessaria per la navigazione nelle directory che non protegge adeguatamente contro gli attacchi basati su server LDAP. Infatti, l’attaccante potrebbe essere in grado di iniettare porzioni di codice che una volta loggate provocano l’esecuzione remota di software (potenzialmente malevolo).
La soluzione in prima battuta era stata la disabilitazione di questa caratteristica o l’aggiornamento alla versione 2.15. Tuttavia, subito dopo è apparsa una nuova vulnerabilità, la CVE-2021-45046, anche questa piuttosto grave (9 su 10 e pertanto definita critica). Infatti, dalle analisi condotte la fix introdotta con la versione 2.15 per la precedente vulnerabilità era ancora instabile e poteva generare, laddove sfruttata opportunamente in alcune configurazioni, perdita di informazioni e ancora esecuzione remota di codice malevolo.
Ed ecco il rilascio della versione 2.16 che disabilita del tutto il lookup dei messaggi e all’accesso a JNDI. Ma non c’è fine al peggio. Il 20 dicembre scorso viene pubblicata la vulnerabilità CVE-2021-45105, di tipo Denial of Service e classificata a rischio alto. Infatti, la versione 2.16 che risolveva le due precedenti vulnerabilità non gestiva le ricorsioni incontrollate generate da lookup che chiamavano se stessi. In questo modo è possibile generare un errore di Stack Overflow che fa abortire il processo, causando una negazione di servizio (DoS). Apache ha rilasciato la versione 2.17 della libreria ma l’attenzione è ancora alta e non è detto che ci possano essere ulteriori vulnerabilità.
Gli attacchi laterali e i rischi per le aziende (e non solo)
Naturalmente la grande attenzione sul tema ha portato ricercatori e hacker a scovare tutti i possibili modelli di attacco. Infatti, se all’inizio sembravano esserci problemi solo con i server vulnerabili, si è poi scoperto che la vulnerabilità può essere sfruttata anche in contesti interni alla rete come macchine che presentano servizi in esecuzione su localhost. Ad esempio, questo nuovo vettore d’attacco sfrutta l’utilizzo delle websocket che sono difficilmente identificabili soprattutto quando aperte verso localhost. Se i servizi in esecuzione in locale presentano la vulnerabilità di Log4j (ovvero una libreria non patchata) è possibile eseguire un attacco completo con l’esecuzione remota di codice malevolo.
Accanto ai nuovi vettori virali si sta ampiamente sviluppando un filone di attacco che verosimilmente cercherà di sfruttare Log4j in combinazione con un ransomware. Anche se ancora non ci sono evidenze, sono molte le segnalazioni di attacchi che sfruttano Log4j per fare movimenti laterali nei sistemi colpiti. Ad esempio, il gruppo di ricerca Conti ha dichiarato di aver sfruttato Log4j per raggiungere e prendere possesso dei server VMWare vCenter. Una volta raggiunto questo obiettivo, sono stati in grado di muoversi liberamente nella rete aziendale attaccando gli altri sistemi connessi.
In conclusione, Log4j si sta dimostrando un tallone d’Achille importante per l’informatica moderna creando una base estremamente ampia e diffusa per gli hacker di tutto il mondo. Risolvere il problema richiederà probabilmente molto tempo e non è detto che si riuscirà a mettere in sicurezza completamente tutti i sistemi.