Názory k článku Dan Kaminsky a jeho útok na DNS servery

Co je zarážejícího na tom, že je potřeba mít řešení, které ochrání všechny a nikoli jen pár "vyvolených"?

Urážky jsou většinou znakem toho, že diskutující straně došly argumenty.

Nehledě na to, že vaše reakce nějak úplně nedává smysl.

Já celou dobu mluvím o tom, že pokud má přijít nějaké řešení, tak to má být řešení, které ochrání všechny. A reagoval jsem na větu, kdy pisatel píše o tom, že to root a tld servery nezatíží, protože si to nastaví jenom pár lidí.

A máte váš názor podložený i nějakými technickými znalostmi nebo jenom opakujete, co jste našel v doporučení CERTu, ale jinak podstatě problému vůbec nerozumíte? Ale oceňuji, že jste konečně zvládl naformulovat, o co vám jde.

Lokální DNS cache vás může ochránit před dvěmi věcmi:

a) útokem na stub resolver, který nemá implementovanou randomizaci DNS portů (viz. ona advisory od CERTu, kterou se oháníte)
b) útokem na vašeho lenivého ISP, který neaktualizoval svoje rDNS (v ČR momentálně nevím o žádných velkých, ale pár malých jsem v querylogu viděl)

Lokální DNS cache je v zásadě jenom řešením, které vám umožní kontrolovat, zda-li máte DNS, který používá náhodné zdrojové porty.

Ale i kdybychom se podívali na to, jestli by se za pomoci lokální DNS cache dala zvýšit ochrana proti Kaminsky-style útokům, tak závěr je, že použití lokální DNS cache není systémovým řešení a problém pouze odsouvá. Aby se útočníkovi nevyplatilo napadnout rDNS, tak by dopad takového útoku musel být velmi malý - jinými slovy museli by na model - co počítač, to rDNS, přejít všichni. Předem upozorňuji, že segmentace na rDNS per organizace nestačí - i útok na nějakou firmu může být dostatečně zajímavý (průmyslová špionáž, atp.). V tu chvíli se ale dostáváme zpátky k první reakci - to by pravděpodobně znamenalo výrazně zvýšenou zátěž na všechny autoritativní DNS servery a speciálně root servery a servery TLD.

Naštěstí se i tady na rootu v diskuzi dají najít lidé, kteří podstatě problému porozuměli, a navrhují věci, které mají hlavu a patu.

Omlouvám se, že se tak blbě ptám ;), ale komu byla tahle poznámka určena?

Já jsem vám předložil argumenty, vy se opět vyjadřujete nikoli k předloženým argumentům, ale k mé osobě a lacině mě pod rouškou anonymity napadáte. Pokud máte pocit, že jsem tak katastroficky selhal, máte možnost předložit své argumenty buď zde, nebo mi poslat email, nebo mi zatelefonovat a vysvětlit mi v čem se mýlím. Do té doby s vámi diskuzi končím.

Ano pletete. U banky váš nemusí zajímat ani FQDN ani IP. Jediné co by váš u inet-banky mělo hodně zajímat je SSL certifikát.

To ovšem řešíte Vy, já a většina čtenářů Roota (snad). Běžný uživatel netuší nic o HTTPS, fingerprintech a o šifrování má jen velmi mlhavé znalosti. Všichni běžní uživatelé dotaz na certifikát automaticky potvrzují. Kdysi mi někdo vyprávěl, že zkoušel na routeru podvrhovat uživatelům falešné certifikáty. Měl na to nějaký automat, který jednou podvrhl a pokud uživatel nesouhlasil, napodruhé už nechal spojení bez změny. Úspěšnost byla 40 000:12. Jen 12 uživatelů podvržený certifikát nepřijalo. Ostatní souhlasili. HTTPS je bez správného užívání naprosto k ničemu.

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ů.

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.

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.

(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?)

Ano, já myslím, že to může být zcela normální. Třeba v případě toho, že je adresa, kterou to vrací, vybírána nějakým round robinem nebo zcela náhodně.

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.

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.)

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.

Bohužel se toho o nym base security v podání djb dá zjistit ještě méně než o genocidě Arménů v Turecku... takže mě kdyžtak opravte... nicméně nepředpoklám, že by google měl speciální filtr na djb a jeho nym based security, takže hádám, že oba vycházíme z té jediné stránky s názvem forgery.html a případně občasných drobných zmínkách.

Pokud jsem djb správně pochopil, tak by se jednalo o to, že by doménové jméno nevypadalo 'www.root.cz', ale např. www.128309ADCA12A.root.cz (nebo jinak poskládané, ale pro ilustraci to doufám stačí). Tzn. když by bylo potřeba vyměnit klíč a doménové jméno znovu podepsat, tak by došlo k tomu, že by ta adresa najednou nebyla www.128309ADCA12A.root.cz ale www.9876AD9BEF.root.cz (opět jen příklad). Důsledky doufám vysvětlovat nemusím. To byla první námitka.

Druhá námitka je doufám očividná - bylo by to stejné jako návrh výše v diskuzi, aby se používaly IP adresy. Stejně nesrozumitelné. A to jak pro www, tak pro emailové adresy...

Ale možná vycházím ze špatného předpokladu. Pokud ano, tak by mě zajímalo, kde to djb popisuje detailněji.

Ad první odstavec) V DNSSECu je distribuce klíčů hierarchická stejně jako DNS. Na DNSSECu je pěkné právě to, že nemění model důvěry.

Ad druhý odstavec) Věřím, že certifikačním autoritám by se váš návrh moc líbil.

Ad třetí odstavec) Bohužel vaše věta o tom, že se to nepovedlo za deset let, je blábol pramenící pouze z vaší neznalosti problematiky.

Mé doporučení zní - vyřaďte djb z vašeho soukromého panteonu a nad jeho návrhy zkuste přemýšlet.