Ebbene, se siete curiosi di conoscere il caso, naturalmente totalmente inventato, su cui era basato il CyberCop 2009 organizzato da IISFA, basta andare sul sito dell’associazione e scaricare la newsletter numero 2, è gratuita e di libera distribuzione.

Il mio racconto parte dalla prima pagina e si chiama “Detective Morgan”, dal nome di uno dei componenti della squadra di cui facevo parte, che è appunto un Sovrintendente di Polizia. Sono una dozzina di pagine.

Buona lettura.

Ti senti un Gil Grissom, nel profondo? Che aspetti? Comprati una certificazione!

Da questo momento le battute su come sei diventato CTU si sprecheranno.

Non è che ci trovi molto da ridere. Ma anche questo è prevedibile, non sono mai stato un tipo originale.

Per chi non sapesse chi è Gil Grissom. E qui per chi non sapesse cosa sia la Forensics. Magari vale la pena di leggere qualcosa sull’effetto CSI (anche in inglese: CSI effect). Posso testimoniare che, almeno nel mio campo di competenza, l’effetto CSI ha conseguenze devastanti.

Nota personale: nell’articolo in inglese sulle scienze forensi, la Computer Forensics, insieme alla Information Forensics, occupano un posticino molto piccolo. Ma proprio piccolo. Ecco.

Il primo giorno è stato interamente dedicato alla presentazione di software ed hardware di supporto alla computer forensic, con particolare attenzione alla mobile forensic (quella dei cellulari, per capirci). Tutti molto disponibili i rappresentanti delle ditte intervenute. Nonostante qualche intoppo, dovuto soltanto alla densità elevatissima di cose interessanti, ho trovato estremamente utile la panoramica che ne ho ricavato, sia dal punto di vista di cosa offre il mercato, sia per quello che nelle brochures non c’è scritto.

Il giorno successivo è stato dedicato invece alla gara denominata “CyberCop”, in parallelo ai seminari, che purtroppo non ho potuto seguire, dato che ho partecipato con la mia squadra, composta quasi all’ultimo momento, e peraltro ci siamo conosciuti sul posto, visto che una metà non conosceva l’altra metà. Ma l’affiatamento è stato immediato, e ci siamo battuti con tenacia fino alla fine, anche se ha vinto la squadra con più esperienza, come era anche atteso che fosse.
L’intreccio informatico-giuridico era degno dei più intricati casi mai scritti dai migliori giallisti, con un criminale virtuale che dimostrava una grande competenza sia in campo informatico che nelle tecniche e metodi di indagine delle Forze dell’Ordine.
Alla fine siamo riusciti a mettergli le mani addosso, in senso virtuale, ma il tempo per risolvere l’enigma è scaduto senza che riuscissimo a dimostrare, con prove in grado di reggere un processo, che il criminale fosse proprio quello.

L’ultimo giorno si è svolta la simulazione del dibattimento in aula, con tanto di Pubblico Ministero, Difensore e Giudice, e non si sono fatti mancare nulla: prove non ammesse, eccezioni del difensore, imbarazzo del Pubblico Ministero e colpo di scena finale. Insomma, una sceneggiatura perfetta per una puntata di Law&Order.

Se da un lato mi viene da dire “Pazienza, andrà meglio la prossima volta”, dall’altra devo ammettere di aver “rosicato” un poco, lo confesso. Ero convinto di aver inquadrato perfettamente il modus operandi del criminale virtuale, ma i fatti mi hanno dato torto, e sulle prime ci sono rimasto parecchio male.
Poi, dopo qualche giorno, a mente fredda, mentre scrivevo un qualcosa legato alla sfida (e che per ora non posso dire), ho capito parecchie cose su come sono andati i fatti.

Riassumendo brevemente, a parte quello che mi ripeto spesso, ossia che c’è veramente tanto da imparare, forse troppo, il problema è stato proprio l’essere convinto di aver inquadrato la situazione. Due parole: presunzione e pregiudizio.

Il presumere di aver compreso tutto di una situazione, quando se ne ha un punto di vista ristretto e limitato, porta a sottovalutare la realtà e sopravvalutare l’immagine che ce ne siamo fatta. arrivando a scartare elementi che ad un osservatore esterno e non coinvolto appaiono palesi. Per fare un esempio: in una certa fase vi era un file ZIP protetto da password. Ero talmente convinto che il criminale virtuale fosse troppo furbo per usare una password debole, che non ci ho neanche provato a fare un attacco a dizionario. Invece la password era banale, di quattro lettere e senso compiuto, in un attacco a dizionario l’avrei trovata in pochi secondi.

