Názory k článku Otrávení DNS cache se opravdu používá k únosu mailů

Jako že podvrhnout záznam v cache je jen krůček od toho podvrhnout podpis TLD zóny nebo kořenové zóny?

To právě nejde. To by byl downgrade attack a tomu se musí návrh bezpečnostní technologie vyhnout.

Pokud není zóna podepsaná, musí to nadřazená zóna deklarovat v podepsané zprávě. Tedy CZ.NIC řekne buď:

a) zónu spravuje server ns.nekde.cz a všechny odpovědi musí být podepsány tímto klíčem
b) zóna není podepsaná
Ale obě zprávy jsou podepsané klíči CZ.NIC. Taky se to podvrhnout nedá.

Asi budu muset napsat nějaký hodně zjednodušující článek (blogpost) o tom, jak funguje DNSSEC.

Tohle ale stavi na tom, ze se mi nikdy nepodari vlozit do cache zaznam, klidne i totozny, ale bez podpisu.
Mne by jen zajimalo, kdyz uz tedy lze vlozit do cache obecne podvrzeny zaznam, proc toto nelze kdyz to na prvni pohled vypada uplne stejne (a zaroven stavim na tom, ze co uz mam v cache, na to se ven neptam).

Protože cache se obvykle otráví tak, že se k odpovědi přidá GLUE záznam s matoucí informací. Je to jako přílepek k zákonu, prostě útočník odpoví a k tomu dodá: „Jo a o doménu Google.cz se stará falesnyserver.cz“. Ovšem pokud je Google.cz podepsaná zóna, musela by být i tahle informace podepsaná. Pokud není, pak se má zahodit.

Samozřejmě je možné, že některé rekurzivní servery jsou špatně implementované a podaří se jim tam tu informaci nějak propašovat, ale to je jednoznačně bezpečnostní chyba a je třeba ji opravit. Ovšem není to principiální problém v návrhu DNSSEC.

Nebo presneji: Tohle stavi na tom, ze se mi nikdy nepodari vlozit do cache zaznam z nadrazene zony.

Ne, staví to na tom, že se vám nikdy nepodaří vložit do cache podvržený věrohodný záznam kořenové zóny.

V pohode, pan Krcmar uz odpovedel vyse.

Vy stavite na tom, ze to nutne musi byt vzdy podepsane a ze vsichni, vcetne klientu, jej overuji.

Kořenová zóna už nějaký ten pátek podepsaná je. Zóny nepodepsané DNSSECem samozřejmě DNSSECem chráněné nejsou. Ale zóny podepsané jím chráněné jsou a uživatel má možnost je ověřit, i když bude cache vracet libovolné podvržené nepodepsané záznamy. Protože kořenovou zónu se cache podvrhnout nepodaří.
Celou dobu se bavíme o případu, kdy klient ověřuje. Nikdo jiný, než klient, pak ověřovat nemusí - klient si ty záznamy ověří sám. Pokud by cache dostala podvržený záznam, neověřila ho a poslala dál, klient, který ověřuje, ten podvrh stejně zjistí.

Při ověřování DNSSEC se každý záznam ověřuje oproti údajům v nadřízeném záznamu. Kde případně musí být i uvedeno, že ten podřízený záznam není podepsaný. cache vám sice může podvrhnout i nepodepsaný ten nadřízený záznam, ale tímhle způsobem se jednou dostanete ke kořenové zóně, ale každý, kdo ověřuje DNSSEC, ví, že kořenová zóna je podepsaná a ví, jakým klíčem. Takže tenhle údaj už DNS cache ověřujícímu klientovi podvrhnout nedokáže, a nejpozději v tomhle okamžiku ověřovatel zjistí, že je něco špatně, a prohlásí tu celou strukturu pod tím za neověřenou.

Huh, vy jste se na mne sesypali :-)

Ok, ja si to budu muset spis nacmarat, protoze se nemuzu ubranit dojmu ze DNSSEC je jen berle, nikoliv oprava kulhajiciho reseni.

