[ad_1]
La vulnerabilità Log4j, o “Log4Shell”, è considerata uno dei difetti software più catastrofici di sempre. Apache ha risolto il problema nel dicembre 2021, ma rimane una preoccupazione per i team di sicurezza. In effetti, è ancora tra le vulnerabilità di sicurezza più sfruttate.
Log4Shell persiste perché il pacchetto software Apache Log4j 2 interessato è una delle librerie di registrazione più utilizzate al mondo. Secondo il Dipartimento per la Sicurezza Nazionale degli Stati Uniti, ci vorranno dieci anni per trovare e riparare ogni istanza di Log4Shell.
Nel frattempo, i team di sicurezza possono adottare alcune misure per accelerare la mitigazione e la risoluzione di Log4Shell nelle loro reti.
Comprensione delle vulnerabilità Log4j
Prima di approfondire come rilevare e applicare le patch a Log4Shell, è importante comprendere la natura della vulnerabilità.
Log4j è un logger open source (gestito dalla Apache Software Foundation) che registra informazioni ed eventi in un programma. Log4j non è un software autonomo ma un pacchetto di codice che gli sviluppatori possono inserire nelle proprie app Java. Il framework Apache Log4j viene utilizzato in alcuni dei più grandi servizi sul Web, che vanno dalle infrastrutture di rete come Amazon Web Services (AWS) e soluzioni Cisco alle app popolari come Twitter e Minecraft.
Alcune versioni di Log4j, in particolare Log4j 2.17.0 e precedenti, soffrono di gravi vulnerabilità. Il più pericoloso di questi è Log4Shell (CVE-2021-44228; valutazione CVSS: 10), una vulnerabilità zero-day RCE (Remote Code Execution) rilevata nelle versioni Log4j 2.14.1 e precedenti.
Log4Shell è il risultato del modo in cui le versioni vulnerabili di Log4j gestiscono Java Naming and Directory Interface (JNDI), un’API utilizzata dalle app Java per accedere alle risorse ospitate su server esterni. Gli autori delle minacce possono assumere il controllo quasi totale dei sistemi vulnerabili inviando comandi di ricerca JNDI dannosi tramite Log4j. Questi comandi inducono l’app a eseguire codice arbitrario che può fare quasi qualsiasi cosa: rubare dati, installare ransomware, mettere offline i dispositivi e altro ancora.
Attacchi Log4Shell
Un tipico attacco informatico Log4Shell funziona in questo modo:
- Un hacker configura un server utilizzando un protocollo comune, come Lightweight Directory Access Protocol (LDAP) o Domain Name System (DNS).
- L’hacker memorizza malware o altri payload dannosi sul server.
- L’hacker invia una ricerca JNDI a un’app che esegue Log4j, indirizzando l’app al server dell’hacker.
- La ricerca JNDI fa sì che l’app si connetta al server dell’hacker, scarichi il payload dannoso ed esegua il codice dannoso.
Vulnerabilità correlate di Log4j e come vengono sfruttate
Mentre Apache lavorava per applicare le patch a Log4Shell, i ricercatori di sicurezza hanno identificato una manciata di difetti correlati in alcune versioni di Log4j. Questi includono:
- CVE-2021-45046 consente agli hacker di inviare ricerche JNDI dannose a sistemi che utilizzano determinate impostazioni non predefinite, anche se tali sistemi hanno corretto Log4Shell. Presente nelle versioni Log4j 2.15 e precedenti.
- CVE-2021-45105 consente agli hacker di lanciare attacchi di negazione del servizio inviando messaggi dannosi a Log4j. Presente nelle versioni Log4j 2.16 e precedenti.
- CVE-2021-44832 è una vulnerabilità legata all’esecuzione di codice in modalità remota. Questo difetto è meno critico di Log4Shell perché gli hacker devono ottenere autorizzazioni elevate prima di poterlo sfruttare. Presente nelle versioni Log4j 2.17 e precedenti.
Come rilevare le vulnerabilità Log4j
Trovare ogni istanza vulnerabile di Log4j in una rete può essere difficile. Log4j appare in circa milioni di app, il che significa che i team di sicurezza hanno molte risorse da ispezionare.
Inoltre Log4j è spesso presente come dipendenza indiretta. Ciò significa che non è contenuto direttamente nel codice sorgente di una risorsa, ma appare come una dipendenza di un pacchetto software o un’integrazione su cui fa affidamento la risorsa. Google segnala che le istanze Log4j più vulnerabili si trovano a più di un livello di profondità nella catena di dipendenze e alcune sono profonde fino a nove livelli.
Detto questo, i team di sicurezza possono rilevare le vulnerabilità di Log4j con le tattiche e gli strumenti giusti.
Cosa cercare
Ogni versione di Log4j 2 dalla 2.0-beta9 alla 2.17 è vulnerabile a Log4Shell o ad un difetto correlato. In altre parole, i team di sicurezza devono trovare e risolvere qualsiasi versione di Log4j precedente alla 2.17.1.
Log4Shell e i relativi difetti sono presenti solo nei file “Log4j-core”, che forniscono le funzionalità principali di Log4j. I difetti non sono presenti nei file “Log4j-api”, che controllano l’interfaccia tra le app e i logger Log4j.
Log4j può apparire nelle risorse controllate dall’azienda, nelle risorse di terze parti utilizzate dall’azienda (ad esempio, servizi cloud) e nelle risorse utilizzate dai fornitori di servizi con accesso alla rete aziendale. Sebbene Log4j sia più probabile che venga visualizzato nelle app basate su Java, può essere presente anche in app non Java tramite dipendenze e integrazioni.
All’interno delle app Java, le librerie come Log4j sono spesso inserite in file Java Archive o “file JAR”. I file JAR possono contenere altri file JAR, che a loro volta possono contenere i propri file JAR e così via. Per trovare tutte le versioni vulnerabili di Log4j, i team di sicurezza devono ispezionare tutti i livelli dei file JAR, non solo i file di livello superiore.
Come trovarlo
Gli esperti consigliano di utilizzare una combinazione di tecniche per individuare le vulnerabilità Log4j.
Ricerche manuali. I team di sicurezza possono cercare manualmente i difetti Log4j. Possono utilizzare strumenti di sviluppo come Apache Maven per generare alberi delle dipendenze che mappano tutte le dipendenze in un’app oppure possono utilizzare l’intelligence sulle minacce esterne per identificare le risorse interessate. Ad esempio, la Cybersecurity and Infrastructure Security Agency (CISA) ha compilato un elenco di software noti per soffrire di Log4Shell. L’elenco è disponibile su GitHub.
Sui sistemi operativi Linux, Microsoft Windows e macOS, i team di sicurezza possono cercare nelle directory dei file istanze di Log4j utilizzando l’interfaccia della riga di comando.
Strumenti di scansione delle vulnerabilità. In seguito alla scoperta di Log4Shell, alcune organizzazioni hanno rilasciato strumenti gratuiti progettati per individuare le vulnerabilità di Log4j. Gli esempi includono Log4j-sniffer di Palantir e lo scanner del Centro di coordinamento CERT, tra molti altri.
Sebbene siano ancora disponibili scanner specializzati, molte soluzioni di sicurezza standard come scanner di vulnerabilità, piattaforme di gestione della superficie di attacco (ASM) e soluzioni di rilevamento e risposta degli endpoint (EDR) possono ora rilevare le vulnerabilità Log4j.
Poiché Log4Shell può nascondersi in profondità nelle catene di dipendenze, i team di sicurezza possono integrare le scansioni automatizzate con metodi più pratici, come i test di penetrazione.
Caccia alla minaccia. Secondo CISA, è noto che gli aggressori utilizzano Log4Shell per penetrare in una rete e quindi applicare patch alla risorsa compromessa per coprire le proprie tracce. Per questo motivo, si consiglia ai team di sicurezza di presumere che una violazione sia già avvenuta e di cercare attivamente segni di sfruttamento di Log4Shell.
Gli strumenti di sicurezza informatica come le soluzioni SIEM (Security Information and Event Management) e le piattaforme XDR (Extended Detection and Response) possono aiutare a rilevare attività anomale associate a Log4Shell, come strane voci di registro o modelli di traffico sospetti. I team di sicurezza dovrebbero avviare procedure complete di risposta e indagine sugli incidenti per ogni possibile indizio di Log4Shell, data la gravità delle conseguenze di un attacco.
Come risolvere le vulnerabilità Log4j
I team di sicurezza hanno alcune opzioni quando affrontano le vulnerabilità Log4j.
Il caso migliore: applicare patch ai sistemi vulnerabili
Per la completa riparazione di Log4Shell e dei relativi difetti, le organizzazioni devono aggiornare tutte le istanze di Log4j nelle loro reti alla versione più recente (o almeno alla versione 2.17.1). Le ultime versioni di Log4j rimuovono le funzioni che gli aggressori possono sfruttare e rimuovono il supporto per i protocolli comunemente abusati come LDAP.
Non è disponibile un’unica patch a livello di sistema e l’aggiornamento di Java in sé non risolve il problema. I team di sicurezza devono aggiornare ogni istanza di Log4j in ogni risorsa interessata.
Altre misure di mitigazione
I ricercatori in materia di sicurezza concordano sul fatto che l’applicazione di patch è la soluzione ideale. Se l’applicazione delle patch non è fattibile, le organizzazioni possono utilizzare altre misure di mitigazione per ridurre al minimo le possibilità di un attacco.
Non consentire la ricerca dei messaggi nelle app vulnerabili. Gli aggressori utilizzano una funzionalità di Log4j chiamata “sostituzioni di ricerca dei messaggi” per inviare comandi dannosi alle app vulnerabili. I team di sicurezza possono disattivare manualmente questa funzione modificando la proprietà di sistema “Log4j2.formatMsgNoLookups” su “true” o impostando il valore della variabile di ambiente “LOG4J_FORMAT_MSG_NO_LOOKUPS” su “true”.
Sebbene la rimozione della funzione di sostituzione della ricerca dei messaggi renda più difficile l’attacco da parte degli aggressori, non è infallibile. Gli autori malintenzionati possono comunque utilizzare CVE-2021-45046 per inviare ricerche JNDI dannose ad app con impostazioni non predefinite.
Rimozione della classe JNDIlookup dalle app vulnerabili. In Log4j, la classe JNDIlookup governa il modo in cui il logger gestisce le ricerche JNDI. Se questa classe viene rimossa dalla directory delle classi di Log4j, le ricerche JNDI non potranno più essere eseguite.
Apache rileva che il seguente comando può essere utilizzato per rimuovere la classe JNDIlookup dalle app vulnerabili:
zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class
Sebbene questo metodo sia più efficace rispetto a impedire la ricerca dei messaggi, non impedisce agli aggressori di organizzare altri tentativi di sfruttamento, come l’attivazione di attacchi di negazione del servizio tramite ricerche ricorsive.
Blocco del traffico potenziale di attacco Log4Shell. I team di sicurezza possono utilizzare firewall per applicazioni web (WAF), sistemi di rilevamento e prevenzione delle intrusioni (IDPS), EDR e altri strumenti di sicurezza informatica per intercettare il traffico da e verso server controllati dagli aggressori bloccando protocolli comunemente utilizzati come LDAP o RMI. I team di sicurezza possono anche bloccare gli indirizzi IP associati agli attacchi o le stringhe che gli aggressori utilizzano comunemente nelle richieste dannose, come “jndi”, “ldap” e “rmi”.
Tuttavia, gli aggressori possono aggirare queste difese utilizzando nuovi protocolli e indirizzi IP o offuscando stringhe dannose.
Mettere in quarantena le risorse interessate. Se tutto il resto fallisce, i team di sicurezza possono mettere in quarantena le risorse interessate mentre aspettano una patch. Un modo per farlo è collocare le risorse vulnerabili in un segmento di rete isolato a cui non è possibile accedere direttamente da Internet. È possibile posizionare un WAF attorno a questo segmento di rete per una protezione aggiuntiva.
Tenere a bada Log4Shell
Uno degli aspetti complicati della riparazione di Log4Shell è che non sempre rimane aggiornato. Nel novembre 2022, Tenable ha riferito che il 29% delle risorse ancora vulnerabili a Log4Shell erano “recidive”, il che significa che erano state patchate, ma il difetto è riapparso. Le ricorrenze si verificano quando gli sviluppatori utilizzano accidentalmente librerie software che contengono versioni senza patch di Log4j per creare o aggiornare app.
Sebbene gli sviluppatori possano esaminare più da vicino i framework che utilizzano, è facile non notare le versioni vulnerabili di Log4j quando si trovano a diversi livelli di profondità nei file JAR.
L’implementazione di programmi formali di gestione delle vulnerabilità e di gestione delle patch può offrire ai team di sicurezza un modo più efficace per monitorare le risorse per il ritorno delle vulnerabilità Log4j. La scansione regolare delle vulnerabilità e i test di penetrazione possono aiutare a individuare rapidamente nuove vulnerabilità, Log4Shell o altro. La gestione delle patch garantisce che le nuove vulnerabilità vengano chiuse non appena i fornitori rilasciano le correzioni.
Ulteriore aiuto nella lotta contro Log4Shell e altre vulnerabilità zero-day
Gli hacker utilizzano sempre più spesso strumenti automatizzati per sfruttare facilmente le vulnerabilità zero-day come Log4Shell e per lanciare una raffica di attacchi ransomware e altre minacce informatiche. I team di sicurezza che lavorano con approcci tradizionali alla sicurezza degli endpoint devono affrontare un affaticamento degli avvisi, strumenti complessi e indagini lunghe, e faticano a tenere il passo.
IBM Security® QRadar® EDR, in precedenza ReaQta, risolve le minacce note e sconosciute agli endpoint quasi in tempo reale con un’automazione intelligente di facile utilizzo che richiede un’interazione umana minima o nulla. Con QRadar EDR, gli analisti possono prendere decisioni rapide e informate e utilizzare la gestione automatizzata degli avvisi per concentrarsi sulle minacce che contano di più. Le funzionalità avanzate di intelligenza artificiale per l’apprendimento continuo e un’interfaccia intuitiva restituiscono il controllo al personale addetto alla sicurezza e aiutano a salvaguardare la continuità aziendale.
Esplora IBM Security QRadar EDR
[ad_2]
Source link
