Archivi tag: tracking

HTTP Cache-Control user tracing exploited

dscf1673.jpg Nel pomeriggio di ieri, a seguito del post di commento all’articolo del Corriere su come “aggirare Google”, ho messo su un piccolo script php che vorrebbe dimostrare quanto rapido e veloce sia tracciare gli utenti di un sito web senza dover usare i cookies (sui quali si concentrano molti dei sistemi per migliorare la “privacy” degli utenti).

Tanto per rendere l’idea di quanto semplice sia lo script, qui ne trovate il codice sorgente, che vedo di commentare nelle prossime righe.

Il concetto sul quale si basa questo breve script, è che il sistema di gestione dei files in cache può essere agevolmente utilizzato per correlare tra loro le sessioni di uno stesso utente, anche dopo che questi ha chiuso ed riaperto il browser (magari a distanza di tempo) e senza dover necessariamente mantenere in memoria un cookie, facilmente identificato per altro da una serie di strumenti, o disabilitabile da parte dell’utente in questione (che può per l’appunto rifiutarlo al momento di caricare la pagina).

Lo script php quindi, comunica (inviando un apposito header di sessione HTTP) al browser che la pagina che sta caricando deve essere mantenuta in cache, e che questi dovrà perciò provvedere a validare nuovamente la pagina (alla quale viene per questo motivo associato un codice univoco, l’ETag) alla prossima visita. Il meccanismo della cache è utile perché nel caso in cui la pagina non venga modificata tra le due visite, al browser potrà essere inviato solamente un header con codice 302 (Pagina non modificata), evitando che questi debba andare a ricaricare tutti i componenti della pagina, sprecando tempo e banda. Come tutte le umane cose però, l’ETag (o la data di modifica, o qualsiasi altro parametro della pagina) può essere utilizzato (come nel nostro esempio) per correlare le sessioni, impostandolo ad un valore univoco e differente utente per utente (nel nostro caso impostato banalmente ad un valore casuale di 4 cifre).

Se volete verificare che il sistema effettivamente funzioni, non dovete far altro che cancellare i vostri cookie, chiudere e riaprire il browser, e tornare alla pagina in questione.

Inutile dire che esistono molti altri modi per tenere traccia delle sessioni degli utenti senza dover ricorrere ai cookies, ma ho voluto esplorare in pratica questa possibilità perché l’unico sistema che conosco che rimuova e sostituisca l’ETag è Privoxy (o l’uso di altri proxy appositamente configurati) ed è allo stesso tempo particolarmente semplice da attuare.

Motori di ricerca e Privacy

Presso la sede di OpenLabs, esporrò lunedi 26 marzo i risultati della mia “ricerca” relativa a privacy e motori di ricerca, svolta soprattutto analizzando le privacy lines attuali di Google (ma applicabile anche agli altri motori di ricerca) e cercando di vedere le cose con un’ottica d’insieme che troppo spesso tende a sfuggire.

Http server: linux piu sicuro di Windows (?)

ApacheHo trovato su del.icio.us un link che porta ad una interessante ricerca condotta da Richard Stiennon e pubblicata sul suo blog presso ZDnet (le immagini sono state realizzate e fornite da Sana Security).

Lo scopo di questa ricerca è definire un metro di paragone per giudicare la sicurezza di un server http su linux (utilizzando Apache) e su Windows Server (utilizzando IIS). Il metro di giudizio, secondo Stiennon, potrebbe essere identificato nel numero e nella complessità delle relazioni tra le chiamate di sistema che vengono fatte al fine di produrre il risultato (in questo caso, la pagina HTML da spedire al browser). Le chiamate di sistema infatti, sono quelle che espongono a problemi il sistema a fronte di un bug nel webserver, in quanto sono quelle che consentono di portare a buono fine un attacco di tipo (ad esempio) buffer overflow.

IISPer verificare questa teoria, Sana Security ha mappato un grafico di complessità relativo ai due sistemi, ed ecco cosa ne emerge. La prima immagine (in alto) si riferisce alle chiamate di sistema che Apache fa al kernel Linux a fronte di una richiesta. Qui a fianco invece, vediamo il grafico relativo alle chiamate portate dal webserver Microsoft IIS ad un sistema Windows Server.

