Il pinning DNS protegge da tutti gli attacchi di rebinding DNS?

Il blocco dei DNS non protegge dai sofisticati attacchi di rebinding DNS .

Considera uno scenario in cui un utente malintenzionato imposta un firewall davanti al proprio server web. Richiedete il loro sito web, attacker.com, che risulta in una query DNS che restituisce il loro indirizzo IP. Il risultato DNS ha un TTL (time to live) di 1 secondo. Normalmente, questo significa che il browser deve effettuare un'altra richiesta DNS dopo che è trascorso 1 secondo, tuttavia, il blocco DNS indica al browser di ignorare il TTL e aggiungere un'unità di tempo (ad esempio un'ora). Quindi ora il tuo browser non effettuerà un'altra query DNS per quel nome host per 1 ora e 1 secondo. Al termine della query DNS, la richiesta HTTP viene inviata e l'utente malintenzionato restituisce il sito Web richiesto con codice javascript che avvierà l'attacco.

Ora, il Javascript dell'attaccante ha impostato una richiesta AJAX che attende due secondi prima di sparare. Quindi richiede di nuovo alcune risorse sul sito Web dell'attaccante. Tuttavia, la richiesta non riesce. Questo perché l'autore dell'attacco ha già impostato una regola firewall che blocca la richiesta del tuo browser . Ora siamo nel seguente stato:

1. Il TTL è scaduto sulla prima richiesta DNS, ma il blocco DNS è ancora in vigore
2. Hai inoltrato una richiesta al sito web dell'attaccante tramite la loro chiamata JS AJAX
3. La richiesta è stata rilasciata dal firewall dell'attaccante

Queste tre cose faranno sì che il tuo browser invii un'altra query DNS nonostante tu stia usando il pinning DNS. In effetti, l'attaccante ha facilmente sconfitto la tua strategia di blocco DNS usando un firewall e inviare una seconda richiesta al di fuori del TTL. Il blocco dei DNS non è una strategia efficace perché ci sono molti motivi legittimi per cui il server di qualcuno potrebbe essere inattivo; il tuo browser è costretto a fare una seconda query DNS nel caso in cui ci sia un altro record DNS che verrà risolto sulla macchina corretta (ad esempio in caso di migrazione del server, tempi di inattività, qualsiasi cosa). Fondamentalmente, il tuo browser non ha modo di sapere se viene effettivamente attaccato qui o no; per quello che ne sa, il server è legittimamente inattivo e quindi DEVE fare un'altra richiesta DNS.

Quindi ... perché è importante che ci sia una seconda richiesta DNS?

La seconda richiesta DNS viene solitamente utilizzata dall'attaccante per restituire un indirizzo IP errato per il record DNS. I browser hanno quella che viene definita una politica di "stessa origine" che impedisce alle pagine Web di effettuare richieste di risorse che non possiedono. Fondamentalmente il modo in cui funziona la stessa origine è che dice che il link può richiedere solo link . Ma in realtà funziona usando l'indirizzo IP per hostname.com, non il nome host leggibile da solo. Quindi, in un attacco di rebinding DNS, quando il browser esegue la seconda query DNS che ho descritto in precedenza, l'utente malintenzionato restituirà un indirizzo IP "falso" nel risultato della query DNS. Quindi il tuo browser penserà, ad esempio, che l'indirizzo IP 1.1.1.1 appartiene ad attacker.com anche se appartiene davvero a google.com. Ciò consente all'aggressore di sfruttare la stessa politica di origine del browser; ora il javascript dell'attaccante può richiedere materiale da google.com tramite AJAX. Inoltre, possono leggere e impostare cookie e altre informazioni dannose. Questo sfrutta la stessa politica di origine ingannando il browser e confidando nel secondo record DNS che è stato restituito. Ora il browser pensa che hostname.com sia associato all'indirizzo IP 1.1.1.1 anche se in realtà non lo è. Cosa deve fare un browser? DNS non ha quel tipo di autenticazione integrata.: (

Prevenzione dell'attacco rebinding DNS

Ci sono un sacco di modi per prevenirlo, e sono abbastanza sicuro che i browser moderni abbiano già implementato la protezione contro questi attacchi. Un modo semplice per prevenirlo (come proprietario del web) è controllare l'intestazione dell'host HTTP di una richiesta. Ad esempio, se sei google.com, riceverai una richiesta ma l'intestazione host direbbe ancora attacker.com. Ovviamente questo non fa parte del tuo dominio, quindi puoi prevenire l'attacco semplicemente facendo cadere la richiesta. Perché qualcuno dovrebbe voler fare questo per cominciare? Bene, clicca la frode nella pubblicità. Raschiare i motori di ricerca da molte macchine contemporaneamente. Rubare dati preziosi dai siti Web sulla rete aziendale interna. Ecc.

Se si desidera prendere in considerazione la totalità del contenuto che può essere eseguito da un browser, il solo browser che esegue il pinning DNS non sarebbe sufficiente. I plug-in del browser come Flash e Java possono avere accesso al socket e questo significa che potrebbero eseguire le stesse query DNS e se non implementano una strategia di blocco DNS, il browser sarebbe comunque vulnerabile per proxy. Vedi link o Google per "Protezione dei browser dagli attacchi di rebinding DNS" di Jackson et al. per ulteriori dettagli.

Cercherò di rispondere alla mia stessa domanda con l'aiuto di un attacco di esempio a cui sono stato collegato. Feedback e osservazioni sono i benvenuti, perché non sono sicuro della correttezza di questa risposta.

Sì , il blocco DNS impedirebbe l'attacco descritto, anche se non è necessario rendere la situazione al sicuro. Immagina questo:

1. Inizialmente, il pharmer organizza le query DNS della vittima per www.good.com per risolvere l'indirizzo IP del pharmer, 6.6.6.6.
2. Quindi, quando la vittima visita www.good.com, il pharmer restituisce un documento trojan contenente Javascript e un riferimento iframe www.good.com/homepage. Il pharmer si assicura anche che l'intestazione Cache-Control specifichi un valore max-age molto alto.
3. Il pharmer aggiorna la voce DNS per www.good.com all'indirizzo IP del server legittimo di Good e nega le connessioni successive dalla vittima.
4. Ciò fa sì che il browser della vittima rinnovi la sua voce DNS per www.good.com, che il browser non consentirà a causa del blocco DNS.
5. Il blocco DNS causerà il recupero della sorgente iframe dall'indirizzo IP del pharmer (6.6.6.6/homepage).
6. La richiesta è negata dal server del pharmer e all'utente viene visualizzato un errore.

Quando la vittima riapre il suo browser qualche tempo dopo e tenta di accedere a www.good.com

1. La versione cache della pagina viene caricata nel browser, indipendentemente dai record DNS, incluso il Javascript dannoso.
2. L'iframe sarà caricato nuovamente, perché l'intestazione di Cache-Control non si applica al contenuto negli iframe (questa affermazione richiede un certo backup).
3. Il contenuto iframe punterà al server corretto, perché il record DNS è fisso
4. La legittima home page di Good viene caricata nell'iframe.

Quali sono alcuni esempi di scenari di attacco non protetti con successo?

Oltre allo scenario descritto sopra, uno scenario di attacco di esempio di un tipo diverso è indicato in un commento sul sito Bugzilla di Mozilla , riguardante un problema con la memorizzazione nella cache DNS.

DNS TTL information is not something that a single application should decide it doesn't want to abide by.

There has been some discussion that the current behavior is a "security" issue. Refusing to abide by the TTL parameter from a DNS lookup is every bit as large of a security hole, perhaps larger. Using a cached, expired DNS lookup (such as for those users using dynamic DNS services,) will end up sending the wrong information to the wrong server, possibly an e-vil server.

Possible scenario:

1. My home server, using DHCP, receives a dynamic IP address of 12.13.14.15
2. I register the dynamic service myhome.dyndns.org to point to 12.13.14.15
3. User Alice visits my web site, using Mozilla, and begins a transaction.
4. My DHCP lease expires and I am given a new IP address of 12.200.200.200
5. My server detects the change and automatically registers myhome.dyndns.org to 12.200.200.200
6. My old DHCP address, 12.13.14.15 is given to Bob Evil's computer.
7. Alice finishes filling out a web form in Mozilla and submits it. Mozilla erroneously uses the cached IP address 12.13.14.15, and the data is incorrectly sent to Bob Evil's computer.

This has actually happened for me. I've ended up hitting other peoples' DSL routers (if they have no web site set up) instead of my own server with Mozilla, even though I've registered a new IP address.