SIDN Labs dicht tsuNAME-kwetsbaarheid in dns

SIDN Labs heeft samen met andere partijen een kwetsbaarheid in dns beschreven waarmee resolvers misbruikt konden worden voor ddos-aanvallen. De onderzoekers hebben de kwetsbaarheid TsuNAME genoemd en een fix beschikbaar gesteld.

TsuNAME doet zich volgens de onderzoekers voor bij misconfiguratie bij resolvers waardoor cyclic dependency oftewel wederzijdse afhankelijkheid kan optreden. In hun rapport geven de onderzoekers als voorbeeld een resolver met name server-gegevens die example.org laten verwijzen naar cat.example.com en example.com naar mouse.example.org. In die situatie kunnen resolvers de ip-adressen bij de name server-gegevens niet ophalen.

Onder omstandigheden kan de verkeerde configuratie een stortvloed aan queries veroorzaken, omdat resolvers dan dns-queries tussen de twee domeinen heen en weer blijven sturen. De onderzoekers beschrijven dat een configuratie-error met wederzijdse afhankelijkheid begin 2020 maakte dat de autoritatieve servers voor het toplevellandendomein van Nieuw-Zeeland 50 procent meer verkeer te verduren kregen: van 800 miljoen naar 1,2 miljard dagelijkse queries. Al die extra queries waren te relateren aan de twee verkeerd geconfigureerde domeinen. Dns gebruikt caching om de autoratieve servers te ontlasten, maar als de resolver de name server-gegevens niet cachet, maakt deze veel vaker contact met de servers.

Een aanvaller kan deze kwetsbaarheid misbruiken om ddos-aanvallen te veroorzaken. Met name oude resolvers zijn kwetsbaar maar ook Googles publieke dns-resolver bleek een bron van herhaalde queries. Google heeft het probleem verholpen en Cisco deed dit ook met OpenDNS. De fix is om code aan resolvers toe te voegen zodat deze cyclic dependency detecteren en een einde kunnen maken aan de queryloops. Beheerders kunnen met behulp van de opensourcesoftware CycleHunter controleren op wederzijdse afhankelijkheden. De kwetsbaarheid werd onderzocht door SIDN Labs, in samenwerking met InternetNZ en het Amerikaanse USC Information Sciences Institute. Die hebben een speciale TsuNAME-pagina opgezet met verdere details.

Reacties (12)

Dus configuratiefouten die zonder overdrijven al decennia bekend zijn en beschreven staan in de RFC komen nog steeds voor, en het wordt nu als vulnerability aangemerkt (met uiteraard een fancy naam zoals dat tegenwoordig blijkbaar moet) dat DNS resolvers hier niet voor compenseren?

Begrijp me niet verkeerd, goed dat ze achter de broek hebben aangezeten van de makers van een aantal veelgebruikte resolvers om een workaround te implementeren (want dat is het detecteren van NS records die naar elkaar wijzen wat mij betreft), maar allemachtig zeg, dit probleem had allang niet meer bestaan als delegaties simpelweg nooit naar een DNS server in een ander domein wijzen, zoals al >15 jaar geleden beschreven is op bijvoorbeeld https://cr.yp.to/djbdns/notes.html#gluelessness.

De werkelijke fix zou zijn dat content ("authoritative") DNS servers het niet meer toestaan om NS records te publiceren die buiten het gedelegeerde domein vallen.

[Reactie gewijzigd door jurjeno op 7 mei 2021 14:55]