I kdyz v hybridnim prostredi (podepisovane i nepodepisovane zony a validace/nevalidace najednou) to asi jinak nejde.

Pokud zóna není podepsaná, pak samozřejmě je možné měnit si ve vzduchu informace libovolně a rekurzivní server uživatele nemá jak ověřit, zda jsou změněné nebo ne. Je to jako s nepodepsaným mailem. Nepodepsáno = nechráněno.

Ovšem pokud už zóna podepsaná je, je o tom záznam v nadřazené zóně (třeba v .cz) a jsou tam i klíče, se kterými musí přijít odpovědi od autoritativního serveru té zóny. Nelze pak prohlásit, že zóna není podepsaná, protože to by musel udělat nadřazený server.

Příklad: Když se zeptám autoritativního serveru pro doménu .cz na doménu Root.cz, dostanu odpověď, že se mám dál ptát na autoritativních serverech ns.iinfo.cz a ns6.adminit.cz a je mi předán veřejný klíč, který pasuje k privátnímu klíči, kterým musí být odpovědi od těch dvou serverů podepsané.

Tak ještě jednou a o úroveň výš. Pokud by chtěl někdo prohlásit TLD zónu cz za nepodepsanou, musel by do kořenové zóny umístit podespanou informaci, že TLD cz je nepodepsaná, tedy musel by nějak získat privátní klíč kořenové zóny.

Abych předešel další iteraci dotazu, tak prohlásit kořenovou zónu za nepodepsanou není možné, protože validátor DNSSEC si s sebou nese informaci o tom, že kořenová zóna je podepsaná a také otisk jejího klíče. Takže neuvěří žádné informaci, která by naznačovala, že kořenová zóna podepsaná není.

V současné době se používá RSA/SHA-256 s 2048bitovým klíčem. Když se to ukáže jako nedostatečné, neměl by být problém klíč vyměnit. Výměna je vymyšlena tak, že validátory by si jí samy měly všimnout a aktualizovat si pevný bod důvěry (informace o něm bude podepsána starým klíčem). Samozřejmě ale systémy, které budou během výměny klíče dlouhodobě vypnuté, nebo nebudou mít zapisovatelné uložiště, změnu kořenového klíče bez ručního zásahu nepřežijí. To je taky důvod, proč se do výměny klíče kořenové zóny nikomu moc nechce :)

Asi budu fakt otravny, ale stejne.

Takze pokud se do cache validujiciho resolveru dostane zaznam "legalni" cestou (pricemz se bere ze otraveni cache resolveru je legalni cestou, t.j. v odpovedi od tazaneho*), tak nez si jej resolver ulozi do cache, tak si vzdy (duraz na "vzdy") probehne cely retez podpisů od korenove zony az po podepsany zaznam nebo podepsanou informaci ze zona, klidne i jedna z nadrazenejsich, neni podepsana a to cele bez ohledu na to jestli zaznam podepsany je ci neni (duraz na to "neni")? Pokud ano, tak uz to dava vetsi smysl.

Ono se mozna lehce kouli ocima, ale bud byva popis DNSSEC tak strucny ze tam tahle informace neni, nebo naopak tak podrobny, ze se tam ztrati. Nebo tam take neni (nemuzu dolozit zda skutecne neni nebo jsem to vzdycky prehledl v kazdem clanku o DNSSEC, ktery jsem kdy cetl), protoze se obvykle probiraji pouze zony ktera jsou podepsany (at uz validne nebo nevalidne).

*) kde tazany muze byt podvrzeny.

Pakliže je cache validátoru prázdná, pak se skutečně ověřuje celý řetěz až ke kořenové zóně. Ověřené informace se samozřejmě kešují, takže přijde-li později dotaz například na jinou doménu ve stejné TLD, už není třeba znovu ověřovat jestli ta TLD má nebo nemá být podepsaná a ověřuje se pouze ta část stromu, která dosud v cache není.

Tak jeste jednou, nebot se nam do toho plete kesovani, o kterem jsem se ani moc bavit nechtel.

