I SEE WHAT YOU SEE. Unconventional tracking technique

Shotokan - domenica 25 Gennaio

Quindi… Eccoci nel 2015!
Macchine volanti, viaggi nel tempo etc etc! ESATTO! Nulla di tutto cio’.
La cosa bella e’ che con il passare del tempo a quanto pare nulla cambia.
Il 90% dei siti/forum che trovo in giro usano il classico protocollo HTTP e perche’ sbattersi per una S in piu’?
A chi gliene frega?

La sicurezza data dal protocollo HTTPS e’ decisamente piu’ elevata rispetto all’HTTP e oggi aggiungero’ un nuovo motivo alla risposta classica:
“Devo usare HTTPS?”
CAZZO SI.

Cioe’ non e’ indispensabile ma cribbio, l’hanno creato per un po’ di motivi.

When features turns against you…

I like cookies, deal with it.

Ok, abbiamo visto recentemente che il protocollo HTTPS puo’ essere usato per ‘tracciare’ un utente (HSTS Super cookie).
Ma puo’ essere fatto generalmente solo dall’admin del sito stesso, e tramite diverse richieste a diversi sottodomini.
Sono richieste fondamentalmente booleane, se viene contattata la pagina http e’ uno 0, se viene contattata la pagina https saltando la http significa che l’HSTS e’ stato letto, quindi viene contato come un 1, e’ a farla breve ma fondamentalmente funziona cosi’, e quindi sono anche abbastanza facilmente rilevabili e poco utilizzabili da “terzi” su siti tipo forum o altro.

La tecnica di cui vi sto per parlare e’ simile al tracking via immagini: posti un’immagine in una chat privata e quando viene effettuato il caricamento boom, useragent, ip, data e ora diretti.
Il problema della tecnica di tracking via immagini e’ che ormai e’ praticamente inutilizzabile: molti siti appena viene caricata un’immagine la storano, o la presentano tramite proxy (CAMO?) cosi’ bloccando il passaggio di qualsiasi informazione al destinatario, compresa data ed ora, che in molti casi ci basta per capire se l’utente, per esempio, ha letto un nostro messaggio.

Smanettando un po’ in giro ho scoperto una feature abbastanza interessante, che puo’ essere sfruttata per ottenere almeno la data ed ora, purtroppo senza molte altre informazioni a seguito, ma decisamente stealth.

So what? More cookies?

No, non stiamo parlando di cookie.
Stiamo parlando di richieste “involontarie” DNS.
Magari questa tecnica e’ gia’ conosciuta e non lo sapevo, fatemelo sapere nei commenti in caso, ora cerchero’ di spiegarla nel miglior modo possibile.

Ok, adoro CloudFlare, ma purtroppo non mi permette una visualizzazione alcuna dei log vari.
Ho dunque creato una regola del genere:

Cloudflare

Che equivale fondamentalmente a:

*.tracking.aitch.me.	300	IN	NS	aitch.me.

Tutte le richieste DNS verso i sottodomini di tracking.aitch.me verranno quindi inoltrate ad aitch.me, che le elaborera’ e fornira’ loro una risposta.

Se proviamo infatti a contattare (ping?) per esempio ‘test.tracking.aitch.me’ controllando i log di bind9 (log impostati con “severity info”) nei log apparira’:

25-Jan-2015 20:31:37.864 security: info: client 74.125.47.144#43838 (test.tracking.aitch.me): query (cache) 'test.tracking.aitch.me/A/IN' denied
25-Jan-2015 20:31:37.874 security: info: client 74.125.47.144#48525 (test.tracking.aitch.me): query (cache) 'test.tracking.aitch.me/A/IN' denied
25-Jan-2015 20:31:37.884 security: info: client 208.69.33.11#39775 (test.tracking.aitch.me): query (cache) 'test.tracking.aitch.me/A/IN' denied
25-Jan-2015 20:31:37.884 security: info: client 74.125.47.147#45023 (test.tracking.aitch.me): query (cache) 'test.tracking.aitch.me/A/IN' denied
25-Jan-2015 20:31:37.895 security: info: client 208.69.33.11#8872 (test.tracking.aitch.me): query (cache) 'test.tracking.aitch.me/A/IN' denied
25-Jan-2015 20:31:37.939 security: info: client 208.69.33.11#63778 (test.tracking.aitch.me): query (cache) 'test.tracking.aitch.me/A/IN' denied
25-Jan-2015 20:31:37.951 security: info: client 208.69.33.11#56627 (test.tracking.aitch.me): query (cache) 'test.tracking.aitch.me/A/IN' denied

Ottenendo quindi data & ora del collegamento.
Ok, ma in questo caso abbiamo dovuto pingare/cliccare su un link/visualizzare una immagine sul relativo sottodominio.

Il tutto verrebbe loggato dal browser, tramite la tab “networking”, apparirebbe quindi in chiaro la connessione.

Come possiamo rendere questa richiesta stealth?

La risposta arriva da una feature aggiunta recentemente sui browser principali, chiamata “DNS Prefetching“.

DNS prefetching is an attempt to resolve domain names before a user tries to follow a link. This is done using the computer’s normal DNS resolution mechanism[…]DNS prefetching can help is when a user is looking at a page with many links to various domains, such as a search results page.  When we encounter hyperlinks in pages, we extract the domain name from each one and resolving each domain to an IP address.

…Quindi?
Se in una qualsiasi pagina HTTP (senza <meta http-equiv=”x-dns-prefetch-control” content=”off”> ) pubblico un link, esso sara’ in automatico “risolto” dal browser.
Quindi per esempio, in un forum con BBCode attivo:

[url=http://test.tracking.aitch.me] [/url]

Verrebbe risolto in:

<a href="http://test.tracking.aitch.me"> </a>

e grazie al DNS Prefetching verrebbe inviata una richiesta al NameServer, ottenendo quindi data e ora esatte dell’apertura della pagina.

Nessun log lato client, nessun dato visualizzato nella famosa “Network” tab di chrome/firefox etc, e abbiamo comunque un valido metodo di tracking.

Immaginate i possibili utilizzi per, per esempio, client mail HTTP o chat online.

Stay safe. Use HTTPS.

O almeno usate <meta http-equiv=”x-dns-prefetch-control” content=”off”>!
Theme made by Koala