Il non-blog di Mario Pascucci

Sto lavorando sodo per preparare il mio prossimo errore (B. Brecht)

Articoli con tag sicurezza dell’informazione

Tre mesi di phishing

Aug 31

Pubblicato da Mario Pascucci in Computer Forensics, Information security | Disattiva commenti

Di solito tendo ad ignorare lo spam, fra cui i messaggi di phishing abbondano. Sarà che da un tre anni ormai, offrendo la mia competenza a chi ha un sito web violato, ne ho viste talmente tante da aver acquisito una sorta di “occhio clinico”, il fatto è che negli ultimi mesi non riesco più a fare “Seleziona tutti” seguito da “Elimina definitivamente” nella cartella dello spam, senza prima dare una scorsa ai messaggi insoliti.
Immediata, o quasi, è arrivata l’idea di dare più di una semplice occhiata ai messaggi di phishing.
I risultati sono per me in parte attesi, nel senso che in molti dei miei interventi ho indicato come possibile scopo per violare un blog o un sito l’ospitarci un sito di phishing. Intendiamoci, non sono “mie scoperte di sicurezza informatica”: sono in molti ad indicarlo, ben più autorevoli di quanto io possa mai diventare.
Vista la disponibilità di alcuni account di posta elettronica, e di un po’ di tempo durante i viaggi da pendolare, ho raccolto e studiato per tre mesi i messaggi di phishing che mi arrivavano. Qui presento alcuni risultati, se poi l’argomento riscuote un minimo di interesse, posso espandere aggiungendo dettagli.

La procedura di analisi

Non potendo accedere direttamente al contenuto originale dei siti, che permetterebbe una analisi puntuale ed accurata, quanto riportato è frutto di controlli e verifiche fatte dall’esterno, con strumenti assolutamente innocui: un browser, un editor di testo per programmatori, le utility whois, dig, host per ottenere informazioni pubbliche su IP e registro dei nomi DNS. Eppure, anche con così poche informazioni è possibile imparare molto sul phishing.

All’arrivo di ogni messaggio di posta elettronica palesemente di phishing, se ne salva una copia del “sorgente”, con tutte le intestazioni e le parti normalmente non visibili all’utente normale. Segue poi una visita sul sito di phishing, con prelievo di uno screenshot e del codice html della pagina così come emessa dal server. Se il sito è in hosting, il prelievo dei campioni finisce qui, altrimenti si tenta di arrivare al sito originale, catturando anche qui uno screenshot e l’html della pagina così come emesso dal server. In qualche caso è stato possibile visitare le directory intermedie fra il sito principale e il sito di phishing, acquisendo informazioni preziose su come e dove è avvenuto l’insediamento. In qualche caso è stato possibile mettere le mani sul sorgente originale del sito di phishing, lasciato in una directory intermedia da chi lo ha installato, di solito sotto forma di file ZIP o RAR.

Il materiale è poi analizzato e classificato per quanto possibile, ricavandone informazioni che ritengo interessanti. Ma basta con le chiacchiere, andiamo al sodo.

Quanti? Quali?

In tre mesi i messaggi ricevuti ed esaminati sono stati 73, non moltissimi, ma certamente sufficienti per costituire un campione con qualche significato statistico. Iniziamo con la distribuzione dei “bersagli”, ossia gli istituti di credito e servizi online presi di mira.

Distribuzione dei tentativi di phishing verso Istituti di credito e servizi online

Distribuzione dei tentativi di phishing verso Istituti di credito e servizi online

I più bersagliati sono i clienti di Poste Italiane e di Intesa S. Paolo, seguiti da quelli di Cartasì, ma non mancano i soliti eBay e PayPal. In tutti i casi esaminati i siti di phishing sono praticamente indistinguibili dall’originale, se non per qualche dettaglio, di cui ci si accorge solo possedendo adeguate conoscenze: ad esempio i link sono tutti uguali, ossia conducono tutti alla pagina per inserire i dati, oppure vi sono piccoli difetti nella presentazione della pagina, poco evidenti.

Le cose naturalmente cambiano quando si va ad esaminare il codice html emesso dai siti di phishing. Tipicamente sono copie dei siti originali, prese con note utility, di cui spesso non viene neanche rimosso il marchio dai file, eccone un esempio:

