Log4Shell: l'emergenza della vulnerabilità di Log4j spiegata chiaramente

Dal 1° dicembre 2021 una vulnerabilità legata alla libreria di registrazione open source Apache Log4j 2 è stata sfruttata attivamente, con un impatto su innumerevoli prodotti e servizi digitali a livello globale.

Per aiutarti a essere rapidamente informato su questo evento, le sue implicazioni e come rispondere, abbiamo riassunto i dettagli importanti di Log4Shell in questo post.

Un riepilogo della vulnerabilità di Log4Shell

Una falla di sicurezza critica nel framework Log4j consente ai criminali informatici di compromettere i sistemi vulnerabili con una sola iniezione di codice dannoso.

La vulnerabilità è associata al registratore di attività dell'utente noto come Log4J, una libreria di registrazione distribuita gratuitamente da Apache Software Foundation.

Java è implementato in un'ampia gamma di prodotti digitali, tra cui soluzioni cloud, server Web e app, rendendo ciascuno di questi prodotti vulnerabile allo sfruttamento attraverso la vulnerabilità Log4Shell.

Poiché questa falla di sicurezza è così diffusa e la maggior parte delle organizzazioni non è consapevole di essere colpita, è attualmente in corso una frenesia di sfruttamento nel mondo dei criminali informatici. I ricercatori di sicurezza hanno identificato circa 10 milioni di tentativi di exploit di Log4Shell ogni ora.

Il settore della vendita al dettaglio sta subendo il maggior numero di attacchi, seguito dalla tecnologia, dai servizi finanziari e dai servizi di produzione.

Anche gli operatori sanitari sono in allerta, data la reputazione di lunga data del settore di subire attacchi informatici.

La mappa seguente mostra le regioni in cui sono stati effettuati tentativi di sfruttamento di Log4Shell e la densità di questi attacchi. Le regioni più interessate sono gli Stati Uniti, il Regno Unito, la Germania, la Turchia e i Paesi Bassi.

Come risolvere il problema di Log4j

L'attualità di questa vulnerabilità, unita al suo punteggio CVSS massimo di 10, significa che ci vorrà del tempo prima che venga sviluppata una patch affidabile di questa esposizione.

Nel frattempo, i team di risposta devono seguire questo protocollo di protezione e correzione per gestire la vulnerabilità.

1. Aggiorna all'ultima versione della libreria Log4j

La risposta di mitigazione più rapida e attualmente più efficace consiste nell'aggiornare tutte le istanze di Log4j alla versione più recente: Log4j 2.17.1 (scarica l'ultima versione di Apache Log4j qui).

Secondo Apache, la vulnerabilità CVE-2021-45105 è stata risolta nell'ultima versione della libreria. Questo dovrebbe prevenire attacchi futuri, ma non rimedierà ai danni causati prima dell'aggiornamento della libreria.

Poiché questa vulnerabilità è così diffusa, è più sicuro presumere che l'ecosistema sia stato compromesso prima di un aggiornamento della libreria e avviare immediatamente le risposte agli incidenti di violazione dei dati.

Anche le entità che non utilizzano i servizi di log Apache dovrebbero presumere una violazione dei dati perché l'impatto di questa coppia zero-day potrebbe influire sull'intera superficie di attacco.

Scopri di più sulla mentalità della violazione presunta.

Oltre a una mentalità di presunta violazione, tutti i log del server dovrebbero essere esaminati per gli indicatori di compromissione (IOC) come dettagliato nelle seguenti risorse:

• Risorsa GitHub 1
• Risorsa GitHub 2
• Risorsa GitHub 3
• Risorsa Greynoise

UpGuard ha sviluppato uno scanner di domini e IP che rileva rapidamente le entità interessate da CVE-2021-44228.

Lo scanner funziona inviando una stringa all'interno dell'URL di una richiesta HTTP GET a ogni dominio e indirizzo IP sottoposto a scansione.

Le librerie Log4j vulnerabili vengono confermate quando viene stabilita una connessione LDAP benigna a un server sicuro.

Se tutte le connessioni in uscita sono bloccate, l'origine dei tentativi non riusciti di connessione al server LDAP sicuro di UpGuard nel proxy/firewall in uscita viene confermata come vulnerabile allo zero-day.

