Nieuwe SAD DNS-aanval om valse gegevens in de DNS-cache te plaatsen

Een team van onderzoekers van de Universiteit van Californië, Riverside heeft een nieuwe variant van de SAD DNS-aanval (CVE-2021-20322) gepubliceerd die werkt ondanks de vorig jaar toegevoegde beveiligingen om de CVE-2020-25705-kwetsbaarheid te blokkeren. De nieuwe methode is over het algemeen vergelijkbaar met de kwetsbaarheid van vorig jaar en verschilt alleen in het gebruik van een ander type ICMP-pakketten om actieve UDP-poorten te controleren. De voorgestelde aanval maakt de vervanging van fictieve gegevens in de cache van de DNS-server mogelijk, die kan worden gebruikt om het IP-adres van een willekeurig domein in de cache te vervangen en verzoeken naar het domein door te sturen naar de server van de aanvaller.

De voorgestelde methode werkt alleen in de Linux-netwerkstack vanwege de verbinding met de eigenaardigheden van het ICMP-pakketverwerkingsmechanisme in Linux, dat fungeert als een bron van gegevenslekken die de bepaling vereenvoudigt van het UDP-poortnummer dat door de server wordt gebruikt om een ​​bericht te verzenden. extern verzoek. Wijzigingen die het lekken van informatie blokkeren, zijn eind augustus in de Linux-kernel doorgevoerd (de oplossing was opgenomen in kernel 5.15 en september-updates voor de LTS-takken van de kernel). De oplossing komt neer op het overschakelen naar het gebruik van het SipHash-hashing-algoritme in netwerkcaches in plaats van Jenkins Hash. De status van het oplossen van de kwetsbaarheid in distributies kan worden beoordeeld op deze pagina's: Debian, RHEL, Fedora, SUSE, Ubuntu.

Volgens de onderzoekers die het probleem hebben geïdentificeerd, is ongeveer 38% van de open solvers op het netwerk kwetsbaar, inclusief populaire DNS-services zoals OpenDNS en Quad9 (9.9.9.9). Wat betreft serversoftware kan een aanval worden uitgevoerd door gebruik te maken van pakketten als BIND, Unbound en dnsmasq op een Linux-server. Het probleem doet zich niet voor op DNS-servers die op Windows- en BSD-systemen draaien. Om een ​​aanval succesvol uit te kunnen voeren, is het noodzakelijk om IP-spoofing toe te passen, d.w.z. het is vereist dat de ISP van de aanvaller geen pakketten met een vals bron-IP-adres blokkeert.

Ter herinnering: de SAD DNS-aanval omzeilt de bescherming die aan DNS-servers is toegevoegd om de klassieke DNS-cachevergiftigingsmethode te blokkeren die in 2008 door Dan Kaminsky werd voorgesteld. De methode van Kaminsky manipuleert de kleine omvang van het DNS-query-ID-veld, dat slechts 16 bits bedraagt. Om de juiste DNS-transactie-ID te selecteren die nodig is voor spoofing van de hostnaam, is het voldoende om ongeveer 7000 verzoeken te verzenden en ongeveer 140 fictieve antwoorden te simuleren. De aanval komt erop neer dat een groot aantal pakketten met een fictieve IP-binding en met verschillende DNS-transactie-ID's naar de DNS-resolver worden gestuurd. Om te voorkomen dat het eerste antwoord in de cache wordt opgeslagen, bevat elk dummy-antwoord een enigszins gewijzigde domeinnaam (1.example.com, 2.example.com, 3.example.com, enz.).

Om zich tegen dit soort aanvallen te beschermen, hebben fabrikanten van DNS-servers een willekeurige verdeling geïmplementeerd van het aantal bronnetwerkpoorten van waaruit resolutieverzoeken worden verzonden, wat de onvoldoende grote omvang van de identificatie compenseert. Na het implementeren van bescherming voor het verzenden van een fictief antwoord, werd het, naast het selecteren van een 16-bits identificatie, noodzakelijk om een ​​van de 64 poorten te selecteren, waardoor het aantal selectieopties toenam tot 2^32.

Met de SAD DNS-methode kunt u de bepaling van het netwerkpoortnummer radicaal vereenvoudigen en de aanval terugbrengen tot de klassieke Kaminsky-methode. Een aanvaller kan de toegang tot ongebruikte en actieve UDP-poorten detecteren door gebruik te maken van gelekte informatie over de activiteit van netwerkpoorten bij het verwerken van ICMP-antwoordpakketten. Met deze methode kunnen we het aantal zoekopties met 4 ordes van grootte verminderen: 2^16+2^16 in plaats van 2^32 (131_072 in plaats van 4_294_967_296). Het lekken van informatie waarmee u snel actieve UDP-poorten kunt bepalen, wordt veroorzaakt door een fout in de code voor het verwerken van ICMP-pakketten met fragmentatieverzoeken (vlag ICMP Fragmentation Needed) of omleiding (vlag ICMP Redirect). Het verzenden van dergelijke pakketten verandert de status van de cache in de netwerkstack, waardoor het mogelijk wordt om op basis van de reactie van de server te bepalen welke UDP-poort actief is en welke niet.

Aanvalsscenario: Wanneer een DNS-resolver een domeinnaam probeert om te zetten, verzendt deze een UDP-query naar de DNS-server die het domein bedient. Terwijl de solver op een antwoord wacht, kan een aanvaller snel het bronpoortnummer bepalen dat werd gebruikt om het verzoek te verzenden en er een nepantwoord op sturen, waarbij hij zich voordoet als de DNS-server die het domein bedient met behulp van IP-adresspoofing. De DNS-resolver zal de gegevens die in het nep-antwoord zijn verzonden in de cache opslaan en enige tijd het IP-adres retourneren dat door de aanvaller is vervangen voor alle andere DNS-verzoeken voor de domeinnaam.

Bron: opennet.ru

Voeg een reactie