<!-- Mirrored from www.monetaonline.it/layout/03069/pop/dispores_card_01.asp by HTTrack Website Copier/3.x [XR&CO'2008], Mon, 13 Apr 2009 23:59:09 GMT -->

In qualche caso il sito usa solo pagine html, le immagini vengono prelevate dal sito originale, diminuendo la dimensione necessaria ad ospitare il codice per mostrare ed eseguire la raccolta di dati.
Il metodo di raccolta dati preferito è l’e-mail, ossia al momento in cui il cliente vittima del phishing inserisce i suoi dati e preme il pulsante di conferma, vengono inviati per e-mail all’autore del phishing, in vari modi: se il sito è in PHP, viene usata la funzione mail(), in altri casi viene sfruttato un form di invio posta di un altro sito, legale, che però permette di inviare messaggi a chiunque semplicemente chiamandolo con i giusti parametri (vedere ad esempio questi due avvisi di sicurezza di Secunia). In qualche caso gli indirizzi di posta di destinazione sono in chiaro e perfettamente leggibili dalle pagine HTML del sito di phishing.

Veniamo ora alla questione di dove vengano ospitati i siti di phishing. Ebbene, come avevo premesso, per me non è una sorpresa, ma il grafico parla chiaro.

Dove vengono ospitati i siti di phishing?

Dove vengono ospitati i siti di phishing?

Circa un terzo è ospitato in normali servizi di hosting, spesso gratuito, con dei trucchi per ritardare il rilevamento e la cancellazione del sito, come ad esempio l’uso di directory profonde per ospitare il sito di phishing, invece della home page, lasciata a quella di default, e l’uso di servizi di abbreviazione degli URL (come Tinyurl o Snipurl). Uno dei sistemi utilizzati è quello di registrare il nome del sito da un fornitore e prendere lo spazio di hosting da un altro, in entrambi i casi usando dati di identità falsi e differenti.

Oltre due terzi dei siti di phishing sono inseriti in siti web violati. In quasi un quarto dei casi i siti violati coinvolti sono due, differenti: il primo è quello di cui compare l’URL nella e-mail di phishing: una volta chiamato, il codice nascosto nel sito opera un semplice redirect con vari metodi al secondo sito violato, contenente il sito di phishing vero e proprio.

Per quanto riguarda il tipo di web application colpita nei siti violati, in gran parte dei casi non è stato possibile determinare se l’applicazione è preconfezionata, ad esempio un software open source o commerciale, o se è stato sviluppato ad hoc. Quello che appare da alcuni indizi è che in buona parte dei casi si tratta di applicazioni costruite a partire da una open source, cancellando ogni riferimento alla web application originale. Il problema è che molto probabilmente la base di partenza è una versione che a distanza di uno o due anni è obsoleta e verosimilmente vulnerabile a diversi tipi di attacchi, di conseguenza lo diventa anche l’applicazione da essa derivata, con ovvie conseguenze. Dato che chi cerca siti vulnerabili opera un fingerprinting della web application, l’operazione di nascondere, eliminare o modificare il contenuto dei messaggi di copyright dell’applicazione non sposta di un millimetro il problema. Anzi, proprio perché l’applicazione è modificata pesantemente è impossibile operare un aggiornamento in tempi rapidi, o spesso per motivi contrattuali non è proprio previsto, per cui il sito diventa e rimane vulnerabile a lungo.

Altre volte è proprio l’applicazione sviluppata a mostrare chiaramente problemi. In un caso, un sito che pubblicizzava “enlargement sessuali” (uno dei preferiti da chi fa spam), era costruito con una semplice web application in ASP, che non controllava per nulla i parametri di tipo URL-encoded che usava per mostrare i vari sottomenu. Inserendo una lettera al posto del numero in uno di essi appariva nel codice emesso un errore caratteristico delle applicazioni vulnerabili ad attacchi di tipo SQL-Injection. Eccone un esempio con uno dei parametri modificati appositamente:

<p>Microsoft JET Database Engine</font> <font face="Arial" size=2>error '80040e14'</font>
<p>
<font face="Arial" size=2>Syntax error (missing operator) in query expression 'nMenuNumb = cLNG(''0 or 1=1;'')'.</font>
<p>
<font face="Arial" size=2>/source/view_data.asp</font><font face="Arial" size=2>, line 38</font> 

Quando invece è stato possibile determinare con certezza l’applicazione colpita, i nomi che escono sono in un certo senso attesi.

Numero di siti violati e siti di phishing ospitati per tipo di web application

Numero di siti violati e siti di phishing ospitati per tipo di web application

Sei siti con Mambo, uno con Wordpress, due con Joomla, tre con phpBB, quattro con applicazioni commerciali, di cui ho trovato i rispettivi avvisi per vulnerabilità piuttosto gravi. Non sembrano molti, ma tenendo conto che chi li ha violati li sta sfruttando a fondo, il danno è rilevante: sia in quello Wordpress che in uno di quelli con phpBB vi sono nascosti tre differenti siti di phishing e quelli con Mambo presentano anche i segni di altre intrusioni, volte a diffondere malware.

Dei 49 siti violati, solo 8 appartengono a privati, ossia sono personali o amatoriali. La parte del leone la fanno i siti delle società, seguiti a distanza dai siti istituzionali.

I siti delle società sono i più gettonati.

I siti delle società sono i più gettonati.

I siti di cui non è stato possibile determinare la categoria erano o sotto forma di puro indirizzo IP, oppure erano vuoti o quasi, al momento del phishing, forse abbandonati dai proprietari, o forse sorpresi a metà di una ristrutturazione, quindi non c’era indicazione della reale appartenenza del sito. Anche ricerche nella cache di Google hanno dato esito negativo, segno che i siti stessi erano da tempo in quella condizione.

Altro fronte di analisi è quello dei presunti autori dei tentativi di phishing. E’ ovviamente impossibile determinare con sicurezza se l’autore è lo stesso per due siti, ma quello che si può dire è che i siti confezionati per il phishing possiedono in qualche caso delle caratteristiche che li accomunano, ma a parte alcune eccezioni notevoli, i responsabili potrebbero essere differenti.

La sorpresa viene da uno dei siti di phishing impiantato nel sito con Joomla: il “wannabe” Grande Hacker ha lasciato in bella vista il file zip con il kit di phishing in una delle directory. Chissà se il Grande Hacker si è accorto che un Più Grande Hacker lo ha fatto fesso? Il kit di phishing è uno di quelli con la sorpresa, con un secondo indirizzo email offuscato e nascosto nel codice PHP.

Conclusioni

Per ora chiudo qui. Dovrebbe essere evidente il pericolo ed il rischio di avere un sito con una applicazione obsoleta, vulnerabile notoriamente a vari tipi di attacchi, come pure dovrebbe essere chiaro che anche un sito web sviluppato appositamente, se non è pensato in origine per resistere a vari tipi di attacchi, tutti arcinoti e ampiamente documentati, diventa una porta di ingresso per tutta la pletora di mentecatti in giro per la Rete. Il fatto che non sia disponibile il sorgente dell’applicazione non rende affatto più difficile il lavoro di chi ha intenzione di violare il sito per farci i suoi comodi.

Ed ancora, chi ha un sito violato non si aspetti di vedere segnali particolari o sentir squillare una sirena: le intrusioni sono estremamente silenziose, poco evidenti e ben tollerate da tutti i siti e applicazioni. Difficilmente sul sito si vedrà un defacement, o almeno non contemporaneamente all’apparire del sito di phishing. Potrebbe invece succedere che prima ci sia il sito di phishing, e solo dopo che abbia fatto i propri comodi l’autore del phishing abbandoni il sito al suo destino, dopo aver lasciato porte scardinate e finestre sfondate. A quel punto il defacement sarebbe il minore dei problemi.

Riferimenti

Tags: , ,

La vita comoda dell’insider

Apr 10

Pubblicato da Mario Pascucci in Computer Forensics, Information security, Pensieri sparsi | 4 commenti

Il nemico in casa

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

Tags: , , ,

Wordpress Autotest: effetti collaterali imprevisti

Feb 12

Pubblicato da Mario Pascucci in Information security, Wordpress | 1 commento

Sono piuttosto impegnato in questo periodo e, piuttosto malvolentieri, sono costretto a dare delle priorità. Il non-blog in questo frangente risulta avere un livello di urgenza minimo. Appena cala il carico prometto che mi rimetto in riga.

Andiamo al motivo che mi ha fatto uscire dalla tana e scrivere queste poche righe.

Quando ho creato il Wordpress Autotest, la mia intenzione era di fornire uno strumento automatico di diagnosi alla portata di tutti per verificare se il proprio sito era caduto vittima di un attacco molto specifico ed estremamente pericoloso. Al contempo, avevo pubblicato anche una guida rapida per riportare il blog con Wordpress, attaccato e violato, sotto il nostro controllo legittimo.

Tramite il test, a distanza ormai di quasi un anno dall’inizio dell’attacco, ed a oltre otto mesi dalla pubblicazione del test, vengono tuttora scoperti blog violati sotto il controllo del mentecatto che ha dato origine a tutto questo, segno che il pericolo è tutt’altro che passato.

Quello che avevo immaginato è che coloro in possesso di un sito Wordpress autogestito (in self-hosting, come si dice) dopo aver fatto il test e rilevata l’infezione, procedessero, da soli o con l’aiuto di qualcuno, alla pulizia seguendo le più elementari regole di buon senso, primo fra tutti un sano e robusto upgrade della versione di Wordpress ad una che non offra occasioni di far birbonate ai mentecatti in giro per la Rete.

Invece quello a cui sto assistendo è che molti usano il test come un “allarme” per rilevare se è ora di ripristinare un backup. E rimettere la stessa identica versione di Wordpress, lasciando di fatto il sito aperto ad una nuova intrusione che puntualmente si verifica nel giro di qualche giorno.

Immagino ci siano delle ottime ragioni per usare questa strategia, come ad esempio il dover rifare un template, o il rinunciare ad alcuni plugin assolutamente necessari, ma a questo punto perché non installare un plugin apposito come il Wordpress Exploit Scanner. Faccio notare che il plugin funziona solo con Wordpress 2.5.1 o successivo, perché (cito l’autore): “There’s not much point in finding exploited files if you’re running an old version of the software that can be broken into again.” (tradotto grossolanamente: non è molto utile cercare file modificati se si usa una vecchia versione che può essere sfasciata in qualsiasi momento).

C’è anche un altro problemino. Un sito bucato con questa tecnica potrebbe diventare la porta di ingresso in un hosting condiviso. Mi spiego: molti servizi di hosting impiegano dei software per far convivere tanti siti web sullo stesso server, mantenendoli separati sia dal punto di vista logico che dal punto di vista sicurezza. Ma i meccanismi di separazione non sono infallibili, e un singolo sito violato rappresenta una minaccia gravissima per tutti i siti ospitati sullo stesso server fisico. Tanto per fare un esempio, sullo stesso server su cui state leggendo queste righe sono ospitati centinaia di siti, tutti indipendenti uno dall’altro.

Non è un caso raro, anzi, mi sono capitati casi in cui siti perfettamente a posto sul piano sicurezza, o addirittura “statici”, ossia senza pagine dinamiche ma solo in HTML, fossero iniettati di schifezze a causa di una intrusione massiccia originata da un altro sito ospitato sullo stesso server.

Ad un certo punto, il mentecatto che usa i siti Wordpress bucati per fare pubblicità a scrocco (il termine tecnico sarebbe black SEO o black hat SEO) potrebbe trovarsi tagliato fuori dai motori di ricerca, che stanno attivamente reagendo a queste tecniche di spamming con l’esclusione dei siti infettati dagli indici. Nessuno ci assicura che non possa prendere una strada differente e cercare di violare l’intero server, invece di limitarsi ad un singolo blog. Alcuni servizi di hosting prendono provvedimenti molto seri verso chi ha il sito “bucato”, a partire dalla diffida a provvedere a turare le falle, fino alla risoluzione del contratto ed alla citazione per danni. Leggete attentamente le clausole del vostro servizio di hosting e poi riflettete se è il caso di continuare a ripristinare un backup dello stesso sito, o magari non è giunto il momento di tappare qualche buco.

Tags: , ,

Linux software RAID: disco rotto, GRUB e problemi di boot

Nov 25

Pubblicato da Mario Pascucci in Fedora, Linux | Disattiva commenti

Situazione: un server con due dischi in RAID1 software, ossia in mirroring, con Linux. I dischi sono SCSI, se fossero IDE o SATA il problema non cambierebbe. Il disco di avvio è sda, ed è “specchiato” con sdb. Si guasta il disco sda, ed occorre sostituirlo. Si spegne il server, si sostituisce con uno nuovo, si riaccende il server. Risultato: Non system disk or disk error. Il server non riparte.

Dato che il bootloader e GRUB sono completamente installati solo sul disco sda, la sua sostituzione con un disco vuoto toglie la possibilità di fare il boot. Come risolvere?

Si può operare in due modi: a cose fatte, ossia col disco già guasto e computer riavviato, oppure prima di spegnere il computer, o meglio prima che il disco si guasti, ossia al momento dell’installazione.

Nel primo caso occorre usare la modalità “Rescue” messa a disposizione da Fedora, avviare il server dal DVD di installazione ed operare come se si fosse perso il bootloader, come spiegato nella guida di installazione di Fedora nell’apposito capitolo.

Nel secondo caso si può operare in anticipo, o anche appena prima di spegnere il server per sostituire il disco guasto. Cosa andiamo a fare: installiamo GRUB anche sul secondo disco con tutto il necessario per far eseguire il boot anche da questo.

Da un terminale dove siamo root entriamo nella console di comando di GRUB:

# grub

    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename.]

