Scopri i nostri percorsi di Hacking e approfitta dell'imperdibile promozione! Scopri di più
Avevamo già parlato di uno scivolone simile operato da Microsoft, e in qualche misura avevamo predetto la inevitabilità di eventi di tal genere.
Con la versione 2.15 di log4j appena rilasciata (che ci aveva tranquillizzato), ecco emergere la conoscenza di differenti mutazioni dell’attacco, ed in particolare un vettore di attacco che potrebbe sfruttare Log4Shell rompendo anche il limite dei soli servizi esposti in rete come obiettivi possibili. In questo caso, tramite un server vulnerabile (strategia watering hole), un attaccante potrebbe fare innescare tramite un URL l’attivazione (silente all’utente) di una Javascript WebSocket al caricamento della pagina e porre questa in comunicazione con una destinazione esterna tramite una connessione JNDI: questo perché le WebSocket non rispettano la Same-Origin-Policy. A differenza di altre varianti osservate, questo caso è solo una PoC, quindi una idea e non una certezza, ma un brivido corre lungo la schiena.
Ma ancora una volta non si fa in tempo a recuperare da questo ultimo brutto spavento, che ecco emergere un nuovo problema, il peggior incubo: la falla originale denominata Log4Shell (CVE-2021-44228) non è stata correttamente risolta.
Una nuova variante della medesima vulnerabilità è ancora possibile, con annessa remote-code-execution. Parliamo della vulnerabilità CVE-2021-45046 (gravità 9.0) capace di rinnovare il rischio Log4Shell nuovamente mediante il coinvolgimento dei lookups dei dati registrati, con la differenza che questa volta i lookups (ricerche per decodificare valori) coinvolti sono i Context Map invece di quelli della JNDI e la debolezza è la deserializzazione di dati non affidabili.
I ContextMapLookup consentono alle applicazioni J2EE di utilizzare informazioni immagazzinate i appositi “contenitori” definiti ThreadContext Map per creare dei contesti diagnostici con cui tracciare il comportamento di applicazioni complesse e distribuite (con molti thread). In sostanza questa tecnologia intende disporre di un modo per differenziare i messaggi registrati per ciascun client (thread) della libreria senza dover utilizzare differenti registratori, ossia adoperando dei marcatori, timbri, etichette utilizzando appunto un sistema di chiavi/valori per l’identificazione (da cui il termine Map).
La soluzione viene predisposta nel rilascio della versione 2.16 di log4j, ma anche in questo caso non si dormono ancora sonni tranquilli.
Infatti a breve segue il rilevamento di una nuova vulnerabilità, la CVE-2021-45105 (gravità 7.5), nella versione 2.16. Questa vulnerabilità consente, per validazione insufficiente dell’input e per mancato controllo della ricorsione, che la sostituzione di variabili nei ContextMapLookup porti facilmente, come sostenuto dai tecnici di Trend Micro Research Team, ad un Denial-of-Service DoS del servizio esposto operante con log4j e preso di mira da un attaccante.
Il rimedio? Al solito, aggiornare urgentemente i sistemi, portandosi alla versione 2.17 rilasciata per la correzione (speriamo) definitiva di questo problema.
Intanto ricercatori di Checkpoint, Microsoft, Trend Micro e altri stanno osservando il montare di sfruttamenti delle vulnerabilità Log4Shell da parte di differenti APT associabili a stati nazionali (iraniani, cinesi, nord coreani e turchi): la fretta aumenta.
