100mila Carte di Credito Italiane Rubate!? No, vediamoci chiaro!

Lunedì 19 Ottobre l’utente @theneogod ha annunciato su Twitter che lui e la sua Crew hanno sottratto attraverso il dump di un dabatase 100 mila carte di credito di utenti Italiani, poche ore dopo un nuovo Tweet annunciava la disponibilità del pacchetto da scaricare attraverso Mega.nz! Il download è protetto da una password resa disponibile solo stamattina, pubblicata sempre tramite il social network. Per chi fosse interessato al download dovrà usare la seguente password: !juiKuTcwzN4sTGG6jdXsLdVFmjRAaKvGfz7EnLErz5k

Assieme a Denis Frati del D3Lab ho condotto un’attenta analisi dei database per confermare o meno l’autenticità dei dati, il D3Lab effettua operazioni di contrasto al Phishing e di recupero delle carte di credito sottratte a diversi istituti di credito nostrani per arginare il sempre più crescente fenomeno delle truffe di Ingegneria Sociale basate sul Phishing. Nell’anno incorso, spiega Denis, stimiamo il recupero di circa 7mila carte di credito di utenti caduti nella trappola di Phisher, recuperando le carte di credito in tempi brevi permettiamo all’istituto di credito di bloccare la carta in maniera preventiva e l’utente finale sarà contento di non vedere il proprio plafond azzerato.

Analisi Archivio

L’archivio scaricato da Mega.nz ha le seguenti caratteristiche:

• Nome file: 53030_db.zip
• Dimensione: 4,2MB
• Hash Sha256: 4C4B0E2399F6C91BB6C22B44FA182CEF1902573DF481985E7C5DC0886E5C127A
• Hash Sha1: 85B1DD39475834C6ED3DDEF384A08AC21CFE8781
• Hash MD5: 16249270459F2F4A8D1248232EA2F939

L’archivio contiene tre file:

• readme.txt, creato il 19 Ottobre 2015 alle 14:49
• 53031_db.sql, creato il 19 Ottobre 2015 alle 13:28
• 53030_db.sql, creato il 19 Ottobre 2015 alle 12:00

Il file readme.txt specifica che i due database contengono ciascuno 50.000 conti italiani di Visa/Mastercad, per un totale di 100.000 classificati in tabelle:

• indirizzo_mail
• password
• data_scadenza
• tipocarta
• ccnumber
• CVV2
• telefono
• browseruseragent

Infine consigliano di utilizzare un Proxy e di non farsi recapitare a casa gli eventuali acquisti.

Analisi dei Database

Aprendo i due database in formato .sql salta subito all’occhio la dichiarazione CREATE TABLE in formato SQL:

CREATE TABLE `53031_db` (
`indirizzo_mail` varchar(100) NOT NULL,
`password` varchar(25) NOT NULL,
`data_scadenza` varchar(10) NOT NULL,
`tipocarta` varchar(10) NOT NULL,
`ccnumber` varchar(16) NOT NULL,
`CVV2` varchar(3) NOT NULL,
`telefono` tinytext NOT NULL,
`browseruseragent` varchar(255) NOT NULL
);

le righe successive invece contengo la dichiarazione INSERT TO seguita dai dati delle “vittime”, ecco un breve estratto:

insert into 53031_db values(‘LiviaXXPirozXX@gmail.com’,’sohRae9ae’,’1/2016′,’Visa’,’4532416359404396′,’872′,’0374 5404526′,’Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36′);
insert into 53031_db values(‘ProserpXXPalerXX@hotmail.com’,’Choo6noon’,’2/2019′,’MasterCard’,’5150464089044049′,’994′,’0398 2738251′,’Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36′);
insert into 53031_db values(‘ErminXXPalerXX1992@hotmail.it’,’imoraed4Ai’,’1/2016′,’MasterCard’,’5532742505727399′,’864′,’0332 4429040′,’Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36′);
insert into 53031_db values(‘AdelXXCocXX@gmail.com’,’Aol5yaeh’,’5/2017′,’Visa’,’4716687395227086′,’493′,’0367 5691515′,’Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/600.8.9 (KHTML, like Gecko) Version/7.1.8 Safari/537.85.17′);
insert into 53031_db values(‘ClementiXXBareXX@yhaoo.com’,’cheepieNg3′,’12/2018′,’MasterCard’,’5472781920701052′,’593′,’0352 7178140′,’Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36′);

Gli indirizzi eMail li ho volutamente oscurati parzialmente introducendo le doppie X alla fine del nome e del cognome.

eMail e NickName

Ad un primo sguardo ci accorgiamo subito di un’anomalia, le eMail sembrano create da uno script automatico. Deduciamo questa ipotesi dai seguenti fattori:

• Tutte le eMail contengono nomi propri di persona e cognomi Italiani;
• Non vi è alcuna eMail con un NickName (es. papero23, pluto85, kikka78, ecc);
• Le iniziali dei Nomi e dei Cognomi sono rigorosamente in maiuscolo, in tutti i cento mila records.

Analizzando questi tre punti abbiamo iniziato a storcere il naso e a credere che i dati non siano proprio così reali, ma non ci siamo fermati volevamo essere sicuri della nostra ipotesi.

Abbiamo quindi estratto i provider eMail contenuti nel dump, scoprendo:

• 1 eMail di: agenzialillo.com
• 1 eMail di: calzaturerossi.it
• 1 eMail di: cmsit.com
• 1 eMail di: deboraprofumi.it
• 10013 eMail di: fastweb.it
• 24974 eMail di: gmail.com
• 9959 eMail di: hotmail.com
• 5055 eMail di: hotmail.it
• 1 eMail di: impresaedilecassari.it
• 10011 eMail di: libero.it
• 9933 eMail di: live.it
• 10045 eMail di: outlook.com
• 9905 eMail di: vodafone.it
• 10100 eMail di: yhaoo.com

Prima di tutto parliamo dei grandi assenti, è un dump Italiano è difficilmente ci immaginiamo che tra 100mila utenti non ve ne sia almeno uno con una eMail di @virgilio.it o @tiscali.it o la più gettonata @alice.it.

Poi ci casca l’occhio su @yhaoo.com (non lo abbiamo scritto male, nel database ci sono 10100 eMail @yhaoo.com e non @yahoo.com), crediamo fin da subito che ci sia stato un errore di digitazione in fase di generazione dei dati ma per sicurezza simuliamo la creazione di una nuova eMail sul portale di Yahoo.

Il sito di Yahoo ci conferma che non è possibile creare una eMail gratuita con il dominio @yhaoo.com, anche simulando la creazione in un’altra lingua diversa dall’Italiana.

Per ultimo voliamo analizzare i 5 domini privati che risultano nel dump con una sola eMail per dominio, “casualmente” i domini risultano disponibili alla registrazione.

• impresaedilecassari.it: AVAILABLE;
• deboraprofumi.it: AVAILABLE;
• cmsit.com: REGISTRED ma è un dominio non in uso registrato da una azienda Americana;
• calzaturerossi.it: AVAILABLE;
• agenzialillo.com: AVAILABLE.

Ma giusto per essere stra sicuri che queste eMail siano state generate casualmente decidiamo di scrivere a 10 eMail, per capire se ci ritorna indietro il classico messaggio di User Unknown oppure il recapito va a buon fine. Abbiamo quindi estrapolato casualmente 10 indirizzi dal database e 8 eMail non sono state recapitate per inesistenza dell’account.

Già dall’eMail potevamo dedurre che questo dump non è veritiero, ma abbiamo proseguito.

Password

Un dump che si rispetti deve contenere le password degli utenti, meglio ancora se sono in chiaro proprio come in questo caso. Ma qualcosa non torna…con un semplice grep da linea di comando non abbiamo trovato alcuna password debole/semplice:

• 0 – password
• 0 – 123456
• 0 – 111111
• 0 – qwerty
• 0 – 000000
• 0 – 987654

Che 100mila utenti siano diventati così diligenti da usare password non deboli/semplici ci sembra un miracolo, avranno usato allora nomi comuni? No, il successivo test che abbiamo intrapreso è stato quello di utilizzare un dizionario di parole Italiane più comuni e con grande sorpresa non ne abbiamo trovata nessuna nel campo password. Sì avete capito, non c’è alcuna password che contiene una delle seguenti parole: Andrea, Casa, Anna, Lavoro, Francesca, Denis, Palestra, ecc ecc nessuna!

Infine tutte le password contengono una lettera Maiuscola e un Numero! 100mila utenti un po’ troppo diligenti…

Carte di Credito

In prima battuta abbiamo notato un dettaglio importante, su 100mila carte di credito NESSUNA risulta scaduta! Un archivio così aggiornato, se reale, può solo provenire da un database bancario poiché qualsiasi sito online di eCommerce o sevizi vari avrà in memoria carte di credito scadute di utenti che non comprano beni o servizi da parecchio tempo.

Il passo successivo è stato quello di identificare gli istituti di credito attraverso il BIN (Bank Identification Number) e le prime 6 cifre del PAN (Primary Account Number), ma nel 99% dei casi non siamo riusciti ad associare le carte di credito ad un istituto ben preciso. Abbiamo quindi confrontato i dati delle carte di credito in questione con le carte di credito che il D3Lab ha recuperato in operazioni anti Phishing, ottenendo il seguente grafico.

Il grafico evidenzia una eccessiva discrepanza dei dati relativi agli istituti emittenti delle carte dei due campioni.

Ma non ci siamo voluti fermare, abbiamo contattato due nostri partner per effettuare una verifica sui codici PAN delle carte di credito elencate. I numeri delle carte di credito PAN, spiega Denis, sono formalmente validi, rispettano quindi l’algoritmo di Luhn, tuttavia due nostri partner ci hanno confermato che le carte a loro riconducibili attraverso il BIN sono risultate inesistenti.

Numeri Telefono

Per finire abbiamo analizzato i numeri di telefono riportati, in primis non è riportato all’interno del database neanche un numero di cellulare ma soprattutto tutti i numeri fissi appartengo a prefissi telefonici inesistenti.

Conclusioni

Visti tutti i precedenti punti siamo fortemente convinti che questo dump di 100.000 carte di credito sia finto e creato ad-hoc con uno script automatico, non vi è stata alcuna sottrazione di dati reali!

Perché hanno voluto far credere di avere così tante carte di credito? A chi volevano far paura? Cosa si nasconde dietro a questo dump e al profilo di The Neo God con più di 100mila follower?

Queste sono le domande che mi sto facendo da qualche ora e onestamente non riesco a darmi una spiegazione di questa grossa operazione mediatica…falsa!

Ancor prima di pubblicare l’articolo The Neo God ha iniziato a seguirmi su Twitter, sono uno dei pochi fortunati (154 Following su 100.960 Follower)…sarà un caso?! 😀