grub>

Per prima cosa vediamo se è tutto installato come ci serve, ossia se i file necessari a GRUB sono su tutti e due i dischi:

grub> find /grub/stage1
 (hd0,0)
 (hd1,0)

GRUB risponde nella sua notazione con l’indicazione delle partizioni dove sono i suoi file. Normalmente dovrebbero essere su tutti e due i dischi, tranne naturalmente il caso in cui uno dei due sia guasto, ma a quel punto ci interessa che siano installati sul disco ancora funzionante. Annotiamo la partizione per il secondo disco (hd1), in questo caso la 0, e procediamo ad installare:

grub> device (hd0) /dev/sdb

Con questo abbiamo detto a GRUB di considerare il secondo disco come primario. Serve perché al boot con il disco principale guasto, GRUB considererà il secondo disco come primo, per cui i comandi devono essere impartiti considerando quella ipotesi. Naturalmente dovremo sostituire adeguatamente i device per adattarli al nostro caso. 

grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0xfd

Con questo abbiamo detto a GRUB quale sarà la partizione di avvio, ossia la root. Attenzione che può non essere la root del filesystem, ma è la partizione dove è posizionata la directory di boot con i file di GRUB. Nel mio caso avevo una partizione separata di boot, la prima sul disco. 

grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd0)"...  15 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/grub/stage2 /grub/grub.conf"... succeeded
Done.

Con questo abbiamo installato tutto il necessario per il boot. Possiamo spegnere il server, sostituire il disco guasto e riavviarlo, ricordando che occorre dire al BIOS del server o del controller di avviare dal secondo disco e non dal primo.

Riferimenti

Tags: , , , , ,

