Log4j fa il bis. Apache rilascia la versione 2.16 che disabilita JNDI.

Come riportato la scorsa settimana, Apache ha rilasciato la versione 2.15 della sua utility Log4j, che risolve la famigerata vulnerabilità Log4Shell (CVE-2021-44228), che consente di hackerare server e applicazioni basate su Java.

Tuttavia, questo aggiornamento ha risolto solo parzialmente la vulnerabilità. Nella versione 2.15, solo un aspetto della funzionalità di recupero dei messaggi di JNDI era disabilitato di default.

Ora è stata rilasciata una seconda correzione, la 2.16, che disabilita tutto il supporto JNDI per impostazione predefinita e rimuove completamente la gestione della ricerca dei messaggi.

Il rilascio del secondo aggiornamento si è reso necessario perché la versione 2.15 può ancora essere sfruttata in determinate configurazioni non di fabbrica. A questo problema è stato assegnato il proprio identificatore CVE-2021-45046 .

Apache ha riconosciuto che JNDI “ha seri problemi di sicurezza”, quindi è stata presa la decisione di disabilitarlo per impostazione predefinita.

“CVE-2021-44228 ci ha mostrato che JNDI ha seri problemi di sicurezza. Sebbene abbiamo eliminato ciò che sapevamo, è stato deciso di disabilitarlo completamente per impostazione predefinita per una maggiore sicurezza dell’utente, soprattutto perché la maggior parte delle persone non lo usa”

ha affermato Apache.

Pertanto, nella versione 2.16.0 JNDI è disabilitato. JNDI è un’API utilizzata da Log4j per recuperare oggetti da server remoti da utilizzare nei record di log.

Con JNDI abilitato, gli aggressori possono forzare l’utility Log4j a estrarre il codice Java da un server sotto il suo controllo ed eseguirlo, compromettendo il dispositivo. Per fare ciò, gli aggressori devono inserire un testo appositamente predisposto, ad esempio, nel nome di un account dell’applicazione o in una query di ricerca su un sito. Quando viene registrato da Log4j, questo attiverà l’esecuzione del codice remoto.

Java Naming and Directory Interface (JNDI) è un insieme di API Java organizzate come un servizio di directory che consente ai client Java di aprire e visualizzare dati e oggetti per nome. Come qualsiasi altra API Java, come un insieme di interfacce, JNDI è indipendente dall’implementazione sottostante. Oltre a ciò, fornisce un’implementazione dell’interfaccia del provider di servizi (SPI) che consente di associare i servizi di directory a un framework.

Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.

Redazione

La Redazione di Red Hot Cyber fornisce aggiornamenti quotidiani su bug, data breach e minacce globali. Ogni contenuto è validato dalla nostra community di esperti come Pietro Melillo, Massimiliano Brolli, Sandro Sana, Olivia Terragni e Stefano Gazzella. Grazie alla sinergia con i nostri Partner leader nel settore (tra cui Accenture, CrowdStrike, Trend Micro e Fortinet), trasformiamo la complessità tecnica in consapevolezza collettiva, garantendo un'informazione accurata basata sull'analisi di fonti primarie e su una rigorosa peer-review tecnica.