Sårbarheter funnet i Dnsmasq tillatt for spoofing av innhold i DNS-hurtigbufferen

Det ble nylig publisert informasjon om identifiseringen av sju sårbarheter i Dnsmasq-pakken, som kombinerer en DNS-resolver for mellomlagring og en DHCP-server med kodenavnet DNSpooq. Disse problemene muliggjør falske DNS-cache-angrep eller bufferoverløp som kan føre til ekstern kodekjøring av en angriper.

Selv om Dnsmasq nylig har blitt avskrevet som standardresolver i standard Linux-distribusjoner, brukes den fortsatt i Android og spesialiserte distribusjoner som OpenWrt og DD-WRT, samt i fastvaren til mange trådløse rutere. I standarddistribusjoner er implisitt bruk av dnsmasq mulig; for eksempel, når du bruker libvirt, kan den startes for å tilby DNS-tjenester i virtuelle maskiner eller aktiveres ved å endre innstillinger i NetworkManager-konfiguratoren.

Gitt at kulturen med å oppdatere trådløse rutere etterlater mye å være ønsket, frykter forskere at de identifiserte problemene kan forbli uløste i lang tid og bli mål for automatiserte angrep på rutere for å få kontroll over dem eller omdirigere brukere til falske, ondsinnede nettsteder.

Det er omtrent 40 selskaper som er avhengige av DNSmasq , inkludert Cisco, Comcast, Netgear, Ubiquiti, Siemens, Arista, Technicolor, Aruba, Wind River, Asus, AT&T, D-Link, Huawei, Juniper, Motorola, Synology, Xiaomi, ZTE og Zyxel. Brukere av disse enhetene kan bli frarådet å bruke den innebygde DNS-spørrevideringstjenesten.

Den første delen av sårbarhetene som ble oppdaget i Dnsmasq, gjelder beskyttelse mot DNS-cache-forgiftningsangrep, basert på en metode foreslått i 2008 av Dan Kaminsky.

De identifiserte sårbarhetene gjør eksisterende beskyttelse ineffektiv og tillater forfalskning av et vilkårlig domenes IP-adresse i hurtigbufferen. Kaminskys metode manipulerer den ubetydelige størrelsen på DNS-spørringens identifikasjonsfelt, som bare er 16 bits.

For å finne den riktige identifikatoren som trengs for å forfalske vertsnavnet, er det nok å sende omtrent 7.000 forespørsler og simulere rundt 140 000 falske svar. Angrepet koker ned til å sende et stort antall forfalskede IP-koblede pakker til DNS-resolveren med forskjellige DNS-transaksjonsidentifikatorer.

De identifiserte sårbarhetene reduserer det forventede entropinivået fra 32 bits til et 19-bits gjetningskrav, noe som gjør et cache-forgiftningsangrep ganske realistisk. Videre tillater dnsmasqs håndtering av CNAME-poster at den kan forfalske CNAME-poststrengen, og effektivt forfalske opptil ni DNS-poster samtidig.

  • CVE-2020-25684: manglende validering av forespørsel-ID i kombinasjon med IP-adresse og portnummer når du behandler DNS-svar fra eksterne servere. Denne oppførselen er inkompatibel med RFC-5452, som krever at flere forespørselsattributter skal brukes når du samsvarer med et svar.
  • CVE-2020-25686: Mangel på validering av ventende forespørsler med samme navn, slik at bruken av bursdagsmetoden reduserer antall forsøk som kreves for å forfalske et svar betydelig. I kombinasjon med CVE-2020-25684-sårbarheten, kan denne funksjonen redusere angrepets kompleksitet betydelig.
  • CVE-2020-25685: bruk av upålitelig CRC32 hashingalgoritme når du verifiserer svar, i tilfelle kompilering uten DNSSEC (SHA-1 brukes med DNSSEC). Sårbarheten kan brukes til å redusere antall forsøk betydelig ved å tillate deg å utnytte domener som har samme CRC32-hash som måldomenet.
  • Det andre settet med problemer (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 og CVE-2020-25687) er forårsaket av feil som forårsaker bufferoverløp ved behandling av visse eksterne data.
  • For sårbarhetene CVE-2020-25681 og CVE-2020-25682 er det mulig å lage utnyttelser som kan føre til kjøring av kode på systemet.

Til slutt nevnes det at sårbarhetene er adressert i Dnsmasq 2.83-oppdateringen , og som en midlertidig løsning anbefales det å deaktivere DNSSEC og spørrebuffering ved hjelp av kommandolinjealternativer.

Kilde: https://kb.cert.org


Legg til som foretrukket kilde i Google