NTFS, file cancellati e tool di analisi (parte II)

Nov 18

Pubblicato da Mario Pascucci in Computer Forensics, Information security, Linux | 5 commenti

Non potevo accontentarmi di lasciare perdere l’argomento, trattato qualche giorno fa, rimanendo con un punto interrogativo. Quindi eccomi di nuovo qui a riprendere il discorso sui file cancellati in NTFS e sui tool forensi.

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

Tags: , , ,

Falso aggiornamento per Wordpress: bug nelle versioni 2.5.x e successive?

Nov 7

Pubblicato da Mario Pascucci in Information security, Wordpress | 2 commenti

Apprendo tramite Paolo Valenti di Wordpress-it.it di un recentissimo problema riguardante Wordpress, a quanto pare dalla versione 2.5.x in poi.

Nella bacheca, nello spazio di solito ospitante le notizie dal blog di sviluppo di Wordpress, appare improvvisamente un avviso di aggiornamento immediato ad una fantomatica versione 2.6.4, di cui sul sito originale non vi è traccia. L’avviso è contrastante con il pulsante in alto, sempre nella bacheca, che afferma che l’ultima versione disponibile è la 2.6.3. Il link porta ad un falso sito di Wordpress, residente sul dominio wordpresZ.org, dove l’ultima “s” del nome è sostituita da una “z”.

La versione distribuita da quel sito è contraffatta: nel file wp-includes/pluggable.php alla riga 598 sono state aggiunte 5 righe il cui scopo è trafugare cookie di autenticazione e di sessione di utenti registrati nel blog.

La domanda più importante è: come hanno fatto a modificare le impostazioni del “widget” che mostra i feed del blog di sviluppo di Wordpress? Tali impostazioni dovrebbero essere modificabili solo da utenti con un livello di accesso alto, tipicamente un amministratore, e le impostazioni stesse sono conservate nel database. Ho provato ad ipotizzare tre scenari:

  1. bug che permette un SQL-injection non ancora scoperto in Wordpress 2.5.x e successivo
  2. bug nel codice di modifica del widget che mostra i feed RSS nella bacheca
  3. blog violato in precedenza, prima di un upgrade, con un amministratore abusivo

La prima la escluderei per un semplice ragionamento di economia: se c’è una vulnerabilità di questo tipo, perché non usarla direttamente per iniettare un amministratore abusivo nel blog e fare tutti i comodi da quell’account? Il fatto che la versione “troianizzata” si limiti a trafugare i cookie di sessione fa pensare che lo scopo è di operare tramite session hijacking per agire sul blog con le credenziali di un utente attivo in quel momento, quindi se lo scopo è questo, ossia operare nel blog, perché non creare al volo un utente amministratore tramite SQL-injection, operare ed eliminare poi l’utente per non lasciare tracce. Quindi escluderei questa ipotesi.

La terza è parimenti da escludere per le stesse ragioni: se c’è un amministratore abusivo frutto di una violazione precedente all’aggiornamento, perché non usare direttamente quello? I due blog che hanno avuto il problema non mostrano nessun segno dell’intrusione, e sono entrambi in versioni “non sospette”, uno ha la 2.5.1, mentre l’altro addirittura ha l’ultima versione ufficiale, la 2.6.3.

La seconda invece è abbastanza verosimile. Un bug limitato al solo codice di modifica delle impostazioni del widget limiterebbe l’effetto alla sola visualizzazione del widget e niente altro. Si spiegherebbe anche perché venga usato il falso sito con l’avviso per l’aggiornamento, per indurre l’utente ad autoinfettarsi installando la versione troianizzata.

Ulteriori indagini sono in corso. Se qualcuno ha notizie più fresche o ha elementi nuovi, non esiti a contattarmi. Se vi capita di avere questo messaggio che invita a passare alla versione 2.6.4 nella bacheca, non toccate nulla, fate un backup del database e dell’installazione di Wordpress e contattatemi. E’ importantissimo poter analizzare questi dati per trovare il punto d’ingresso.

Aggiornamento delle 14.45

Il sito wordpresz.org è ora “down”, nel senso che non è più risolto dai DNS. Il record Whois è ancora presente, segno che il nome è registrato e non pare cancellato. Rimane comunque alto il livello di attenzione: potrebbero provarci con un altro sito, con nome differente, e tentare lo stesso trucco, o una variante. Rimane da stabilire quale sia stato il sistema usato per cambiare il feed nella bacheca, e se la mia ipotesi è vera potrebbero esserci sviluppi in futuro.

Tags: , ,

NTFS, file cancellati e tool di analisi

Nov 3

Pubblicato da Mario Pascucci in Computer Forensics, Information security, Linux | 3 commenti

Come spesso mi succede, quando sto lavorando a qualcosa mi imbatto in comportamenti inattesi che, per mia sfortuna, mi distraggono dal mio compito principale fino a quando la mia curiosità, un tantino patologica, non è soddisfatta.

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

Tags: , , , ,

Repliche estive: “Malware batte Investigatore 2-0″ (2 maggio 2007)

Sep 15

Pubblicato da Mario Pascucci in Computer Forensics, Information security | Disattiva commenti

Questo è l’ultimo dei miei articoli del vecchio sito di ISMProfessional che, secondo me, vale la pena rileggere. Fra l’altro, l’estate è quasi andata, come calendario, anche se il caldo rende ancora i miei viaggi da pendolare molto simili ad una deportazione di massa, e le repliche di solito terminano con l’estate.

Questa volta l’argomento è presentato sotto forma di racconto alla CSI, naturalmente del tutto inventato. Come di consueto, ci rileggiamo alla fine per qualche oziosa considerazione.

Malware batte Investigatore 2-0

L’investigatore scende dall’auto, priva di insegne di riconoscimento, scortato da due uomini vestiti di scuro, piuttosto robusti.

La chiamata è giunta in tarda notte, ed ora è quasi mattina: il palazzo in cui stanno per entrare è la sede della più importante azienda di credito del Paese.

Pare che qualcuno sia riuscito ad accedere al database principale delle carte di credito, ed ha cominciato a sfruttare i dati trafugati. Le normali operazioni di gestione delle emergenze non hanno avuto l’effetto sperato, e pare che anche il centro elaborazione dati di riserva, attivato per l’emergenza, sia affetto dallo stesso problema.
Sa che sarà un lavoro delicato e complesso, ma ha con sé la valigetta con tutti i suoi strumenti di lavoro: il fido notebook con dentro tutti i software più sofisticati per l’analisi forense, un duplicatore di dischi e memorie flash ultimo modello e un gioiellino acquistato da qualche tempo: un duplicatore di memoria RAM hardware con interfaccia FireWire, che permette di acquisire il contenuto della memoria del computer mentre è in funzione e senza alterarne l’operatività.

