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
Cos'è il DNS rebinding e perché dovrebbe interessarti
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.
| Approccio | Chiude il divario del rebinding? |
|---|---|
| Convalidare una sola volta la stringa dell'hostname | No: non dice nulla su ciò in cui si risolve |
| Risolvere una volta e riusare l'IP per le richieste successive | No: il record può cambiare prima del riutilizzo |
| Risolvere e controllare la blocklist a ogni singolo utilizzo | Sì: 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.
Per approfondire
I record che incontrerai in quasi ogni zona DNS
Cos'è un record CAA? Decidi quali CA emettono certificati
Scopri come i record DNS CAA indicano gli emittenti di certificati consentiti e come evitare gli errori di configurazione più comuni.
Un lookup DNS ricorsivo, un passaggio alla volta
Browser
vuole example.com
Resolver
il tuo ISP / 1.1.1.1
Root + TLD
chi gestisce .com?
Autorevole
la risposta vera
Ogni passaggio della catena è a sua volta un lookup DNS, poi messo in cache
DNSSEC: come si autenticano le risposte DNS
Scopri cosa fanno le firme DNSSEC e i record DS e DNSKEY, come funziona la validazione e come una configurazione errata può causare risposte SERVFAIL.
Ogni intervallo IPv4 ha un equivalente IPv6
Considerazioni sulla sicurezza IPv6 da non trascurare
Dal punto di vista della sicurezza, IPv6 non è solo «IPv4 con più indirizzi»: alcune differenze cambiano davvero il modello di minaccia.