Il pregiudizio di avere di fronte qualcuno “che ci capisce”, ma non così tanto, visto che usa software comuni e strategie note, mi ha fatto di nuovo sottovalutare la situazione. Ho subito associato al criminale virtuale la figura di quello che conosce tutti i programmini del mondo, ma in fondo non sa come funzionano e soprattutto perché. Un esempio: il criminale virtuale aveva un campionario estesissimo di software per crittografia e steganografia, e c’era una immagine che risultava differente da una copia presente in Rete. Le ho provate tutte: analisi del contrasto, mappatura, confronto per sottrazione, istogrammi RGB, ma ho mancato la prova più ovvia: l’immagine conteneva dati nascosti da steganografia, appunto.

Errori banali, dettati appunto da presunzione e pregiudizio. Le mie convinzioni personali mi hanno impedito di accettare ed accertare i fatti come erano. Era un gioco, ma se fosse stata una indagine reale il danno sarebbe stato tutt’altro che trascurabile.

Sul treno del ritorno, con il mio amico Lorenzo, stavamo ricapitolando gli errori e le sviste commesse, ripetendoci ad ogni passo: “Manco le basi!“.

Oltre questo, la lezione ha avuto per me un valore incalcolabile, a parte la constatazione di avere ancora molto da imparare: si può essere buoni tecnici, ma fare l’investigatore è tutto un altro paio di maniche.

Per il resto, ho ancora parecchio materiale da elaborare, contatti da perfezionare e qualche nuovo amico, che male non fa.

Conto di partecipare anche l’anno prossimo, ma così faranno le altre squadre, e la battaglia sarà dura. Ma il divertimento sarà maggiore, ne sono certo.

L’insider, ossia quello che attacca da dentro, che colpisce alle spalle. La traduzione è “addetto ai lavori”, quindi è uno che sa come funzionano i processi aziendali su cui va a fare danni. Quello che i manager ignorano è che spesso l’insider conosce i processi e le relazioni non scritte, quelle che non compaiono nei documenti corposi di analisi prodotti dal solito consulente per la sicurezza e la privacy.

Per carità, nessuna critica ai consulenti, è anche il mio lavoro, per cui sarebbe un autogol.

La realtà è che spesso le aziende non conoscono le proprie interiora, il proprio corpo. Non sanno che il signore che da anni lavora in quella stanzetta al terzo piano è quello che sa perfettamente come funziona e chi contattare per fare quella cosa specifica, che nella mappatura dei processi aziendali magari non compare neanche, perché è inglobata in una casella con un nome (naturalmente in inglese “burocratico”), che in realtà dice poco su quanto sia importante il lavoro svolto.

La dimensione dell’azienda conta, e conta molto. Più è grande, e più è fisiologico che succeda. D’altra parte il management cambia in fretta, difficilmente regge più di cinque anni, mentre il signore nella stanzetta sta lì magari da venti e più. Il manager ha poco tempo, ha un compito preciso, spesso ingrato, e non può umanamente conoscere tutti.

Ed il signore nella stanzetta passa pian piano nel dimenticatoio, fino a quando non salta fuori che la stanza serve a qualcun altro. O il collega più giovane e “rampante” ottiene la promozione, passando avanti al signore. Ecco creato un altro insider.

Alla faccia della risk analysis

Lo so, ho semplificato, le ragioni sono molto più complesse, e qualsiasi semplificazione o schematizzazione è pericolosissima, perché ogni caso va trattato a parte, come ogni persona è differente dalle altre. Fare altrimenti costituisce un errore di valutazione, che non può essere che fatale.

I documenti di analisi dei rischi, e delle relative contromisure, sono corposi, ben organizzati, dettagliati, ma purtroppo non possono scendere al livello di dettaglio a cui lavora l’insider.

A che ora l’impiegato che consegna la posta interna passa a ritirare le lettere, dove vengono depositate in attesa di spedizione, a che ora l’impiegata del personale stila il foglio delle assenze, le sue abitudini dell’ora del caffè, sono cose che spesso l’insider conosce da tempo, come da tempo sa quale sia il punto debole nella catena, non perché “pensi nero”, ma semplicemente sono informazioni trasformate in abitudini.

Senza parlare poi di quando l’organizzazione aziendale è carente dal punto di vista della assunzione di responsabilità. L’informatica ha molto successo in alcuni ambiti, soprattutto perché consente di scaricare la responsabilità sullo strumento. O almeno così credono molti manager. Mettiamo quel sistema di autenticazione sicuro con la smart card, con le impronte retiniche, con l’ultimo grido tecnologico, e siamo al sicuro da tutto.

