Generazione di Zonefile per l'Attacco NSEC3-Encloser

Questo progetto genera zonefile DNS con parametri NSEC3 personalizzati per riprodurre e valutare gli attacchi descritti in CVE-2023-50868.

Requisiti

Python3 (testato su Python3.10)

Dipendenze Python installate:

cryptography 42.0.5
dnspython 2.6.1

Componenti

lib: utilità Python, tra cui:
- keys.py: funzioni wrapper per caricare/salvare le chiavi su file
- nsec.py: implementazione degli hash NSEC DNSSEC
- dnssec.py: funzioni dnspython modificate/patchate con supporto NSEC3
- config.py: utilità per il caricamento della configurazione
keys: file PEM con chiavi pre-generate (generate con gen_keys.py)
zones: zonefile (generati con gen_zones.py)
config.json: esempio di configurazione

Setup

Configurare quali zone NSEC3 devono essere create modificando il file config.json (vedi Configurazione)
Generare le chiavi: $ ./gen_keys.py

Per ogni zona vengono generate una KSK e una ZSK. Le chiavi vengono riutilizzate quando si modifica la configurazione, purché i nomi delle zone rimangano invariati nella configurazione.
Generare i zonefile: $ ./gen_zones.py -c

L'opzione -c abilita l'esportazione dei file di configurazione (attualmente solo per BIND9)

Usare --help per ulteriori opzioni.

Configurazione

La struttura della configurazione contiene due elementi:

default: parametri predefiniti per le zone (non tutti sono attualmente supportati)
zones: elenco di tutte le zone da esportare

Zona

Una zona contiene:

