NXNSAttack angrep som påvirker alle DNS-løsere

En gruppe forskere fra Tel Aviv University og det tverrfaglige senteret i Herzliya (Israel) har utviklet ny angrepsmetode NXNSangrep (PDF), slik at du kan bruke alle DNS-resolvere som trafikkforsterkere, og gir en forsterkningshastighet på opptil 1621 ganger når det gjelder antall pakker (for hver forespørsel sendt til resolveren kan du oppnå 1621 forespørsler som sendes til offerets server) og opptil 163 ganger når det gjelder trafikk.

Problemet er relatert til særegenhetene ved protokollen og påvirker alle DNS-servere som støtter rekursiv spørringsbehandling, inkludert BINDE (CVE-2020-8616) Knute (CVE-2020-12667) PowerDNS (CVE-2020-10995) Windows DNS-server и ubundet (CVE-2020-12662), samt offentlige DNS-tjenester fra Google, Cloudflare, Amazon, Quad9, ICANN og andre selskaper. Reparasjonen ble koordinert med DNS-serverutviklere, som samtidig ga ut oppdateringer for å fikse sårbarheten i produktene deres. Angrepsbeskyttelse implementert i utgivelser
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.

Angrepet er basert på at angriperen bruker forespørsler som refererer til et stort antall tidligere usett fiktive NS-poster, som navnebestemmelse er delegert til, men uten å spesifisere limposter med informasjon om IP-adressene til NS-servere i svaret. For eksempel sender en angriper en spørring for å løse navnet sd1.attacker.com ved å kontrollere DNS-serveren som er ansvarlig for attacker.com-domenet. Som svar på løserens forespørsel til angriperens DNS-server, utstedes et svar som delegerer bestemmelsen av sd1.attacker.com-adressen til offerets DNS-server ved å indikere NS-poster i svaret uten å spesifisere IP NS-serverne. Siden den nevnte NS-serveren ikke har blitt møtt før og dens IP-adresse ikke er spesifisert, prøver resolveren å bestemme IP-adressen til NS-serveren ved å sende en spørring til offerets DNS-server som betjener måldomenet (victim.com).

NXNSAttack angrep som påvirker alle DNS-løsere

Problemet er at angriperen kan svare med en enorm liste over ikke-gjentakende NS-servere med ikke-eksisterende fiktive underdomenenavn for offer (fake-1.victim.com, fake-2.victim.com,... fake-1000. victim.com). Resolveren vil prøve å sende en forespørsel til offerets DNS-server, men vil motta et svar om at domenet ikke ble funnet, hvoretter den vil prøve å finne neste NS-server i listen, og så videre til den har prøvd alle NS-poster oppført av angriperen. Følgelig, for en angripers forespørsel, vil løseren sende et stort antall forespørsler for å bestemme NS-verter. Siden NS-servernavn genereres tilfeldig og refererer til ikke-eksisterende underdomener, hentes de ikke fra hurtigbufferen, og hver forespørsel fra angriperen resulterer i en mengde forespørsler til DNS-serveren som betjener offerets domene.

NXNSAttack angrep som påvirker alle DNS-løsere

Forskere studerte graden av sårbarhet for offentlige DNS-løsere for problemet og slo fast at når du sender forespørsler til CloudFlare-resolveren (1.1.1.1), er det mulig å øke antall pakker (PAF, Packet Amplification Factor) med 48 ganger, Google (8.8.8.8) - 30 ganger, FreeDNS (37.235.1.174) - 50 ganger, OpenDNS (208.67.222.222) - 32 ganger. Mer merkbare indikatorer er observert for
Nivå 3 (209.244.0.3) - 273 ganger, Quad9 (9.9.9.9) - 415 ganger
SafeDNS (195.46.39.39) - 274 ganger, Verisign (64.6.64.6) - 202 ganger,
Ultra (156.154.71.1) - 405 ganger, Comodo Secure (8.26.56.26) - 435 ganger, DNS.Watch (84.200.69.80) - 486 ganger, og Norton ConnectSafe (199.85.126.10 ganger) - 569 ganger. For servere basert på BIND 9.12.3, på grunn av parallellisering av forespørsler, kan forsterkningsnivået nå opp til 1000. I Knot Resolver 5.1.0 er forsterkningsnivået omtrent flere titalls ganger (24-48), siden bestemmelsen av NS-navn utføres sekvensielt og hviler på den interne grensen for antall tillatte navneløsningstrinn for én forespørsel.

Det er to hovedforsvarsstrategier. For systemer med DNSSEC foreslått å bruke RFC-8198 for å hindre omgåelse av DNS-cache fordi forespørsler sendes med tilfeldige navn. Essensen av metoden er å generere negative svar uten å kontakte autoritative DNS-servere, ved å bruke rekkeviddekontroll via DNSSEC. En enklere tilnærming er å begrense antallet navn som kan defineres ved behandling av en enkelt delegert forespørsel, men denne metoden kan forårsake problemer med enkelte eksisterende konfigurasjoner fordi grensene ikke er definert i protokollen.

Kilde: opennet.ru

Legg til en kommentar