Il direttore operativo della sede è stato molto chiaro: dieci minuti di interruzione di servizio equivalgono ad alcuni milioni di Euro di danni per le mancate transazioni, per cui i server non devono essere spenti per nessun motivo.
Arrivano in sala server principale, e si mette immediatamente al lavoro. Connette il notebook alla rete, sul segmento fra i server e il firewall che li protegge dal brodo primordiale di Internet.

Attiva prima un Intrusion Detection System ed un analizzatore di rete, ma dopo venti minuti di analisi non rilevano nulla di sospetto. Esamina i log del firewall, niente di anormale. Decide di passare al semplice sniffer e guarda il traffico di rete man mano che scorre sul video.

Qualcosa continua a solleticargli nel cervello: il viavai dei pacchetti TCP è normale, per una installazione di questo tipo, ma c’è qualcosa che non torna.

Passa ad esaminare i server. Ovviamente non può installare nulla, per non comprometterne il regolare funzionamento, ma conosce abbastanza il sistema operativo per sapere dove guardare per scovare un intruso.
Non ci sono processi estranei, né servizi sconosciuti. I driver delle principali periferiche sono in ordine. L’elenco delle applicazioni installate corrisponde perfettamente ai file sparsi in giro per il disco di sistema, ed ovviamente alle specifiche di installazione dell’applicazione principale.

Trova finalmente una discrepanza: ci sono installati DUE protocolli TCP/IP. Non se ne era accorto subito, il secondo era in basso, e lo nota dopo aver fatto scorrere in basso l’elenco.

Ricorda di aver letto qualcosa in merito. Sfoglia rapidamente la documentazione sul notebook e trova quello che cercava: una presentazione che parlava di malware invisibili. Ma questo ha lasciato qualche traccia, quindi forse non è del tipo III, non sfrutta la virtualizzazione per nascondersi.

Il problema rimane: non può spegnere il server, e non può installare nulla, per cui non può scoprire dove si è infilato l’intruso.

Sa che è là, da qualche parte nella memoria del computer… Aspetta! La memoria!

Apre la valigetta e prende il gioiellino, il duplicatore di RAM. Ora potrà analizzare con calma tutto il contenuto della memoria, trovare l’intruso ed analizzarne il codice: è questione di ore, e potrà consegnare abbastanza dati al direttore della sede per individuare chi si nasconde dietro l’operazione.

Inserisce il connettore sulla porta FireWire del server, inserisce un pen drive da 16G, su cui il duplicatore scriverà il contenuto della memoria e preme il tasto che avvia la copia. Immediatamente il server si blocca completamente: dopo pochi secondi il sistema di controllo dei servizi di rete lancia l’allarme per la caduta dei servizi. Rivoli di sudore scorrono sul volto dell’investigatore, nonostante la sala sia condizionata e mantenuta a 20 gradi.

Il tecnico responsabile fa iniziare la procedura per instradare tutti i servizi verso il centro di elaborazione di riserva. Il tutto è durato meno di un minuto, ma la telefonata del direttore della sede arriva poco dopo: non saranno ammessi altri errori.

Il server si è bloccato talmente male che riaccendendolo impone un controllo completo di integrità al filesystem. Ma il peggio deve ancora venire: il database si è corrotto, e occorre replicarlo da quello di riserva, ora diventato principale. Ci vorranno ore.

L’investigatore, le mani un po’ tremanti, sfila il pen drive dal duplicatore di memoria e lo inserisce nel notebook: dei quattro gigabyte di RAM del server ha replicato meno di un gigabyte. E dentro non c’è nulla di utilizzabile: la struttura di dati compromessa dal malware punta allo spazio di memoria subito dopo dove si è bloccata la duplicazione.

Non può essere che una maledetta sfortuna. Imprecando fra sé, l’investigatore va a parlare col tecnico responsabile, chiedendogli se può duplicare la memoria dal server del database di riserva. Ovviamente il tecnico rimane dubbioso: e se è stato il gioiellino a bloccare il server?

L’investigatore insiste, e gli propone di provarla su altri server non critici, per dimostrare che è stato solo un caso. Insieme inseriscono il duplicatore su quattro differenti server, e su tutti l’operazione termina senza alcun problema. I server continuano il lavoro come se niente fosse.

Il tecnico si convince, anche se è ancora un po’ titubante. Squilla di nuovo il telefono, sono arrivati altri rapporti di transazioni fraudolente: chi sta trafugando i dati sta ancora operando indisturbato: è la prova che anche il server nel centro di elaborazione di riserva è compromesso. Questo fa decidere il tecnico: però vuole aspettare almeno che finisca la duplicazione dal database di emergenza.

Si spostano nell’edificio adiacente: la sala server è la metà dell’altra, ma è posizionata sotto il livello stradale, con spessi muri di calcestruzzo.

L’investigatore inserisce di nuovo il duplicatore sulla porta FireWire del server, ma questa volta è meno deciso. Non vuole perdere i dati dal pen drive usato in precedenza, per cui usa un altro pen drive, un po’ più vecchio ed un po’ più lento dell’altro.

Preme il tasto di avvio della copia. Passano i secondi, e pare funzionare tutto. Il pen drive è lento, maledettamente lento.

Sullo schermo del server si vede lo screensaver con il logo del sistema operativo che dovrebbe fluttuare, ed invece è inesorabilmente immobile. Anche il server di riserva si è bloccato. E stavolta non ci sono più riserve. Il tecnico freneticamente lo riavvia, ma non c’è nulla da fare: filesystem e database corrotti. Devono fermare il servizio e ripristinare lo stato dei database: per fortuna c’è la copia dei dati, fatta appena prima. Ma nelle due ore che serviranno a ripristinare il database l’azienda di credito perderà milioni di Euro. E l’investigatore non solo quelli…

Stavolta ho cambiato modo di presentare l’argomento. Il racconto è completamente inventato, ma li elementi che fanno fallire il povero investigatore ipertecnologico sono tutti reali. La nostra amica Joanna Rutkowska ha colpito ancora.

Si parla della possibilità di duplicare il contenuto della memoria di un computer mentre è in funzione e senza interferire con la sua operatività: esistono in commercio schede per bus PCI che fanno questo, ed è possibile usare una porta FireWire per fare la stessa cosa, con la differenza che nel caso delle schede PCI occorre inserirle prima di poterle utilizzare, e quindi spegnere il computer, a meno di schede di tipo PCI-Hotplug.

