Recentemente, le informazioni sul identificato 7 vulnerabilità nel pacchetto Dnsmasq, che combina un resolver DNS memorizzato nella cache e un server DHCP, a cui è stato assegnato il nome in codice DNSpooq. Il problemas consentono attacchi falsi alla cache DNS o overflow del buffer ciò potrebbe portare all'esecuzione remota del codice di un utente malintenzionato.
Anche se di recente Dnsmasq non è più utilizzato per impostazione predefinita come risolutore nelle normali distribuzioni Linux, è ancora utilizzato in Android e distribuzioni specializzate come OpenWrt e DD-WRT, oltre a firmware per router wireless di molti produttori. Nelle distribuzioni normali è possibile l'uso implicito di dnsmasq, ad esempio quando si usa libvirt, può essere avviato per fornire il servizio DNS su macchine virtuali oppure può essere attivato modificando le impostazioni nel configuratore di NetworkManager.
Poiché la cultura dell'aggiornamento del router wireless lascia molto a desiderare, I ricercatori temono che i problemi identificati possano rimanere irrisolti per molto tempo e sarà coinvolto in attacchi automatici ai router per ottenere il controllo su di essi o per reindirizzare gli utenti a siti dannosi canaglia.
Ci sono circa 40 aziende basate su Dnsmasq, inclusi Cisco, Comcast, Netgear, Ubiquiti, Siemens, Arista, Technicolor, Aruba, Wind River, Asus, AT&T, D-Link, Huawei, Juniper, Motorola, Synology, Xiaomi, ZTE e Zyxel. Gli utenti di tali dispositivi possono essere avvisati di non utilizzare il normale servizio di reindirizzamento delle query DNS fornito su di essi.
La prima parte delle vulnerabilità scoperto a Dnsmasq si riferisce alla protezione dagli attacchi di avvelenamento della cache DNS, basato su un metodo proposto nel 2008 da Dan Kaminsky.
I problemi identificati rendono inefficace la protezione esistente e consentire lo spoofing dell'indirizzo IP di un dominio arbitrario nella cache. Il metodo di Kaminsky manipola la dimensione trascurabile del campo ID query DNS, che è di soli 16 bit.
Per trovare l'identificatore corretto necessario per falsificare il nome host, è sufficiente inviare circa 7.000 richieste e simulare circa 140.000 risposte false. L'attacco si riduce all'invio di un gran numero di falsi pacchetti legati a IP al resolver DNS con identificatori di transazione DNS diversi.
Le vulnerabilità identificate riducono il livello di entropia a 32 bit dovrebbe essere necessario indovinare 19 bit, il che rende un attacco di avvelenamento della cache abbastanza realistico. Inoltre, la gestione dei record CNAME da parte di dnsmasq consente di falsificare la catena di record CNAME per falsificare in modo efficiente fino a 9 record DNS alla volta.
- 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 si è detto che le vulnerabilità vengono risolte nell'aggiornamento 2.83 di Dnsmasq e come soluzione alternativa, si consiglia di disabilitare DNSSEC e la cache delle query utilizzando le opzioni della riga di comando.
fonte: https://kb.cert.org