name (obbligatorio): il nome usato per riferirsi alla zona e come nome file durante l'esportazione
origin (obbligatorio): il nome di dominio canonico dell'origine della zona
parent: il nome della zona padre (non l'origine), a cui vengono aggiunti i record NS, A, DS e NSEC3PARAM di questa zona
keysize (obbligatorio): la dimensione della chiave RSA (attualmente solo RSA)
nsec3: i parametri NSEC3:
- iterations: valore predefinito 0
- salt: valore predefinito ''
- algorithm: valore intero; al momento è supportato solo SHA-1 (1)
- tight: un booleano speciale che controlla se devono essere aggiunti i record NSEC3 immediatamente dopo l'origine e prima e dopo *.origin. Ad esempio, se *.origin ha un record NSEC3 1d..ua.origin., allora vengono aggiunti al zonefile anche i record per 1d..u0.origin. e 1d..ub.origin.. Questo garantisce che ogni prova NXDOMAIN su un sottodominio di origin (ad es. a.origin.) richieda tre record NSEC3, poiché i record NSEC3 che coprono l'origine e il wildcard hanno un intervallo molto piccolo verso next_hash
ns: i nameserver di questa zona. Un singolo valore o un elenco di:
- ns: il nome di dominio di un nameserver, valore predefinito ns1.origin
- ip: il dominio IPv4 (IPv6 attualmente non supportato), valore predefinito 172.0.0.1
soa: il RDATA SOA
rrsets: un elenco di RRset aggiuntivi, forniti come tupla di 5 elementi [nome di dominio, ttl, classe, tipo, rdata] in cui tutti i valori (tranne, opzionalmente, ttl) sono forniti come stringhe

Riproduzione dell'Attacco

Per riprodurre l'attacco NSEC3, questa sezione illustra una possibile configurazione personalizzata composta da un nameserver DNS e un resolver vittima. Prima di continuare, assicurarsi che l'ambiente di sistema abbia un firewall configurato in modo adeguato per non esporre server pubblici ai zonefile dell'attacco.

Installare il nameserver NSD (versione corrente)

Visitare il sito NLNetlabs (https://nsd.docs.nlnetlabs.nl/en/latest/installation.html) per le istruzioni di installazione.

Si consiglia di distribuire il nameserver in una VM o in un container. Come punto di partenza, è disponibile un piccolo Dockerfile in docker/nsd.

Creare il container con docker build -t <tag> <path_to_dockerfile>, ad esempio: cd docker/nsd && docker build -t nsd .

Eseguire il container con docker run -it --name <name> nsd bash per aprire una console nel container.

Successivamente, il nameserver deve essere configurato per ospitare i zonefile dell'attaccante. Ciò richiede una corretta configurazione dei zonefile da generare (soprattutto, l'indirizzo IP indicato nei record NS deve corrispondere all'indirizzo IP del container). Se non è stata configurata alcuna rete, l'indirizzo IP del container può essere visualizzato con: docker container inspect <name> | grep IPAddress

Generare le zone con l'output di configurazione (./gen_zones.py -c, vedi sopra) e copiare la cartella di output delle zone dalla directory del repository nel container docker: docker cp ./zones <name>:/etc/nsd

Nella console del container, il file di configurazione NSD /etc/nsd/nsd.conf nel container deve essere integrato con le seguenti righe:
```
verify:
    enable: no
remote-control:
    control-enable: no

include: "/etc/nsd/zones/nsd.conf"
```
Infine, eseguire NSD dalla shell del container con il comando /usr/sbin/nsd -d -c /etc/nsd/nsd.conf

Abilitare l'output di log con l'opzione -V 4.

Ora, se non si sono verificati problemi, il nameserver autoritativo dovrebbe essere in esecuzione. È possibile verificarlo eseguendo una query su uno dei domini delle zone dal sistema host usando dig: dig @<ip-addr-of-nsd-container> <domain>
Installare un resolver. In questa dimostrazione mostriamo un possibile approccio per Unbound 1.17.1.

Un Dockerfile ufficiale si trova qui: https://github.com/NLnetLabs/pythonunbound

Abbiamo incluso una versione modificata di questo Dockerfile in docker/unbound con una versione aggiornata di Ubuntu e pre-configurata per Unbound 1.17.1.

Clonare il repository, spostarsi nella sua directory e creare il container Unbound: docker build -t <tag> .

Eseguire il container con: docker run --name <name> -it <tag> bash

Successivamente, Unbound deve essere configurato in modo da poter individuare il nameserver autoritativo NSD. Ciò si ottiene modificando il file unbound.conf nella directory di lavoro del container. A tale scopo, assicurarsi che la voce server.module-config sia rimossa dalla configurazione.

Per abilitare la validazione DNSSEC, i record DNSKEY della zona padre dell'attaccante devono essere configurati manualmente. Deve essere la stessa chiave usata per generare le firme, ad esempio:
```
server:
    chroot: ""
    do-ip6: no
    trust-anchor: "attack.er. DNSKEY 257 3 7 AwEAAdqDN3rJYlmGP3jJs5lCZq5NYrCn pCVlV0ko17JnbfYfLCroEF4reO/Xy0MK C9AVvSRTk83MHDuzMYXogm7m/gcn3Mh0 MwB2InP8jkPw5not+TMH/Wrbs31xkT2n RIBJJ+1lPF+e2AvwWvgREcEVTRbdhIqQ iM1StWXoTVudry4V"
```
Inoltre, deve essere configurata una stub-zone per consentire al resolver Unbound di trovare il nameserver autoritativo NSD. Ciò si ottiene aggiungendo quanto segue al file unbound.conf:
```
stub-zone:
    name: "attack.er."
    stub-prime: yes
    stub-addr: <ip-addr-of-nsd-container>
```
Avviare unbound nel container con: unbound -vvv (usare -dd per impedire la demonizzazione)

Ora dovrebbe essere possibile interrogare unbound con dig e osservare il tempo di risposta: dig @127.0.0.1 attack.er

Se avete problemi con questa guida, non esitate a contattarci per ulteriore assistenza.

NSEC3-Encloser-Attack

Più Popolari