Domain IP Lookup

Lo stesso dominio, due risposte diverse

Prima richiesta

si risolve in un IP pubblico

Convalida

superata: sembra sicuro

Scade il TTL

pochi secondi dopo

Seconda richiesta

si risolve in 127.0.0.1

Sicurezza

Cos'è il DNS rebinding e perché dovrebbe interessarti

3 min di lettura

La maggior parte dei controlli di sicurezza che riguardano un dominio dà per scontato che il suo indirizzo IP sia abbastanza stabile da poter essere convalidato una sola volta e poi considerato affidabile. Il DNS rebinding sfrutta proprio questo presupposto. Un attaccante controlla il DNS di un dominio e lo configura in modo che all'inizio si risolva in un normale indirizzo IP pubblico, superando qualunque convalida il sistema bersaglio effettui, per poi cambiare la risposta in un indirizzo interno (come 127.0.0.1 o un intervallo interno 10.x.x.x) per una richiesta successiva, quando il controllo è già stato superato.

Perché non è solo un trucco teorico

Un TTL molto breve rende l'attacco praticabile: l'attaccante imposta la scadenza del record a pochi secondi, così un controllo di convalida e la richiesta vera e propria che lo segue possono vedere due risposte diverse, a pochi millisecondi di distanza, senza che il sistema vittima si accorga che il terreno è cambiato sotto i suoi piedi. Qualsiasi sistema che risolve un dominio una sola volta e riusa quell'IP in più operazioni, o peggio lo risolve una volta per la convalida e lascia che qualcos'altro lo risolva di nuovo per la richiesta vera, è potenzialmente esposto.

L'unica difesa affidabile

Convalidare la stringa di un hostname non basta, e convalidare un IP una sola volta nemmeno. L'unica difesa robusta è confrontare l'indirizzo realmente risolto con una blocklist di intervalli privati/interni nel punto in cui la connessione viene effettivamente stabilita, ogni singola volta e non solo alla convalida iniziale. Questo chiude il divario temporale da cui il rebinding dipende, perché non c'è più alcuna finestra tra «controllato» e «usato» in cui la risposta possa cambiare.

  • Blocca gli intervalli privati (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), il loopback (127.0.0.0/8), i link-local (169.254.0.0/16) e gli endpoint dei metadati cloud, sia per IPv4 che per IPv6.
  • Ricontrolla a ogni utilizzo, non solo una volta alla convalida dell'input.
  • Tratta un indirizzo IPv6 mappato su IPv4 (come ::ffff:127.0.0.1) come equivalente all'indirizzo IPv4 che contiene: a volte i tentativi di rebinding usano proprio questa codifica per aggirare un controllo ingenuo valido solo per IPv6.
ApproccioChiude il divario del rebinding?
Convalidare una sola volta la stringa dell'hostnameNo: non dice nulla su ciò in cui si risolve
Risolvere una volta e riusare l'IP per le richieste successiveNo: il record può cambiare prima del riutilizzo
Risolvere e controllare la blocklist a ogni singolo utilizzoSì: non resta alcuna finestra in cui la risposta possa cambiare

Dove ha avuto importanza nella pratica

Il DNS rebinding non è una preoccupazione accademica di nicchia: è stato usato più volte contro router domestici, hub per la smart home e altri dispositivi che espongono un'interfaccia di amministrazione locale senza autenticazione, partendo dal presupposto che solo il traffico locale affidabile possa raggiungerla. Una pagina web malevola, aperta in una normale scheda del browser nella stessa rete, può usare il rebinding per far sì che il browser della vittima, già considerato affidabile dal router per il solo fatto di trovarsi nella rete locale, invii richieste direttamente a quell'interfaccia di amministrazione per conto dell'attaccante. Il browser crede per tutto il tempo di parlare ancora con il dominio pubblico originale; è cambiata solo la risposta DNS sottostante.

Una variante più sottile: il rebinding a risposte multiple

Una versione più sofisticata evita del tutto di aspettare la scadenza di un TTL. Una singola risposta DNS può legittimamente contenere più di un record A e alcuni software client li provano semplicemente in ordine, o addirittura li alternano a rotazione tra richieste diverse. Un attaccante può restituire nella stessa identica risposta sia un indirizzo pubblico legittimo sia uno interno, contando sul fatto che prima o poi il client provi la seconda voce: nessuna attesa, nessuna finestra temporale, solo lo sfruttamento del fatto che il DNS non è mai stato progettato per garantire che ogni indirizzo di una risposta multipla sia ugualmente affidabile. È un buon promemoria del fatto che «controllare il primo indirizzo restituito» non è mai sufficiente: ogni indirizzo di una risposta richiede lo stesso scrutinio.

Devi controllare gli indirizzi DNS pubblici di un dominio? Usa lo strumento Domain IP Lookup.