Questo permette di duplicare il contenuto della memoria ed esaminarlo con calma, rilevando tutti i tipi di malware possibili, dato che viene usato un accesso DMA diretto, senza passare per il processore.

Ma, anche se per ora solo su hardware AMD, i malware possono sfruttare un trucco per arrivare a tre differenti comportamenti tesi ad impedire l’acquisizione della zona di memoria dove sono annidati:

  • bloccare il computer
  • far leggere valori senza senso (tutti 0×00 o 0xff)
  • far leggere valori arbitrari a scelta.

Tutti e tre questi comportamenti sono fattibili, e con grado di complessità crescente. I primi due sono stati implementati e dimostrati, il terzo è stato solo ipotizzato, ma già così è sufficiente per rendere inutile l’uso di questi miracolosi marchingegni.

C’è di peggio: l’attuale implementazione lascia fuori tutte le architetture non AMD, dato che sfrutta un comportamento legale ed atteso della tecnologia HyperTransport, ma a partire dal 2008 sia Intel che AMD rilasceranno processori ed architetture che supporteranno una tecnologia analoga per la gestione delle periferiche, e che sarà parte della tecnologia di virtualizzazione. Ingannare i duplicatori di RAM sarà un gioco da ragazzi. Duplicatori che ancora sono praticamente inesistenti in commercio in versione PCI, e del tutto ipotetici in FireWire (esiste un software dimostrativo, vedere nei riferimenti).

Il messaggio finale di Joanna, ed il nostro, vuole essere questo: finché non esisteranno sistemi operativi in grado di autoverificarsi e di segnalare la perdita di integrità, ogni altro strumento, per quanto sofisticato, sarà solo un costoso palliativo dalla durata limitata.

Riferimenti:

  • La presentazione di Joanna Rutkowska.
  • Un documento sulla fattibilità dei duplicatori di RAM via FireWire
  • Altro documento di presentazione di un software dimostrativo per duplicare la memoria via FireWire.

Oggi

Nel racconto ho volutamente esagerato i vincoli posti sull’operato dell’investigatore, per rendergli inevitabile la figuraccia. Inoltre gli ho fatto compiere un errore madornale, ossia operare sul sistema principale, invece che quello di riserva, inattivo. Ma il suo fato di personaggio virtuale era già segnato, quindi anche operando sul sistema di riserva per primo non sarebbe cambiato nulla sul suo destino finale.

Ma veniamo a noi. Joanna Rutkowska, nel frattempo, non è rimasta certo con le mani in mano. Abbiamo malware virtualizzanti in grado di infilarsi dietro l’hypervisor di un sistema di virtualizzazione, ossia capaci di operare una virtualizzazione annidata, mandando all’aria l’assioma che un sistema impiegante la virtualizzazione è sicuro rispetto all’attacco di un malware. Abbiamo malware che riescono, sotto certe condizioni, naturalmente, ad evadere da una macchina virtuale ed attaccare l’hypervisor, demolendo un altro assioma della virtualizzazione.

Insomma, sono tempi duri per chi pensava di mettersi al sicuro usando un sistema di virtualizzazione. Come sempre, non si può contare su strumenti automagici e soluzioni semplicistiche. I malware, espressione (perversa) della creatività e fantasia umane, sono sempre pronti a raccogliere nuove sfide, demolendo miti e soprattutto fedi mal riposte.

Poi, naturalmente, ci sono gli integralisti, come il signore della nota azienda IT americana che ha attaccato e, secondo lui, demolito il lavoro del team di Joanna tramite un articolo su un noto portale IT. Peccato che il signore in questione abbia dimostrato che nella fretta di confutare (o forse per voler avere ragione a tutti i costi) ha letto male e compreso peggio il lavoro presentato al noto Black Hat di quest’anno, riguardante una trilogia per sovvertire il funzionamento di Xen, il sistema di virtualizzazione basato su Linux. Ora, considerando che l’hypervisor di Xen è molto piccolo e compatto, il codice è sottoposto ad una serie impressionante di test e di controlli allo scopo di eliminare, ragionevolmente, ogni possibile bug di sicurezza, gli altri produttori di sistemi di virtualizzazione non hanno di che stare allegri. Nel senso, non pensino di gioire della dimostrazione che Xen non è invulnerabile: il loro hypervisor si basa su codice proprietario chiuso, e quindi senza il possibile contributo di questi geniali ricercatori per scovare falle e buchi.

Molto probabilmente alcuni degli attacchi portati con successo a Xen sono altrettanto efficaci anche con altri prodotti, naturalmente con qualche modifica.

I dettagli della trilogia su Xen, sull’articolo del signore e la relativa risposta di Joanna, si possono trovare leggendo il blog di Joanna Rutkowska, presente da tempo nel mio blogroll e nel mio lettore di feed.

Tags: , ,

Repliche estive: “Un malware veramente cattivo #2: trovami, se ci riesci…” (20 dicembre 2006)

Sep 9

Pubblicato da Mario Pascucci in Information security | 2 commenti

Siamo quasi al termine delle repliche estive. Ancora un altro articolo e abbiamo terminato. Qui esaminavo una classificazione dei malware proposta dalla ricercatrice di sicurezza Joanna Rutkowska. Ci rileggiamo alla fine per le oziose considerazioni di rito.

Un malware veramente cattivo #2: trovami, se ci riesci…

Nel precedente articolo abbiamo mostrato (con l’aiuto di Joanna Rutkowska) come risolvere il problema di comunicare con l’esterno senza essere scoperti.

Qui vedremo le opzioni a disposizione dei malware per occultarsi invece all’interno del computer colpito.

Ogni malware, come sappiamo, è un programma, una porzione di codice che deve essere eseguita per rendere attivo il malware stesso. Una volta attivato e compiute le operazioni necessarie a stabilirsi, rimane da risolvere il problema di evitare di essere scoperto troppo facilmente. Un malware che si fa scoprire ha vita breve, mentre lo scopo è quello di agire senza insospettire né il normale utente, né l’amministratore di rete più smaliziato.

In realtà questo problema ha due aspetti: sfuggire sia all’occhio umano, sia agli strumenti automatici di rilevamento (antivirus, rootkit checker, ecc.). Joanna propone una classificazione ragionata dividendo i malware in quattro classi, in funzione del modo in cui si insediano e di come questo li renda difficili da rilevare.

Tipo 0

L’insediamento avviene con un normale programma, che usa le normali funzioni del sistema operativo per essere avviato per esempio come servizio di sistema. In questo caso il malware compare fra i processi in esecuzione, ed ha una porzione di memoria dedicata come tutti gli altri. La sua rilevazione è piuttosto semplice, in quanto con le normali funzioni di controllo del kernel se ne può controllare lo stato di esecuzione, le risorse impegnate, ecc.

