Tento článek popisuje NXNSAttack, nově objevenou zranitelnost protokolu DNS, která postihuje většinu rekurzivních DNS resolverů. Umožňuje provádět útok dotazováním na náhodné subdomény (random subdomain attack) pomocí delegačního mechanismu DNS, což vede k vysokému zesílení počtu paketů od útočníka směrem k oběti.
Než začneme
Pokud spravujete nějaký DNS resolver, ať už jakékoliv výrobce, prosím aktualizujte ho na nejnovější verzi. (Pokud jste teď zklamaní, že musíte narychlo aktualizovat, zeptejte se svého výrobce na včasná upozornění na bezpečnostní aktualizace.)
Pokud chcete vědět, jak útok funguje a jak před ním můžete příště ochránit své systémy, čtěte dál.
Princip NXNSAttack
Nově objevená zranitelnost zneužívá delegační mechanismus v DNS protokolu k tomu, aby DNS resolvery posílaly velké množství DNS dotazů na autoritativní servery podle přání útočníka. Jak je to možné?
Celý DNS je postaven na principu delegování, kdy autoritativní servery DNS odpovědné za vyšší úrovně hierarchie DNS delegují (můžeme také říci přesměrovávají) dotazy pro domény nižší úrovně na jiné servery, čímž odpadá potřeba mít jednu obrovskou databázi s DNS daty pro celý Internet.
Takto například autoritativní DNS server pojmenovaný „a.gtld-servers.com.“, který odpovídá za doménu „com.“, deleguje dotazy „example.com. A” na jinou sadu serverů:
$ kdig @a.gtld-servers.com example.com A ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10976 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.com. IN A ;; AUTHORITY SECTION: example.com. 172800 IN NS a.iana-servers.net. example.com. 172800 IN NS b.iana-servers.net. ;; From 2001:503:a83e::2:30@53(UDP) in 46.9 ms
Zde vidíme, že i když jsme se dotazovali na „example.com. typ A“, autoritativní server pro doménu „com.“ nám odpověděl delegací pro doménu „example.com.“, která obsahuje názvy dvou jiných autoritativních DNS serverů, ale neobsahuje odpověď na náš původní dotaz.
Jedná se o tzv. „glueless“ delegaci, tj. delegaci, která obsahuje pouze jména autoritativních DNS serverů (a.iana-servers.net. and b.iana-servers.net.), ale neobsahuje jejich IP adresy. DNS resolver samozřejmě nemůže poslat dotaz na „jméno“, takže musí nejprve získat IPv4 nebo IPv6 adresu autoritativního serveru „a.iana-servers.net.“ nebo „b.iana-servers.net.“ a až poté může pokračovat v řešení původního dotazu „example.com. A“.
Tato glueless delegace je základním stavebním kamenem zranitelnosti NXNSAttack: Útočník pošle zpět delegaci s falešnými (náhodnými) jmény serverů směřujícími do DNS domény oběti, čímž nutí resolver, aby generoval dotazy na DNS doménu oběti (v marném pokusu o překlad falešných jmen autoritativních serverů).
Dopad
Hlavním poznatkem studie o NXNSAttack je, že útočníci jsou schopni významně „zesílit“ jeden dotaz na DNS resolver + jednu DNS odpověď s falešnými delegacemi (tj. 2 pakety), a výsledným provozem bombardovat autoritativní servery oběti náhodnými dotazy, přičemž účinně využívají standardní DNS resolver jako zesilovač. V praxi poměr zesílení (packet amplification factor, PAF) záleží zejména na strategii řešení dotazů používané konkrétní implementací DNS resolveru, na který cílí útok. Například:
- Resolver BIND 9.12.3 se snaží získat IPv4 a IPv6 adresy pro všechny autoritativní servery z delegace paralelně, což vede k zesílení 1000x.
- Knot Resolver 5.1.0 překládá jména jmenných serverů jedno po druhém a navíc vynucuje další limity na počet kroků generovaných jediným dotazem klienta, což snižuje zesílení na hodnotu v řádu desítek. Polovina z maximálního zesílení 48x je ve skutečnosti způsobena kódem který se snaží vylepšit kompatibilitu s nestandardně se chovajícími autoritativní servery. Bez hacků pro obcházení nekompatibilit s RFC8020 a RFC7816 by byl PAF Knot Resolveru pouze 24x. (Což je doklad toho, že snažit se řešit problémy jiných implementací je špatný nápad, ale o tom někdy příště.)
Žádná z těchto strategií není sama o sobě špatná; pouze představují různé kompromisy mezi prostředky investovanými do jednotlivého dotazu od klienta vs. paralelního zpracování více klientských dotazů najednou.
Tím, co nakonec rozhodne, která strana bude „obětí“ NXNSAttack, je volná kapacita resolveru a autoritativních serverů, protože jedna ze stran bude přetížena jako první. Dokud bude kapacita dostatečná, budou servery fungovat normálně dál, což může vést k tomu, že jedna ze stran bude prakticky neovlivněna a bez správného monitoringu si útoku ani nemusí všimnout.
NXNSAttack bohužel zneužívá nejzákladnější princip DNS protokolu, což v praxi znamená, že neexistuje žádné skutečné řešení a jsme odkázáni pouze na zmírňování jeho následků.
Vědci naštěstí dodrželi pravidla responsible disclosure (zodpovědného hlášení chyb) a umožnili výrobcům implementovat a vydat verze software se „zmírňujícími opatřeními“ ještě před zveřejněním útoku.
NXNSAttack je zvláštní případ dobře známého útoku dotazováním na náhodné subdomény, takže možnosti obrany spadají do dvou kategorií: Specifické pro NXNSAttack a obecné pro útoky dotazováním na náhodné subdomény.
Zmírnění následků NXNSAttack
Na rozdíl od klasických útoků pomocí dotazů na náhodné subdomény (random subdomain attack) jsou v případě NXNSAttack dotazy generovány samotným resolverem. Tento rozdíl umožňuje výrobcům implementovat jednoduchá zmírňovací opatření, jako je omezení počtu překládaných jmen při zpracování jedné delegace, jednoho dotazu atd.
Zřejmou výhodou této techniky je její jednoduchost, alespoň teoretická.
Nevýhodou technik založených na počítadlech je, že nutí výrobce zavést svévolně stanovené limity, které nejsou založeny na specifikaci protokolu DNS, a v zásadě tím vybrat maximální možné zesílení pro jejich konkrétní implementaci.
Tyto limity ale mohou způsobit potíže u některých domén, a bohužel ne jen teoreticky. Nedávno zveřejněný výzkum odhalil, že 4 % domén druhé úrovně (např. example.com.) má problém v delegování z první úrovně (např. com.), takže jakákoli změna, která přidává limity pro počty pokusů během procesu překládání je riziková a musí být velmi pečlivě zvážena.
V nadcházejících dnech uvidíme, jak byli výrobci úspěšní při určování svých „magických konstant“ a jestli se jim podařilo nerozbít DNS některé z velkých domén.
Univerzální obrana proti útokům náhodnými dotazy
Jakýkoli útok pomocí náhodných dotazů, NXNSAttack nevyjímaje, používá náhodná jména k obejití DNS cache. Z toho vyplývá, že univerzální obrana musí zabránit útočníkům v obcházení cache – a naštěstí již máme technologii, která to dokáže.
Tzv. agresivní použití cache validované pomocí DNSSEC (RFC 8198) využívá „metadata“ DNSSEC ve formě záznamů NSEC(3) a RRSIG ke generování negativních odpovědí bez nutnosti kontaktovat autoritativní servery. Jak to funguje?
Nejprve se podívejme na příklad NSEC záznamů:
$ kdig +dnssec @l.root-servers.net example. ;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 55933 ;; Flags: qr aa rd; QUERY: 1; ANSWER: 0; AUTHORITY: 6; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: do; UDP size: 4096 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; example. IN A ;; AUTHORITY SECTION: events. 86400 IN NSEC exchange. NS DS RRSIG NSEC events. 86400 IN RRSIG NSEC 8 1 86400 20200531170000 20200518160000 48903 . bWcSkQHURJGO... . 86400 IN NSEC aaa. NS SOA RRSIG NSEC DNSKEY . 86400 IN RRSIG NSEC 8 0 86400 20200531170000 20200518160000 48903 . Ru23msHh23... . 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020051801 1800 900 604800 86400 . 86400 IN RRSIG SOA 8 0 86400 20200531170000 20200518160000 48903 . pIolh2KxjZbgtwuePLA4...
Poslali jsme ukázkový DNS dotaz example. A na jeden z kořenových DNS serverů, který nám odpověděl odpovědí NXDOMAIN. Tím nám říká, že požadované jméno neexistuje. Zároveň jsme obdrželi dva důkazy o neexistenci ve formě záznamů NSEC (a jejich DNSSEC podpisy v záznamech RRSIG).
První záznam events. 86400 IN NSEC exchange. NS DS RRSIG NSEC znamená, že kořenová zóna obsahuje doménu events. s typy záznamů NS DS RRSIG NSEC, a co je důležitější, že mezi jmény events. a exchange. nejsou žádné jiné domény.
Druhý záznam . 86400 IN NSEC aaa. NS SOA RRSIG NSEC DNSKEY znamená, že kořenová zóna obsahuje kořen DNS stromu . (překvapení!) s typy záznamů NS SOA RRSIG NSEC DNSKEY, a také že mezi jmény . a aaa. nejsou žádné jiné domény. Tento druhý záznam dokazuje, že neexistuje žádný wildcard záznam *., a proto je NXDOMAIN skutečně správnou odpovědí na dotaz example. A.
Každý ze záznamů v našem příkladu má time-to-live (TTL) specifikované jako 86400 sekund. To umožňuje resolverům syntetizovat odpovědi NXDOMAIN pro všechny dotazy spadající do uvedených rozsahů (. – aaa., events. – exchange.) po celý jeden den, čímž se účinně omezí komunikace s autoritativními servery.
Jedním z důsledků agresivního použití „DNSSEC důkazů“ je, že náhodné dotazy směřované do DNS zóny, která obsahuje N jmen, zaplní cache resolveru důkazy neexistence za zhruba O(N) odpovědí a pak už není potřeba komunikovat s autoritativním serverem. Jinými slovy, náklady na zastavení útoku náhodnými dotazy mezi DNSSEC validujícím resolverem a autoritativními servery na dobu jednoho TTL rostou lineárně s počtem jmen v cílové DNS zóně, bez ohledu na to, kolik paketů pošle útočník. Funguje to překvapivě dobře i pro velké zóny s 1 milionem domén – výmluvné grafy k této technice najdete v mé starší prezentaci (z roku 2018).
Co dál?
Ze všeho nejdříve si aktualizujte své DNS resolvery, abyste NXNSAttack alespoň trochu zmírnili.
Až se situace uklidní, zauvažujte prosím o zabezpečení svých zón pomocí DNSSEC na autoritativních serverech, a také o zapnutí DNSSEC validace na svých na DNS resolverech.
Agresivní použití cache validované pomocí DNSSEC zeslabuje účinek útoků náhodnými dotazy. My v Knot Resolveru už je máme plnou podporu. Částečnou podporu má i Unbound (pouze pro NSEC) a prototyp najdete i v BINDu. Pokud to váš výrobce DNS resolveru ještě nemá naimplementováno, dejte mu vědět, že máte zájem a pomozte zastavit útoky náhodnými dotazy jednou provždy!
Pokud nejste zvyklí komunikovat se svým výrobcem DNS softwaru, prosím vyplňte tento dotazník a my už se postaráme, aby se dozvěděl souhrnné výsledky.
Autorem ikon je Bernar Novalyi z Noun Project.