Een groep onderzoekers van de Universiteit van Tel Aviv en het Interdisciplinair Centrum in Herzliya (Israël) nieuwe aanvalsmethode (), waardoor u alle DNS-resolvers kunt gebruiken als verkeersversterkers, wat een versterkingssnelheid tot 1621 keer oplevert in termen van het aantal pakketten (voor elk verzoek dat naar de oplosser wordt verzonden, kunt u 1621 verzoeken naar de server van het slachtoffer sturen) en tot 163 keer in termen van verkeer.
Het probleem houdt verband met de eigenaardigheden van het protocol en treft alle DNS-servers die recursieve queryverwerking ondersteunen, inclusief (CVE-2020-8616) (CVE-2020-12667) (CVE-2020-10995) и (CVE-2020-12662), evenals openbare DNS-diensten van Google, Cloudflare, Amazon, Quad9, ICANN en andere bedrijven. De oplossing werd gecoördineerd met DNS-serverontwikkelaars, die tegelijkertijd updates uitbrachten om de kwetsbaarheid in hun producten te verhelpen. Aanvalsbescherming geïmplementeerd in releases
, , , .
De aanval is erop gebaseerd dat de aanvaller verzoeken gebruikt die verwijzen naar een groot aantal niet eerder geziene fictieve NS-records, waaraan de naambepaling is gedelegeerd, maar zonder in de reactie lijmrecords met informatie over de IP-adressen van NS-servers op te geven. Een aanvaller verzendt bijvoorbeeld een query om de naam sd1.attacker.com op te lossen door de DNS-server te controleren die verantwoordelijk is voor het domein aanvaller.com. Als reactie op het verzoek van de solver aan de DNS-server van de aanvaller wordt een antwoord afgegeven dat de bepaling van het sd1.attacker.com-adres delegeert aan de DNS-server van het slachtoffer door NS-records in het antwoord aan te geven zonder de IP NS-servers te specificeren. Omdat de genoemde NS-server nog niet eerder is aangetroffen en het IP-adres ervan niet is opgegeven, probeert de solver het IP-adres van de NS-server te achterhalen door een vraag te sturen naar de DNS-server van het slachtoffer die het doeldomein (victim.com) bedient.
Het probleem is dat de aanvaller kan reageren met een enorme lijst van niet-herhalende NS-servers met niet-bestaande fictieve subdomeinnamen van het slachtoffer (fake-1.victim.com, fake-2.victim.com,... fake-1000. slachtoffer.com). De solver zal proberen een verzoek naar de DNS-server van het slachtoffer te sturen, maar krijgt als antwoord dat het domein niet gevonden is, waarna hij zal proberen de volgende NS-server in de lijst te bepalen, enzovoort, totdat hij alle NS-records vermeld door de aanvaller. Dienovereenkomstig zal de solver voor het verzoek van één aanvaller een groot aantal verzoeken verzenden om NS-hosts te bepalen. Omdat NS-servernamen willekeurig worden gegenereerd en verwijzen naar niet-bestaande subdomeinen, worden ze niet uit de cache opgehaald en resulteert elk verzoek van de aanvaller in een stroom verzoeken aan de DNS-server die het domein van het slachtoffer bedient.
Onderzoekers bestudeerden de mate van kwetsbaarheid van publieke DNS-resolvers voor het probleem en stelden vast dat bij het verzenden van queries naar de CloudFlare-resolver (1.1.1.1) het mogelijk is om het aantal pakketten (PAF, Packet Amplification Factor) met 48 keer te verhogen, Google (8.8.8.8) - 30 keer, FreeDNS (37.235.1.174) - 50 keer, OpenDNS (208.67.222.222) - 32 keer. Er worden meer opvallende indicatoren waargenomen
Niveau 3 (209.244.0.3) - 273 keer, Quad9 (9.9.9.9) - 415 keer
SafeDNS (195.46.39.39) - 274 keer, Verisign (64.6.64.6) - 202 keer,
Ultra (156.154.71.1) - 405 keer, Comodo Secure (8.26.56.26) - 435 keer, DNS.Watch (84.200.69.80) - 486 keer, en Norton ConnectSafe (199.85.126.10) - 569 keer. Voor servers gebaseerd op BIND 9.12.3 kan het versterkingsniveau, vanwege de parallellisatie van verzoeken, oplopen tot 1000. In Knot Resolver 5.1.0 is het versterkingsniveau ongeveer enkele tientallen keren (24-48), sinds de bepaling van NS-namen worden opeenvolgend uitgevoerd en berusten op de interne limiet van het aantal toegestane stappen voor naamomzetting voor één aanvraag.
Er zijn twee belangrijke verdedigingsstrategieën. Voor systemen met DNSSEC te gebruiken om DNS-cache-bypass te voorkomen omdat verzoeken met willekeurige namen worden verzonden. De essentie van de methode is om negatieve reacties te genereren zonder contact op te nemen met gezaghebbende DNS-servers, met behulp van range checking via DNSSEC. Een eenvoudiger aanpak is het beperken van het aantal namen dat kan worden gedefinieerd bij het verwerken van een enkel gedelegeerd verzoek, maar deze methode kan problemen veroorzaken bij sommige bestaande configuraties omdat de limieten niet in het protocol zijn gedefinieerd.
Bron: opennet.ru