La notizia del bug Log4j è iniziata a circolare in Internet già il 9 dicembre, all’inizio come una vulnerabilità dei server Minecraft. In poco tempo, tuttavia, ci si è accorti della potenza del bug e della portata della diffusione che ha causato l’innalzamento del livello di rischio a 10 (su una scala da 1 a 10). Infatti, la libreria di Java Log4j è ampiamente diffusa in moltissime piattaforme e web server sparsi in giro per il mondo.
Probabilmente dopo Heartbleed e ShellShock potrebbe essere la vulnerabilità più pericolosa attualmente presente tanto che la stessa Apache Software Foundation ha cercato di rimediare con il rilascio di una patch in grado di risolvere il problema. La vulnerabilità nota come CVE-2021-44228 riguarda la versione 2 della libreria ed è stata patchata con la release 2.15.0.
Log4j è una delle librerie di logging più usate in Java ed è estremamente utile e diffusa. All’origine della vulnerabilità c’è una funzionalità introdotta in Log4j nel 2013: il plugin di lookup JNDI. Prima di capire come funziona il bug è necessario fare un passo indietro e analizzare lo scopo della libreria e JNDI. Java Naming and Directory Interface è presente fin dagli anni 90 in Java ed è un servizio che permette di ritrovare dei dati (oggetti Java) attraverso la struttura delle cartelle. I servizi di directory possono essere molteplici da CORBA COS (Common Object Service) a Java RMI (Remote Method Interface) Registry fino a LDAP, il servizio usato nella CVE.
La potenza di questo bug sta nel fatto che può essere sfruttato anche da sistemi non direttamente esposti in Internet. Infatti, alcune informazioni (come l’User-Agent o l’username) vengono tipicamente loggate anche nei sistemi di backend che possono essere scritti in Java. Se si riesce a far arrivare questi dati corrotti dal frontend al backend si riesce a prendere possesso dei sistemi con relativa facilità.
Il servizio di lookup LDAP di JDNI permette di recuperare oggetti tramite URL del tipo ldap://localhost:389/o=JavaObject. Tuttavia è possibile anche passare strutture del tipo ${prefix:name} ed effettuare un lookup JDNI su un qualsiasi server in Internet contenuto in name. Da qui si capisce la tipologia di vulnerabilità, classificata come Remote Code Execution (RCE). Infatti, passando appropriatamente questo campo è possibile caricare un oggetto Java da un server sotto il controllo degli attaccanti.
Dei Proof of Concepts (POC) sono già disponibili sul web e sono molte le notizie riportanti campagne di scansione massive alla ricerca di questa vulnerabilità.
L’impatto di questo attacco è a dir poco enorme considerando la diffusione di Java nel mondo e fra le aziende. Moltissimi stanno correndo al riparo con importanti campagne di patching dei propri server. Infatti, le versioni di Log4j dalla 2.10 possono essere corrette facilmente impostando la proprietà di sistema log4j2.formatMsgNoLookups o la variabile d’ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS a true.
Laddove sia possibile è anche possibile aggiornare la libreria alla versione 2.15.0 che risolve definitivamente il problema e mette al sicuro gli applicativi. Le versioni dalla 2.0 alla 2.10 invece hanno bisogno di rimuovere la classe JndiLookup per poter essere sicure.
Alcuni ricercatori riferiscono che la risoluzione di questa vulnerabilità potrà andare avanti per mesi, se non anni, vista la grandissima diffusione della libreria. Sicuramente, la cosa migliore è seguire le indicazioni della Apache Software Foundation al più presto e assicurarsi di avere i propri sistemi aggiornati.