Complessità del DNSSEC e considerazioni

DNS is split into smaller pieces called zones. A zone typically starts at a domain name, and contains all records pertaining to the subdomains. Each zone is managed by a single manager. For example, cloudflare.com is a zone containing all DNS records for cloudflare.com and its subdomains (e.g. www.cloudflare.com, api.cloudflare.com).

There is no directory service for subdomains in DNS so if you want to know if api.cloudflare.com exists, you have to ask a DNS server and that DNS server will end up asking cloudflare.com whether api.cloudflare.com exists. This is not true with DNSSEC. In some cases, enabling DNSSEC may expose otherwise obscured zone content. Not everyone cares about the secrecy of subdomains, and zone content may already be easily guessable because most sites have a ‘www’ subdomain; however, subdomains are sometimes used as login portals or other services that the site owner wants to keep private. A site owner may not want to reveal that “secretbackdoor.example.com” exists in order to protect that site from attackers.

The reason DNSSEC can expose subdomains has to do with how zones are signed. Historically, DNSSEC is used to sign static zones. A static zone is a complete set of records for a given domain. The DNSSEC signature records are created using the Key Signing Key (KSK) and Zone Signing Key (ZSK) in a central location and sent to the authoritative server to be published. This set of records allows an authoritative server to answer any question it is asked, including questions about subdomains that don’t exist.

Unlike standard DNS, where the server returns an unsigned NXDOMAIN (Non-Existent Domain) response when a subdomain does not exist, DNSSEC guarantees that every answer is signed. This is done with a special record that serves as a proof of non-existence called the NextSECure (NSEC) record. An NSEC record can be used to say: “there are no subdomains between subdomains X and subdomain Y.” By filling the gap between every domain in the zone, NSEC provides a way to answer any query with a static record. The NSEC record also lists what Resource Record types exist at each name.

For statically signed zones, there are, by definition, a fixed number of records. Since each NSEC record points to the next, this results in a finite ‘ring’ of NSEC records that covers all the subdomains. Anyone can ‘walk’ a zone by following one NSEC record to the next until they know all subdomains. This method can be used to reveal all of the names in that zone---possibly exposing internal information.

Suppose there is a DNSSEC-enabled zone called example.com, with subdomains public.example.com and secret.example.com. Adding NSEC records will reveal the existence of all subdomains.

Asking for the NSEC record of example.com gives the following:

example.com. NSEC public.example.com. A NS SOA TXT AAAA RRSIG NSEC DNSKEY

Asking for public.example.com gives the following NSEC record:

public.example.com. NSEC secret.example.com. A TXT AAAA RRSIG NSEC

Asking for secret.example.com gives the following NSEC record:

secret.example.com. NSEC example.com. A TXT AAAA RRSIG NSEC

The first one is for the zone top/apex, and says that the name “example.com” exists and the next name is “public.example.com”. The public.example.com record says that the next name is “secret.example.com” revealing the existence of a private subdomain. The “secret.example.com” says the next record is “example.com” completing the chain of subdomains. Therefore, with a few queries anybody can know the complete set of records in the zone.

Technically, DNS records are not supposed to be secret, but in practice they are sometimes considered so. Subdomains have been used to keep things (such as a corporate login page) private for a while, and suddenly revealing the contents of the zone file may be unexpected and unappreciated.

Before DNSSEC the only way to discover the contents of names in a zone was to either query for them, or attempt to perform a transfer of the zone from one of the authoritative servers. Zone Transfers (AXFR) are frequently blocked. NSEC’s alternatative, NSEC3, was introduced to fight zone enumeration concerns, but even NSEC3 can be used to reveal the existence of subdomains.

Most domains under .ch use NSEC3

The NSEC3 record is like an NSEC record, but, rather than a signed gap of domain names for which there are no answers to the question, NSEC3 provides a signed gap of hashes of domain names. This was intended to prevent zone enumeration. Thus, the NSEC3 chain for a zone containing “example.com” and “www.example.com” could be (each NSEC3 record is on 3 lines for clarity):

231SPNAMH63428R68U7BV359PFPJI2FC.example.com. NSEC3 1 0 3 ABCDEF
NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM
A NS SOA TXT AAAA RRSIG DNSKEY NSEC3PARAM

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM.example.com. NSEC3 1 0 3 ABCDEF
231SPNAMH63428R68U7BV359PFPJI2FC
A TXT AAAA RRSIG

Where

231SPNAMH63428R68U7BV359PFPJI2FC

example.com

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM

www.example.com

The first line of the NSEC3 record contains the “name” of the zone after it has been hashed, the number of hash rounds and salt used in the hashing are the two last parameters on the first line “3 ABCDEF”. The “1 0” stands for digest algorithm (1 means SHA-1) and if the zone uses Opt-out (0 means no). The second line is the “next hashed name in the zone”, the third line lists the types at the name. You can see the “next name” at the first NSEC3 record matches the name on the second NSEC3 record and the “next name” on that one completes the chain.

