3 milioni di server a rischio ransomware per via di software non aggiornato

3 milioni di server a rischio ransomware per via di software non aggiornato

Le vulnerabilità delle versioni non aggiornate dell'applicativo server JBoss mettono a rischio molti server esposti sulla rete che possono essere sfruttati per eseguire attacchi ransomware

di pubblicata il , alle 11:50 nel canale Sicurezza
 

Più di 3 milioni di server esposti su Internet sono a rischio di contaminazione ransomware a causa della presenza su di essi di applicativi vulnerabili, in particolare versioni non aggiornate dell'applicazione JBoss di Red Hat.

L'allarme viene lanciato dai ricercatori Cisco con un post sul blog ufficiale della compagnia. Circa 2100 di questi server sono già stati compromessi da webshell che consegnano nelle mani degli attaccanti il controllo persistente sulle macchine, aprendo la strada a possibilità di infezione in qualsiasi momento. I server compromessi sono collegati a circa 1600 indirizzi IP differenti appartenenti a scuole, uffici governativi, società di aviazione e altri tipi di organizzazione.

Alcuni dei server compromessi fanno parte dei distretti scolastici che utilizzano il gestionale Destiny, usato da molte biblioteche scolastiche per mantenere traccia di libri e di altre risorse. Cisco ha notificato la falla agli sviluppatori di Destiny, i quali hanno dichiarato di aver risolto una vulnerabilità di sicurezza presente nel programma, inserendo inoltre nella versione aggiornata una fuzione di scan per l'individuazione di segni di infezione e per rimuovere ogni possibile backdoor che venga identificata dalla scansione.

E' già da qualche settimana che l'attività degli attaccanti si è spostata verso lo sfruttamento di vulnerabilità in versioni non patchate di JBoss. Al momento delle prime avvisaglie di questo tipo di attività, i ricercatori Cisco hanno identificato circa 2 milioni di server vulnerabili. La conta è salita ora a 3 milioni di server, fattore che suggerisce come la minaccia debba ancora essere contenuta e che la situazione potrebbe ulteriormente peggiorare, specie ipotizzando la presenza di vulnerabilità ancora non conosciute presenti in altri applicativi server.

I ricercatori Cisco suggeriscono inoltre un modus operandi da adottare nel caso in cui si trovasse una webshell installata su un server. Anzitutto è indispensabile, quando possibile, rimuovere l'accesso esterno al server per prevenire che gli attaccanti vi possano accedere da remoto. L'azione migliore da compiere potrebbe essere il ripristino dell'immagine originale del sistema per installare poi tutti gli aggiornamenti disponibili per il software presente sulla macchina. Se questa strada non fosse praticabile, è allora utile ripristinare un backup precedente alla compromissione e installare tutti gli aggiornamenti prima di riportare la macchina in produzione.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione.
Leggi la Privacy Policy per maggiori informazioni sulla gestione dei dati personali

7 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
illidan200018 Aprile 2016, 15:29 #1
"... è allora utile ripristinare un backup precedente alla compromissione e installare tutti gli aggiornamenti prima di riportare la macchina in produzione."

se il backup non è pure lui già stato infettato...
Tasslehoff18 Aprile 2016, 17:51 #2
Ma questa non è una vulnerabilità del prodotto, è una vulnerabilità nella testa della gente che usa il prodotto...

Se qualcuno espone a web un intero application server senza filtri (o con filtri inutili e insufficienti, es un reverse proxy totale senza alcun filtro) e senza preoccuparsi di cosa gira su quel servizio è un incosciente o un ignorante, e non serve essere un esperto di sicurezza per arrivarci, basta il comune buon senso.