Per vedere lo scanner di vulnerabilità UpGuard Log4j in azione, clicca qui.

3. Modificare le proprietà del sistema Java

Se non è possibile eseguire l'aggiornamento all'ultima versione di Log4j, i team di sicurezza devono implementare immediatamente la seguente risposta per le versioni da 2.10 a 2.14.1:

Impostare la seguente proprietà di sistema su true:

log4j2.formatMsgNoLookups

In alternativa, impostare la seguente variabile di ambiente su true:

LOG4J_FORMAT_MSG_NO_LOOKUPS

4. Disabilita JNDI

Un difetto di progettazione nel plug-in JNDI Lookup è principalmente responsabile di questa vulnerabilità critica. JNDI facilita l'esecuzione del codice in base ai dati trovati nel registro, dati che possono essere facilmente manipolati poiché vengono accettati dal logger senza sanificazione.

Di recente è stato scoperto che il plug-in JNDI Lookup ha sempre permesso l'invio di informazioni non analizzate alla libreria Log4j, sin dal suo rilascio nel 2013.

Questo è il motivo per cui CVE-2021-44228 può essere sfruttato da una singola iniezione di stringhe.

Una volta iniettata, il logger considererà l'operazione incorporata nella stringa come parte della sua base di codice originale e la eseguirà immediatamente.

Disabilitando la classe JndiLookup, il logger non sarà in grado di eseguire un'azione in base ai dati trovati nel log. JNDI è disabilitato per impostazione predefinita nella versione 2.16.0 di Log4j

Le versioni vulnerabili di Log4j possono essere protette anche rimuovendo la classe JndiLookup dal seguente classpath:

zip -q -d log4j-core- *.jar org /apache/logging /log4j /core/lookup /JndiLookup.class

5. Invia il questionario Apache Log4j ai fornitori

Il questionario Apache Log4j di UpGuard aiuta i team di sicurezza a scoprire fornitori di terze parti che utilizzano software o servizi cloud interessati dalla vulnerabilità Log4j, direttamente o tramite catene di approvvigionamento.

Per vedere questo questionario in azione, clicca qui.

6. Aggiorna tutti i firewall e i sistemi di prevenzione delle intrusioni

Aggiorna tutti i firewall di nuova generazione, i Web Application Firewall e i sistemi di prevenzione delle intrusioni con le regole e le firme più recenti. Le patch potrebbero filtrare o bloccare il traffico LDAP e RMI che tenta di raggiungere server LDAP dannosi.

7. Implementare l'autenticazione a più fattori

Le pratiche di sanificazione generali come l'autenticazione a più fattori e le rigide politiche VPN potrebbero ostacolare il successo delle violazioni dei dati se un utente malintenzionato riesce a ottenere l'accesso alla rete attraverso la vulnerabilità Apache Log4j,

8. Utilizzare il tester di vulnerabilità Log4Shell di Huntress

Huntress ha creato uno strumento di scansione per verificare se i processi o i dati comunemente registrati e trasmessi tramite le API sono interessati dalla vulnerabilità di Log4Shell. Il codice sorgente può essere scaricato da GitHub qui.

Utilizzando entrambi gli scanner, avrai maggiori possibilità di scoprire gli impatti sui confini della vulnerabilità di Log4j.

Per ulteriori raccomandazioni sulle misure di protezione contro questa minaccia zero-day, fare riferimento a questo post della Cybersecurity and Infrastructure Security Agency (CISA).

Che cos'è CVE-2021-44228?

La vulnerabilità originale di Apache Log4j (CVE-2021-44228), nota anche come Log4Shell, è una vulnerabilità di sicurezza informatica sulla libreria Java Apache Log4j 2.

Questo difetto di sicurezza è una vulnerabilità di esecuzione di codice remoto (RCE), una delle esposizioni di sicurezza più critiche.

Poiché la vulnerabilità Log 4j originale ha il grado di minaccia più critico di CVSS 10 - un punteggio che viene raramente assegnato - è improbabile che un singolo tentativo di patch risolva tutti i problemi di sicurezza del logger, soprattutto quando quasi tutti i criminali informatici del mondo stanno cercando di aggirare le difese di uno dei più grandi exploit dell'era di Internet.

