Vlákno názorů k článku Dan Kaminsky a jeho útok na DNS servery od Leoš Bitto - Na http://www.doxpara.com/?p=1215#comments jsem zkoušel navrhnout co mě napadlo...
-
Leoš Bitto (neregistrovaný)Na http://www.doxpara.com/?p=1215#comments jsem zkoušel navrhnout co mě napadlo pro zvýšení zabezpečení nameserveru, zatím mi připadá že by to mohlo fungovat. V podstatě jde o to, že pokud se nameserveru v odpovědi na jeho dotaz vrátí něco, co je v rozporu s údaji, které má v cache, prostě se zeptá znovu. To, že by útočník dokázal podvrhnout dvě odpovědi za sebou, má už značně nižší pravděpodobnost.
-
Bohužel to by nefungovalo. Různé cache a CDN můžou vracet na každý dotaz jinou IP adresu. (Úplně nejjednodušší případ je překročení velikosti paketu bez použití EDNS0) A co pak? Čemu důvěřovat?
Jinak na diskuzi nad dns protokolem je mnohem lepší diskutovat to konferenci namedroppers @ ietf (pracovní skupina dnsext). A dobré je si přečíst archív než člověk něco napíše. -
Leoš Bitto (neregistrovaný)Pak by se dalo preventivně více důvěřovat své cache než obsahu první či druhé odpovědi. Když už se mi ta data do cache dostala, tak jsou dvě možnosti: buď je někdo chce často měnit, tak jim dá malé TTL. Pak by nemělo vadit že si je chvilku podržím (do konce TTL) a nenechám přepsat. Nebo je nechce často měnit, pak jim dá velké TTL, a zase by nemělo vadit pokud si je podržím v cache až do konce. Prostě připadá mi že přepisování záznamů v cache před koncem jejich TTL je příliš nebezpečné - dává zbytečně vyšší šanci útočníkům. namedroppers @ ietf neznám, a číst preventivně všechny archivy nezvládám. :-)
-
Tak ještě jeden příklad:
od TLD serveru dostanu v AUTHORITATIVE/ADDITIONAL nějakou IP adresu autoritativního serveru. Ale autoritativní server vrací IP adresu jinou (nebo více třeba kromě A vrací i AAAA záznam). Co je pak správně?
Jistě přepisování nebezpečné je. Ale tak nějak to reflektuje současný stav DNS dat...
Není potřeba číst všechny archívy... stačí tak posledních čtrnáct dní... ale jestli budu mít dobrou náladu a trochu času tak do CZ.NICového blogu zkusím udělat takový výcuc návrhů, které jsem za ten poslední měsíc viděl, a jejich výhody a nevýhody. -
Leoš Bitto (neregistrovaný)To co teď píšeš mému řešení vůbec nevadí. Já jsem navrhoval poslat znovu ten samý dotaz (pouze s jiným TRXID a případně z jiného čísla portu) tomu samému serveru. Pokud mi ten samý server na druhý stejný dotaz vrátí jinou odpověď, pak teprve bych to považoval za útok. Pokud vrátí podruhé stejnou odpověď jako poprvé, už bych jí věřil - nepředpokládám že se v součanosti publikovanými informacemi se podaří útočníkovi trefit dvě odpovědi (jak bylo prezentováno např. na http://tservice.net.ru/~s0mbre/blog/devel/networking/dns/2008_08_08.html jednu odpověď trefit může).
Pokud dojde k té nekonzistenci kterou zmiňuješ, může se stávat, že budu duplikovat dotazy - pokud se budu střídavě ptát TLD nameserveru a autoritativního nameserveru. Ale proč bych se takhle hloupě ptal střídavě TLD nameserveru a autoritativního nameserveru, když už mám data v cache? Takže zase tak moc často moje navrhované řešení duplikované dotazy posílat nebude. -
Já myslím, že jako odpověď můžu použít:
http://www.root.cz/clanky/dan-kaminsky-a-jeho-utok-na-dns-servery/nazory/220161/
Hlavně teda tu část, co psal Vixie - tj. že se nutně nemusí jednat o přepisování cache.
Co se týče dvojitých dotazů, tak otázka je, zda-li by se stejného efektu nedosáhlo jenom tím, že ve variantě b) by se prostě počkalo až vyprší TTL toho, co má server uložené v cache. Tvůj návrh má pouze tu přidanou hodnotu, že by v některých případech cache zaktualizovala a v některých ne, což se, jak správně píšeš v předchozím postu, dá mnohem lépe řídit pomocí TTL u takovýchto záznamů. -
Leoš Bitto (neregistrovaný)Naprosto sdílím obavu Paula Vixieho, že pouhé spoléhání na TTL by mohlo vést k problémům. Nakombinovat totiž část dat (answer section) z odpovědi nameserveru a část dat (additional section) ze své cache je evidentně netransakční, a kdoví co všechno by se tím mohlo rozbít - viz "there are plenty of kaminsky message patterns that rely only on insertion of new data". Ale já přeci navrhuji něco jiného! Můj přístup je takový, že v případě potenciálního útoku (kdy by v případě klasické implementace došlo k přepisu cache) se hodlám ujistit, že k přepisu cache (který by možná mohl být skutečně užitečný) skutečně má dojít. Ujištění hodlám provést opakováním dotazu, neboť zabezpečení z prostoru necelých 2^32 (2^16 TRXID + necelých 2^16 číslo UDP portu) nepovažuji za dostatečné - naopak zabezpečení z prostoru necelých 2^64 už mi bezpečné připadá.
Takže bych to shrnul: pokud cache a 1. odpověď obsahuji stejná data, pouze podle odpovědi upravím TTL (nejen prodloužím, jak píšeš, ale klidně i zkrátím). K druhému dotazu nedojde. Pouze pokud cache a 1. odpověď obsahují různá data, dojde k opakování dotazu. Pak pokud 1. a 2. odpověď obsahují stejná data, dojde k použití dat z 2. odpovědi (přeci jen je čerstvější). Pokud cache a 2. odpověď obsahují stejná data, dojde k použití dat z 2. odpovědi (a tím k potenciálnímu odvrácení útoku).
Jediné, u čeho si ve svém přístupu nejsem úplně jistý, je jak se zachovat v případě, že cache, 1. odpověď a 2. odpověď budou obsahovat tři různé údaje. Preventivně žádný z údajů nepoužít (jako kdyby nepřišla žádá odpověď)? Nebo použít údaje z 1. odpovědi? Nebo použít údaje z 2. odpovědi? Použít mix dat z jedné z odpovědí a cache se obávám že by mohlo vést k potížím. -
Jediné, u čeho si ve svém přístupu nejsem úplně jistý, je jak se zachovat v případě, že cache, 1. odpověď a 2. odpověď budou obsahovat tři různé údaje. Preventivně žádný z údajů nepoužít (jako kdyby nepřišla žádá odpověď)? Nebo použít údaje z 1. odpovědi? Nebo použít údaje z 2. odpovědi? Použít mix dat z jedné z odpovědí a cache se obávám že by mohlo vést k potížím.
Tak se zeptat ještě jednou. Pokud bude 2. a 3. odpověď nebo 1. a 3. odpověď stejná, použít data ze 3. odpovědi. Pokud se to nadále bude lišit, považovat to za útok a ponechat data v cache tak, jak jsou a počkat X hodin.
-
Leoš Bitto (neregistrovaný)Třetí dotaz už podle mě nic neřeší, jen komplikuje. Případná neshoda se bude muset řešit tak jako tak. A s dnes známými informacemi to vypadá, že se útočníkovi zfalšovat dvě odpovědi za sebou téměř nemá šanci povést a to ani při mnohonásobném opakování. Na rozdíl od zfalšování jedné odpovědi, což při mnohonásobném opakování má reálnou šanci na úspěch.
-
imho řeší. Buď ukáže, že jedna z odpovědí byla útokem či chybou a lze tedy tudo odpověď zahodit, nebo ukáže, že se v dané chvíli nedá na odpovědi spolehnout, protože jsou pokaždé jiné (nebo je snad normální, aby byly pokaždé jiné odpovědi na stejný dotaz opakovaný třikrát v řádu maximálně sekund, spíše ale desítek milisekund?), a tak se prostě ponechají data v cache a dotaz se zopakuje později.
-
jj, dočetl jsem se to těsně po odeslání svého komentáře. Nicméně takové odpovědi asi mají typicky velmi krátké TTL, ne? Tedy by se to dalo snadno ošetřit. Navíc to asi nebudou příliš běžné cíle útoku...
Každopádně to řešení s opakovaným dotazem při pokusu o přepis před koncem expirace by pomohlo řešit část útoků bez nějakých větších zásahů do systému DNS i jeho funkčnosti (netřeba měnit protokol ani způsob komunikace, stačí malý update DNS serveru).
Není to však řešení úplné. Je to jako NAT na IPv4. Jen by to oddálilo, resp. zmenšilo aktuální problém. Bohužel stejný "pocit" mám i z DNSSEC, pro které je už nutná změna způsobu komunikace. Chce to změnit a zabezpečit celé DNS.
Jenže protože nejsem z oboru a prd tomu rozumím, tak se jdu radši věnovat své práci. ;) -
Nene, to jsi podle mě Vixieho špatně pochopil. On říká, že tvůj druh obrany chrání jenom proti části těchto útoků. Tj. jsou Kaminsky-style útoky, které nepotřebují přepisovat cache. Alespoň tak já chápu, to co napsal.
Vzhledem k tomu, co píšeš ve třetím odstavci, je podle mě jediné konzistentní chování nepřepisovat cache vůbec. Ale stále jsme i tak tam, kde jsme pořád byli - pokud existuje útok, o kterém píše Vixie (dle prvního odstavce mé zprávy), tak si tímto řešením nijak zvlášť nepomůžeme. -
Leoš Bitto (neregistrovaný)To, co navrhuji, skutečně slouží pouze k ochraně proti přepsání cache. Je pravda, že Dan Kaminsky ukazuje i jak do cache dostat informaci o DNS záznamu, jehož jméno si ale nemůže útočník vybrat. Prostě se bude ptát nameserveru na náhodná jména, a zároveň ho zaplavovat podvrženými odpověďmi. Toto se spoustou náhodných jmen. Útočník ovšem v tomto případě nemá kontrolu nad tím, kterého náhodné jméno se mu povede do cache nameserveru dostat. I toto se dá zneužít, za předpokladu že nějaký jiný protokol (např. HTTP) pokládá přítomnost nějakého jména v doméně za dostatečnou autorizaci (např. cookie). Toto neřeším a připadá mi že je to problém těch jiných protokolů, které autorizují na základě DNS jména - to je prostě jejich chyba. "tak si tímto řešením nijak zvlášť nepomůžeme" mi tedy nepřipadá jako pravda - zabránit přepisu existujícího záznamu v cache mi připadá jako velmi cenná pomoc.
Základem mé obrany je druhý odstavec který jsem popsal. Tam se podle mne vyřeší drtivá většina běžných situací. Ve třetím odstavci se řeší pouze poslední možnost, která podle mne nebude v praxi často nastávat, a je na zvážení případných implementátorů aby si nějaké chování vybrali. Ale opakuji, ten třetí odstavec už není to podstatné, základem je druhý odstavec! -
Podle mě dostání neexistujících záznamů do DNS cache může být stejný problém jako přepsání údajů v ní.
Představ si například podvrhnutou odpověď:
;; QUESTION SECTION:
006a.klient5.ebanka.cz. 86400 IN A 1.2.3.4
;; AUTHORITY SECTION:
klient5.ebanka.cz. 86400 IN NS 006a.klient5.ebanka.cz.
;; ADDITIONAL SECTION:
006a.klient5.ebanka.cz. 86400 IN A 1.2.3.4
(Tj. útočník má kontrolu nad tím, co do cache dostane.)
V tu chvíli jediné, co potřebuju, je uživatele nějak nasměrovat na "nové" stránky bankovnictví.
Nebo můžu zkusit něco jako wvw.původnístránky.cz... nebo nechvalně známé .cy vs. .cz. - tj. podvrhnout www.internetovabanka.cy - jasně, že si toho spousta lidí všimne, ale určitě se najdou i takoví, co překlep přehlédnou.
***
Chápu, že základem je druhý odstavec. Mě se na tvém návrhu v podstatě nelíbí dvě věci:
a) řeší to jenom část problému (viz. výše)
b) podle mě ty validní nekonzistence budou nastávat právě u nejvíce exponovaných adres (například www.l.google.com). Přiznám se, že mám pouze obecnou představu, jaké algoritmy používají CDN (typu Akamai) na přidělování IP adres, ale mám takové tušení, že zrovna tady by to mohlo narážet nejčastěji. Různé load-balancery od Cisca a dalších fungují v jednom módu například tak, že přidělí záznamu nízké TTL a vyberou IP adresu stroje, který má požadavek obsloužit. Pokud je výběr IP adresy řízený aktuálním zatížením (nebo round robinem) strojů v clusteru, tak se opravdu může stát, že na každý dotaz bude vrácena jiná IP adresa.
Ale v zásadě pokud tvůj návrh bude obsahovat i řešení konfliktních situací, tak bych navrhoval, abys jej hodil do angličtiny a poslal do namedroppers. Nicméně osobně si myslím, že na něj bude stejná reakce, jako jsem posílal citaci od Vixieho (nebo žádná).
Mimochodem, našel jsem ještě jeden příklad toho, jak může vypadat legitimní rozdíl mezi odpověďmi:
authority foo.org NS ns1.a.foo.org
additional ns1.a.foo.org A 10.0.0.51
authority a.foo.org NS ns1.a.foo.org
additional ns1.a.foo.org A 10.0.0.71
(Vixie navrhuje používat vždy ten nejhlubší záznam; Matasaka udržovat kontext.) -
submarine worm (neregistrovaný)Mozna byste mohl misto vycucu navrhu se zabyvat timto svym iracionalnim konstatovanim:
"Jistě přepisování nebezpečné je. Ale tak nějak to reflektuje současný stav DNS dat..."
Predstavte si, ze vam nejaky dodavatel rekne: "Jiste, v nasem softu je chyba, ktera s docela velkou pravdepodobnosti umozni nejakemu zlodeji behem pristich par let pustit zilou vasemu bankovnimu uctu, ale tak nejak to reflektuje soucasny stav naseho softwaru, takze to opravovat nebudem"
Netreba byt expertem, aby bylo jasne, ze zakaz prepisovani existujiciho (stale platneho) zaznamu nezpusobi vubec nic. Existuje snad nejaky vesmirny ukaz, ktery by nastal, kdyby onen paket s prepisujici informaci neprisel ? -
Motáte dohromady dvě věci. Já o software nic netvrdil. Mluvím o DNS datech - tedy obsahu všech těch zónových souborů, které v DNS stromu momentálně jsou.
Současné implementace fungují tak, že odpověď, které jsou na stejné úrovni podle RFC 2181 sekce 5.4.1., je přijmuta do cache následujícím způsobem:
a) pokud jsou data stejná - prodloužíme TTL
b) pokud jsou data rozdílná - použij novější data
Obecně panuje názor, že by to nemuselo ničemu ublížit, a mohlo by se vyzkoušet experimentálně nasimulovat, co by se stalo, kdyby se chování v tomto případě změnilo.
Každopádně to v zásadě nic neřeší, budu citovat Paula Vixieho:
"nonreplacement of rrsets is not a general fix. there are plenty of kaminsky
message patterns that rely only on insertion of new data. so while i'm having
great fun with just reducing the TTL when a replacement is attempted,
especially with NS RRsets, it doesn't make me safe."
Mimochodem opatrnost je opravdu na místě. Každá změna může potencionálně zasáhnout milióny uživatelů. Pořád se bavíme o protokolu DNS.
