Verifiche di Restore

Abbiamo messo in atto una fantastica procedura di backup, che salva i dati in due locazioni diverse ed inoltre nel cloud, per maggiore sicurezza.

Siamo assolutamente certi che qualunque cosa accada potremo superarla brillantemente.

Poi, un giorno, viene un consulente dataprotection e ci domanda se abbiamo mai effettuato delle simulazioni di ripristino dei sistemi, ipotizzando che i sistemi “live” siano morti e che ci siano rimasti solo i backup.

Il poveretto viene squadrato con un sorrisetto; la richiesta qualificata come eccessiva e non giustificata, e quindi nessuno si “prende la briga” di provare ad effettuare un restore (ma neanche verificare l’integrità degli archivi costituenti i vari backups).

Poi, un brutto giorno, accade quanto ipotizzato dal consulente ed assolutamente certificato dal MTBF – una semplice rottura di un hard disk, funzionante da 8 anni – e tutte le certezze vengono meno (insieme ai dati); i backups sono inservibili in quanto nessuno, in otto anni, si era mai accorto che la procedura creava degli archivi corrotti.

Un esempio di cosa può succedere, accaduto nel mese di gennaio 2019.

Continuiamo a pensare che le procedure di controllo sono tempo perso.

L’ineluttabilità della insicurezza

Ogni tanto accade un fatto talmente eclatante che dovrebbe fare scuola, nel campo della sicurezza informatica.

Il giorno 11 febbraio VFEmail, un provider e-mail americano è stato oggetto di un attacco catastrofico (definita da loro stessi “catastrophic destruction”), da parte di soggetti che hanno completamente azzerato le loro risorse I.T. , ivi compresi tutti i backups.

Allo stato attuale, sembra che non riusciranno a recuperare nulla; sono stati quindi cancellati tutti gli archivi di posta dei loro utenti.

Allo stato, non hanno ancora realizzato come questo attacco totale sia stato possibile:
“Strangely, not all VMs shared the same authentication, but all were destroyed. This was more than a multi-password via ssh exploit, and there was no ransom. Just attack and destroy.”

Sono molto spiacente dell’accaduto; talvolta capita che un cracker (in questo caso, probabilmente dei paesi dell’est) “bussi alla porta 22”; sta a noi averla precedentemente resa resiliente (oppure bloccata per gli IP “alieni”).

P.S. invito i giornalisti a comprendere la differenza tra hacker e cracker e ad usare la definizione appropriata.

Tentati databreach su siti web

In questi giorni si stanno evidenziando molteplici tentativi di databreach a danno di siti web.

Il sistema è molto semplice ed è stato già usato in passato con successo; spesso, i webmasters hanno la brutta abitudine di realizzare copie del database per attività di manutenzione e di piazzarle nella root del sito, talvolta dimenticando di cancellarli.

I soliti ignoti, tramite dei bot appositamente predisposti, si sono messi a scansionare innumerevoli siti alla ricerca di tali copie (dump), tentando i nomi più usati, quali:

//db.zip
//db.tar.gz
//db.rar
//2018.zip
//2018.tar.gz
//2018.rar
//2017.zip
//2017.tar.gz
//2017.rar
//2016.zip
//2016.tar.gz
//2016.rar
//123.rar
//123.7z
//111.zip
//111.tar.gz
//111.rar
//1.zip
//1.tar.gz
//1.rar
//1.7z

Si consiglia di non effettuare mai backup temporanei di basi dati in spazi pubblici del sito, in quanto potrebbero essere scaricati da soggetti malintenzionati e realizzandosi, in tal modo, un probabile databreach (di norma i dump non sono cifrati).


Data Breach Unicredit

Unicredit è stata ancora oggetto di un data breach, il 21 ottobre 2018.

Il fatto è divenuto di pubblico dominio a seguito del provvedimento del 13 dicembre della Autorità di Controllo italiana, nella quale si prescrive di comunicare, a tutti i 731.519 interessati dalla violazione, quanto accaduto.

Tra le varie considerazioni che mi saltano in mente, non riesco a capire come sia possibile che una Banca come Unicredit non avesse disposto un blocco del traffico proveniente dalla rete TOR e indirizzato verso il portale di accesso all’area clienti.