E’ la stessa credulità che qualche volta deridiamo in chi va dal mago. Non esistono strumenti magici, anche se vengono venduti per tali. E’ e sarà sempre il contesto e l’essere umano a fare la differenza.

Di cosa parlo? Esistono i tesserini per le presenze, no? “Strusci” il tesserino e attesti la tua presenza in azienda. Naturalmente nessuno si sogna di crearne delle copie, prestarlo al collega, lascialo incustodito sulla scrivania. Certo che no.

Infatti la comparsa dei tesserini per le presenze ha debellato la piaga dell’assenteismo. Lo sappiamo tutti. Naturalmente, questo si accompagna al metodo “punire tutti per non educare nessuno”. Tradotto: anche quando, per un caso più che per intenzione, si individui il colpevole di una violazione o di un comportamento negligente, si preferisce lanciare in aria una manciata di sassolini, che danno fastidio a tutti ma in fondo non danneggiano nessuno, piuttosto che tirare un “sanpietrino” al colpevole, perché implicherebbe un coinvolgimento personale e l’assunzione di responsabilità da parte del manager.

Ecco. L’esempio calza a pennello.

Sistemi di Single Sign-On, log centralizzati e certificati, postazioni dotate di smartcard, crittografia forte, tutto quello che vi viene in mente e che trovate nelle raccomandazioni di chi stila le analisi di sicurezza. Metteteci proprio tutto.
Poi aggiungete il fattore umano: emozioni, situazioni, eventi, relazioni, pensieri, convinzioni, pregiudizi.

Il risultato non tarda ad arrivare. Ogni precauzione, per quanto intelligente e studiata, ha la sua nemesi. Autenticazione con smart card assolutamente sicura? L’impiegato la lascia inserita nel lettore e va alla toilette, lasciando la porta aperta. Oppure la dimentica a casa, e le prossime volte, per paura di scordarla di nuovo, la lascia inserita nel lettore.
Password sottoposte ad un rigido protocollo (del tipo: scadenza ogni tre mesi, lettere numeri e simboli, niente termini a dizionario, differente dalle ultime 4 utilizzate)? Il foglietto attaccato sul fondo del cassetto (o sotto la tastiera, o sotto il portapenne) con le sei password da usare a rotazione risolve il problema di doverle tenere a memoria e inventarne una nuova quattro volte l’anno.

La fantasia è l’unico limite, e quando si tratta di fare meno fatica la fantasia abbonda.

Poi arriva l’incidente di sicurezza. Quello serio. Che non è il virus devastante, non è l’hacker “black” di turno. No, molto meno. Qualcuno ha, a scelta:

• Cancellato dei file
• Modificato dei file
• Copiato dei file
• Svuotato un database
• Modificato un database
• Copiato un intero database
• … e via di seguito…

Parte il panico. I manager tuonano, i responsabili tremano, gli amministratori di rete e dei server sono chiamati a casa, di solito nel fine settimana, per rimettere a posto i disastri, i computer sono spenti, tolti dalla “scena del crimine” e riaccesi per fare un backup, gli impiegati interrogati, i log studiati.
Il risultato? La magia tecnologica si rivela insufficiente:

• i log non dicono nulla di utile, a parte quello che si sapeva già, ossia postazioni rimaste accese per giorni con un account utente loggato, amministratori che entrano ed escono dalle postazioni “violate”, generando rumore e cancellando molto probabilmente dati preziosi
• le postazioni sono state manipolate in più occasioni e da più persone, alterando tracce e cancellando indizi importanti
• gli operatori ammettono candidamente di fare uso promiscuo di account e credenziali “perché se il collega è in ferie non posso lavorare senza i suoi file” (i file server, questi sconosciuti)
• Sempre sulle postazioni si trova di tutto: software installato senza licenza, configurazione di sicurezza lasciata sulle impostazioni di default, quindi inesistente, dati estranei all’impiego ufficiale della postazione, per usare un eufemismo

Poi si passa al lato organizzativo, e lì si assiste alla sconfitta completa anche del semplice buonsenso. Operatori non formati ed informati sui propri diritti e doveri, amministratori che operano senza linee guida, e quando queste ci sono c’è sempre un buon motivo per fare eccezioni, naturalmente vanificandone l’efficacia. Ed è quasi impossibile far capire al responsabile di turno che lo strumento, pur sofisticato, senza indicazioni d’uso e regole precise è inutile, quando non dannoso per la mal riposta fiducia nella magia tecnologica.