Ad esempio un classico botnet agent come Gaobot è un malware di tipo 0. Il fatto che alcuni malware, come Gromozon, adottino delle strategie molto sofisticate per non essere rimossi, non cambia il fatto che rimangono malware di tipo 0, usando sempre e solo API documentate del sistema operativo per agire.

Tipo I

I malware di questo tipo non si presentano come processi separati, ma si agganciano al codice di altri processi sia del kernel che di servizi di sistema fondamentali. Una volta attivati non si notano processi aggiuntivi, ma un servizio di sistema, una porzione del kernel, un driver o una applicazione fondamentale per il funzionamento del sistema divengono portatori del malware, che si esegue nello stesso processo.

Per far questo viene modificata una parte dell’immagine in memoria del processo preso di mira dal malware, con una vera e propria operazione di patching, che aggiunge il proprio codice a quello in esecuzione.

In questo caso è molto più difficile trovare il malware, dato che non ha usato normali API per insediarsi, ma ha modificato il codice di una parte del sistema operativo o di una delle sue applicazioni.

Tipo II

Questo tipo di malware usa una strategia ancora più sofisticata. Il kernel contiene alcune strutture dati che sono in realtà puntatori a funzioni, di dimensione variabile e compilate con i giusti valori al momento dell’avvio del sistema operativo. Ad esempio i driver NDIS sono elencati in una struttura dati di questo tipo. I malware di questo tipo non toccano niente nel codice del kernel o delle applicazioni principali, ma si agganciano ad una di queste strutture dati, modificando un puntatore e inserendosi al suo posto o in aggiunta a quelli già presenti.

Il vantaggio di questo tipo di tecnica è che tali strutture sono modificabili per definizione e non possono essere bloccate, né protette dalle modifiche.

Tipo III

E’ il tipo più temibile: non tocca nulla all’interno del sistema operativo colpito, non genera nuovi processi, non modifica né porzioni di codice né strutture dati, è completamente esterno e fuori dalla visibilità. Al momento l’unica tecnica conosciuta è quella della virtualizzazione, applicata ad esempio nella pillola blu, che abbiamo già conosciuto.

Richiede che l’architettura del computer colpito sia conforme alle specifiche per macchine virtuali sicure, come la tecnologia Pacifica di AMD™ e quella VT-d di Intel™, e quindi è legata ad uno specifico tipo di hardware, ma l’efficacia è devastante.

La ciliegina sulla torta

I malware di tipo 0 e I hanno bisogno di operazioni aggiuntive per non rivelare troppo facilmente la loro presenza. Alcuni agganciano porzioni specifiche del kernel e nascondono le informazioni necessarie a scoprirli: per esempio filtrando l’elenco dei processi in esecuzione o l’elenco dei driver caricati. Il discusso sistema anticopia della nota multinazionale usa un filtro sul filesystem per nascondere i propri file.

Un rootkit sperimentale denominato Shadow Walker usa un sofisticato metodo per capire se un altro processo sta leggendo la zona di memoria in cui risiede il suo codice, tipicamente un antivirus che spazzola la memoria per capire se ci sono segni di malware, e mostra una differente zona di menoria all’antivirus, rendendone impossibile la rilevazione. Ma ha bisogno di modificare la parte di kernel che gestisce la memoria, e questo permette di scoprirne le tracce.

I malware di tipo II pongono un problema del tutto nuovo: non modificando in alcun modo nessuna parte del codice del kernel o delle applicazioni, ma solo strutture di dati che per definizione sono modificabili, diventano del tutto invisibili ai normali meccanismi di rilevamento.

I malware di tipo III, pur limitati ad una specifica architettura hardware, sono del tutto fuori dalla portata di qualsiasi metodo di rilevamento che sia interno alla macchina compromessa.

Sappiamo tutti la difficoltà di rimozione per alcuni tipi di malware, vedi Gromozon, come pure la fatica nel rilevarne la presenza, come il noto rootkit del sistema anticopia. Vedremo in un prossimo articolo le difficoltà che pongono queste nuove categorie di malware, sia per la rilevazione da parte di strumenti automatici che da parte di una persona che sappia dove guardare.

Oggi

Joanna Rutkowska è andata molto più avanti, ed in direzioni impensate. Ora è possibile annidare gli hypervisor, ossia un malware può virtualizzare un sistema già virtualizzato: ecco il NBP (Nested Blue Pill, pillola blu annidata). E’ stato dimostrato che la virtualizzazione, ritenuta dai più anche un modo per rendere più sicuro un sistema operativo, dato che l’hypervisor è in teoria isolato dall’interferenza delle macchine virtuali, non risolve per nulla il problema. Prendendo di mira Xen, il sistema di virtualizzazione usato in Linux, di cui è disponibile il sorgente, è stato dimostrato come sovvertirlo e riuscire da una macchina virtuale a modificare la memoria dell’hypervisor, demolendo di fatto l’assunto base della sicurezza della virtualizzazione.

E’ stato anche dimostrato come aggirare la protezione aggiuntiva offerta dall’architettura VT-d di Intel, grazie ad un bug nel bios di alcuni modelli di schede madri.

Ora, il semplice fatto che sia stato dimostrato che si può fare, dimostra che la virtualizzazione e tutto meno che un sistema di sicurezza. Ma il mondo IT, sordo a queste dimostrazioni, ritenute teoriche ed irrealizzabili in pratica, sta andando esattamente in questa direzione, con l’idea di mettere un semplice hypervisor dentro il sistema operativo allo scopo di proteggere il nucleo principale di esso.

Tutto questo nella Xen 0wning Trilogy di Joanna Rutkowska che vi invito a leggere.

Ma, naturalmente, nessuno userà mai questo per creare malware. Noooooo. Mai. E’ impraticabile.

D’altra parte lo stesso si diceva riguardo l’IP spoofing ed il TCP sequence number prediction. Poi nel Natale del 1994 Kevin Mitnick riuscì a penetrare nel computer di Tsutomu Shimomura usando proprio questo tipo di attacco.

Tags: , ,

Repliche estive: Caramelle dagli sconosciuti #1 (17 dicembre 2006)

Sep 1

Pubblicato da Mario Pascucci in Information security | 1 commento

Per iniettare un malware in un computer in sostanza esistono due vie: lavorare di cracking, cercando e sfruttando vulnerabilità note o meno in sistemi operativi ed applicazioni, oppure sfruttare le umane inclinazioni.

