5 ZVEŘEJNĚNÍ ZÁVAŽNÉ BEZPEČNOSTNÍ SLABINY V DNS

část 2, díl 5, str. 1

BEZPEČNÁ POČÍTAČOVÁ SÍŤ

díl 5, Zveřejnění závažné bezpečnostní slabiny v DNS

2/5 ZVEŘEJNĚNÍ ZÁVAŽNÉ BEZPEČNOSTNÍ SLABINY V DNS V minulém dílu aktualit jsme psali o DNS cache-poisoning útocích a oznámení Dana Kaminského, že nalezl chybu, která umožňuje provést takový útok ve většině používaných DNS serverů mnohem snadněji, než si dosud všichni mysleli, a že tato chyba souvisí se samotnou podstatou DNS protokolu.

Nový přístup ke cachepoisoningu

Dnešní článek je o něco více techničtější, uvádí potíže, které je nutné překonat při praktické realizaci útoku, okolnosti, za kterých došlo ke zveřejnění útoku, jaká je časová náročnost provedení takového útoku. Dan Kaminsky nezveřejnil žádné detaily nalezené chyby, pouze oznámil, že popis útoku bude součástí jeho prezentace na konferenci Black Hat. Kaminsky je známý tím, že dokáže své prezentace dobře prodat a často okolo nich dělá velkolepou reklamu. Mnoho odborníků si proto myslelo, že ve skutečnosti nepůjde o nic revolučního, pouze o nějaký nový trik. Kamin-

Plán zveřejnění útoku

listopad 2008




sky požádal odbornou veřejnost, aby se před zveřejněním vyvarovala spekulací o podstatě této chyby. Předčasné zveřejnění útoku

Tato žádost ale vyprovokovala studenta, který se do té doby DNS nijak nevěnoval, aby si proložil přípravu na zkoušku občasným čtením začátečnického textu DNS for dummies. Student, publikující jako Halvar Flake, popsal svůj nápad jak podvrhnout falešnou informaci do cache DNS serveru. Ve svém návrhu byl poměrně naivní, ale použil nečekaný způsob, jak obejít jednu z překážek při podvržení falešných údajů do cache serveru. Jeho nápadu se chytli znalci DNS, a za několik hodin koloval na internetu první vzorový kód pro přepsání DNS cache během několika sekund.

Za revolučním nápadem nemusí být znalec

Na příběhu zveřejnění této chyby je nejzajímavější, že s originální myšlenou přišel člověk, který se DNS protokolem profesionálně nezabývá, po přečtení začátečnického textu o principech DNS. Právě svou jednoduchostí se tato chyba podobá dalším, „na první pohled zřejmým“ útokům na internetové protokoly, které vedly k jejich postupnému vývoji do dnešní podoby.

Úloha TTL při ukládání DNS záznamů

V minulém díle aktualit byl popsán princip útoku typu cache-poisoning a použití identifikačních čísel (DNS ID) dotazů pro obranu proti němu. Podvrhnutí správného DNS ID však není jediný problém, se kterým se musí útočník potýkat. Každý DNS záznam obsahuje položku TTL (time to live), která udává dobu platnosti záznamu v cache jednotlivých serverů. Tato hodnota bývá obvykle ve dnech nebo i týdnech. Útočník může do cache serveru podvrhnout jen takové záznamy, které v ní zatím nejsou. Pro podvržení často dotazovaných a tím i pro útočníka zajímavých záznamů je tak k dispozici poměrně úzké časové okno.

listopad 2008




Flake přišel s postupem, který zajišťuje, že není třeba čekat na vypršení TTL, ale je možné přepsat záznam kdykoli. Jeho postup je založen na myšlence odesílání dotazů na jiné domény, než je doména, která je cílem útoku. Tyto jiné domény, třeba složené z náhodných znaků doplněných pořadovým číslem (abhdj001.cz, abchdj002.cz...), nemá téměř jistě napadený server ve své cache a jejich úspěšné podvržení je jen otázkou času. Druhá Flakeova myšlenka spočívala v tom, co by měla obsahovat podvržená odpověď. Flake navrhoval podvržení záznamu pro DNS server oběti (např. google.com) s adresou útočníka. Napadený server by při příštím dotazu na doménu oběti (např. www.google.com) kontaktoval server útočníka, který by mohl tazatele přesměrovat na libovolnou IP adresu.

Flakeův útok a jeho nedostatky

Druhá část Flakeovy myšlenky je nepoužitelná, protože dnešní DNS servery provádějí při příjmu odpovědi kontrolu zvanou „bailiwick checking“. Tuto kontrolu provádí dotazující se DNS server a spočívá v tom, že z dotazovaného serveru přijme jen takovou odpověď, za kterou je dotazovaný server zodpovědný (bailiwick = je jeho písečkem). Tyto kontroly jsou v DNS serverech už řadu let, ale začátečnický text, z nějž Flake čerpal, takovéto detaily nezmiňuje.

Ochrana pomocí bailiwick checking

Kaminsky pro podstrčení falešné informace zvolil jiný způsob, který dovoluje do odpovědi uvést adresu DNS serveru, a to pomocí tzv. glue záznamu. Tento druh DNS záznamů slouží pro urychlení některých operací s DNS a pro řešení některých dalších případů.