La differenza di complessità può lasciare davvero sbalorditi e portare ad affermare che “Linux è piu sicuro di Windows”, ma ci sono da fare un paio di precisazioni molto importanti da questo punto di vista.

  1. Stiamo facendo riferimento ad server web. Non si deve assolutamente generalizzare prendendolo come paragone per l’intero sistema.
  2. Non abbiamo a disposizione particolari riferimenti riguardo alle modalità con cui quei grafici sono stati generati. Non sappiamo ad esempio se si tratta di una semplice richiesta di una pagina HTML o dell’elaborazione di uno script PHP che interagendo con MySQL porta alla produzione di tale pagina (il primo caso essendo sicuramente meno vulnerabile ad attacchi di tipo buffer overflow, non potendo introdurre codice arbitrario). Allo stesso modo non abbiamo riferimenti sulle versioni dei software utilizzati.

Fatte le debite precisazioni, cerchiamo di cavare qualcosa di buono da quanto “scoperto”.
Possiamo dire che la complessità del server web IIS è davvero spaventosa. Mi chiedo da chi sia stato progettato, sembra tutto fuorchè modulare (un webserver della complessità di IIS o Apache è sicuramente terreno adatto all’applicazione delle teorie di Ing. del Software).

Al di la del maggior numero di chiamate di sistema che questo pastruglio lo porta a fare, mi immagino un codice piuttosto spaghettizzato, e sicuramente piu difficilmente mantenibile rispetto a quello che potrebbe essere il codice di Apache.

Leggendo poi tra i commenti al post di Stiennon, mi sono imbattuto nell’affermazione che Apache è stato maggiormente violato rispetto a IIS secondo le classifiche di Zone-H. Potendo con buona approssimazione considerare il citato documento come attendibile (nonostante si riferisca a quanto accaduto durante l’anno 2005, in quanto le statistiche del 2006 non sono ancora disponibili), dobbiamo però notare che l’autore del commento ignora completamente il fatto che fin dal 2004 la stragrande maggioranza degli attacchi vengono condotti a livello applicativo, quindi nei confronti di PHP e MySQL quindi, o ASP e MsSQL (a pagina 17 delle citate statistiche trovate le percentuali relative alle tipologie di attacco), indipendentemente dal webserver installato.
Anche nel merito, però, l’autore del commento sbaglia. Osservando la pagina 14 del pdf infatti, notiamo che i due server web sono in sostanziale parità.

Inoltre, Apache è largamente piu diffuso di IIS sul web. Secondo le statistiche di febbraio di NetCraft.com, nonostante sia in letterale caduta libera (argomento sul quale ci sarebbero da fare profonde riflessioni), Apache detiene ancora quasi il 59% del mercato dei WebServer, mentre IIS di Microsoft si attesta intorno al 31%. Questo rende 2 volte piu probabile imbattersi in un webserver Apache che in un webserver IIS, e ciò spiega (in parte) il maggior numero di violazioni segnalate su piattaforme su cui è installato Apache.

In piu, c’è da dire che le statistiche di Zone-H vengono elaborate sulla base degli attacchi segnalati, ma (come dicevo) non tutti gli attacchi sono condotti direttamente nei confronti del webserver. Con un attacco di tipo SQL Injection, poco c’entra il tipo di webserver utilizzato. Oltretutto mentre Apache è disponibile anche su piattaforme Microsoft Windows, IIS non è disponibile su piattaforme Linux, quindi i dati sono ancora meno ricollegabili alla reale sicurezza dei due sistemi operativi.

Piu senso avrebbe quindi riferirsi al tipo di piattaforma che ospita il webserver (questo non elimina però il discorso legato alla metodologia di attacco, che spesso e volentieri non coinvolge direttamente ne il webserver ne tantomeno il sistema operativo), ed osservando questo dato sulle statistiche relative al 2005 fornite da Zone-H (attendo con ansia quelle relative al 2006), emerge una sostanziale parità tra i sistemi Windows ed i sistemi Linux.