For NSEC enumeration, you can create the full list of domains by starting to guess at possible names in the domain. If the zone has around 100 domain names, it will take around 100 requests to enumerate the entire zone. With NSEC3, when you request a record that does not exist, a signed NSEC3 record is returned with the next zone present ordered alphabetically by hash. Checking if the next query name candidate fits in one of the known gaps allows anyone to discover the full chain in around 100 queries. There are many tools that can do this computation for you, including a plug-in to nmap

With the hashes that correspond to all the valid names in the zone, a dictionary attack can be used to figure out the real names. Short names are easily guessed, and by using a dictionary, longer names can be revealed as existing without having to flood the authoritative nameservers with guesses. Tools like HashCat make this easy to do in software, and the popularity of bitcoin has dramatically lowered the price of hashing-specific hardware. There is a burgeoning cottage industry of devices built to compute cryptographic hashes. The Tesla Password cracker (below) is just one example of these off-the shelf devices.

The Teslsa Cracker

Because hashing is cheap, zone privacy is only slightly improved when using NSEC3 as designed; the amount of protection a name gets is proportional to its unguessability.

In short, NSEC is like revealing plaintext passwords, and NSEC3 is like revealing a Unix-style passwords file. Neither technique is very secure. With NSEC3 a subdomain is only as private as it is hard to guess.