Collections #2-5

Ovviamente, dopo Collection #1 attendevamo ulteriori leaks; la prima segnalazione proviene dal quotidiano tedesco Heise Online; successivamente è stata confermata da un gruppo di ricercatori universitari tedeschi dello Hasso Plattner Institute.

Si tratta di oltre 2,2 miliardi di registrazioni contenenti dati personali, talvolta solo credenziali, altre profili completi provenienti da database (violati) relativi a registrazioni su siti e servizi in tutto il mondo.

Anche l’università tedesca ha reso disponibile uno strumento di controllo per verificare se i propri dati sono presenti all’interno dei miliardi di dati personali collezionati.

Stavolta è liberamente disponibile su InterNet, anche se si tratta di archivi da quasi 1 TeraByte; ovviamente lo scaricamento e la detenzione sono illegali.

Valgono le considerazioni espresse per Collection #1.

Collection #1

Notizia del giorno, la comparsa di una gigantesca raccolta di credenziali rubate a seguito di svariati data breach e site breach occorsi nel passato.

Qualcuno si è preso la briga di collezionare (per proporne la vendita) le credenziali rubate disponibili nel dark-web; si tratta di oltre 773 milioni di credenziali (prevalentemente e-mail / password associata, moltissime addirittura decifrate oppure in formato testo ).

Dato che spesso gli utenti usano la stessa password per molteplici credenziali, visto che nella raccolta ci sono anche molti datasets di siti italiani, consiglio di verificare se il proprio indirizzo e-mail è compreso nella vastissima collezione.

Adesso tutti hanno capito che le credenziali di accesso con sola password non garantiscono grande sicurezza; abbiamo anche capito perchè occorre cambiare spesso la password.

Aggiornamento: come al solito, molta stampa generale non ha capito molto di quanto accaduto; alcuni hanno banalizzato, molti altri hanno paventato scenari catastrofici. Negli 87 TeraByte, sono presenti sicuramente credenziali “datate”, ma gli indirizzi e-mail non sono soggetti a cambiare (come sarebbe previsto per le password, ma anche qui occorrerebbe condurre un lungo ragionamento sulla frequenza con la quale gli utenti cambiano la password di servizi on-line).

Quindi gli indirizzi e-mail (che sono reali e moltissimi dei quali attivi) si prestano a tutta una serie di attività illecite. Inoltre, un indirizzo e-mail è (di norma) facilmente riconducibile ad una specifica persona; si pensi agli effetti indotti dalla conoscenza della sua iscrizione ad un particolare sito o servizio.

Per non parlare del dataset delle password, le quali costituiscono un campione reale e significativo di password comunemente usate e che quindi può essere usato per “alimentare” sistemi automatici di brute-force attack.

Aggiornamento2: famosi esperti di sicurezza hanno sentenziato che verificare il proprio indirizzo e-mail sul sito haveibeenpwned peggiorerebbe ulteriormente la situazione, in quanto si fornirebbe, insieme ad una e-mail, l’indirizzo IP da quale ci si collega.

Prima considerazione: il proprietario del sito è un affermato professionista e security developer, Troy Hunt; quindi dietro al sito non c’è un hacker ma una persona seria che ha messo gratuitamente a disposizione una importante (e costosa) risorsa per capire se si è incappati in un data breach; non credo che il servizio abbia fini reconditi.

Secondo: la consapevolezza del fatto che i proprio indirizzo e-mail (magari associato alla relativa password) è finito in giro per il mondo è estremamente rilevante; proprio per questo, il GDPR obbliga i titolari che sono stati oggetto di data breach a comunicare tempestivamente il fatto agli interessati coinvolti.

Terzo: in ogni caso, è possibile collegarsi da un indirizzo IP “anonimizzato”, come quello fornito da una delle tantissime vpn (anche gratuite) disponibili oppure tramite TOR. Per i soggetti privati che volessero approfondire in sicurezza ma che non si sentono in grado di farlo, sono a disposizione, nel tempo libero, pro bono.