Nel quadro complessivo, a mio avviso, l’unica cosa seria che possiamo dire è che IIS è estremamente piu complesso di Apache (almeno per quel che riguarda le versioni prese in considerazione), e le uniche conclusioni che si possono da questo estrapolare, sono probabilmente legate alla maggior difficoltà di manutenzione del software, ma anche, tutto sommato, la maggior messa a disposizione di risorse agli attaccanti (precisando naturalmente che per sfruttare queste risorse sono necessarie ben piu gravi violazioni ai servizi dei livelli superiori).

POC: tracking dei risultati di una ricerca tramite immagini

A seguito di una interessante discussione nata sulla quale avevo già detto la mia in precedenza, Carlo Beccaria ha condotto un minimo di indagine (sfruttando curl) e scoperto un paio di cose interessanti sul conto di Google.

Sono già alcune settimane che sto studiando e cercando documentazione in questo campo, ed ho ritenuto interessante condurre due ricerche personali ad ampliamento di quanto scoperto da Carlo.

In particolare ho eseguito richieste (tramite curl) a Google passandogli cookie diversi (uno dei quali mi è stato gentilmente regalato dal buon Vecna :P), o simulando user agent diversi.

La seconda ricerca che ho effettuato è alla base del titolo del post: sviluppare un sistema analogo a quello che sembrerebbe utilizzare Google (secondo la scoperta di Carlo Beccaria) per verificarne l’effettivo funzionamento.

Il frutto di queste ricerche (e della documentazione che sto raccogliendo), sarà presentato all’HANC Meeting del 3 e 4 marzo a Milano, e successivamente riproposto in sede OpenLabs.

Alcune cose però, posso cominciare a dirle già da buon inizio, perchè trattandosi di aspetti prettamente tecnici, non servono approfondimenti ulteriori.

Il quadro che emerge dalla prima ricerca è piuttosto chiaro. Come già mostrato da Carlo Beccaria nel post precedentemente citato, Google include la funzione clk solo quando lo User-Agent è Internet Explorer. Questo avviene indipendentemente dalla piattaforma (ho provato a simulare sia una piattaforma MacOSX che una piattaforma Windows Vista e Windows Media Center, e la funzione è sempre presente).

La stessa funzione però. non viene inclusa in tutti gli altri browser, ed in particolare in Firefox, neppure quando questo si trova su una piattaforma Windows.

Rimane da approfondire la possibilità che l’introduzione dell’estensione Firebug possa in qualche modo scatenare l’introduzione di questa funzione (e quindi del relativo meccanismo di tracking) anche con il browser della Mozilla Foundation.

Se qualcuno avesse informazioni che discordano con quanto qui riportato, è invitato a contattarmi affinchè le ricerche possano svilupparsi ulteriormente in questa direzione..

La seconda parte della ricerca, forse quella piu interessante da questo punto di vista, è l’implementazione pratica di uno script PHP che simulasse in dettaglio quando fatto da Google, comprensivo di un meccanismo di tracing delle query.

Lo script che trovate qui (sorgente), non fa altro che impostare un cookie (a meno che questo non sia già stato impostato in una precedente query), di validità simile a quella del cookie di Google. A fronte della query, viene scatenato l’inserimento di questa all’interno del database, e vengono mostrati dei fittizzi risultati.

Ognuno di questi risultati riporta una funzione (qq) di fatto simile alla clk di Google, ma scremata di una serie di informazioni, al fine di semplificarne la comprensione. Questa funzione, associata all’evento OnMouseDown, scatena la richiesta di un’immagine inesistente da parte del client, e mentre questi si dirige sul link selezionato, questa richiesta (corredata di id e numero di riga) viene memorizzata nel database, prima di restituire un errore 204 (empty content).

Con un secondo script ( sorgente) preparato ad-hoc, ho reso possibile guardare nel database (le qui specifiche sono qui), in modo che ognuno di voi possa verificare l’effettivo funzionamento del meccanismo.

Redirect Google? Non mi quadra…

Questo pomeriggio ho notato su Persone un post di Flexer in cui si parlava di un paio di brutte cose che fa Google.

Non che Google sia il mio paladino, ma andando a verificare quanto scritto in questo post, mi sono accorto che (almeno sul mio sistema) quanto descritto non accade.

Magari sbaglio io qualcosa, qui c’è una screencast da vedere…