Sono state recentemente divulgate informazioni relative all'identificazione di sette vulnerabilità nel pacchetto Dnsmasq, che combina un resolver DNS con caching e un server DHCP, nome in codice DNSpooq. Queste vulnerabilità consentono attacchi di tipo "false cache" DNS o buffer overflow che potrebbero portare all'esecuzione di codice in remoto da parte di un utente malintenzionato.
Sebbene Dnsmasq sia stato recentemente deprecato come resolver predefinito nelle distribuzioni Linux standard, è ancora utilizzato in Android e in distribuzioni specializzate come OpenWrt e DD-WRT, nonché nel firmware di molti router wireless. Nelle distribuzioni standard, è possibile utilizzare dnsmasq in modo implicito; ad esempio, quando si utilizza libvirt, è possibile avviarlo per fornire il servizio DNS nelle macchine virtuali o abilitarlo modificando le impostazioni nel configuratore NetworkManager.
Considerato che la prassi di aggiornare i router wireless lascia molto a desiderare, i ricercatori temono che i problemi individuati possano rimanere irrisolti a lungo e diventare bersaglio di attacchi automatizzati per ottenere il controllo dei router o per reindirizzare gli utenti verso falsi siti dannosi.
Sono circa 40 le aziende che si affidano a Dnsmasq , tra cui Cisco, Comcast, Netgear, Ubiquiti, Siemens, Arista, Technicolor, Aruba, Wind River, Asus, AT&T, D-Link, Huawei, Juniper, Motorola, Synology, Xiaomi, ZTE e Zyxel. Agli utenti di questi dispositivi potrebbe essere sconsigliato l'utilizzo del servizio di inoltro delle query DNS integrato.
La prima parte delle vulnerabilità scoperte in Dnsmasq riguarda la protezione contro gli attacchi di avvelenamento della cache DNS, basata su un metodo proposto nel 2008 da Dan Kaminsky.
Le vulnerabilità identificate rendono inefficace la protezione esistente e consentono lo spoofing dell'indirizzo IP di un dominio arbitrario nella cache. Il metodo di Kaminsky manipola le dimensioni trascurabili del campo di identificazione della query DNS, che è di soli 16 bit.
Per trovare l'identificativo corretto necessario per falsificare il nome host, è sufficiente inviare circa 7.000 richieste e simulare circa 140.000 risposte false. L'attacco consiste essenzialmente nell'inviare un gran numero di pacchetti IP contraffatti al resolver DNS con diversi identificativi di transazione DNS.
Le vulnerabilità identificate riducono il livello di entropia previsto da 32 bit a un requisito di indovinamento di 19 bit, rendendo un attacco di avvelenamento della cache piuttosto realistico. Inoltre, la gestione dei record CNAME da parte di dnsmasq gli consente di falsificare la stringa del record CNAME, contraffacendo in modo efficiente fino a nove record DNS contemporaneamente.
- CVE-2020-25684: mancanza di convalida dell'ID richiesta in combinazione con indirizzo IP e numero di porta durante l'elaborazione delle risposte DNS da server esterni. Questo comportamento non è compatibile con RFC-5452, che richiede l'utilizzo di attributi di richiesta aggiuntivi durante la corrispondenza di una risposta.
- CVE-2020-25686: Mancata convalida delle richieste in sospeso con lo stesso nome, che consente l'uso del metodo del compleanno per ridurre significativamente il numero di tentativi necessari per falsificare una risposta. In combinazione con la vulnerabilità CVE-2020-25684, questa funzione può ridurre in modo significativo la complessità dell'attacco.
- CVE-2020-25685: utilizzo di algoritmo di hashing CRC32 inaffidabile durante la verifica delle risposte, in caso di compilazione senza DNSSEC (SHA-1 è usato con DNSSEC). La vulnerabilità potrebbe essere utilizzata per ridurre in modo significativo il numero di tentativi consentendo di sfruttare i domini che hanno lo stesso hash CRC32 del dominio di destinazione.
- La seconda serie di problemi (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 e CVE-2020-25687) è causata da errori che causano overflow del buffer durante l'elaborazione di determinati dati esterni.
- Per le vulnerabilità CVE-2020-25681 e CVE-2020-25682, è possibile creare exploit che potrebbero portare all'esecuzione di codice sul sistema.
Infine, viene menzionato che le vulnerabilità sono state risolte nell'aggiornamento Dnsmasq 2.83 e, come soluzione temporanea, si consiglia di disabilitare DNSSEC e la memorizzazione nella cache delle query tramite opzioni da riga di comando.
Fonte: https://kb.cert.org