Alla fin fine questo noi lo sappiamo già. Quello in cui veniamo sconfitti ogni giorno è nel far capire che lo strumento non è la soluzione. Ma anche questo lo sappiamo già. Solo che non riusciamo a trasmetterlo, e chi ha la possibilità di comunicare in maniera efficace e massiva spreca l’occasione mostrando situazioni e soluzioni che in una finzione sono perfette, ma nella realtà sono inesistenti.
Basti pensare agli innumerevoli telefilm e film che presentano il lavoro di investigazione sui computer come una sorta di panacea che risulta essere anche la nemesi di tutti i cattivi, mostrando con coloratissime animazioni in pseudo-computergrafica come in pochi passaggi si ricostruisca il volto di una persona da un fotogramma preso da una telecamera di sorveglianza in cui la persona è inquadrata a figura intera. Peccato che bastino alcuni semplici calcoli per mostrare come sia impossibile, indipendentemente dalla tecnologia impiegata. O che da un messaggio di posta elettronica si possa risalire all’effettiva identità di chi lo ha inviato, cosa che anche l’informatico più sprovveduto sa essere impossibile, e sicuramente non utilizzabile come “prova”, perché anche risalendo all’indirizzo IP del mittente, e da questo all’intestazione dell’abbonamento a Internet, non ci sono prove per dimostrare che era proprio lui al computer in quel momento, certo non esaminando il computer e basta. Ed ecco perché nei casi noti della cronaca i periti nominati dai tribunali possono dimostrare ben poco. Ma questo siamo in pochi a capirlo.

Per tutti gli altri, basta usare un sistema biometrico e si risolve il tutto.

Riferimenti ed altre letture

• Bruce Schneier – Biometrics: Uses and Abuses – un articolo del noto esperto ricercatore di sicurezza che parla dei limiti e delle trappole concettuali della biometria.
• Bruce Schneier – Thwarting an Internal Hacker – Pensieri e considerazioni su un caso reale di insider scoperto prima che potesse fare danni
• Roger Clarke – Biometric Insecurity – alcune presentazioni in PowerPoint che mostrano le ragioni che stanno alla base dell’errato uso della biometria
• Un ricercatore universitario inganna nove volte su dieci un lettore di impronte digitali usando una pasta per modellare
• Duc Nguyen – Your Face Is NOT Your Password – uno scritto presentato alla conferenza Black Hat DC 2009 che mostra come ingannare i sistemi di riconoscimento facciale introdotti da alcuni produttori nei notebook
• Un articoletto sulle regole di sicurezza (le famigerate security policy).

Ringrazio di nuovo l’Associazione e Gerardo Costabile per l’opportunità concessami.

Presenterò due casi reali, presi fra quelli su cui ho lavorato, con le tecniche e le considerazioni relative all’analisi per individuare punto d’ingresso, modalità e scopi dell’intrusione. Uno dei due casi riguarda un blog WordPress compromesso.

Sul sito IISFA tutti i dettagli del seminario, e le informazioni per raggiungere la località. Per chi fosse interessato all’argomento, è il caso di prendere in considerazione l’iscrizione all’associazione.

Per chi partecipa, ci vediamo là.

Ho condotto ulteriori analisi, in particolare sulle due immagini disco generate con Windows XP ed ho scoperto cose interessanti, lavorando però di dump esadecimale.

Ho estratto il file $MFT da entrambe le immagini, ne ho fatto il dump esadecimale e li ho messi a confronto usando gvimdiff, la versione grafica del noto editor Vim nella variante per mostrare le differenze fra due file.

Il file è la Master File Table del filesystem e contiene praticamente tutte le informazioni per mettere insieme i pezzi del filesystem. La struttura è molto complessa, ma per quello che ci serve cercheremo di limitarci all’essenziale per capire come stanno le cose, a scapito dell’estremo dettaglio, che in questo specifico caso non ci interessa.

Riassumo il problema: nella directory docs sono stati cancellati due dei quattro file PDF presenti (pdf2.pdf e pdf4.pdf), e solo uno risulta presente e recuperabile (pdf2.pdf), l’altro pare svanito nel nulla. Tutti i tool forensi provati mostrano questo risultato, sia open source che commerciali.

Confrontando i dump esadecimali delle due MFT si trova il problema. La directory è un file come tutti gli altri, che in questo caso viene memorizzato all’interno della MFT stessa, nello stesso record, vista la ridotta dimensione, condizione in cui il file viene chiamato “residente”. Da qui partono i puntatori agli altri record che rappresentano i singoli file presenti nella directory. Nella MFT dell’immagine con tutti i file prima della cancellazione il record è posizionato nella entry numero 29, all’offset 0×7400 del file. I file sono invece posizionati come segue:

