Že riziko otrávení DNS cache není jen teoretické, jsem se mohl nedávno přesvědčit na vlastní servery. Všechno začalo kolem půlnoci prvního listopadu, kdy dohledový systém začal hlásit přítomnost všech poštovních serverů sdružení CESNET na jednom z DNS blacklistů, konkrétně dnsbl-3.uceprotect.net. Přitom ruční kontrola daného blacklistu žádný problém neobjevila. Podezření padlo na DNS, dohledový systém totiž používá svůj vlastní DNS resolver. Zajímavá byla také IP adresa, kterou blacklist hlásil: 176.107.178.7. To je samo o sobě nezvyklé, black listy pro svojí činnost obvykle používají loopbackové adresy. Vyčištění DNS cache skutečně problém odstranilo, blacklist začal fungovat jako dříve.
Rozhodl jsem se prozkoumat, jaké adresy používá služba www.uceprotect.net. K měření jsem použil distribuovanou síť hardwarových sond RIPE Atlas. Vybral jsem všechny české a slovenské sondy a navíc pět set sond z celého světa. Každou sondu jsem požádal o položení dotazu na IP adresu daného doménového jména prostřednictvím místního resolveru. Měření pod číslem #6917800 je veřejně přístupné. Bohužel, vestavěné vizualizační funkce nedokáží vizualizovat konkrétní obsah DNS odpovědi. Bylo tedy potřeba použít surová data, která měřicí systém zpřístupňuje prostřednictvím API.
Čtrnáct otrávených
Pomocí knihovny Sagan jsem vytvořil jednoduchý skript, který z naměřených dat vyčte číslo sondy, IP adresu a TTL DNS záznamu. Skript vypsal celkem 758 záznamů. 744 sond dostalo jako odpověď správnou IP adresu 217.23.49.178 a TTL menší nebo rovno 3600, tedy jedné hodině. Čtrnáct sond ale dostalo jinou adresu – 176.107.178.7 a hodnota TTL takovýchto záznamů byla výrazně vyšší – až 604800, což odpovídá sedmi dnům. Cache jejich resolverů byly tedy evidentně otráveny stejným způsobem, jako náš dohledový server. Spustil jsem další měření #6919176, kde jsem se zaměřil na těchto čtrnáct otrávených sond. Zajímalo mě, zda mohou mít něco společného.
Poloha sond s otrávenými resolvery
Už jen prostý pohled na mapu ukazuje, že problém měl skutečně globální dosah, postiženy byly sondy v Evropě, na Blízkém východě a dokonce i jedna v Austrálii. Zdá se tedy, že problém je potřeba hledat na straně autoritativních serverů. Dotazem na autoritativní servery nadřazené domény zjistíme, na které servery je doména delegována, včetně příslušných glue záznamů:
$ dig uceprotect.net @a.gtld-servers.net.
…
;; AUTHORITY SECTION:
uceprotect.net. 172800 IN NS ns1.uceprotect.net.
uceprotect.net. 172800 IN NS ns2.uceprotect.net.
uceprotect.net. 172800 IN NS ns3.uceprotect.net.
uceprotect.net. 172800 IN NS ns4.uceprotect.net.
;; ADDITIONAL SECTION:
ns1.uceprotect.net. 172800 IN A 217.23.48.85
ns2.uceprotect.net. 172800 IN A 208.77.218.116
ns3.uceprotect.net. 172800 IN A 67.212.83.77
ns4.uceprotect.net. 172800 IN A 96.43.138.38 Pomocí nástroje RIPEstat lze snadno odhalit, že služba je v tomto případě dostatečně diverzitní, každý server leží v jiné fyzické lokalitě, jiném IP prefixu i jiném autonomním systému.
Útočník mohl ovládnout pouze některý z autoritativních serverů – to by ostatně vysvětlovalo, proč byla infikována pouze část obětí. Útočník také mohl unést pouze master server, což bude nejspíše ten první, umístěný v Německu, a nechat ostatní slave servery přenést zónu.
Únos IP adres je poměrně komplikovaná věc, například kvůli filtrování prefixů při BGP peeringu. Pokud by měl být takový únos účinný globálně, pravděpodobně by byl vidět i v nejrůznějších kolektorech BGP informací, jako už zmíněný RIPEstat. Žádné podezřelé chování se mi ale vypozorovat nepodařilo.
Podezřelé Whois
Další hypotézou, která stojí za prozkoumání, je, že k únosu domény došlo jejím předelegováním přímo v centrálním registru domén. To se nakonec ukazuje jako nejpravděpodobnější varianta. Ve Whois databázi je totiž mimo jiné uvedeno datum poslední změny na 31. října 2016. Při pohledu do historie whois dat jsem pouze objevil delegaci vedoucí do jiné domény lautenschlager.net, která však obsahovala stejná data. Rozhodl jsem se tedy dotázat e-mailem přímo u držitele domény, zda prováděl nějaké změny v poslední době a za jakým účelem.
Záhy dorazila poměrně zmatená odpověď přímo od provozovatele služby, který vystupuje pod jménem Claus von Wolfhausen:
Hi, We are aware that someon seems to have poisened multiple COM, NET, EDU Domains at Internic Rootservers by Monday... Our DNS had the correct Informations and also the datas at our registrar are fine. Registrar told us, theyrecommend to retransmitt our DNS to the Rootservers so we did an Update at Monday .... Since that the Problem should be fixed. If you still expirience problems please delete your DNS-Cache or request your provider to do so. Regards Claus
Zavádějící je zmínka o organizaci interNIC a kořenových serverech; generickou doménu první úrovně .net spravuje společnost Verisign. O jejím napadení by se pravděpodobně už dávno psalo všude. Jako mnohem pravděpodobnější se jeví napadení příslušného registrátora, kterým je v tomto případě společnost PSI-USA, případně nějakého přeprodejce jeho služeb.
Došlo tedy pravděpodobně k dočasné delegaci na jiné IP adresy, která byla záhy vrácena zpět. Resolvery, které v inkriminovanou dobu přistupovaly k datům domény, načetly ze změněných adres falešná data. Dokud bude v jejich cache paměti uložena falešná delegace, budou poskytovat nesprávné odpovědi.
Ostatní si taky všimli
V e-mailové diskuzi spamassasin-users se 2. listopadu objevil příspěvek uživatele, jehož DNS cache byla evidentně otrávena stejným útočníkem. Ve zprávě uvedený výstup příkazu dig dává tušit, kde byly hostovány alternativní servery pro uvedenou doménu. Prostým dotazem je možné zjistit, že dané autoritativní servery stále žijí a vesele poskytují odpovědi s dobou života sedm dnů všem resolverům, jejichž delegace byla otrávena:
$ dig uceprotect.net @176.107.178.7
…
;; ANSWER SECTION:
www.uceprotect.net. 604800 IN A 176.107.178.7
*.uceprotect.net. 604800 IN A 176.107.178.7
uceprotect.net. 604800 IN A 176.107.178.7
ww9.uceprotect.net. 604800 IN A 166.78.101.108 Shodou okolností se nedávno objevilo diskuzní vlákno na fóru Let's Encrypt, kde si tazatel stěžuje, že kvůli problémům s jeho registrátorem si kdosi vystavil certifikát pro tazatelem drženou doménu. Může jít samozřejmě jen o shodu okolností, stejně tak je ale možné, že se brzy dozvíme o nějakém masivním napadení registrátora domén.
Je možné se bránit?
Incident ukazuje, že otrávení cache rekurzivního serveru je reálná hrozba. Tou hlavní technikou, která by podobným incidentům měla zabránit, je DNSSEC. Pokud by byla originální zóna podepsaná, neměl by případný únosce IP adres žádnou šanci injektovat obsah do cache DNS resolverů.
Ani DNSSEC ale není všespásný. Podobně jako TLS garantuje pouze bezpečný přenosový kanál, ale už neříká nic o tom, jak s daty naloží jedna či druhá strana spojení, nedokáže ani DNSSEC ochránit před vektorem útoku spočívajícím v napadení registrátora, nebo dokonce registru. Proti napadení registrátora je však možné se ochránit pomocí zamčení domény na úrovni registru. V případě české domény první úrovně je takové uzamčení možné provést i zrušit snadno a rychle pomocí aplikace doménový prohlížeč, tedy za předpokladu, že jako kontakt držitele domény používáte mojeID a vaše identita byla validována.
Pro situaci, kdy jsou slave servery od master serveru vzdáleny tak výrazně, jako v tomto případu, se rozhodně vyplatí nespoléhat při zónových přenosech pouze na správnou adresu master serveru, ale ochránit přenos zón i kryptograficky, například použitím TSIG podpisů.
Konečně provozovatel kešujícího resolveru může zmírnit případné problémy jednak zapnutím DNSSEC validace, jednak i omezením maximální doby života záznamu v cache. Jen málokterá legitimní služba používá záznamy s životností delší než 24 hodin, je tedy zbytečné podporovat tak extrémní doby, jako celý týden. Zvlášť v případě, kdy je protokol DNS používán pro blacklisty, jejichž odpovědi jsou generovány v reálném čase.
ČLÁNKY DO MAILU