
31 Marzo 2022
La scorsa settimana è stata scoperta una nuova vulnerabilità particolarmente pericolosa nella libreria Apached Log4j. CVE-2021-44228 o Log4Shell o LogJam è nota come una vulnerabilità di classe Remote Code Execution (RCE), il che significa che se sfruttata su un server vulnerabile, gli attaccanti ottengono la capacità di eseguire codice arbitrario e, potenzialmente, di prendere il pieno controllo di un sistema. Il CVE è stato classificato 10 su 10 in termini di gravità.
L'Apache Logging Project (Apache Log4j) è una libreria di logging open-source utilizzata per milioni di applicazioni Java e altri framework, come Elasticsearch, Kafka e Flink, che sono alla base di molti siti e servizi web popolari. Tutte le applicazioni che utilizzano il framework in esecuzione su sistemi operativi come Windows, Linux, macOS e FreeBSD sono vulnerabili. Java, inoltre, alimenta web cam, sistemi di navigazione per auto, lettori DVD e set-top box, vari terminali e persino parchimetri e dispositivi medici. Di conseguenza, questa vulnerabilità ha un effetto a catena molto significativo ed è difficile prevedere la portata totale e l'impatto a lungo termine della vulnerabilità.
Al momento, la maggior parte degli attacchi si concentrerebbe comunque sull'installazione di estrattori di cryptovalute e tentativi di attacchi per distribuire Trojan, Botnet e Ransomware, questi ultimi sempre più utilizzarti per rubare dati sensibili, documenti di identità, contratti e chiedere riscatti. Secondo i ricercatori di Bitdefender, i criminali informatici stanno tentando di diffondere Khonsari, una nuova famiglia di ransomware, per colpire i sistemi basati su Windows e il Trojan (RAT) di accesso remoto Orcus. La maggior parte dei primi attacchi finora ha preso di mira i server Linux e sarebbero principalmente di “reverse bash shell”, tecnica utilizzata per guadagnare un punto d'appoggio nei sistemi per sfruttarli in un momento successivo.
Check Point Research ha registrato oltre 100 hack al minuto, 200.000 attacchi dopo 24 ore dalle rilevazioni iniziali, che sono diventati 800.000 dopo 72 ore, e a cui ne vanno aggiunti altri 40.000 registrati solo sabato scorso. Nelle ultime ore, tuttavia, sarebbero emersi indizi secondo cui i tentativi di exploit sulla vulnerabilità log4j potrebbero essere in atto già da mesi. Solo negli ultimi giorni, inoltre, i ricercatori di CPR hanno anche rilevato oltre 60 nuove varianti dell'exploit originale che può essere sfruttato sia su HTTP che su HTTPS e il numero di combinazioni di come sfruttarlo dà molte alternative all’aggressore per aggirare le protezioni appena implementate.
A differenza di altri grandi attacchi informatici che coinvolgono uno o un numero limitato di software, Log4j è fondamentalmente incorporato in ogni prodotto o servizio web basato su Java. È molto difficile rimediare manualmente. Quelli che non vogliono implementare una protezione sono probabilmente già controllati dagli hacker. Abbiamo già documentato più di 846.000 attacchi, dove più del 40% delle reti aziendali a livello globale sono state prese di mira.
In Italia, il tentativo di exploit si aggira sul 43% delle reti aziendali – numerica che è in linea con la percentuale europea (42%), ma poco al di sopra della media globale (40%). L’Europa quindi rimane comunque il secondo bersaglio preferito dagli hacker. Al momento sono coinvolti oltre 90 Paesi in tutte le regioni e in generale sono state colpite oltre il 60% delle reti aziendali.
Commenti
sono un ragazzo carino... zappo.
Disastro.
Non credere che sia così piccola, firmware come OpenWRT sono stati distribuiti in grandissimi numeri.
Non metto in dubbio che chi lo ha fatto poi sia in grado di applicare le patch.
Però anche i sistemisti aziendali sanno tenere aggiornati i sistemi informativi sotto la loro responsabilità, eppure sappiamo bene che una lerghissima parte non lo fa.
Ti rimando con la memoria allo scorso anno, quando il Governo statunitense agì d'imperio per patchare i server Exchange.
Se vengono trascurati importanti server aziendali, figuriamoci i router domestici.
È una piccolissima percentuale quelli che installano apache e se lo fanno, sanno quello che fanno e quindi presumo che in caso di problemi così eclatanti, stiano un minimo attenti o cmq sappiano come porvi rimedio.
Su tutti i router di grandi dimensioni, che significa praticamente tutti i router di alto livello attualmente sul mercato, può essere installato Apache, e se un utente installa Apache è perché intende far uso di software che lo richiede.
Quindi, quanti sono i router "casalinghi" con questa vulnerabilità?
Impossibile dirlo, per certo OpenWRT è presente su milioni di dispositivi, ed è la stessa OpenWRT a raccomandare l'installazione di Apache.
Ora, quanti di questi sono affidati ad utenti che poi realmente si preoccupano di tenere aggiornato il software del router?
Ti arrabbi se dico che solo una piccolissima percentuale lo fa, mentre la stragrande maggioranza lo installa, lo configura... e poi si dimentica di averlo?
Cmq il mio fritz non ha ricevuto aggiornamenti né dato problemi. Ed è uno di quelli a cui puoi collegare il disco
Non esistono "cose" bug free, ma mantenendole nel tempo e avendo il totale controllo sul loro sviluppo posso assicurarmi che siano il più possibile esenti da problemi. Per ora mi è andata bene così.
Non su quelli nuovi, che sono macchine grandi sotto ogni aspetto, usano Apache e per la memoria di massa sono spesso collegati a dischi rigidi.
Ovviamente parlo di avanzamenti operari dagli utenti, diversamente non avrei scritto che non lo so.
Difatti ho detto di non saperlo neppure io.
Però se vai a curiosare nel sito OpenWRT troverai una nota che invita ad installare Apache, dunque è lecito supporre che esistano nel mondo molti router che eseguono software a rischio.
In base a quale principio?
OpenWRT ad esempio, comsiglia vivamente di installare Apache.
I router casalinghi ormai sono diventati roba grossa.
Chi altro usa JNDI? La vulnerabilità è dovuta ad un lookup JNDI da file di log. La seconda patch si limita a togliere completamente questa funzionalità per risolvere il problema. Sui router di ultima generazione nei datacenter sì. Sui router casalinghi no.
Lavoro già in una bella azienda :) Grazie per l'input
Tendenzialmente sui router si tende a risparmiare ogni bit, immagino che non si usi tale programma ma qualcosa di privato o cmq epurato dalla roba inutile (sembrerebbe che il problema non sia il programma in se ma tutto la roba che gli hanno aggiunto dopo).
Ma che c'entra? Non possono scrivere su hdblog perché sono bravi?
Cioè leggo di gente che riscrive le librerie e sono a posto da decine d'anni... ma cavolo se siete così bravi perchè siete ancora a scrivere su HDBLOG?
mah.... mah... mah... siete già in 2, vi consiglio di metter su azienda insieme
beh... immagino che le tue "cose" siano bug free no? Quindi ti consiglio di mandare il CV alla Apache (per rimanere in tema)
Visto che si parla di seesharp le query parametrizzate sono tipo la base per evitare le iniezioni. Inoltre, dipende dal progetto se uno vuole, fa una classe base con le previsioni del caso. Non c'è bisogno di invadere tutto il codice di query e controlli che ovviamente possono scappare.
Poi dipende sempre da quanto sei pulito come sviluppatore. Ci sono quelli che duplicano codice come se non ci fosse un domani e quelli che non ripetono una sola riga a costo di non dormirci la notte e perdere le amicizie e la famiglia
Forse volevi dire sgallettate vegane?
Mi sto divertendo abbastanza, devo ammetterlo.
No, prendo solo clienti che prediligono la qualità alla velocità di realizzazione. Anche perché nella maggior parte dei casi la fretta del cliente non è giustificata da reali esigenze...
Nel merito dell'interfaccia si, il resto per ora non è stato mai toccato se non per metodi e classi deprecate, praticamente 1 volta che io ricordi per un paio di sorgenti.
A maggior ragione dipende dal cliente.
Quindi prendi solo clienti disposti ad accettare prezzi alti (fuori mercato) e tempi di consegna lunghi? Sono abbastanza rari.
A te pensavo!
Sui router di ultima generazione?
Come ho scritto non ne ho idea, ma immagino molte e regolarmente NON aggiornate.
Perché parli di applicazioni di classe Enterprise? cosa c'entrano le applicazioni Enterprise con Log4j?
Ma proprio perchè è una libreria stra utilizzata gli infilano sempre nuove funzionalità. Anche fosse stata memory safe, il lookup a JNDI lo faceva lo stesso. Perchè non è un errore, è una funzionalità. Pensi di poter legiferare sullo scope-creep?
Lui probabilmente ha la tastiera dietro la schiena e riesce a scrivere guardando il monitor davanti a lui
Fai bene, se lo dovessi accendere, ti ritroveresti in un attimo i russi ed i cinesi in casa
Sentiamo, quanti deployment di applicazioni enterprise scritte in Java ti aspetti su un router? Il solo runtime Java occupa 100 MB minimo.
Non significa nulla però. Certi programmini che ho fatto per hobby erano molto più curati di altri che ho fatto per lavoro, visto che li ho potuti fare con calma e come si deve, senza avere una scadenza che ti costringe a fare tutto in fretta.
Meglio che non ti dica solo quest'anno quanti clienti hanno preso cripto perchè qualcuno ha aperto il file/link sbagliato.
Questo non vuol dire che non esistano buchi di sicurezza, ma credere che il grosso dei problemi derivi da quello vuol dire non aver mai lavorato nel settore.
Questo post è talmente bislacco che può essere solo una provocazione
vero
ed il fatto che ci siano matrioske simili, e chesiano gestiti da volontari, part time e sottopagati
'nzomma
Giustamente ci si preoccupa molto dei server, però mi chiedo quanti router basati su Linux presentino la medesima vulnerabilità.
È una domanda seria del tutto priva di volontà polemica... è che proprio non lo so.
Se usi dei pattern popolari, potrebbero provarci lo stesso.
Dipende quanto stai vicino allo schermo
Ci rubano tutto!!!!@
Sarà la fortuna, sarà altro, l'importante è il risultato :)
Finché te lo lasciano fare, no problema.
mah!
Tutti! Da ogni dove!
Io faccio l'analisi e preventivo, se vuole un lavoro veloce, poi ovviamente il contratto di manutenzione per gli aggiornamenti sarà più salato.
Fatti li caxxi tua!
https://uploads.disquscdn.c...
Potendolo fare è il top!