Esistono modi molto semplici e assolutamente economici (non dico gratuiti perchè anche i 5 minuti che servono per implementarli costano, seppur un'inezia...) per esporre solo il context di una applicazione deployata su un application server o un servlet container j2ee, basta una banale istanza apache con mod_proxy e un semplice proxypass.
Poi se uno vuol mascherare anche il prodotto nell'header http o implementare chissà quale altra misura di sicurezza ben venga, ma esporre a web il context di un servizio è il minimo sindacale, per il resto console (web o jmx) sono strumenti utilissimi, anzi indispensabili per il monitoraggio e il problem solving, quindi eliminarli mi pare una soluzione inutile e controproducente a prescindere...
illidan200019 Aprile 2016, 00:03 #3
Originariamente inviato da: Tasslehoff
Ma questa non è una vulnerabilità del prodotto, è una vulnerabilità nella testa della gente che usa il prodotto...

Se qualcuno espone a web un intero application server senza filtri (o con filtri inutili e insufficienti, es un reverse proxy totale senza alcun filtro) e senza preoccuparsi di cosa gira su quel servizio è un incosciente o un ignorante, e non serve essere un esperto di sicurezza per arrivarci, basta il comune buon senso.

Esistono modi molto semplici e assolutamente economici (non dico gratuiti perchè anche i 5 minuti che servono per implementarli costano, seppur un'inezia...) per esporre solo il context di una applicazione deployata su un application server o un servlet container j2ee, basta una banale istanza apache con mod_proxy e un semplice proxypass.
Poi se uno vuol mascherare anche il prodotto nell'header http o implementare chissà quale altra misura di sicurezza ben venga, ma esporre a web il context di un servizio è il minimo sindacale, per il resto console (web o jmx) sono strumenti utilissimi, anzi indispensabili per il monitoraggio e il problem solving, quindi eliminarli mi pare una soluzione inutile e controproducente a prescindere...


ehm... che sarebbe mod_proxy e proxypass?
mi informo..........
LukeIlBello19 Aprile 2016, 10:54 #4
quoto tasselhoff..

Originariamente inviato da: illidan2000
ehm... che sarebbe mod_proxy e proxypass?
mi informo..........


appunto
Tasslehoff19 Aprile 2016, 16:58 #5
Originariamente inviato da: illidan2000
ehm... che sarebbe mod_proxy e proxypass?
mi informo..........
Si tratta di un modulo di apache (e di una delle direttive da usare con questo modulo) per usare il webserver come reverse proxy, ovvero fare in modo che il webserver riceva la richiesta dal client e la inoltri all'application server.
Questo è utile per diversi motivi, es:
[LIST]
[*]scaricare l'application server da un carico non necessario (es risorse statiche, lasciando gestire all'application server solo le componenti dinamiche o più in generale "applicative"
[*]gestire le richieste in modo flessibile (es tramite regole di rewrite e regular expression)
[*]bilanciare le richieste su più application server per garantire continuità di servizio e/o bilanciamento di carico
[*]filtrare le richieste esponendo solo quello che gli utenti devono vedere, quindi riducendo il più possibile l'eventuale finestra di attacco
[/LIST]

Non fraintendermi, non voglio sembrarti arrogante o supponente, quando parlavo di ignoranza intendevo in senso letterale.
E' normale che per un utente generico o specialistico ma che si occupa di altro (es uno sviluppatore, un analista, un commerciale) queste cose siano sconosciute o non chiare, ma se una persona gestisce un application server e ha i permessi per poterlo esporre a web allora deve conoscere questi strumenti che esistono dalla notte dei tempi, e con questo mi riferisco in generale ai reverse proxy, poi uno può usare Nginx, haproxy, oppure apparati superfighi e costosi tipo F5, l'importante è usarli.

Se uno si trova in queste condizioni e non li conosce allora è un problema, magari non è colpa sua ma di chi l'ha messo in questa condizione e gli ha sbolognato servizi e sistemi che non è in grado di gestire (con le competenze che ha in quel momento, poi chiunque si può formare per fare una cosa del genere); e qui ci ricolleghiamo a un discorso ben più ampio che riguarda il pressapochismo e la corsa al risparmio (non per stare nei costi ma per massimizzare il margine di guadagno che non può mai essere in qualche modo eroso per nessun motivo ) che caratterizza il mondo dell'IT in Italia

[EDIT]
Dimenticavo una cosa, mi aspetto anche che un sito che si considera una "testata giornalistica tecnica e specialistica" (che oltretutto possiede anche una sezione "business" analizzi un tema del genere anzichè limitarsi a fare un copia e incolla becero, che oltretutto veicola una informazione tecnicamente errata e controproducente, senza nemmeno citare la vera soluzione.
illidan200019 Aprile 2016, 17:10 #6
mmmh... onestamente il webserver apache, in senso stretto, non l'ho mai usato. Sono programmatore java, e uso molto tomcat (che sempre apache è..., ma non è la stessa cosa ).

Pensavo comunque che le direttive di cui parlavi sopra fossero già attive di default
Tasslehoff19 Aprile 2016, 22:53 #7
Originariamente inviato da: illidan2000
mmmh... onestamente il webserver apache, in senso stretto, non l'ho mai usato. Sono programmatore java, e uso molto tomcat (che sempre apache è..., ma non è la stessa cosa ).

Pensavo comunque che le direttive di cui parlavi sopra fossero già attive di default
E' possibile che il mod_proxy sia attivo di default con la configurazione di default di diverse distribuzioni GNU/Linux, però per utilizzarlo devi comunque configurare un ProxyPass usando l'opportuna sintassi.

Comunque per chiarezza queste direttive e moduli sono dell'http server dell'apache software foundation (comunemente detto "apache" perchè è oggettivamente il progetto più rilevante della fondazione), in Tomcat non credo ci sia nulla del genere. Puoi gestire i permessi sulle varie applicazioni deployate, ma è certamente un modo meno flessibile e sicuro per implementare un controllo del genere, non esporre qualcosa è sempre più sicuro che esporlo protetto da autenticazione.

Se cerchi su google "apache proxypass" troverai l'infinito in termini di guide e howto per farlo.

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.
 
^