DNS spoofing e cache poisoning

Il DNS spoofing consiste nel fornire una risposta DNS falsificata, così che la vittima risolva un nome nell'IP controllato dall'aggressore. Il cache poisoning è una forma specifica in cui la risposta falsificata viene accettata e memorizzata da un resolver ricorsivo, contaminando ogni client che lo utilizza.

L'obiettivo è solitamente il reindirizzamento del traffico: inviare gli utenti verso pagine di phishing, siti da cui scaricare malware o proxy man-in-the-middle.

Quando un resolver invia una query, un aggressore tenta di iniettare una risposta falsificata prima che risponda il server autoritativo legittimo. Se la falsificazione arriva per prima e corrisponde ai campi attesi, vince la gara e viene memorizzata nella cache.

Per questo latenza, ordine dei pacchetti e porta in uscita del resolver sono così importanti sia nell'attacco sia nella difesa.

Perché una risposta UDP falsificata venga accettata, l'aggressore deve far corrispondere:

• L'IP sorgente (il server autoritativo).
• La porta di destinazione (la porta in uscita del resolver).
• Il nome e il tipo della query.
• L'ID di transazione (TXID) a 16 bit.

In assenza di protezioni, l'unico vero segreto è il TXID, con una probabilità di circa 1 su 65.536 per pacchetto.

La divulgazione del 2008 di Dan Kaminsky ha mostrato che il poisoning era molto più semplice di quanto si pensasse. Invece di una sola gara per record, l'aggressore interroga molti sottodomini inesistenti (aaa.bank.com, aab.bank.com...) e inonda il resolver di risposte falsificate contenenti un record NS o un record glue malevolo per l'intero dominio.

Ogni tentativo è una nuova gara, senza penalità di caching quando il nome non esiste, quindi l'aggressore può riprovare finché un tentativo non va a buon fine e avvelena l'intera zona.

La principale mitigazione introdotta dopo Kaminsky è stata la randomizzazione della porta sorgente. Invece di utilizzare una porta in uscita fissa, il resolver sceglie una porta effimera casuale per ogni query.

Ora l'aggressore deve indovinare sia il TXID (16 bit) sia la porta sorgente (circa 16 bit), ampliando lo spazio di ricerca a circa 2^32 possibilità. Questo rende impraticabile il cache poisoning off-path alla cieca, anche se non impossibile con implementazioni dall'entropia debole.

Un aggressore off-path non può vedere la query e deve indovinare alla cieca il TXID e la porta. Un aggressore on-path (Wi-Fi malevolo, router compromesso, ISP) può leggere direttamente la query e creare facilmente una risposta corrispondente.

Lo spoofing on-path annulla completamente l'efficacia della randomizzazione della porta. Per questo, per ottenere una garanzia solida e non solo basata sull'entropia, sono necessari il trasporto cifrato e la convalida DNSSEC.

Gli aggressori non falsificano sempre i pacchetti. Un server DHCP malevolo può fornire ai client l'indirizzo di un resolver DNS dannoso, facendo sì che ogni ricerca riceva una risposta dall'aggressore. In modo analogo, un malware può modificare /etc/resolv.conf o le impostazioni del router.

Minacce storiche come il malware DNSChanger reindirizzavano silenziosamente il DNS delle vittime verso server fraudolenti per anni. Verifichi quali resolver utilizza effettivamente il suo parco dispositivi.

I resolver applicano le regole di bailiwick: una risposta può fornire record solo per nomi inclusi nella zona per cui è autoritativa. Una risposta per bank.com non può introdurre di nascosto un record per unrelated.com.

Questo limita le iniezioni in stile Kaminsky al dominio interrogato e impedisce che una risposta avvelenata contamini zone non correlate. Verifichi che il suo resolver applichi un filtro bailiwick rigoroso.

Segnali di un cache poisoning in corso o riuscito:

• Un picco di query per sottodomini casuali inesistenti.
• Risposte DNS duplicate o fuori ordine per lo stesso TXID.
• IP risolti che improvvisamente puntano ad ASN o aree geografiche inattesi.
• Discordanza tra le risposte del resolver e una ricerca di verifica affidabile eseguita fuori banda.

Nessun singolo controllo è sufficiente. Combini:

• Randomizzazione della porta sorgente e del TXID per aumentare il costo di un attacco off-path.
• Convalida DNSSEC, così che le risposte falsificate non superino i controlli di firma.
• DoT/DoH per impedire agli aggressori on-path di vedere o manomettere il traffico.
• Codifica 0x20 (maiuscole casuali nei nomi delle query) per aggiungere entropia.
• Monitoraggio dei flood NXDOMAIN e delle anomalie nelle risposte.

Nella pratica, il cache poisoning off-path alla cieca è oggi raro sui resolver aggiornati, ma riemerge tramite canali laterali, ad esempio la frammentazione UDP e gli attacchi di inferenza della porta basati su ICMP, come SAD DNS. Mantenga i resolver aggiornati e preferisca resolver che eseguono la convalida e usano la crittografia.

Ricordi: la compromissione DNS più grave spesso non è una gara di poisoning sofisticata, ma un account del registrar sottratto. Protegga entrambi gli estremi.

Lo spoofing DNS falsifica le risposte; il cache poisoning le rende persistenti nella cache di un resolver. L'accettazione dipende dalla corrispondenza tra IP sorgente, porta, nome della query e TXID. La randomizzazione della porta sorgente e i controlli di bailiwick hanno alzato l'asticella per gli attaccanti off-path, ma gli attaccanti on-path e i canali laterali restano una minaccia.

Una difesa in profondità, basata su entropia, convalida DNSSEC, trasporto cifrato e monitoraggio, è essenziale. Ora vedremo come gli attaccanti abusano del DNS per spostare i dati: tunneling ed esfiltrazione.