NXNSAttack-angreb, der påvirker alle DNS-resolvere

En gruppe forskere fra Tel Aviv University og det tværfaglige center i Herzliya (Israel) har udviklet ny angrebsmetode NXNSangreb (PDF), hvilket giver dig mulighed for at bruge alle DNS-resolvere som trafikforstærkere, hvilket giver en forstærkningshastighed på op til 1621 gange i forhold til antallet af pakker (for hver anmodning, der sendes til resolveren, kan du opnå, at 1621 anmodninger sendes til offerets server) og op til 163 gange i forhold til trafik.

Problemet er relateret til protokollens særegenheder og påvirker alle DNS-servere, der understøtter rekursiv forespørgselsbehandling, herunder BINDE (CVE-2020-8616) Knude (CVE-2020-12667) PowerDNS (CVE-2020-10995) Windows DNS-server и Ubundet (CVE-2020-12662), såvel som offentlige DNS-tjenester fra Google, Cloudflare, Amazon, Quad9, ICANN og andre virksomheder. Rettelsen blev koordineret med DNS-serverudviklere, som samtidig udgav opdateringer for at rette op på sårbarheden i deres produkter. Angrebsbeskyttelse implementeret i udgivelser
Ubundet 1.10.1, Knot Resolver 5.1.1, PowerDNS Recursor 4.3.1, 4.2.2, 4.1.16, BIND 9.11.19, 9.14.12, 9.16.3.

Angrebet er baseret på, at angriberen bruger anmodninger, der refererer til et stort antal hidtil usete fiktive NS-poster, hvortil navnebestemmelse er delegeret, men uden at specificere limrecords med information om IP-adresserne på NS-servere i svaret. For eksempel sender en angriber en forespørgsel for at løse navnet sd1.attacker.com ved at kontrollere den DNS-server, der er ansvarlig for domænet attacker.com. Som svar på resolverens anmodning til angriberens DNS-server udsendes et svar, der delegerer bestemmelsen af ​​sd1.attacker.com-adressen til offerets DNS-server ved at angive NS-poster i svaret uden at angive IP NS-serverne. Da den nævnte NS-server ikke er stødt på før, og dens IP-adresse ikke er angivet, forsøger resolveren at bestemme IP-adressen på NS-serveren ved at sende en forespørgsel til offerets DNS-server, der betjener måldomænet (victim.com).

NXNSAttack-angreb, der påvirker alle DNS-resolvere

Problemet er, at angriberen kan reagere med en enorm liste over ikke-gentagende NS-servere med ikke-eksisterende fiktive underdomænenavne for offer (fake-1.victim.com, fake-2.victim.com,... fake-1000. victim.com). Resolveren vil forsøge at sende en anmodning til offerets DNS-server, men vil modtage et svar om, at domænet ikke blev fundet, hvorefter den vil forsøge at bestemme den næste NS-server på listen, og så videre, indtil den har prøvet alle de NS-poster opført af angriberen. Følgelig vil resolveren for én angribers anmodning sende et stort antal anmodninger for at bestemme NS-værter. Da NS-servernavne genereres tilfældigt og refererer til ikke-eksisterende underdomæner, hentes de ikke fra cachen, og hver anmodning fra angriberen resulterer i en byge af anmodninger til DNS-serveren, der betjener offerets domæne.

NXNSAttack-angreb, der påvirker alle DNS-resolvere

Forskere undersøgte graden af ​​offentlige DNS-resolveres sårbarhed over for problemet og fastslog, at når man sender forespørgsler til CloudFlare-resolveren (1.1.1.1), er det muligt at øge antallet af pakker (PAF, Packet Amplification Factor) med 48 gange, Google (8.8.8.8) - 30 gange, FreeDNS (37.235.1.174) - 50 gange, OpenDNS (208.67.222.222) - 32 gange. Mere mærkbare indikatorer observeres for
Level3 (209.244.0.3) - 273 gange, Quad9 (9.9.9.9) - 415 gange
SafeDNS (195.46.39.39) - 274 gange, Verisign (64.6.64.6) - 202 gange,
Ultra (156.154.71.1) - 405 gange, Comodo Secure (8.26.56.26) - 435 gange, DNS.Watch (84.200.69.80) - 486 gange, og Norton ConnectSafe (199.85.126.10 gange) - 569 gange. For servere baseret på BIND 9.12.3 kan forstærkningsniveauet på grund af parallelisering af anmodninger nå op til 1000. I Knot Resolver 5.1.0 er forstærkningsniveauet cirka flere titusinder (24-48), da bestemmelsen af NS-navne udføres sekventielt og hviler på den interne grænse for antallet af navneopløsningstrin, der er tilladt for en anmodning.

Der er to hovedforsvarsstrategier. Til systemer med DNSSEC foreslog at bruge RFC-8198 for at forhindre omgåelse af DNS-cache, fordi anmodninger sendes med tilfældige navne. Essensen af ​​metoden er at generere negative svar uden at kontakte autoritative DNS-servere ved hjælp af rækkeviddekontrol via DNSSEC. En enklere tilgang er at begrænse antallet af navne, der kan defineres, når en enkelt delegeret anmodning behandles, men denne metode kan forårsage problemer med nogle eksisterende konfigurationer, fordi grænserne ikke er defineret i protokollen.

Kilde: opennet.ru

Tilføj en kommentar