Nel 2008 il ricercatore Dan Kaminsky ha rilevato una particolare vulnerabilità nel funzionamento del sistema di DNS. Questa poteva essere sfruttata per fare un attacco di tipo “cache poisoning“, ovvero -semplificando- che permetta di inserire nelle cache dei vari sistemi DNS risoluzioni errate, rimpiazzando gli IP di servizi ben conosciuti con altri arbitrari, dirottando così il traffico verso siti di facciata, con lo scopo ultimo di carpire dati agli utenti ignari.

La scoperta ha scosso non poco chi forniva questi servizi, perché lo sfruttamento di questa vulnerabilità era basato su un funzionamento intrinseco di queste cache. Per capirlo è necessario esplorare il funzionamento di questi “resolver” di cui internet è pieno: non avendo essi stessi la possibilità di conoscere la risoluzione di tutte le possibili richieste che gli arrivano, quando ad essi giunge una richiesta per un elemento non presente in cache, questi fanno a loro volta richieste DNS ad altri servizi similari, e sono in grado di capire quando la risposta ad una data richiesta è valida (ovvero proviene da un server autoritativo) o meno. Passano l’informazione al client e salvano nella loro cache così da essere più rapidi a future risposte per le medesime richieste.

Seppure questa spiegazione sia estremamente semplificata, rende chiaro come si può sfruttare l’attacco. Questi servizi utilizzano un codice, il “transaction ID” per determinare appunto se il server che ha risposto alla richiesta è autoritativo per la stessa o se si tratta di un impostore. Questo ID numerico è composto da soli 16 bit, il che vuol dire che ci sono solo 65536 possibili ID.

Il ricercatore, ai tempi, ha appunto dimostrato che questa mancaza di entropia ha sempre permesso agli attaccanti di bombardare un server DNS con risposte errate fino a quando questo non prende per autoritativa la risposta. Alla fine, ne servono giusto 65536, numeri che nell’informatica sono irrisori.

La risposta delle varie aziende, organizzazioni ed ISP (le maggiormente colpite da questa cosa) è stata abbastanza semplice: è stata cambiata la porta di default utilizzata per rispondere alle query, dalla buon vecchia 53/udp ad una porta randomica scelta da un range possibile di porte UDP. Combinando questi 16 bit di entropia del transaction ID con altri 16 bit dati dalla randomizzazione delle porte, le nuove possibili 134 milioni di combinazioni sono semplicemente matematicamente poco sfruttabili. Problema risolto, tutti felici.

Pare invece di no, perchè partendo da quella ricerca alcuni ricercatori dell’Università della California hanno trovato un metodo alternativo per dedurre sia il transaction ID che la porta randomizzata, sfruttando una tecnica chiamata “side channel” ovvero l’analisi di una data implementazione invece che la forzatura delle specifiche su cui essa è stata sviluppata.

Il documento rilasciato, estremamente dettagliato, non solo spiega come può avvenire questo “avvelenamento” delle cache, ma mostra anche che l’impatto dello stesso è estremamente ampio, andando a funzionare su una grande varietà di software DNS, tra cui gli stessi BIND, Unbound e dnsmasq (sicuramente tra i più famosi).

In this paper, we conduct an analysis of the previously overlooked attack surface, and are able to uncover even stronger side channels that have existed for over a decade in Linux kernels […] The side channels affect not only Linux but also a wide range of DNS software running on top of it, including BIND, Unbound and dnsmasq. We also find about 38% of open resolvers and 14% of others are vulnerable including the popular DNS services such as OpenDNS and Quad9.

In questo articolo, abbiamo condotto analisi delle superfici di attacco precedentemente coperte, e siamo stati in grado di scopire metodi ancora più forti che esistono da più di un decennio nei kernel Linux […] Questi metodi non affliggono solo Linux ma anche un ampia gamma di software DNS in esecuzione su di esso, inclusi BIND, Unbound e dnsmasq. Abbiamo anche rilevato che circa il 38% dei risolutori pubblici ed il 14% degli altri sono vulnerabili, inclusi servizi DNS molto popolari come OpenDNS e Quad9.

Ma quale è il problema questa volta? Beh, il problema pare sia come Linux risponde ai pacchetti ICMP, i vecchi e cari ping:

We find that the handling of ICMP messages in Linux uses shared resources in a predictable manner such that it can be leveraged as a side channel […] This allows the attacker to infer the ephemeral port number of a DNS query, and ultimately lead to DNS cache poisoning attacks. It is a serious flaw as Linux is most widely used to host DNS resolvers.

Abbiamo trovato che la gestione dei messaggi ICMP in Linux utilizza delle risorse condivise in maniera prevedibile al punto che può essere utilizzato come metodo alternativo […] Questo permette all’attaccante di determinare il numero di porta effimero di una query DNS, ed infine portare l’attacco al DNS. Questo è una vulnerabilità molto critica poichè Linux è il sistema più utilizzato per erogare risolutori DNS.

Fortunatamente esistono già delle compensative, come impostare specifiche flag nel kernel al fine di ignorare questo tipo di messaggi ICMP, randomizzare la struttura di caching o rifiutare i pacchetti di quel protocollo in toto, ma ovviamente son tutte cose che vanno applicate.

È ora di correre ai ripari!

Matteo Cappadonna

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.