This vulnerability can be mitigated by a techniques introduced in RFCs 4470 and 4471 (https://tools.ietf.org/html/rfc4470 and https://tools.ietf.org/html/rfc4471) called “DNSSEC white lies”; this was implemented by Dan Kaminsky for demonstration purposes. When a request comes in for a domain that is not present, instead of providing an NSEC3 record of the next real domain, an NSEC3 record of the next hash alphabetically is presented. This does not break the NSEC3 guarantee that there are no domains whose hash fits lexicographically between the NSEC3 response and the question.

You can only implement NSEC3 or NSEC “white lies” if signatures can be computed in real-time in response to questions. Traditionally, static zone records for DNS resolution are created offline, and all the records with signatures stored in a zone file. This file is then read by a live DNS server allowing it to answer questions about the zone.

Cloudflare’s DNSSEC implementation leverages ECDSA’s efficient signature generation to sign DNSSEC records on-the-fly.

DNSSEC è stato progettato per funzionare in varie modalità, ognuna delle quali offre diversi compromessi in termini di sicurezza, prestazioni e convenienza. La firma dal vivo risolve il problema dell'esposizione del contenuto della zona in cambio di una gestione meno sicura della chiave.

La modalità DNSSEC più comune è la firma offline delle zone statiche. Ciò consente al sistema di firma di essere altamente protetto da minacce esterne, mantenendo le chiavi private su un computer non connesso alla rete. Questo modello operativo funziona bene quando le informazioni DNS non cambiano spesso.

Un'altra modalità operativa comune è la firma online centralizzata. Se si firmano i dati in sistemi di firma DNS dedicati e ad accesso limitato, i dati DNS possono essere modificati e pubblicati rapidamente. Alcuni operatori eseguono la firma DNS sui loro server DNS principali. Proprio come la firma offline delle zone statiche, questa modalità segue il modello di firma centrale, ossia un singolo (o replicato) firmatario centrale esegue tutte le operazioni di firma e i dati vengono propagati da esso ai server DNS autoritativi effettivi.

Una modalità più radicale è quella di consentire ai server DNS autoritativi effettivi di firmare i dati al volo quando necessario, il che consente una serie di nuove funzionalità, tra cui le informazioni geograficamente dipendenti firmate dove viene generata la risposta. L'aspetto negativo è che ora il materiale delle chiavi si trova su molte macchine diverse che hanno accesso diretto a Internet. L'esecuzione della firma in diretta sul bordo introduce nuovi problemi, come la distribuzione delle chiavi, e impone ai nodi requisiti di calcolo aggiuntivi.

Recentemente è stato scoperto un bug noto come Heartbleed che ha aperto un'importante falla nella sicurezza delle applicazioni server. Il problema era causato da un errore di codifica in OpenSSL che creava una vulnerabilità di divulgazione della memoria in remoto. Questo bug consentiva agli autori di attacchi remoti di estrarre chiavi crittografiche da server rivolti a Internet. I bug di esposizione della memoria remota sono solo una delle tante minacce alla sicurezza delle chiavi private quando queste vengono utilizzate in un processo attivo come la firma live del DNSSEC. Più una macchina è esposta a Internet, più sono i vettori di attacco. Le macchine con firma offline hanno una finestra di esposizione molto più ridotta a tali minacce.

Un modo per mantenere la sicurezza delle chiavi è quello di utilizzare una soluzione supportata da hardware, come un modulo di sicurezza hardware (HSM). Lo svantaggio principale è il costo: gli HSM sono molto costosi (e lenti). Questo è uno dei punti più spinosi per chi gestisce server DNS distribuiti geograficamente per essere vicini ai propri clienti. L'esecuzione di un HSM in ogni sede del server non solo può essere costosa, ma può anche comportare complicazioni legali .

Un'altra soluzione per proteggere le chiavi dalla divulgazione a distanza è quella di scaricare le operazioni crittografiche su componenti fidati del sistema.È qui che può essere utile avere un server DNS personalizzato in grado di scaricare la crittografia.

La gestione delle chiavi per il DNSSEC è simile alla gestione delle chiavi per il TLS e presenta sfide simili. All'inizio dell'anno abbiamo introdotto Keyless SSL per migliorare la sicurezza delle chiavi per TLS. Stiamo valutando la possibilità di estendere Keyless SSL per offrire i vantaggi dei server di chiavi remote per la firma live del DNSSEC.

Gli operatori che gestiscono un server DNS autorevole sono spesso nervosi per il fatto che il loro server venga utilizzato come canale per attacchi DDoS (Distributed Denial of Service) malevoli. Ciò deriva dal fatto che il DNS utilizza UDP, un protocollo stateless.

In TCP, ogni connessione inizia con un handshake a tre vie. In questo modo si garantisce che l'indirizzo IP di entrambe le parti sia noto e corretto prima di avviare una connessione. In UDP non c'è questa stretta di mano: i messaggi vengono inviati direttamente a un IP con un indirizzo IP "from" non verificato. Se un autore di attacchi è in grado di creare un pacchetto UDP che dice "Ciao, dall'IP X" a un server, quest'ultimo risponderà in genere inviando un pacchetto UDP a X. La scelta di X come indirizzo IP della vittima invece di quello del mittente è chiamata "spoofing" UDP. Facendo lo spoofing di una vittima, un autore di attacchi può far sì che un server che risponde alle richieste UDP inondi la vittima con traffico "riflesso". Questo vale sia per i server autoritativi che per i resolver ricorsivi aperti.

Il DNSSEC funziona anche su UDP e le risposte alle query DNS possono essere molto lunghe e contenere più record DNSKEY e RRSIG. Si tratta di un obiettivo interessante per gli autori di attacchi, in quanto consente loro di "amplificare" gli attacchi di riflessione. Se ai server dei nomi viene inviato un piccolo volume di richieste UDP DNSSEC spoofate, la vittima riceverà un grande volume di traffico riflesso. A volte questo è sufficiente per sovraccaricare il server della vittima e causare un denial of service.

La richiesta di un TLD inesistente da parte di un server root restituisce una risposta di circa 100 byte, mentre la risposta firmata per la stessa domanda è di circa 650 byte, ovvero un fattore di amplificazione pari a 6,5. La radice è firmata utilizzando una chiave RSA a 1.024 bit e utilizza NSEC per le risposte negative. La richiesta di un dominio che non esiste in un TLD utilizzando NSEC3 firmato con una chiave a 1.024 bit produrrà un fattore di amplificazione pari a circa 10. Esistono altre query che possono produrre fattori di amplificazione ancora più elevati; la più efficace è la query "ANY".

Come molti servizi, il DNS può funzionare anche su TCP. Esiste un flag di "troncamento" che può essere inviato a un resolver per indicare che è necessario il TCP. Questo risolverebbe il problema della riflessione DNS al costo di richieste DNS più lente. Questa soluzione non è al momento praticabile poiché il 16% dei resolver non rispetta il flag di troncamento TCP e il 4% non prova con un secondo server.

Un'altra opzione per ridurre le dimensioni delle risposte è quella di utilizzare le chiavi Elliptic Curve Digital Signature Algorithm (ECDSA) invece delle tradizionali chiavi RSA. Le chiavi ECDSA sono molto più piccole delle chiavi RSA di forza equivalente e producono firme più piccole rendendo le risposte DNSSEC molto più piccole, riducendo il fattore di amplificazione. Google Public DNS ha aggiunto il supporto per ECDSA alla fine del 2014 e da allora molti altri hanno seguito l'esempio.

Il supporto per il TCP e l'ECDSA è ancora in ritardo rispetto al supporto generale del DNSSEC, pertanto è possibile utilizzare metodi anti-abuso tradizionali. Questo include Resource Rate Limiting (RRL) e altre euristiche.

Per proteggere dagli attacchi di riflessione, Cloudflare sta lavorando a un approccio su più fronti. In primo luogo, utilizzando l'euristica di identificazione degli attacchi e le tecniche anti-abuso che stiamo attualmente utilizzando nel nostro server DNS, e in secondo luogo riducendo il fattore di amplificazione delle risposte DNSSEC. I modi per ridurre il fattore di amplificazione massimo includono la risposta solo alle richieste "ANY" su TCP, l'uso di chiavi ECDSA più piccole quando possibile e la riduzione della frequenza dei rinnovi delle chiavi.

Cloudflare è consapevole della complessità introdotta dal protocollo DNSSEC per quanto riguarda la privacy delle zone, la gestione delle chiavi e il rischio di riflessione/amplificazione. Con decisioni ingegneristiche intelligenti e controlli operativi, è possibile prevenire i pericoli del DNSSEC.