Recent, informații despre identificat 7 vulnerabilități în pachetul Dnsmasq, care combină un rezolvator DNS cache și un server DHCP, cărora li s-a atribuit numele de cod DNSpooq. ProblemaPermite atacuri cache DNS DNS sau depășiri de tampon care ar putea duce la executarea de la distanță a codului unui atacator.
Chiar dacă recent Dnsmasq nu mai este utilizat în mod implicit ca rezolvator în distribuțiile Linux obișnuite, este încă utilizat în Android și distribuții specializate precum OpenWrt și DD-WRT, precum și firmware pentru routerele fără fir de la mulți producători. În distribuțiile normale, este posibilă utilizarea implicită a dnsmasq, de exemplu atunci când se utilizează libvirt, poate fi pornit să furnizeze servicii DNS pe mașini virtuale sau poate fi activat prin schimbarea setărilor din configuratorul NetworkManager.
Deoarece cultura de actualizare a routerului fără fir lasă de dorit, Cercetătorii se tem că problemele identificate pot rămâne nerezolvate pentru o lungă perioadă de timp și vor fi implicați în atacuri automate asupra routerelor pentru a obține controlul asupra acestora sau pentru a redirecționa utilizatorii către site-uri rău intenționate.
Există aproximativ 40 de companii cu sediul în Dnsmasq, inclusiv Cisco, Comcast, Netgear, Ubiquiti, Siemens, Arista, Technicolor, Aruba, Wind River, Asus, AT&T, D-Link, Huawei, Juniper, Motorola, Synology, Xiaomi, ZTE și Zyxel. Utilizatorii unor astfel de dispozitive pot fi avertizați să nu folosească serviciul de redirecționare a interogărilor DNS furnizat pe acestea.
Prima parte a vulnerabilităților descoperit în Dnsmasq se referă la protecția împotriva atacurilor de otrăvire a cache-ului DNS, bazat pe o metodă propusă în 2008 de Dan Kaminsky.
Problemele identificate fac ineficiente protecția existentă și permite falsificarea adresei IP a unui domeniu arbitrar în cache. Metoda lui Kaminsky manipulează dimensiunea neglijabilă a câmpului ID de interogare DNS, care este de numai 16 biți.
Pentru a găsi identificatorul corect necesar pentru a falsifica numele gazdei, trebuie doar să trimiteți aproximativ 7.000 de cereri și să simulați aproximativ 140.000 de răspunsuri false. Atacul se reduce la trimiterea unui număr mare de pachete false legate de IP către rezolvatorul DNS cu identificatori de tranzacții DNS diferiți.
Vulnerabilitățile identificate reduc nivelul de entropie pe 32 de biți se așteaptă să fie nevoie să ghicească 19 biți, ceea ce face ca un atac de otrăvire a cache-ului să fie destul de realist. În plus, gestionarea de către dnsmasq a înregistrărilor CNAME îi permite să falsifice lanțul de înregistrări CNAME pentru a falsifica în mod eficient până la 9 înregistrări DNS la un moment dat.
- CVE-2020-25684: lipsa validării ID-ului cererii în combinație cu adresa IP și numărul portului la procesarea răspunsurilor DNS de la servere externe. Acest comportament este incompatibil cu RFC-5452, care necesită atribute suplimentare de solicitare pentru a fi utilizate la potrivirea unui răspuns.
- CVE-2020-25686: Lipsa validării cererilor în așteptare cu același nume, permițând utilizarea metodei zilei de naștere pentru a reduce semnificativ numărul de încercări necesare pentru falsificarea unui răspuns. În combinație cu vulnerabilitatea CVE-2020-25684, această caracteristică poate reduce semnificativ complexitatea atacului.
- CVE-2020-25685: utilizarea algoritmului de hash CRC32 nesigur la verificarea răspunsurilor, în cazul compilării fără DNSSEC (SHA-1 este utilizat cu DNSSEC). Vulnerabilitatea ar putea fi utilizată pentru a reduce semnificativ numărul de încercări, permițându-vă să exploatați domenii care au același hash CRC32 ca domeniul țintă.
- Al doilea set de probleme (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 și CVE-2020-25687) este cauzat de erori care cauzează depășiri ale tamponului atunci când se procesează anumite date externe.
- Pentru vulnerabilitățile CVE-2020-25681 și CVE-2020-25682, este posibil să se creeze exploit-uri care ar putea duce la executarea codului pe sistem.
În cele din urmă se menționează că vulnerabilitățile sunt abordate în actualizarea 2.83 a Dnsmasq și ca soluție, se recomandă dezactivarea DNSSEC și interogarea memorării în cache folosind opțiunile din linia de comandă.
Fuente: https://kb.cert.org