Link alla notizia: https://www.hwupgrade.it/news/sicurezza-software/log4j-i-problemi-aumentano-c-e-una-terza-vulnerabilita-contenuta-nella-prima-patch_103272.html

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

Click sul link per visualizzare la notizia.

Quanche anima pia mi spiegherebbe cosa dimostra il video di cui sopra ?

Tnx.

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

me cojoni ... :eek:

me cojoni ... :eek:

capisci la portata?

C'è qualche metodo per capire dove viene usato questo Log4j?

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.

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:

è 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" :rolleyes: ).


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" :ncomment: