DNS Zone Transfer Attack (AXFR) - Ricognizione DNS

Cosa fa

#

Un DNS Zone Transfer Attack sfrutta il meccanismo AXFR (Authoritative Zone Transfer) per copiare l'intera zona DNS di un dominio, rivelando tutti i server interni, le naming convention e gli IP privati dell'organizzazione.

TL;DR

#

1. AXFR e' il meccanismo legittimo con cui il DNS primario replica la zona sui server secondari.
2. Se il server accetta richieste AXFR da qualsiasi IP, chiunque puo' ottenere tutti i record DNS.
3. Il risultato e' una mappa completa dell'infrastruttura interna: server, VPN, DB, naming convention.
4. Difesa: limitare AXFR agli IP dei secondary DNS autorizzati (ACL su BIND/Windows DNS).
5. TSIG (Transaction Signature) aggiunge autenticazione crittografica alla richiesta AXFR.
6. DNSSEC non protegge da zone transfer: protegge l'integrita' delle risposte, non la confidenzialita'.

Come funziona AXFR

#

AXFR (Authoritative Zone Transfer) e' il meccanismo standard con cui un Primary DNS server replica l'intera zona DNS ai Secondary server. In un'infrastruttura correttamente configurata, solo gli IP dei secondary autorizzati possono richiedere AXFR. Quando questa restrizione manca, chiunque puo' richiedere e ricevere tutti i record DNS.

sequenceDiagram
    participant P as Primary DNS
    participant S as Secondary DNS (autorizzato)
    participant ATK as Attaccante

    Note over P, S: Scenario legittimo
    P ->> S: NOTIFY (zona modificata)
    S ->> P: SOA Query (verifica serial number)
    P ->> S: SOA Response
    S ->> P: AXFR Request
    P ->> S: Trasferimento intera zona (tutti i record)

    Note over ATK, P: Scenario di attacco (server mal configurato)
    ATK ->> P: AXFR Request (nessuna restrizione)
    P ->> ATK: Trasferimento intera zona
    Note over ATK: Ottiene mappa completa dell'infrastruttura

Cosa ottiene l'attaccante da una zona esposta:

; Esempio di output AXFR (formato zone file)
$ORIGIN corp.com.
@          IN  SOA  ns1.corp.com. admin.corp.com. (...)
@          IN  NS   ns1.corp.com.
@          IN  NS   ns2.corp.com.

; Server esposti a Internet
www        IN  A    203.0.113.10
mail       IN  A    203.0.113.11
vpn        IN  A    203.0.113.12

; Server INTERNI (non dovrebbero essere visibili)
db-prod    IN  A    10.0.1.50
db-dev     IN  A    10.0.1.51
ldap       IN  A    10.0.2.10
jenkins    IN  A    10.0.3.20
backup     IN  A    10.0.4.100

L'attaccante ottiene in un'unica risposta: tutti i server, la naming convention (si capisce immediatamente che db-prod.corp.com e' il database di produzione e jenkins.corp.com e' il CI/CD), e gli IP privati dei sistemi interni.

flowchart TD
    subgraph RICOGNIZIONE ["Fase di Ricognizione"]
        A([Attaccante]) --> B["dig AXFR corp.com @ns1.corp.com"]
        B --> C["Risposta: tutti i record DNS"]
    end

    subgraph RISULTATO ["Informazioni ottenute"]
        D["db-prod.corp.com → 10.0.1.50"]
        E["ldap.corp.com → 10.0.2.10"]
        F["jenkins.corp.com → 10.0.3.20"]
        G["vpn.corp.com → 203.0.113.12"]
    end

    C --> D
    C --> E
    C --> F
    C --> G

    D -. "Target: database" .-> H["Prossimi step di attacco"]
    E -. "Target: credenziali AD" .-> H
    F -. "Target: supply chain" .-> H

    style A fill:#a72626,stroke:#c0392b,color:#fff
    style H fill:#1a1a2e,stroke:#e74c3c,color:#fff

Test e Verifica

#

Un penetration tester o un auditor verifica la vulnerabilita' al zone transfer con un singolo comando:

# Test zone transfer (la risposta NON deve contenere record di zona)
dig @ns1.target.com target.com AXFR

# Se il server e' vulnerabile, la risposta include tutti i record
# Se il server e' configurato correttamente, risponde con:
# Transfer failed. (o semplicemente nessun record)

# Verifica con nslookup (alternativa)
nslookup -type=AXFR target.com ns1.target.com

La risposta attesa da un server ben configurato:

; <<>> DiG 9.16.1-Ubuntu <<>> @ns1.target.com target.com AXFR
; (1 server found)
;; global options: +cmd
; Transfer failed.

Difese

#

La difesa primaria e' la restrizione degli IP autorizzati a richiedere AXFR. La TSIG aggiunge un layer di autenticazione crittografica.

Configurazione BIND per bloccare AXFR non autorizzato:

# /etc/named.conf - configurazione sicura
zone "corp.com" IN {
    type primary;
    file "corp.com.zone";

    # Consente AXFR solo ai secondary DNS autorizzati
    allow-transfer {
        10.0.0.53;    # secondary-1
        10.0.0.54;    # secondary-2
    };

    # Notifica solo i secondary autorizzati di modifiche alla zona
    also-notify { 10.0.0.53; 10.0.0.54; };
};

Scenario Reale

#

Durante una fase di ricognizione di un red team assessment, il tester esegue:

dig @ns1.megacorp.com megacorp.com AXFR

Il server risponde con 847 record. Il tester ottiene in 2 secondi:

• internal-jenkins.megacorp.com → IP interno del CI/CD server
• ad.megacorp.com → IP del domain controller Active Directory
• backup-nas.megacorp.com → IP del server di backup
• staging-api.megacorp.com → IP dell'ambiente di staging delle API
• Naming convention: tutti i server di produzione usano il prefisso prod-, tutti i dev usano dev-

Con questi dati, il passo successivo e' tentare l'accesso ai sistemi interni identificati, partendo dal CI/CD server (jenkins) che spesso ha permessi di deploy sulla produzione.

Dev parallel: come un endpoint GET /api/internal-config che non richiede autenticazione e restituisce tutta la configurazione dell'applicazione (database host, chiavi API, servizi interni). Il DNS non autenticato e' lo stesso problema: un'API che risponde a tutti con informazioni riservate.

Collegato a

#

• dns-records - i tipi di record che AXFR espone (A, MX, CNAME, PTR...)
• dnssec - protegge integrita' DNS ma non da zone transfer
• passive-reconnaissance - zone transfer e' una tecnica di ricognizione passiva
• dns-tunneling - altro vettore di attacco che usa il protocollo DNS