Sono passati alcuni giorni dal mio primo articolo relativo alla compromissione dei siti web su alcuni server dell’hoster Seeweb ed è arrivata, per mezzo di Punto Informatico, una interessantissima risposta da parte della stessa società. A prescindere dai motivi tecnici e dall’analisi delle cause dell’attacco, è da apprezzare la veloce risposta pubblica che il CEO di Seeweb Antonio Baldassarra ha rilasciato per chiarire la situazione e mettere al corrente, indice di interessamento della società verso i propri clienti.

Detto questo, più importante di quanto possa sembrare, si può passare a ragionare sulle possibili modalità con cui questo attacco sia stato sferrato.

Da quanto si apprende dalle dichiarazioni di Seeweb, le pagine modificate sembrerebbero essere state modificate previo accesso ftp con le credenziali corrette. Su questo punto non ci dovrebbero essere grossi dubbi, anche perché si è già a conoscenza di numerosi tool venduti nel mercato nero online adibiti a questo scopo – cioè alla modifica delle pagine web con accesso via ftp e credenziali corrette, controllo se il codice iniettato sia ancora presente dopo un lasso di tempo e in caso possibile nuova re-iniezione del codice.

Ora bisogna fare un passo indietro e tentare di immaginare come sia stato possibile ricavare le credenziali di accesso per i siti web.

Seeweb ha dichiarato che le macchine colpite non presentano vulnerabilità note né sono soggette ad exploit zero-day a livello di rumors. Tralasciando per un momento gli attacchi zero-day, che non sono di facile individuazione sebbene si possano utilizzare strumenti di prevenzione e di analisi statistica, il problema, almeno secondo il mio parere, non è stato totalmente centrato.

Il fatto che in questo momento le macchine non soffrano di alcuna vulnerabilità nota non esclude a priori che in periodi passati non ci possa essere stato un qualche – seppur breve – periodo in cui le macchine siano state vulnerabili a qualche tipologia di attacco zero-day poi patchata nel giro di qualche giorno. Non voglio né posso assolutamente affermare che i tecnici di Seeweb non abbiano aggiornato tempestivamente le macchine con le ultime patch di sicurezza non appena queste siano state rilasciate.

Ciò su cui volevo far riflettere è il fatto che non necessariamente il lasso di tempo intercorso tra i due attacchi – tra quando le credenziali di accesso sono state recuperate e quando sono state utilizzate – sia minimo. In altre parole le credenziali potrebbero essere state recuperate molto tempo prima, magari in un periodo durante il quale era stato scoperto un possibile zero-day exploit o una vulnerabilità nota non tempestivamente sistemata. Poi, una volta recuperate, potrebbero essere state vendute al miglior offerente – identità digitali e password sono, ahimé, merce pregiata.

Come anche Baldassarra ha fatto notare, infatti, c’è una sorta di differenziale tecnologico nelle due fasi dell’attacco, il che lascia presumere che non siano state le stesse persone ad averli effettuati.

Altra ipotesi, rimarcata dallo stesso product manager di Seeweb, è quella di un probabile sniffing della rete. Quello che, almeno a prima vista, mi sembra particolarmente difficile è che sia stato effettuato al di fuori fuori della rete Seeweb. Insomma, in altre parole o gli attacker sono stati bravi e fortunati a beccare tutti gli username e password di gran parte degli utenti che erano ospitati su precisi server o qualcosa non torna. Le modalità di attacco sono state le stesse utilizzate contro Aruba e Hosting Solutions, anche se gli iframe iniettati non sempre sono stati gli stessi – questo a rafforzare l’ipotesi di gruppi differenti nell’utilizzo delle credenziali mentre un possibile unico gruppo in grado di recuperarle in qualche maniera. Le ipotesi che potrebbero venir fuori sono:

  • gli attacker sono stati fortunati e sniffando li hannno beccati tutti di Seeweb;
  • visti i siti compromessi sia su Aruba che su Seeweb e Hosting Solutions, questi eventuali pirati informatici sono in possesso di centinaia di migliaia di credenziali di accesso ricavati da continui sniffing della rete nazionale (magari con keylogger installati su centinaia di migliaia di pc) e li utilizzano in gruppi di singoli hosting provider ogni volta che lanciano un attacco (il che sarebbe veramente preoccupante);
  • lo sniffing è avvenuto in qualche maniera all’interno della rete, magari da qualche macchina che risiede nel percorso di rete tra l’utente e il proprio server e che può interfacciarsi sul traffico; magari una macchina che è stata compromessa per un breve lasso di tempo per poi essere formattata e reinstallata da parte dei tecnici ignari che la macchina appena formattata stesse in realtà funzionando da sniffer di rete.

Cercare un elemento che accomuni i clienti colpiti non è semplice, soprattutto perché a questo punto non si tratta solo dei clienti di Seeweb ma anche le migliaia di utenti colpiti su Aruba e poi ancora Hosting Solutions. In tutti e tre i casi sembrerebbe che gli iframe siano arrivati legalmente da un accesso ftp. Ma cosa possono avere migliaia di utenti in comune? Personalmente ritengo sia difficile trovare qualcosa che li possa accomunare.

Interessante potrebbe essere svolgere la seguente indagine: controllare su uno dei server colpiti le date di creazione e di ultimo update del dominio attraverso un servizio Whois e controllare quale è il limite massimo in termini di data temporale tra i domini colpiti; controllare poi se i domini non colpiti siano stati creati dopo questo limite temporale. Se c’è una certa corrispondenza, con un lieve margine di errore e imprecisione, si potrebbe già restringere il campo e le date su quando l’attacco si potrebbe essere svolto.

Io purtroppo il tempo di fare questa indagine non ce l’ho al momento.