Zonder te weten wat de oorzaken zijn is het lastig een oplossing te noemen. Ik kan me bijna niet voorstellen dat er vooral mensen werken die zulke basiskennis niet hebben, vandaar dat ik eerder ook vroeg wat de oorzaken kunnen zijn. Het antwoord is er voorlopig niet, maar kennelijk ook niet het beseft waarom het basiskennis is. Het lijkt er op dat andere zaken meer prioriteit hebben gehad, of mogelijk zelfs nog hebben, dan basisproblemen voorkomen. Terwijl die hele grote gevolgen kunnen hebben.
Ik ben het met je eens dat je een technisch gezien een mogelijke oplossing noemt, maar in de praktijk komt het er bij bedrijven ook op aan of ze genoeg kennis en geld hebben om dat vrijwillig te willen imementeren. Het vrijblijvende lijkt hier mogelijk eerder waar de opoossing in zit dan steeds maar achterafwijzen wat anders kan met een voorbeeld dat het al te laat was. Preventief problemen voorkomen in plaats van achteraf basiskennis toe te gaan passen.

Het is een beetje hetzelfde als broadcast storms hebben in een netwerk omdat iemand een hub (die tegenwoordig nauwelijks nog gebruikt worden) met zichzelf verbindt.

Goed en netjes dat het nu opgelost is.

Bij ons op werk hebben wij vorige jaar allemaal Mitel toestellen gekregen, deze toestellen kosten ruim 200-300 euro P/s.

In deze toestellen zit een soort van bridge/router. Je kan dus doorlussen naar een pc, zodat je maar 1 netwerkkabel vanuit de outlet naar deze werkplek hoeft te hebben.

Laatst was er een medewerker die dacht zelf even wat zaken te kunnen verplaatsten en kreeg het voor elkaar om een loop te creëren (dus 2x netwerk kabel vanuit de outlet erin pluggen). Je zou denken dat zulke dure toestellen wel een loop-bescherming hebben...

Ja, die dure apparaats hebben een prima loop-beveiliging. Goedkope ook, dat heet spanning- tree of shortest-parh-iets-watwashetookalweer. Er is wat voor te zeggen om het aan te zetten, en er is ook wat voor te zeggen om het vooral uit te laten. Dit is een overweging die je moet doen, samen met je collega's, en weloverwogen. Beide opties kunnen gevloek en getier opleveren.

Juist niet: het is een feature dat "enterprise" dingen makkelijk omvallen, anders krijg je dat mensen vragen waarom je zoveel dure uren schrijft voor eenvoudige wijzigingen, of (nog erger) dat ze dingen zelf op gaan lossen.

Geen BPDU filter/guard/whatever-protectie op je Edge poorten? Dat is gewoon een configuratiefout in je netwerk.

[Reactie gewijzigd door WhizzCat op 7 mei 2021 14:11]

Klopt, het bedrijf draait nog op wat oudere software (inmiddels zijn de switches etc vervangen). Echter gaan we straks over naar een nieuw pand met meteen nieuwe switches etc)

Met twee switches kun je ook prima een broadcast storm maken als je die 2 switches met 2 kabels aan elkaar verbind en Shortest Path Bridging en Spanning Tree Protocol uit staan.

Deze aanval is inderdaad een soort van broadcast-storm op DNS niveau en het is goed dat dat aangepakt is. De aanval was echter wel beperkt tot DNS zone beheerders; Deze aanval kun je bijvoorbeeld niet op Tweakers' nameservers richten. Daarvoor dien je beheer te moeten hebben tot een DNS-zone, die onder de Tweakers.net zone hangt.

Nu een cyclic dependency met 1.000.000 doorverwijzingen. Zouden ze dat ook detecteren?

Problemen van cyclische fouten zijn basiskennis bij digitale communicatie. De aanbeveling aan verantwoordelijken voor een van de belangrijkste communicatievoorzieningen van het internet is om hier op te controleren. Dat wekt de suggestie dat die eigenaren de basis niet toepassen. Dat lijkt me zorgelijk. Niet alleen omdat het mogelijk dus ook op andere basiscontrole mogelijk te kort schiet maar ook dat het dus pas ontdekt lijkt te worden als het mis is gegaan. Ik ben benieuwd wat deze bedrijven en andere organisaties voor excuus hebben dat ze dit niet leken te controleren. Was het te weinig kennis, te veel moeite, te weinig geld, inschatting dat het wel mee zou vallen als het zou gebeuren, inschatting dat het niet zou gebeuren?