Sono state tentate quattro patch e, finora, due di esse sono state trovate per includere vulnerabilità di sicurezza. A ogni nuova vulnerabilità viene assegnata un'identità CVE separata a partire dall'exploit zero-day originale.

Di seguito è riportato un elenco cronologico aggiornato dei CVE associati a Log4j in modo vulnerabile:

• CVE-2021-44228: questa è l'identità di tracciamento per l'exploit Log4j originale
• CVE-2021-45046: l'identità di tracciamento per la vulnerabilità associata alla prima patch di Log4j (versione 2.15.0). Secondo l'avviso di sicurezza di Apache, la versione 2.15.0 è stata trovata per facilitare gli attacchi Denial of Service consentendo agli aggressori di creare dati di input dannosi utilizzando un modello di ricerca JNDI.
• CVE-2021-45105: l'identità di tracciamento per la vulnerabilità associata alla seconda patch di Log4j (versione 2.16.0) dopo che è stato rilevato che consente agli utenti malintenzionati di controllare i dati della mappa del contesto del thread per causare un denial of service quando viene interpretata una stringa creata.
• CVE-2021-44832: l'identità di tracciamento per la vulnerabilità che interessa tutte le versioni di Apache Log4j 2 (escluse 2.32 e 2.12.4). Questo difetto di sicurezza mette tutte le versioni vulnerabili a rischio di Remote Code Injection (RCE)

Tutti i rischi per la sicurezza di cui sopra sono stati risolti nell'ultima versione di Log4J - versione 2.17.1 (scarica la versione 2.17.1 qui).

Per ulteriori informazioni, consulta l'informativa completa di Apache qui.

Come funziona l'attacco informatico Log4j?

La vulnerabilità Log4Shell consente agli hacker di iniettare in remoto codice arbitrario in una rete di destinazione e di assumerne il controllo completo.

Per comprendere la sequenza degli attacchi informatici, è importante innanzitutto capire come operano i logger.

Senza una libreria logger come Log4j, le informazioni provenienti dai server vengono archiviate istantaneamente dopo la raccolta.

Tuttavia, se i dati registrati vengono analizzati attivamente o se sono necessarie determinate azioni in risposta a dati di registro specifici, gli sviluppatori di software Java possono utilizzare una libreria come Log4j per analizzare i registri prima che vengano archiviati.

Qualsiasi azienda che utilizza una libreria Log4j vulnerabile per analizzare i dati di registro nei propri sistemi di back-end è vulnerabile a un attacco informatico Log4j.

Questo logger è in grado di eseguire codice basato sull'input e, poiché la vulnerabilità consente agli aggressori di manipolare i dati di input, il logger potrebbe essere costretto a eseguire codice dannoso.

In termini tecnici, la libreria Log4j vulnerabile, quando viene passata una stringa appositamente predisposta, chiamerà un server LDAP, scaricherà il codice ospitato nella directory LDAP e quindi eseguirà quel codice. Ciò consente ai criminali informatici di creare un server LDAP dannoso che memorizza il codice progettato per assumere il controllo di qualsiasi server in cui viene eseguito, e quindi inviare ad applicazioni/database/API la stringa che punta al loro codice.

Perché Log4Shell è così critico?

CVE-2021-44228 è considerata da molti esperti di sicurezza una delle peggiori esposizioni nella storia della tecnologia digitale.

Questo sentimento audace è supportato da due fattori:

1. CVE-2021-44228 è estremamente facile da sfruttare

Per sfruttare la vulnerabilità, un autore di minacce deve solo inserire una stringa in un evento di log comune per poi iniettare un payload dannoso.

Questo processo richiede pochissime abilità e molti tentativi di sfruttamento si sono già verificati dalla scoperta della vulnerabilità il 5 dicembre 2021.

Per testimoniare la velocità di sfruttamento, dai un'occhiata al seguente proof-of-concept che dimostra un attacco a un server Minecraft.

2. Qualsiasi software Java potrebbe essere interessato

Poiché Log4j è una libreria di registrazione Java di uso comune, questa vulnerabilità potrebbe avere un impatto su tutte le applicazioni e i software che implementano Java.

È difficile quantificare l'enorme numero di sistemi potenzialmente interessati. Una stima di alcuni miliardi di casi sarebbe considerata prudente.

Questo perché Java è incorporato in molti prodotti e servizi digitali, tra cui:

• Router Internet
• Software aziendale
• Server Microsoft, Amazon, AWS e Twitter

Anche i telefoni sono potenzialmente vulnerabili. Sebbene non eseguano direttamente Java, i loro sistemi di backend probabilmente comunicano con la libreria Log4j tramite API. Quindi una stringa dannosa inviata a un iPhone potrebbe essere iniettata nel suo back-end, portando alla compromissione.

I software con vulnerabilità di sicurezza di Apache Log4j non hanno nemmeno bisogno di essere esposti direttamente a Internet per essere sfruttati.

Le stringhe dannose possono persino permeare il software back-end che esegue versioni vulnerabili di Apache Log4j, anche se l'applicazione web rivolta a Internet non è codificata in Java.

Anche se nessuna delle tue applicazioni web e del tuo software di back-end esegue versioni vulnerabili di Log4j, i tuoi fornitori di terze parti potrebbero esserlo, il che espone il tuo ecosistema al potenziale di violazioni di terze parti.

L'enormità delle opzioni dei vettori di attacco e la semplicità del loro compromesso stanno alimentando la frenesia dello sfruttamento tra i criminali informatici.

Secondo la società di sicurezza Check Point, in meno di 24 ore sono state rilevate oltre 60 varianti dell'exploit originale, il che significa che i criminali informatici stanno ampliando i loro framework di sfruttamento in previsione delle prossime patch.

Se il malware viene iniettato nei server LDAP, la vulnerabilità CVE-2021-44228 potrebbe causare un'ondata di colossali violazioni dei dati e attacchi ransomware che farebbero impallidire alcune delle più grandi violazioni che abbiamo visto fino ad oggi.

Esistono due violazioni della sicurezza storiche che potrebbero essere paragonate al potenziale impatto della vulnerabilità Apache Log4j.

• La violazione dei dati di Equifax è stata facilitata dalla vulnerabilità CVE-2017-5638 di Apache Struts, che ha colpito 147 milioni di persone.
• ShellShock (noto come Bashdoor) è una famiglia di bug di sicurezza che interessano Unix Bash Shell. Se sfruttati, i bug di ShellShock potrebbero consentire agli attacchi di costringere Bash a eseguire comandi dannosi. Gli attributi simili tra Bashdoor e Log4Shell suggeriscono che i due rischi informatici potrebbero far parte della stessa famiglia di vulnerabilità.

Quali versioni di Log4j 2 sono interessate?

Tutte le versioni di Log4j precedenti alla versione 2.17.0 sono potenzialmente interessate dall'exploit Log4j. Ogni entità che utilizza Log 4j deve eseguire immediatamente l'aggiornamento alla versione più recente della libreria Apache - 2.17.1

La versione 2.17.1 di Log4j può essere scaricata qui.

Log4j 1 non è più supportato e, di conseguenza, le sue vulnerabilità non verranno risolte con le future versioni di patch. Tutte le istanze dell'endpoint di questa versione devono essere aggiornate immediatamente alla versione 2.17.1

Quali prodotti sono interessati?

Di seguito sono elencati i primi 10 fornitori che sono stati interessati da Log4Shell. Ogni entità elencata si collega alla documentazione che illustra le risposte di sicurezza del provider interessato.

• Adobe
• Fonte: AWS
• CISCO
• IBM
• F-Secure
• Broadcom
• Fortinet
• FortiGuard
• Okta
• VMware

Per l'elenco completo dei prodotti e dei servizi cloud interessati dalla vulnerabilità Log4j, fare riferimento a questo post. Se la tua azienda utilizza uno di questi prodotti, assicurati di aggiornarli immediatamente con le patch più recenti.

Anche se nessuna di queste soluzioni viene utilizzata internamente, potresti comunque essere a rischio. Se uno dei tuoi fornitori utilizza una soluzione interessata dalla vulnerabilità Log4Shell, la tua azienda potrebbe cadere vittima di un attacco alla catena di approvvigionamento.

Le strategie di gestione del rischio dei fornitori aiutano a valutare il potenziale di tali violazioni di terze parti attraverso soluzioni di monitoraggio della superficie di attacco e questionari di sicurezza che affrontano specificamente le minacce informatiche come l'exploit zero-day Log4Shell.