Een groep onderzoekers van de Universiteit Tel Aviv en het Interdisciplinair Centrum in Herzliya (Israƫl) een nieuwe aanvalsmethode (), die elke DNS-resolver kan gebruiken als verkeersversterker, met een versterkingsratio tot 1621 keer het aantal pakketten (voor elk verzonden verzoek naar de resolver kan 1621 verzoeken naar de slachtofferserver worden verzonden) en tot 163 keer het verkeer.
Het probleem is gerelateerd aan de werking van het protocol en betreft alle DNS-servers die recursieve verwerking van verzoeken ondersteunen, inclusief (CVE-2020-8616), (CVE-2020-12667), (CVE-2020-10995), en (CVE-2020-12662), evenals publieke DNS-diensten van Google, Cloudflare, Amazon, Quad9, ICANN en andere bedrijven. De oplossing voor het probleem werd gecoƶrdineerd met de ontwikkelaars van DNS-servers, die tegelijkertijd updates uitbracht om de kwetsbaarheid in hun producten op te lossen. Beveiliging tegen de aanval is geĆÆmplementeerd in de versies
, , , .
De aanval is gebaseerd op het gebruik van verzoeken door de aanvaller die verwijzen naar een groot aantal voorheen onbekende fictieve NS-records, die verantwoordelijk zijn voor het bepalen van de naam, maar zonder in het antwoord glue-records met informatie over de IP-adressen van de NS-servers te specificeren. Bijvoorbeeld, de aanvaller stuurt een verzoek naar de naam sd1.attacker.com, terwijl hij de DNS-server controleert die verantwoordelijk is voor het domein attacker.com. In antwoord op het verzoek van de resolver aan de DNS-server van de aanvaller, wordt een antwoord gegeven dat het bepalen van het adres sd1.attacker.com aan de DNS-server van het slachtoffer delegeren door NS-records in het antwoord te specificeren zonder details over de IP-NS-servers. Omdat de genoemde NS-server eerder niet is tegengekomen en zijn IP-adres niet is opgegeven, probeert de resolver het IP-adres van de NS-server te bepalen door een verzoek naar de DNS-server van het slachtoffer te sturen die het doelgebied (victim.com) beheert.
Het probleem is dat de aanvaller in het antwoord een enorme lijst van unieke NS-servers met niet-bestaande fictieve subdomeinnamen van het slachtoffer (fake-1.victim.com, fake-2.victim.com,ā¦ fake-1000.victim.com) kan genereren. De resolver zal proberen om een verzoek naar de DNS-server van het slachtoffer te sturen, maar zal als antwoord krijgen dat het domein niet gevonden is, waarna hij de volgende NS-server in de lijst zal proberen, en zo doorgaan totdat hij alle door de aanvaller vermelde NS-records heeft doorlopen. Dit leidt ertoe dat er voor Ć©Ć©n verzoek van de aanvaller een overweldigend aantal verzoeken naar de DNS-hosts wordt gestuurd. Aangezien de namen van de NS-servers willekeurig worden gevormd en verwijzen naar niet-bestaande subdomeinen, worden ze niet uit de cache gehaald en leidt elk verzoek van de aanvaller tot een stortvloed van verzoeken naar de DNS-server die het domein van het slachtoffer bedient.
Onderzoekers hebben de mate van kwetsbaarheid van publieke DNS-resolvers bestudeerd en vastgesteld dat bij het verzenden van verzoeken naar de resolver van CloudFlare (1.1.1.1) een vermenigvuldiging van het aantal pakketten (PAF, Packet Amplification Factor) van 48 keer kan worden bereikt, Google (8.8.8.8) ā 30 keer, FreeDNS (37.235.1.174) ā 50 keer, OpenDNS (208.67.222.222) ā 32 keer. Meer opvallende cijfers worden waargenomen voor
Level3 (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 op basis van BIND 9.12.3 kan door parallelisatie van verzoeken het versterkingsniveau tot 1000 oplopen. In Knot Resolver 5.1.0 is het versterkingsniveau ongeveer enkele tientallen keren (24-48), aangezien de bepaling van NS-namen sequentieel gebeurt en tegen een interne beperking op het aantal name resolution stappen aanloopt die voor Ć©Ć©n verzoek zijn toegestaan.
Er worden twee hoofdstrategieƫn voor bescherming onderscheiden. Voor systemen met DNSSEC gebruikt om cache-aanvallen tegen te gaan, omdat verzoeken worden verzonden met willekeurige namen. De essentie van de methode is het genereren van negatieve antwoorden zonder een beroep te doen op autoritatieve DNS-servers, door gebruik te maken van controle op basis van reeksen via DNSSEC. Een eenvoudigere manier is het beperken van het aantal namen dat kan worden bepaald bij de verwerking van ƩƩn gedelgateerde aanvraag, maar deze methode kan problemen veroorzaken met sommige bestaande configuraties, aangezien de limieten niet in het protocol zijn gedefinieerd.
Bron: opennet.ru
