Log4j: i problemi aumentano! C’è una terza vulnerabilità contenuta nella prima patch

Log4j: i problemi aumentano! C’è una terza vulnerabilità contenuta nella prima patch

L'aggiornamento 2.15.0 emesso per risolvere la falla Log4Shell e già dimostratosi incompleto, introduce in realtà una nuova vulnerabilità che può essere usata per l'esfiltrazione di dati

di pubblicata il , alle 10:41 nel canale Sicurezza
 

La seconda vulnerabilità a carico di Apache Log4j identificata nei giorni scorsi e che va ad aggravare il quadro di Log4Shell è già attivamente sfruttata da diversi attori di minaccia, rendendo così ancor più impellente la necessità di installare la versione 2.16.0 di Log4j che elimina il problema

Riassumendo brevemente la situazione, lo strumento Log4j di Apache, diffusamente utilizzato per effettuare il logging di eventi software soffre di una vulnerabilità grave, CVE-2021-44228, che consente di eseguire facilmente codice da remoto senza autorizzazione. La vulnerabilità è stata risolta nella versione 2.15.0 di Log4j che tuttavia è risultata "incompleta", lasciando aperta una seconda falla, CVE-2021-45046, che può consentire l'esecuzione di attacchi denial-of-service. Questa falla è stata risolta nella versione 2.16.0.

Purtroppo però le cattive notizie non cessano di arrivare: è stata individuata infatti una terza nuova vulnerabilità dalla società di sicurezza Praetorian proprio nella versione 2.15.0 di Log4j che può consentire "l'esfiltrazione di dati sensibili in determinate circostanze". Non sono stati divulgati una serie di dettagli tecnici che permetterebbero di comprendere meglio le possibilità di sfruttamento ma attualmente non è chiaro se questo sia già stato risolto nella versione 2.16.0.

La scoperta della terza vulnerabilità avviene in un momento in cui oltre ad una crescita significativa dei tentativi di sfruttamento sono state rilevate dalle società di sicurezza anche la discesa in campo dei sofisticati collettivi hacker supportati da governi, tra cui i famigrerati Hafnium e Phosphorous.

A ciò si aggiunge una nota del Threat Intelligence Center di Microsoft, il quale ha rilevato che anche gli initial access broker stanno attivamente sfruttando Log4Shell per ottenere accesso a reti bersaglio, e rinvenderlo successivamente a terzi principalmente interessati alla diffusione e infezione da ransomware.

7 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
TheZeb16 Dicembre 2021, 11:41 #1
Quanche anima pia mi spiegherebbe cosa dimostra il video di cui sopra ?

Tnx.
igiolo16 Dicembre 2021, 12:30 #2
Originariamente inviato da: TheZeb
Quanche anima pia mi spiegherebbe cosa dimostra il video di cui sopra ?

Tnx.


che se formatti una richiesta ad un server che usa log4j , riesci a fare in modo che questo server esegua un comando, ed in questo caso una connessione verso un ip terzo
c'è gente che formattando una query nella pagina di login di icloud, riusciva a far comunicare i server apple con i propri
TheZeb16 Dicembre 2021, 12:39 #3
me cojoni ...
igiolo16 Dicembre 2021, 14:37 #4
Originariamente inviato da: TheZeb
me cojoni ...


capisci la portata?
ruezzana16 Dicembre 2021, 16:57 #5
C'è qualche metodo per capire dove viene usato questo Log4j?
Lieutenant16 Dicembre 2021, 19:04 #6
Originariamente inviato da: ruezzana
C'è qualche metodo per capire dove viene usato questo Log4j?


Dappertutto. Viene usato dappertutto. Gli hacker comincieranno ad attaccare tutti i server. La società scenderà nel caos più totale. La gente farà la coda fuori dalle banche per prendere i soldi. Moriremo tutti! Capisci? Tutti! Aaaaahhhhhhhhh!!!

Scherzi a parte: la domanda è "dove NON viene usato"... perchè viene utilizzato praticamente in quasi tutti i progetti basati su Java, che viene a sua volta utilizzato in praticamente tutti i settori dall'industria ai servizi. Considera che ogni azienda ha di solito diverse decine di progetti basati su Java, alcuni dei quali probabilmente non ricordano nemmeno di avere... e la portata del problema comincia a diventare chiara.

Questa falla è un problema ENORME.
Roba proprio che mi aspetto comincieranno a usarla per andare a fare operazioni di ransomware sia mirate che ad ampio spettro, furti di informazioni, furti di asset finanziari, distruzione di archivi di ogni tipo, spionaggio...

Insomma: è la vulnerabilità più pericolosa secondo me mai vista.
Tasslehoff16 Dicembre 2021, 23:06 #7
Originariamente inviato da: Lieutenant
SNIP
Questa falla è un problema ENORME.
Roba proprio che mi aspetto comincieranno a usarla per andare a fare operazioni di ransomware sia mirate che ad ampio spettro, furti di informazioni, furti di asset finanziari, distruzione di archivi di ogni tipo, spionaggio...

Insomma: è la vulnerabilità più pericolosa secondo me mai vista.
Ora, la vulnerabilità è seria e pericolosa, però occorre tenere presente che:
[LIST=1]
[*]è estremamente facile da "disinnescare" (basta aggiungere una property tra le JAVA_OPTS) che non causa nessunissimo problema nemmeno su vecchissime versioni di JDK o di log4j
[*]le vecchie versioni di log4j (1.x) di default non ne sono affette perche la lookup jndi è disattivata e per attivarla occorre agire esplicitamente su un parametro
[*]se la versione di log4j che si usa è affetta, e non c'è mitigazione attiva, allora può avere effetto solo se la macchina può fare traffico in outbound, e la cosa non è ne scontata ne automatica (non lo dovrebbe essere ma mi rendo conto che molti gestiscono le proprie macchine "a membro di segugio" ).
[/LIST]

Più che altro imho questa vulnerabilità ha messo in luce un malcostume sia a livello applicativo che architetturale.
Da una parte l'uso a prescindere di librerie e tool su cui nessuno riflette o approfondisce (io sono vent'anni che mi trovo tra i piedi log4j e non ho mai visto nessuno sviluppatore usarlo o conoscerlo decentemente, lo usano tutti ma sempre e solo lasciando tutto a default, quindi con rotazione dei log pessima, retention pessima, niente compressione etc etc...).

Dall'altro architetture fatte appunto "a membro di segugio", ovvero host lasciati liberi di fare il traffico in outbound senza limitazioni di alcun tipo, e se qualcuno osa proporre di usare un proxy o restringere le regole perimetrali di outbound su host, protocolli e porte specifici apriti o cielo, levata di scudi di sviluppatori e PM "perchè così non possiamo lavorare"

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^