Il DNS e' il sistema che traduce nomi di dominio in indirizzi IP. Attaccare il DNS significa controllare dove gli utenti vengono reindirizzati senza che se ne accorgano, anche quando digitano l'URL corretto. Questa nota copre l'attacco lato server (Poisoning), l'attacco lato client (Pharming), e la difesa attiva SOC (Sinkhole).
Mappa globale#
DNS Poisoning (Cache Poisoning)#
Il DNS poisoning corrompe la cache di un server DNS inserendo record falsi: tutti i client che usano quel resolver vengono reindirizzati verso destinazioni controllate dall'attaccante, pur digitando l'URL corretto. L'impatto e' potenzialmente ampio perche' un singolo resolver serve migliaia di client.
Il DNS usa UDP, un protocollo connectionless senza autenticazione delle risposte. La finestra di vulnerabilita' e' la seguente: quando un resolver non ha un dominio in cache, interroga il server autoritativo. L'attaccante deve solo iniettare una risposta falsa prima che arrivi quella vera. Chi risponde prima vince.
Flusso dell'attacco senza DNSSEC:
sequenceDiagram
participant U as Utente
participant D as DNS Resolver
participant A as Attaccante
participant R as Server Autoritativo
U->>D: qual e' l'IP di banca.com?
D->>R: query al server autoritativo
A->>D: risposta falsa - banca.com = 1.2.3.4 (IP malevolo)
Note over D: nessuna firma da verificare
Note over D: risposta falsa arriva prima - cache avvelenata
R->>D: risposta vera - banca.com = 198.51.100.1 (ignorata)
D->>U: 1.2.3.4
U->>A: credenziali inserite sul sito malevolo
Flusso con DNSSEC attivo - attacco bloccato:
sequenceDiagram
participant U as Utente
participant D as DNS Resolver
participant A as Attaccante
participant R as Server Autoritativo
Note over R: firma i record con chiave privata
U->>D: qual e' l'IP di banca.com?
D->>R: query al server autoritativo
A->>D: risposta falsa senza firma valida
R->>D: risposta vera + firma digitale
Note over D: firma falsa assente o invalida - SCARTATA
Note over D: firma vera valida - ACCETTATA
D->>U: 198.51.100.1 (IP corretto)
Indicatore principale: l'utente digita l'URL corretto ma viene portato su un sito diverso. nslookup da quel resolver restituisce un IP anomalo rispetto a quello verificabile via DNS autoritativo esterno.
| Attributo | Dettaglio |
|---|---|
| Vettore | Risposta DNS falsa iniettata nella cache del resolver via UDP |
| Causa | DNS non autentica le risposte - chi risponde prima vince |
| Scope | Ampio - tutti gli utenti del resolver avvelenato |
| CIA Triad | Confidentiality + Integrity |
| Difesa | DNSSEC, source port randomization |
Kaminsky Attack (2008)#
Il Kaminsky Attack e' la tecnica di DNS cache poisoning piu' nota: sfruttava la prevedibilita' del transaction ID nei pacchetti DNS per avvelenare la cache in tempi brevi, senza aspettare che la voce scadesse naturalmente.
Prima del 2008, il DNS usava un transaction ID a 16 bit (65.536 valori possibili). L'attaccante inondava il resolver con migliaia di risposte false, cercando di indovinare l'ID corretto prima che arrivasse la risposta autentica. Con abbastanza velocita' ci si riusciva in pochi secondi.
Il fix fu la source port randomization: il resolver sceglie una porta sorgente casuale tra 65.536 possibili per ogni query. Combinando porta sorgente e transaction ID si ottengono circa 2 miliardi di combinazioni, rendendo impraticabile il brute force in tempo utile.
DNSSEC e la catena di fiducia#
DNSSEC (Domain Name System Security Extensions) aggiunge firme crittografiche ai record DNS. Il server autoritativo firma i record con la sua chiave privata. Il resolver verifica la firma con la chiave pubblica prima di accettare la risposta. Un attaccante non puo' creare risposte false con firma valida senza la chiave privata.
Il resolver non memorizza le chiavi pubbliche di tutti i domini: ha solo una chiave hardcoded nel software, la chiave pubblica della root zone (Trust Anchor). Da li' segue una catena di firme verso il basso.
flowchart TD
SPACER[" "]:::spacer
TA["TRUST ANCHOR
Chiave pubblica root - hardcoded nel resolver
non arriva mai dalla rete"]
ROOT["ROOT ZONE (.)
Firma la chiave pubblica di .com"]
COM[".com
Firma la chiave pubblica di banca.com"]
DOMINIO["banca.com
Firma i suoi record A, MX, ecc."]
RECORD["Record: banca.com = 198.51.100.1
+ firma digitale di banca.com"]
VERIFY["RESOLVER - verifica bottom-up
1 - chiave root verifica firma su chiave .com
2 - chiave .com verifica firma su chiave banca.com
3 - chiave banca.com verifica firma sul record
Record accettato"]
SPACER~~~TA
TA --> ROOT
ROOT -->|"firma chiave pubblica"| COM
COM -->|"firma chiave pubblica"| DOMINIO
DOMINIO -->|"firma record"| RECORD
RECORD --> VERIFY
TA -.->|"punto di partenza fisso"| VERIFY
style TA fill:#1a3a1a,stroke:#4aaf7e,color:#ffffff
style VERIFY fill:#1a2a3a,stroke:#4a9eff,color:#ffffff
style RECORD fill:#1a1a3a,stroke:#9b59b6,color:#ffffff
style ROOT fill:#2a2000,stroke:#f0c040,color:#ffffff
style COM fill:#2a2000,stroke:#f0c040,color:#ffffff
style DOMINIO fill:#2a2000,stroke:#f0c040,color:#ffffff
classDef spacer fill:none,stroke:none,color:none;
Identico al modello PKI/TLS: ti fidi della root CA hardcoded nel browser, lei garantisce per le CA intermedie, che garantiscono per i siti. La root non arriva mai dalla rete e non puo' essere falsificata.
Dev parallel: In PHP/Node,
file_get_contents('https://api.example.com')usa il resolver di sistema. Se il resolver e' avvelenato, la chiamata va al server sbagliato con l'URL corretto. La difesa non e' solo DNS: e' HTTPS con verifica del certificato. Se l'IP di destinazione e' diverso, il certificato non matcha il dominio e la connessione fallisce con errore SSL. Il DNS poisoning da solo non basta se TLS e' configurato correttamente: serve anche un certificato valido per quel dominio, che l'attaccante non puo' ottenere senza controllo del dominio o compromissione della CA.
Pharming#
Il pharming manipola la risoluzione DNS a livello locale, sul sistema dell'utente, modificando il file hosts. Non richiede di compromettere alcun server DNS: colpisce solo quella macchina. La conseguenza visibile per l'utente e' identica al DNS poisoning, ma la causa e' completamente diversa.
Il file hosts ha priorita' assoluta sul DNS: se contiene una entry per un hostname, il sistema operativo la usa senza mai interrogare il resolver esterno. E' un meccanismo legacy che ancora oggi ha precedenza sulle query DNS su tutti i sistemi operativi principali.
| Sistema Operativo | Percorso |
|---|---|
| Windows | C:\Windows\System32\drivers\etc\hosts |
| Linux | /etc/hosts |
| macOS | /private/etc/hosts |
Esempio di entry malevola:
127.0.0.1 localhost
13.207.21.200 banca.comL'utente digita banca.com nel browser, il sistema legge il file hosts e va direttamente all'IP malevolo. Non interroga mai il DNS. Il browser mostra banca.com nella barra degli indirizzi. Se quell'IP serve una pagina clone, l'utente non si accorge di nulla.
Confronto con DNS Poisoning:
| Attributo | DNS Poisoning | Pharming |
|---|---|---|
| Dove colpisce | Cache del DNS resolver | File hosts locale |
| Chi viene colpito | Tutti gli utenti del resolver | Solo quel dispositivo |
| Scope | Ampio - potenzialmente migliaia | Singolo dispositivo |
| Meccanismo | Risposta UDP falsa nel server | Scrittura su file di sistema |
| Difesa | DNSSEC | EDR, file integrity monitoring |
| DNSSEC aiuta? | Si' | No |
DNS poisoning e' come avvelenare il pozzo del villaggio. Pharming e' come avvelenare il bicchiere di una singola persona.
| Attributo | Dettaglio |
|---|---|
| Vettore | File hosts modificato da malware o accesso fisico al dispositivo |
| Causa | File hosts ha priorita' assoluta sul DNS senza verifica crittografica |
| Scope | Singolo sistema - gli altri utenti della rete non sono colpiti |
| CIA Triad | Confidentiality + Integrity |
| Difesa | EDR con regola su scritture al file hosts, antimalware |
DNS Sinkhole#
Un DNS sinkhole e' una tecnica difensiva che risponde alle query per domini malevoli con un IP controllato dal defender invece di NXDOMAIN, permettendo di osservare e loggare esattamente quali host tentano di contattare infrastrutture C2.
La differenza rispetto al semplice blocco DNS e' fondamentale: con NXDOMAIN sai che qualcosa ha tentato la connessione, ma non hai visibilita' su chi. Con il sinkhole il traffico arriva al tuo server controllato, logghi l'IP sorgente, e sai esattamente quale macchina e' infetta.
flowchart LR
%% Nodi globali
HOST["Host infetto"]
DNS["DNS Server
(sinkhole attivo)"]
C2["C2 server attaccante"]
SINK["Sinkhole SOC
IP controllato dal defender"]
LOG["Log - chi e' infetto?
Alert SIEM"]
%% Flusso
HOST -->|"Query - evil-c2.com"| DNS
DNS -->|"Risposta normale"| C2
DNS -->|"Sinkhole attivo"| SINK
SINK -->|"Osservazione + log"| LOG
style C2 fill:#5c1a1a,color:#ffffff
style SINK fill:#1a3a1a,color:#ffffff
style LOG fill:#1a2a3a,color:#ffffff
Il caso classico: le autorita' reverse-engineerano un malware, trovano i domain name dei C2 hardcodati nel codice, e coordinano con i DNS owner per redirigere quei domini verso un sinkhole controllato. I computer infetti continuano a "chiamare casa", ma parlano con le autorita' invece che con l'attaccante. La botnet viene neutralizzata senza toccare nessun computer infetto.
Usato da: Cisco Umbrella, Cloudflare Gateway, Pi-hole con blocklist di threat intelligence, firewall aziendali con DNS filtering integrato.
| Attributo | Dettaglio |
|---|---|
| Tecnica | Difensiva - applicata dal DNS server locale o dal resolver aziendale |
| Differenza da NXDOMAIN | Risponde con IP controllato, non "dominio non esiste" |
| Vantaggio | Ogni hit al sinkhole = macchina infetta identificata e loggata |
| Indicatore Blue Team | Alert SIEM per ogni query verso domini in blocklist |
| Limite | Il malware puo' usare IP diretti invece di domain name, o DNS over HTTPS (DoH) |
Un blocco NXDOMAIN dice "non andare li'". Un sinkhole dice "vai qui invece" e registra chi ci e' andato. La visibilita' e' il vantaggio chiave del sinkhole sul semplice blocco: ogni connessione al sinkhole e' un alert con l'IP dell'host infetto.
Mappa figlia - Difese DNS#
Mappa figlia - 4 attacchi DNS a confronto#
Note correlate: dnssec | dns-tunneling | dns-resolution-flow | dns-records
