Attacken, som sannolikt ännu inte utnyttjats i verkligheten, kan vara svår att hantera eftersom den utnyttjar funktioner i dns som är fullt legitima – det är inget fel på dns på det sätt som vore fallet om det fanns en sårbarhet eller bugg i en mjukvara. Därför finns det heller ingen egentlig fix i form av uppdateringar till olika dns-servrar, men det finns konfigurationsåtgärder administratörer av dns-system kan ta till för att motverka attacken, eller dämpa effekten av en attack.
– Om man har en egen dns-infrastruktur så ska den uppdateras, till exempel BIND CVE-2020-8616, eller konfigureras, till exempel Windows ADV200009, för att minimera risken. Om man har dns som tjänst behöver man säkerställa att dns-leverantören vidtagit nödvändiga åtgärder, säger Thomas Nilsson, vd på it-säkerhetsföretaget Certezza.
Attack som funnits ganska länge
NXNSAttack är en klassisk förstärkningsattack, vilket betyder att den får en dns-server att skicka många förfrågningar mot en viss måltavla bara utifrån att ta emot en eller några få förfrågningar från angriparen. NXNSAttack är ett specialfall av denna typ av attack som funnits ganska länge, och brukar kallas ”random subdomain attack”.
– Det är till stor del en teoretisk situation som beskrivs, men om det inträffar så blir effekten stor. Det går att göra alla möjliga konstiga saker i alla möjliga protokoll på internet om man konfigurerat servrar och klienter fel, eller implementerat saker fel. Även denna gång, säger Patrik Fältström, säkerhetsansvarig på internetknutpunkten Netnod.
NXNS-attacken utnyttjar så kallad ”glueless delegation”, det vill säga en delegering som enbart innehåller den delegerade serverns namn, men inte dess ip-adress. Till exempel kan en förfrågan till servern för .se om domänen idg.se returnera namnet på servern som ansvarar för idg.se men inte ipadressen till servern. För en resolver-server räcker inte den informationen utan den behöver då fråga om ip-adressen, och skickar frågan till ansvarande server för idg.se.
Attacken förutsätter att angriparen har tillgång till minst en dns-klient och en domän-server som svarar på förfrågningar med en stor volym hänvisningar, utan ”glue records”, till offrets subdomäner. Angriparens server svarar med hänvisningar, eller delegeringar, med falska slumpmässiga servernamn som pekar på offrets domän, vilket tvingar offrets resolver att skicka frågor till offrets auktoritativa dns-server.
Skapar en förstärkningseffekt
Offrets resolver kan på detta sätt generera en hel del trafik mot den auktoritativa servern i sina fruktlösa försök att hitta ip-adresserna till de falska sub-domänerna. Effekten är att angriparen skapar en förstärkningseffekt i offrets system, men som också beror på hur offrets dns-system är konfigurerat och vilken resolver offret använder.
För Bind kan effekten bli en förstärkning på över 1 000 gånger, medan Knot bara förstärker med upp till 48 gånger. I bägge fallen räcker det att angriparen skickar två paket. Det finns inga uppgifter om effekten för Microsofts dns-server, men Microsoft har gått ut med rekommendationer för hur attacken ska motverkas för deras del. Vilken del av offrets system som går ned först, alltså resolvern eller den auktoritativa servern, beror på respektive servers kapacitet. Räcker kapaciteten till kommer servrarna helt enkelt att fortsätta svara.
– Förstärkningsfaktorn på upp till 1 600 gånger är ovanlig, det vill säga att en enda förfrågan kan resultera i upp till 1 600 paket mellan resolvern och den auktoritativa servern. Men precis som med alla andra sårbarheter så är det ett antal förutsättningar som krävs för att få den effekten. Det krävs också ett visst hantverk för att kunna rikta belastningsattacken mot ett önskat mål, säger Thomas Nilsson.
Tyvärr utnyttjar NXNSAttack grundläggande delar av dns-protokollet, vilket betyder att det inte finns direkta fixar som systemägare kan installera för att skydda sig. Men det finns motåtgärder i form av konfigurationer och implementationer av säkerhetsprotokoll som effektivt motverkar denna typ av attacker. De israeliska forskarna har också väntat med sitt avslöjande tills leverantörerna av dns-system har hunnit komma ut med rekommendationer. Den enklaste åtgärden är att implementera ”rate limiting” som begränsar antalet namn som kan slås upp per delegering.
Begränsning även i resolvern
Att begränsa antalet uppslag per förfrågan har dock sina risker, och det gäller att veta vad man gör och testa sig fram till bästa resultat. Det viktiga i detta sammanhang är att begränsningen ska ske även i resolvern och inte bara i den auktoritativa servern.
– Rate limiting kan störa. Man måste helt enkelt veta vad man gör, precis som när man kör egen mailserver, eller webbserver eller ntp-server et cetera. Det var länge sedan dns var “fire and forget”, säger Patrik Fältström.
Både Patrik Fältström och Thomas Nilsson vill dock poängtera att att risken med NXNSAttack inte ska överdrivas. Dns-systemet för ett företag eller organisation riskerar inte att kollapsa av en attack, om det ens utförs någon attack, om man inte gjort fruktansvärt fel.
– Ur perspektivet att det finns enklare sätt att göra belastningsattacker så kanske just detta hantverk inte är den självklara vägen fram för att skada någon. Noterbart är att det inte är en sårbarhet i dess rätt element som bara lagas med en rättning, utan vägen fram är att begränsa hur dns hanterar den här typen av anrop för att minimera den skadliga effekten, säger Thomas Nilsson.
Tillämpa de protokoll som redan finns
Patrik Fältströms rekommendationer till oroade systemägare är att införa ”rate limiting” även på resolvern, om det inte redan är infört, men också att tillämpa och implementera de säkerhetsprotokoll som finns, och som kraftigt begränsar möjligheterna för angripare att utföra inte bara den här typen av attack, utan att attacker mot dns generellt.
– Det är delvis gamla vanliga saker som gäller. Se till dina zoner är signerade och om du kör en resolver själv, vilket man precis som alla tjänster enbart bör göra om man anser sig kunna göra det, bör du dessutom se till att hålla programvara uppgraderad och uppdatera konfigurationen i samband med uppgradering, så nya ”features” används, säger Patrik Fältström.
– Du ska också se till att validera DNSSEC-signerade svar, och se över vilka som kan skicka frågor till din resolver. Använd rate limiting, det vill säga inte bara i auktoritativ server. Om man implementerat DNSSEC och DANE minskar man risken generellt för attacker mot dns, eftersom saker som inte valideras kastas utan att man svarar, säger Patrik Fältström.