• pdf1.pdf – entry 33
• pdf2.pdf – entry 31
• pdf3.pdf – entry 32
• pdf4.pdf – entry 30

cosa verificabile con Autopsy nella sezione dei metadati. La struttura dati della directory è lunga 464 bytes, sempre secondo la MFT.

Nell’immagine con i file cancellati la struttura della directory è lunga solo 256 bytes, indice che è stata “accorciata”, fra poco vedremo il perché. Le entry di prima contengono:

• pdf1.pdf – entry 33
• pdf2.pdf (deleted) – entry 31
• pdf3.pdf – entry 32
• images/Thumbs.db – entry 30

andando a vedere la struttura della directory nella MFT si nota questo:

00007590:  0803 7000 6400 6600 3100 2E00 7000 6400    ..p.d.f.1...p.d.
000075A0:  6600 0000 0000 0000 2000 0000 0000 0100    f....... .......
000075B0:  6800 5200 0000 0000 1D00 0000 0000 0100    h.R.............
000075C0:  96D8 C62C C323 C901 00D0 106D 741D C901    ...,.#.....mt...
000075D0:  00D0 106D 741D C901 F03A C92C C323 C901    ...mt....:.,.#..
000075E0:  0094 0200 0000 0000 E493 0200 0000 0000    ................
000075F0:  2000 0000 0000 0000 0803 7000 6400 0800     .........p.d...
00007600:  3300 2E00 7000 6400 6600 0000 0000 0000    3...p.d.f.......
00007610:  0000 0000 0000 0000 1000 0000 0200 0000    ................
00007620:  FFFF FFFF 8279 4711 2E4F BD2C C323 C901    .....yG..O.,.#..
00007630:  0003 BA45 741D C901 0003 BA45 741D C901    ...Et......Et...
00007640:  5275 3E14 5B24 C901 009E 0200 0000 0000    Ru>.[$..........
00007650:  D99D 0200 0000 0000 2000 0000 0000 0000    ........ .......
00007660:  0803 7000 6400 6600 3400 2E00 7000 6400    ..p.d.f.4...p.d.
00007670:  6600 0000 0000 0000 0000 0000 0000 0000    f...............
00007680:  1000 0000 0200 0000 FFFF FFFF 8279 4711    .............yG.
00007690:  2E4F BD2C C323 C901 0003 BA45 741D C901    .O.,.#.....Et...
000076A0:  0003 BA45 741D C901 5275 3E14 5B24 C901    ...Et...Ru>.[$..
000076B0:  009E 0200 0000 0000 D99D 0200 0000 0000    ................
000076C0:  2000 0000 0000 0000 0803 7000 6400 6600     .........p.d.f.
000076D0:  3400 2E00 7000 6400 6600 0000 0000 0000    4...p.d.f.......
000076E0:  0000 0000 0000 0000 1000 0000 0200 0000    ................
000076F0:  FFFF FFFF 8279 4711 0000 0000 0000 0000    .....yG.........

che nella MFT prima della cancellazione è invece così:

00007590:  0803 7000 6400 6600 3100 2E00 7000 6400    ..p.d.f.1...p.d.
000075A0:  6600 0000 0000 0000 1F00 0000 0000 0100    f...............
000075B0:  6800 5200 0000 0000 1D00 0000 0000 0100    h.R.............
000075C0:  E213 C22C C323 C901 8037 4114 741D C901    ...,.#...7A.t...
000075D0:  8037 4114 741D C901 3C76 C42C C323 C901    .7A.t...<v.,.#..
000075E0:  0034 0200 0000 0000 3C33 0200 0000 0000    .4......<3......
000075F0:  2000 0000 0000 0000 0803 7000 6400 6600     .........p.d.f.
00007600:  3200 2E00 7000 6400 6600 0000 0000 0000    2...p.d.f.......
00007610:  2000 0000 0000 0100 6800 5200 0000 0000     .......h.R.....
00007620:  1D00 0000 0000 0100 96D8 C62C C323 C901    ...........,.#..
00007630:  00D0 106D 741D C901 00D0 106D 741D C901    ...mt......mt...
00007640:  F03A C92C C323 C901 0094 0200 0000 0000    .:.,.#..........
00007650:  E493 0200 0000 0000 2000 0000 0000 0000    ........ .......
00007660:  0803 7000 6400 6600 3300 2E00 7000 6400    ..p.d.f.3...p.d.
00007670:  6600 0000 0000 0000 1E00 0000 0000 0100    f...............
00007680:  6800 5200 0000 0000 1D00 0000 0000 0100    h.R.............
00007690:  2E4F BD2C C323 C901 0003 BA45 741D C901    .O.,.#.....Et...
000076A0:  0003 BA45 741D C901 E213 C22C C323 C901    ...Et......,.#..
000076B0:  009E 0200 0000 0000 D99D 0200 0000 0000    ................
000076C0:  2000 0000 0000 0000 0803 7000 6400 6600     .........p.d.f.
000076D0:  3400 2E00 7000 6400 6600 0000 0000 0000    4...p.d.f.......
000076E0:  0000 0000 0000 0000 1000 0000 0200 0000    ................
000076F0:  FFFF FFFF 8279 4711 0000 0000 0000 0000    .....yG.........

Proviamo a riassumere. La directory è stata compattata per conservare i dati di soli due file invece di quattro e nella operazione le entry dei file pdf3.pdf e pdf4.pdf vanno a soprascrivere quella del file pdf2.pdf, poi viene accorciata, perdendo le indicazioni relative al file pdf4.pdf. Tutte queste informazioni si perdono e solo andando di dump esadecimale diretto sul file $MFT si possono vedere.
La entry 30, riguardante il file pdf4.pdf viene soprascritta autonomamente da Windows: nel momento in cui sono andato dalla directory docs alla directory images è passato alla modalità “visualizzatore di immagini”, creando e scrivendo il file delle thumbnail (Thumbs.db), soprascrivendo di fatto la entry del file pdf4.pdf. Il file pdf2.pdf è recuperabile perché, anche se eliminato dalla struttura dati della directory, è ancora presente la sua entry nella MFT, mentre il file pdf4.pdf, pur se ancora presente nella entry della directory docs, non è all’interno di alcuna struttura dati valida, e la sua entry è stata soprascritta da un altro file. Ecco perché il file pdf4.pdf è “sparito”.

Insomma, alla fine niente di strano o preoccupante in sé, solo normali operazioni del filesystem e le sue decisioni autonome relative all’efficienza ed al mantenimento della coerenza interna. Se non mi fossi posto il dubbio, e non avessi operato in questo modo, non avrei mai notato le discrepanze e la “scomparsa” dei file cancellati. Lavorando solo con i tool non si ottiene “tutta la verità”. Occorre come sempre competenza ed un pizzico di scetticismo, che non guasta mai.

Quindi, a maggior ragione
Trust no one

La mia partecipazione è stata possibile grazie alla estrema gentilezza e disponibilità del presidente Gerardo Costabile, che ringrazio per l’opportunità concessami.

Presenterò alcuni esempi di tecniche atte a nascondere dati, pensate anche per resistere ad eventuali indagini forensi, e le relative contromisure. Parlerò inoltre di una categoria del tutto nuova di nascondigli, i siti web violati, utilizzando parte del materiale raccolto nella mia indagine contro i blog WordPress compromessi.

Sul sito IISFA tutti i dettagli del seminario, e le informazioni per raggiungere la località. Per chi fosse interessato all’argomento, è il caso di prendere in considerazione l’iscrizione all’associazione.

Per chi partecipa, ci vediamo là.

Passato il primo momento di sorpresa per tanta tracotanza (arrivare a mettere in vendita dei kit per perfetto phisher, il massimo!), la curiosità prende il sopravvento. Lo so, prima o poi mi metterò nei guai per questo…

La domanda che mi frullava per la testa è stata: cosa ci guadagna il tizio? Perché i kit sono liberamente scaricabili, in pacchetti compressi con il formato RAR, senza alcuna protezione. Quindi che razza di pagamento pensa di ottenere?

Lo confesso, ho scaricato un paio di kit, ed ho iniziato ad analizzare il codice, naturalmente in PHP.

E la sorpresa è doppia. Sì, perché c’è molto di più di un kit per il phishing, nei pacchetti. Vado a spiegarmi. Nella più classica modalità da truffatore esperto di umane debolezze, il kit di phishing ha un doppio uso, il secondo dei quali è a danno anche di chi dovesse sfruttare il kit per fare phishing.

Nei file costituenti il kit ve ne è uno che si incarica di spedire al phisher i dati inseriti dall’ignaro navigante che cada nella trappola. Il metodo scelto è l’e-mail, a differenza di altri che semplicemente scrivono i dati su un file locale al server che poi il nostro amico phisher preleverà dopo qualche giorno. In evidenza c’è una riga in PHP dove si intuisce al volo che è il posto dove inserire il proprio indirizzo di posta elettronica per ricevere i dati.

Il file in oggetto è a prima vista molto semplice, ed è costituito da una serie di istruzioni di concatenazione di stringa, per comporre il messaggio contenente user ID, password, numeri di carta di credito, indirizzi, ecc. Guardando meglio il codice si nota che è inutilmente complicato, e che le istruzioni di concatenazione sono assurdamente frammentate. Trattandosi di codice scritto da un Grande Hacker, è abbastanza nella norma, ma tutto sta nel non lasciarsi fuorviare. Guardando il codice e cercando di capire cosa faccia, mi sono reso conto che in una variabile c’era una vocale “e” al posto di una “a”. Le righe erano alternate e componevano DUE messaggi differenti, uno dei quali in realtà era un indirizzo di posta elettronica molto poco intuitivo. Al termine il messaggio composto viene inviato a tre differenti indirizzi di posta elettronica: il primo è quello nella variabile bene in vista, pronto per essere sostituito dall’indirizzo del phisher-wannabe. Gli altri due indirizzi sono presi da due variabili, una è quella inframmezzata alla composizione del messaggio, dell’altra non vi è traccia nel file.

Ho tentato una ricerca in tutti i file del pacchetto di “$Var3″ (il nome della variabile è inventato, è inutile cercarlo con Google…), senza fortuna. Allora ho tentato il jolly: una ricerca per la funzione PHP base64_decode. Tana!

In uno dei form della pagina di phishing c’è un campo input di tipo hidden il cui nome è “Var3″ ed il cui valore è l’output di una chiamata alla funzione base64_decode, con una stringa che, a questo punto l’avrete capito, si risolve in un altro indirizzo di posta elettronica, diverso da tutti gli altri.

In definitiva, se Ernesto (nome inventato), convinto di fare una gran birbonata, installa il kit del perfetto phisher su un sito, i dati li riceverà anche chi ha preparato il kit. E lo scopo è proprio questo, visto lo sforzo che c’è nel codice di nascondere ed offuscare proprio quei due indirizzi di posta aggiuntivi. Se Ernesto venisse scoperto, cosa abbastanza verosimile, pagherebbe dalla A alla Z, mentre il nostro furbacchione si godrebbe i risultati della birbonata di Ernesto, indisturbato. Ricordiamo che avrebbe a sua disposizione tutti i dati che ha in mano Ernesto, inviatigli in “copia conforme”, e che Ernesto probabilmente attenderebbe di averne un po’ prima di iniziare ad usarli, mentre il creatore del kit inizierà ad usarli da subito, prima che Ernesto sospetti qualcosa o che venga scoperto, come quasi certamente sarà.

Tutto ciò, naturalmente, a meno che non si trovi come avversario un investigatore un po’ più smaliziato. A questo punto non avrebbe vita troppo facile, ma per prima cosa sarebbe necessario che l’investigatore si ponga la domanda, si faccia venire il dubbio.

Altrimenti, la cosa potrebbe venir fuori solo al momento dell’interrogatorio di Ernesto.

Ecco, immaginate. Sala per interrogatori, due agenti vestiti di scuro, uno in piedi alle spalle di Ernesto, l’altro seduto dall’altra parte del tavolo:
- Chi ti ha aiutato a creare il codice per il phishing?
- L’ho fatto io! (Ernesto, credendo di fare più impressione, tenta di prendersi il merito)
- Naaahhh. Non ne sei capace. Abbiamo visto nel tuo computer. Il codice che sviluppi non gli si avvicina neanche. Abbiamo curiosato nella cache del tuo browser e sappiamo dove l’hai preso.

Chi è meno credibile: Ernesto che si vanta di aver sviluppato del codice, cosa di cui non è neanche lontanamente capace, o l’investigatore smaliziato al punto da capire che il livello di competenza di Ernesto è insufficiente ed è anche lui vittima di qualcun altro più furbo?

Fate voi. Al solito, non mi rimane che ricordare:
Trust no one

Qualche settimana fa stavo lavorando su un set di memorie flash di vario tipo (pen drive, SD, Memory Stick, CompactFlash) per verificare alcune ipotesi per uno studio di cui forse parlerò in altra occasione. Le operazioni erano banali, più o meno sintetizzabili in questa sequenza:

1. cancella il contenuto scrivendo tutti zeri
2. formatta la memoria in un filesystem scelto fra FAT, Ext3 e NTFS
3. scrivici dei file dentro, 4 PDF e 30 immagini
4. smonta, fai l’immagine con dd
5. rimonta, cancella alcuni file, 2 PDF e 9 immagini, sempre le stesse
6. smonta, fai l’immagine con dd
7. analizza le immagini per verificare che i dati siano sul supporto e che siano recuperabili con vari tool, anche per uso forense

I tool utilizzati erano Foremost e lo Sleuthkit.

Ebbene, la stranezza rilevata è questa: nel primo supporto in cui ho provato con il filesystem NTFS (un pen drive da 1 gigabyte, acquistato in un centro commerciale) le nove immagini cancellate erano totalmente recuperabili, mentre dei due PDF cancellati, secondo Sleuthkit, non vi era traccia, nel senso che non erano neanche fra i file cancellati e non recuperabili. Non solo, erano segnate come cancellate e non recuperabili 4 copie dell’immagine numero 4 e 5 copie dell’immagine numero 5, che naturalmente non avevo toccato.

Usando Foremost, come atteso, i file erano tutti recuperabili, senza problemi.

Questa cosa, in prima battuta, mi ha fatto pensare ad un mio errore di manovra, per cui ho rifatto il test con un altro supporto, una scheda SD da un gigabyte. Stessa storia, unico cambiamento è stato che uno dei due file PDF risultava fra i cancellati e recuperabile, l’altro era sparito, mentre venivano segnate 5 copie dell’immagine numero 4 e 6 copie dell’mmagine numero 5 cancellate e non recuperabili. Foremost, al solito, recuperava tutto.

Ho cambiato le condizioni del test, pensando a qualche stranezza nella gestione dei dischi removibili, ed ho avviato una macchina virtuale con Windows XP Professional SP2 tramite Qemu, a cui ho “collegato” un disco virtuale da 80 megabyte, formattato NTFS. Stesse operazioni, stessa storia: i due PDF cancellati non risultano da nessuna parte, secondo Sleuthkit, mentre le immagini sono tutte recuperabili e c’è sempre la coppia di immagini segnalate fra le cancellate più volte e non recuperabili.

Sempre più perplesso ne ho parlato con i “colleghi di lista” di CFItaly. Ne è nata una discussione che ritengo estremamente fruttuosa, e che provo a riassumere.

Sono state proposte varie spiegazioni, a partire dalla interferenza della virtualizzazione, cosa che ho scartato, verificando su un computer con installato Windows XP Professional SP2: il mio notebook dell’ufficio, a cui ho leggermente ristretto la partizione di ripristino e ne ho ricavato 80 megabyte per creare un disco da formattare in NTFS. Il risultato è stato analogo ai precedenti. Allora è stata fatta l’ipotesi che la partizione fosse troppo esigua, cosa che ho escluso allargando la partizione nel notebook a 350 megabyte, e trovando ancora gli stessi risultati.

A questo punto ho posto io il dubbio che fosse Sleuthkit ad avere dei problemi ed a “mancare” alcune informazioni critiche. Test fatti da colleghi di lista che avevano a disposizione prodotti commerciali, nomi noti nel campo, escludevano anche questa ipotesi: i tool commerciali restituiscono lo stesso identico risultato dello Sleuthkit.

Quello che ho potuto verificare è che il numero e la posizione dei file che “spariscono” dopo la cancellazione, secondo lo Sleuthkit, e che invece sono completamente recuperabili da Foremost, cambia in funzione dell’ordine in cui avvengono le operazioni e dagli intervalli di tempo fra le stesse.

In conclusione, il risultato è che il filesystem NTFS può “nascondere” dati importanti, a causa di qualcosa nel metodo di gestione dei file cancellati, e che l’elenco non solo dei file recuperabili, ma anche quello dei file cancellati in generale, può contenere dati fuorvianti, o incompleti.

Se avete voglia di cimentarvi, ho preparato tre pacchetti zip:

• il primo con le immagini del disco “virtuale” collegato alla macchina Windows XP con Qemu. Uno dei file è quello dove i file sono stati solo cestinati, il secondo dove invece sono stati direttamente cancellati, il nome è “parlante”. NB: queste due sono immagini del disco completo, con tanto di tabella delle partizioni
• Il secondo contiene due immagini ottenute con dd della partizione “rimediata” dal mio notebook, la prima con i file appena messi e la seconda con i file appena cancellati.
• La terza contiene una sola immagine, sempre ricavata dalla partizione del notebook, dove ho semplicemente cambiato qualcosa nell’ordine di cancellazione e nei tempi, attendendo un po’ prima di cancellare dell’altro.

A questo punto ci sta anche bene:
Trust no one

Tutti i dettagli sul sito di Denis Frati. Correte ad informarvi!