La seconda via non è né meno costosa, né richiede meno competenze, anzi, ne richiede di più ed in campi differenti, ma ha un vantaggio: funziona indipendentemente da problemi hardware o software, anche in assenza di vulnerabilità da sfruttare. Al solito ci si rilegge alla fine per le oziose considerazioni di rito.

Caramelle dagli sconosciuti

Ci sono vari tipi di ladro: lo scassinatore, il rapinatore e il truffatore. Lo scopo è sempre lo stesso, prendere qualcosa che non gli appartiene contro la volontà del legittimo proprietario. Quello che cambia è il modo:

  • lo scassinatore opera di abilità e di astuzia. Studia le abitudini della vittima, le condizioni di sicurezza del bersaglio, poi opera colpendo in un punto debole delle difese quando il proprietario non c’è.
  • Il rapinatore punta invece sulla forza bruta. Si arma e ottiene quello che vuole direttamente dal proprietario, minacciandolo.
  • Il truffatore opera invece di persuasione. E’ la vittima stessa che gli consegna l’oggetto, convinta di ottenere un vantaggio economico o di altra natura.

Un detto abbastanza noto recita che non si può truffare un uomo onesto. I truffatori in giro per la Rete pare ne tengano conto: i siti web più “infetti” sono quelli che contengono (o promettono) materiale in qualche modo illegale. Brani musicali, film, materiale pornografico, crack per programmi noti o meno, generatori di codici di registrazione (i cosiddetti keygen), tutto fa brodo.

Un esempio perfetto di questa situazione è un sito che offre generatori di codici di registrazione: keygen . name (il nome è spezzato e reso non cliccabile perché non è proprio il caso di andarci).

Ad un primo sguardo, sembra identico a centinaia di altri siti web di questo tipo, ma la trappola è là, ed è ben congegnata.

Si cerca nell’elenco dei programmi già inseriti, e se non si trova quanto voluto, si può usare la casella di testo con a fianco il tasto Find! (trova).

Capire che è una trappola è semplice:

  1. tutti i keygen scaricati sono lunghi esattamente 8759 bytes
  2. sono identici bit per bit, indipendentemente dal programma per cui dovrebbero generare il codice
  3. se si cerca un keygen se ne trova sempre uno con il nome contenente esattamente le parole che abbiamo digitato nella ricerca.

Per esempio se nella casella si digita “Fedora Linux”, la ricerca restituisce un file dal nome “Fedora_Linux_keygen.exe”, sempre di 8759 bytes. Ora, a parte che Fedora Linux non ha proprio bisogno di chiave di registrazione, visto che è un sistema operativo libero e gratuito, è strano che il nome sia esattamente lo stesso. Ad ulteriore conferma basta digitare “io sono un fesso che prende caramelle dagli sconosciuti” ed in un attimo ecco il nostro keygen con un nome chilometrico e quanto meno inconsueto, sempre di 8759 bytes.

La conferma finale viene passando il file ad una collezione di antivirus: i due terzi lo identificano come minaccia, anche se non sono concordi sul tipo.

Riadattando un detto usato dai miei nonni, possiamo dire che andò per craccare e rimase craccato…

Oggi

Il sito è ancora attivo, ed il numero ed il tipo di ricerche presenti e memorizzate fa pensare che sia molto “gettonato”. Il keygen (leggi malware) è cambiato, ora è di 204856 bytes, e VirusTotal lo identifica sempre come malware con 28 antivirus su 36. Avviato sulla macchina virtuale sacrificale di rito, scarica roba dai soliti siti con nomi improbabili, installa un servizio ed un modulo da attivare all’avvio del computer, più altra roba che non sono stato a guardare. C’è un po’ di tutto, compreso un Alternate Data Stream.

A dispetto della continua evangelizzazione degli utenti ad opera di chi è un po’ più “smaliziato”, il numero di persone che cadono vittima di truffe e raggiri è in costante aumento. E non c’è bisogno di tirare in ballo il phishing, basta andare molto più vicino e volare bassi: siti che offrono antivirus fasulli per disinfettare inesistenti pestilenze, software altrimenti gratuiti offerti dietro pagamento di una “tassa di installazione”, informazioni riservate inesistenti, servizi 2.0 con fregatura 1.0, e via così.

E’ evidente che non serve assolutamente creare malware sofisticati e pestilenze inarrestabili, basta dire le cose giuste nel modo giusto agli utenti, il resto lo faranno da soli.

Una ultima cosa: una delle ricerche in prima pagina nel sito dei keygen fasulli nel momento in cui l’ho visitato era per una applicazione dal nome: Antivirus XP 2008. Per la cronaca, non è un antivirus, ma un malware camuffato da antivirus che richiede un pagamento con carta di credito per essere “attivato”. Ecco la cattura della pagina. Verso il fondo potete vedere quello di cui parlo.

Il colmo dei colmi: cercare in un sito di crack fasulli qualcosa per poter installare un malware camuffato da antivirus che probabilmente non vede l’ora di essere avviato per fare i suoi porci comodi, dopo ovviamente aver preso un po’ di soldi dalla nostra carta di credito.

Il punto, però, non è il denigrare un poveraccio che è caduto dalla padella nella brace, no. Qui stiamo parlando di qualcuno che per vedere “documentari anatomici”, viene ingannato una prima volta vedendosi presentare una richiesta di scaricare i codec; va sul sito per scaricare i codec e viene ingannato una seconda volta, con una falsa scansione online che lo avverte di avere un numero abnorme di virus e gli propone di installare un antivirus fantastico, la soluzione definitiva di tutti i problemi di virus. Mentre il tizio si convince di avere usato fino a quel momento una chiavica di antivirus, che non l’ha protetto dalla pletora di virus che gli ha trovato l’altro, va a scaricare ed installare l’antivirus fasullo, e viene ingannato la terza volta, dato che gli viene chiesto di acquistare il codice di attivazione con carta di credito. A questo punto, invece di accendere il cervello e iniziare a farsi qualche domanda, adotta il comportamento più amato dai truffatori: fa il furbetto. Cerca su Emule il crack per Antivirus XP 2008 e ne trova centinaia (provare per credere), tutti ovviamente dei falsi, accessoriati però col vero malware all’interno. Cerca un keygen e finisce sul sito appena presentato, prendendo una seconda pestilenza (o una terza, una quarta e via così).

Utenti così sono una manna dal cielo per i truffatori e i criminali in giro per la Rete. Scommetto che il computer di questa persona fa parte di almeno due botnet. Ed ha installati antivirus, firewall, antispyware, rootkit scanner, insomma tutto il campionario.

Tags: , ,