Mam DNS zaznam, ktery _neni_ podepsany (resp. to v tu chvili ani nevim). Jde validujici cache resolver pres cely retez podpisu, pocinaje korenovym (a dopredu znamym), az po _podepsanou_ informaci ze zaznam skutecne neni podepsany?

Takhle je to blbe popsany, ale jak jinak se mam zeptat aniz bych na otazku ohledne overovani podpisu dostal odpoved ohledne kesovani DNS zaznamu?

Můžete si to vyzkoušet i sám pomocí utility unbound-host (dodává se s unboundem). Nejdřív se provede vlastní resolving, a pak se jede znovu od kořene a validuje se DNSSEC podpis.

Nepodepsaný je například google.cz:

$ unbound-host -d -f /etc/unbound/root.key google.cz
…
[1410876360] libunbound[26360:0] info: response for google.cz. A IN
[1410876360] libunbound[26360:0] info: reply from <google.cz.> 216.239.32.10#53
[1410876360] libunbound[26360:0] info: query response was ANSWER
[1410876360] libunbound[26360:0] info: prime trust anchor
[1410876360] libunbound[26360:0] info: resolving . DNSKEY IN
…
1410876360] libunbound[26360:0] info: validate keys with anchor(DS): sec_status_secure
[1410876360] libunbound[26360:0] info: Successfully primed trust anchor . DNSKEY IN
[1410876360] libunbound[26360:0] info: validated DS cz. DS IN
[1410876360] libunbound[26360:0] info: resolving cz. DNSKEY IN
…
[1410876360] libunbound[26360:0] info: validated DNSKEY cz. DNSKEY IN
[1410876360] libunbound[26360:0] info: NSEC3s for the referral proved no DS.
[1410876360] libunbound[26360:0] info: Verified that unsigned response is INSECURE
…

Nj, ale proc sakra tahle informace (ze pokud se resolver nastavi jako validujici, tak validuje i vysledky bez podpisu) nekde nesviti?
I kdyz ja tou fosnou asi potreboval, protoze kdyz mi vlastne odpovedel i pan Krcmar vyse, tak mi to nejak porad nebliklo.

Kazdopadne diky.

Ono to tak nějak plyne z postupu ověřování - to, že zóna může být bez podpisu, se zjistí teprve tehdy, když se všechny podpisy nad ní zvalidují.

No, veci typu DNSSEC nebyvaji toho razu "ja myslel ze .." nebo "tohle je prece jasny". A obzvlast vtipny je typ "to prece vi kazdy".

Takže pokud se mi podaří zapsat do cache DNS serveru (nějakou zranitelností, třeba přímo zápis do RAM), že doména cz je nepodepsaná, tak můžu podvrhovat odpovědi?

Můžete. Ale ty odpovědi neprojdou DNSSEC validací, takže každý, kdo validuje DNSSEC, pozná, že jde o podvržené odpovědi.

Ano, validující klient (klidně cache resolver) bude postupovat od kořene. Ten ověří podle klíče, který zná. TLD ověří podle klíče z kořenové zóny atd. Takhle postupně postupuje k doménám vyššího a vyššího řádu. Buď takhle dojde až k záznamu, který potřeboval získat, pak ví, že je ten záznam platný. Nebo skončí někde dřív, protože pro podřízenou doménu není v nadřazené doméně klíč. Tak věrohodně zjistí, že daná doména není podepsaná a dál nevaliduje. Pokud by někde během té validační cesty narazil na záznam s neplatným podpisem, vyhodnotí celý řetězec jako neplatný a tomu, kdo DNS dotaz vyvolal, vrátí informaci, že požadovaný záznam neexistuje.

Diky moc.

Tahle informace mi celou dobu chybela.
Vzdycky se totiz v popisech o DNSSEC resi jestli podpis sedi, ale o nepodepsanych zonach (a jejich zaznamech) se moc nepise coz mne vzdy privadelo k zaveru, ze u nepodepsanych zon se resolver chova tak jako v situaci bez DNSSEC (a tedy k zaveru, ze DNSSEC toho zase tak moc neresi).