Úloha glue záznamů v DNS

Například bez glue záznamu není možné řešit situaci, kdy správce domény dom.cz pojmenuje její doménový server ns.dom.cz. Při pokusu o nalezení záznamu pro www.dom.cz je na server pro doménu cz zaslána žálistopad 2008




dost o zjištění jména doménového serveru domény dom.cz. Server dodá jméno - ns.dom.cz. Pro zkontaktování serveru je ale nutné znát jeho IP adresu, která je uvedena v DNS záznamu pro doménu dom.cz, a tyto záznamy jsou uloženy na serveru ns.dom.cz... Vzniká nekonečná smyčka, obdoba situace: „Jaké má Jirka číslo? Nevím, zavolej mu a zeptej se.“ Na jeden DNS dotaz může být více odpovědí

Vytvoření takové smyčky je možné zabránit pomocí glue záznamu. Glue záznam je záznam obsahující IP adresu doménového serveru a bývá uváděn na stejném serveru, na kterém je veden záznam o doménovém serveru. V odpovědi na dotaz jsou potom odesílány dva druhy záznamů - jeden je jménem doménového serveru a druhý s jeho IP adresou. Odeslat v rámci odpovědi na dotaz více záznamů je běžná praxe, jejímž cílem je snížit vytížení DNS serveru. Odpovědi na DNS dotazy bývají krátké, a proto není problém je rozšířit o další záznamy, které má odpovídající server o dotazované doméně, a rovnou tak odpovědět na další dotazy, jenž by mohl tazatel poslat. Mezi přidávané informace patří informace o autoritativním serveru pro doménu a pak různé další, kam paří popsané glue záznamy.

Kaminského útok příklad

Kaminsky použil pro svůj útok kombinaci výše uvedených technik. Následující příklad shrnuje postup, jak by probíhal útok, při kterém by útočník přesvědčil doménový server poskytovatele internetového připojení ns.provider.cz, že bankovní server www.banka.cz nemá IP adresu 1.1.1.1, ale 2.2.2.2. Uživatelé tohoto providera by se místo ke své bance připojovali na stránky útočníka. 1. Útočník zasílá na server ns.provider.cz postupně dotazy na jména: blabol001.banka.cz, blabol002.banka.cz.

listopad 2008




2a. Útočník zasílá na server ns.provider.cz odpovědi na své dotazy. Odpovědí zasílá vždy několik s různým DNS ID. Odpovědí nemusí být mnoho, protože útočník nemusí uspět hned napoprvé, může si vymyslet libovolný počet jmen, na která se bude ptát. Odpovědi obsahují záznam se jménem NS serveru pro doménu banka.cz a glue záznam uvádějící, že IP tohoto serveru je 2.2.2.2. 2b. Souběžně posílá odpovědi na dotazy i doménový server banky. Jakmile jednou útočník trefí DNS ID a pošle svou odpověď dříve než doménový server banky, přestanou dotazy z ns.provieder.cz chodit. 3. Server ns.provider.cz začne přeposílat dotazy pro doménu banka.cz na podvrženou IP adresu 2.2.2.2. Podle Kaminského výsledků je možné provést takový útok za několik sekund. Navrhovaná obrana zmiňovaná už v minulém článku spočívající v randomizaci zdrojového portu tento útok značně znesnadňuje a prodlužuje. V laboratorních podmínkách na lokální síti se ho podařilo provést za 10 hodin. Pro rychlé připojení k internetu s kapacitou okolo 50 Mb za sekundu je po útoku trvajícím dvacet čtyři hodin odhadována pravděpodobnost úspěšného podvržení informace na zhruba šedesát pět procent. Při takovém útoku by bylo nutné odeslat téměř půl terabajtu dat, což je množství dat, které by na cílovém serveru pravděpodobně neuniklo pozornosti.

Proveditelnost a obrana

Útok tohoto typu je možné vést nejen na servery, které jsou přímo dostupné z internetu, ale i na servery ukryté ve vnitřních sítích. Tyto servery je možné ovlivnit pomocí stránek, po kterých brouzdají uživatelé vnitřní

Rizika a proveditelnost v lokální síti

listopad 2008




sítě. Ale mnohem praktičtější může být útok na tyto servery prostřednictvím poštovního systému, kdy DNS adresy v obálce emailu ověřuje server sám přímo a nebo prostřednictvím antispamových a antivirových řešení. Dalším rizikem pro lokální sítě je používání překladu IP adres a portů (NAT). Použití randomizace zdrojového portu zvyšuje náročnost tohoto útoku typu cache-poisoning tím, že je nutné zkoušet různé hodnoty DNS ID v kombinaci s číslem odchozího portu. Čísel odchozích portů může být řádově šedesát pět tisíc, ale v kombinaci s překladem IP adres často dochází k omezení tohoto rozsahu na pouhých několik tisíc možností.

listopad 2008

5 ZVEŘEJNĚNÍ ZÁVAŽNÉ BEZPEČNOSTNÍ SLABINY V DNS

Recommend Documents