Ono to ověřování vždy musí jít od kořene (nebo od jiné důvěryhodné kotvy). Je to trochu nepřehledné, protože domény se vyhledávají od úplného jména směrem ke kořenu, ale ověřují se opačně od kořene směrem k úplnému jménu.

Mne v pripade overovani nepodepsanych zon neslo ani tak "odkud", jako spis "jestli".

Musí se to dělat, protože jinak by se nezjistilo, zda ta zóna je nepodepsaná záměrně, nebo zda to je podvod. Jinak by opravdu stačilo, aby útočník místo podepsaného záznamu podstrčil svůj nepodepsaný, a celé DNSSEC by bylo k ničemu.

Nehlede na to, ze sem jeste nevidel resolver, kterej by zkoumal, jestli nahodou domena ma nebo nema byt podepsana, kdyz dostane nepodepsanou odpoved.

Doporučuji podívat se po nějakých validujících resolverech, jako třeba BIND nebo Unbound. Pokud u nich validaci zapnete, rozhodně to zkoumat budou.

Vubec nemluve o tom, ze znam i dns, ktery maji podepsany svoje zaznamy, ale nemaji vydistribuovane klice ... trebas proto, ze jejich registrator to proste neumi. A taky jim to kupodivu funguje.

Na tom není nic zvláštního, nedůvěryhodně podepsaná zóna není o nic méně bezpečnější než nepodepsaná zóna.

Současný stav je takový, že pokud podpis nesedí, validující DNS server vrátí stavový kód SERVFAIL, což stub resolver vyhodnotí jako že doména neexistuje, takže uživatel nemá možnost rozlišit mezi stavem, kdy doména opravdu neexistuje a stavem kdy existuje, ale nevaliduje. To je ale spíš rychlý způsob, jak pomocí DNSSEC rychle ochránit co největší množství služeb, ale přitom je nemuset nijak upravovat.

V ideálním finálním případě DNSSEC validaci bude podporovat přímo koncová aplikace typu WWW prohlížeče a namísto informace „server nenalezen“, rovnou předá informaci „server byl podvržen“.

Člověk by řekl, že když se na téma DNSSEC někdo jednou pořádně historicky znemožní, že si to pak aspoň do příště nastuduje. Jenomže to by pak nezbyl čas urážet ostatní, že?

Takže vy úplně v pohodě nahradíte celý DNS strom, a kořen podepíšete privátním klíčem, k němuž příslušný veřejný klíč má každý klient ověřující DNSSEC uložený u sebe a proti němuž kontroluje podpis kořenové zóny. Zapomněl jste uvést jenom jeden takový nepatrný detail - jak se k tomu pravému privátnímu klíči dostanete?

To, že jste ještě neviděl resolver validující DNSSEC, je z vašich komentářů patrné.

To, že má někdo podepsanou zónu, ale nemá v nadřazené doméně zveřejněné klíče, ničemu nevadí. Akorát tu jeho zónu nelze validovat DNSSECem, pokud klient nemá u téhle domény klíče speciálně uložené. Tak se validovalo dříve, když ještě nebyla podepsaná kořenová doména - klient měl u sebe poznamenané, že třeba TLD .cz používá ten a ten klíč, a nepotřeboval tedy tuhle informaci získávat z DNS stromu.

Určitě to mají ošetřené ve smluvních podmínkách.

Je, jenže kolik provozovatelů serverů to umožňuje, a kolik klientů to upřednostňuje v konfiguraci? Stejně to odesílání přes nejbližší server bylo takové elegantnější…

Popravdě řečeno jsem se za posledních 10+ let nepotkal poskytovalele poštovního řešení, který by MSA nepodporoval. Na klientské straně mi to s rozvojem mobilních zařízení taky připadá už jako standard. Thunderbird/Icedove port 587 také používá jako standard.

Ale vím, že je to pouze má "anecdotal evidence"...