DNS útok podle Kaminského

Útoky typu DNS Cache Poisoning fungují na principu podvržení odpovědi DNS serveru. DNS server, který se ptá na určité doménové jméno, pak dostane falešné informace např. o IP adrese webového serveru. Způsob, jak podvrhnout DNS odpověď, spoléhá na několik vlastností DNS protokolu:

1. DNS dotazy a odpovědi v sobě mají uloženo 2-bytové Transaction ID, tedy počet kombinací je přibližně 65 tisíc.

2. Nezáplatované DNS servery používají pro všechny dotazy stejný zdrojový port.

3. Většina DNS dotazů a odpovědí používá UDP. UDP je bezstavové a v současných sítích je relativně jednoduché podvrhnout zdrojovou IP adresu.

Útočník musí uhodnout správné Transaction ID (nebo vygenerovat všechny možné kombinace) a poslat je ve velmi rychlém sledu za sebou s podvrženou zdrojovou adresou na adresu DNS serveru, na který útočí. Odpověď od útočníka musí přijít v časovém okně na jedné straně vymezeným DNS dotazem a na druhé straně DNS odpovědí od legitimního autoritativního DNS serveru.

Typický útok tohoto typu musel „čekat na chvíli, kdy dotazující server nemá záznam uložený ve vyrovnávací paměti server a musí se zeptat autoritativního serveru.  Takový záznam je pak uložen po dobu uvedenou v TTL záznamu ve vyrovnávací paměti serveru a útočník musí čekat než tato doba vyprší.  Časové okno, kdy lze zaútočit na DNS serveru, tohoto útoku je tak díky TTL velmi malé a se vzrůstajícím TTL se pravděpodobnost takového útoku snižuje. Šance podvrhnout správné Transaction ID je 1 ku 65 tisícům a i v případě, že se útočník vygeneruje DNS odpovědi se všemi Transaction ID, tak je vzhledem k faktu, že lze útočit pouze ve chvíli, kdy záznam není ve vyrovnávací paměti server, šance na úspěch takového útoku malá.

Podvržená odpověď bude vypadat nějak takto (Transaction ID je vyznačeno tučně):

; <<>> DiG 9.4.2-P1 <<>> www.dnssec.cz
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47457
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2

;; QUESTION SECTION:
;www.dnssec.cz.            IN    A

;; ANSWER SECTION:
www.dnssec.cz.        86400    IN    A    192.168.1.1

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug  8 14:17:41 2008
;; MSG SIZE  rcvd: 139

Dan Kaminsky odhalil způsob jak obejít data uložena ve vyrovnávací paměti a falešnou IP adresu podvrhnout v libovolnou chvíli bez ohledu na TTL. Útočník se při útoku neptá přímo na IP adresu webového serveru, ale na libovolný náhodně zvolený neexistující záznam a IP adresu webového serveru podvrhne pomocí sekce AUTHORITATIVE a ADDITIONAL pomocí mechanismu tzv. GLUE záznamu.

Příklad:
Útočník se zeptá DNS serveru, na který útočí, na 007.dnssec.cz
a podvrhne odpověď: Odpověď 007.dnssec.cz neznám, ale zná ho
server www.dnssec.cz s IP adresou 192.168.1.1.

; <<>> DiG 9.4.2-P1 <<>> 007.dnssec.cz
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55309
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 11

;; QUESTION SECTION:
;007.dnssec.cz.            IN    A

;; AUTHORITY SECTION:
dnssec.cz.        86400    IN    NS    www.dnssec.cz.

;; ADDITIONAL SECTION:
www.dnssec.cz.        86400    IN    A    192.168.1.1

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug  8 14:20:58 2008
;; MSG SIZE  rcvd: 139

V tu chvíli dojde k přepsání A záznamu pro www.dnssec.cz ve vyrovnávací paměti serveru a další dotazy na www.dnssec.cz, na které bude odpovídat tento DNS serveru, budou obsahovat podvrženou IP adresu.

Šance na uhodnutí správného Transaction ID zůstává stále stejná, ale útočník může volbou dotazů na různé neexistující domény zkoušet podvrhnout IP adresu stokrát až tisíckrát za sekundu. Navíc je schopen lépe řídit čas dotazu (vždy se ptá útočník) a tím pádem lépe načasovat i generování podvržených odpovědí.

Výrobci a autoři DNS serverů vydali aktualizace, které do dotazu vkládají další prvek náhody – náhodný zdrojový port.  Před aktualizací byl zdrojový port dotazu zvolen náhodně při startu serveru a po celou dobu běhu serveru byl používaný stejný port.  Po aktualizaci se pro každý dotaz používá nové
náhodně zvolené číslo zdrojového portu (pokud budeme počítat, že se využije celý rozsah, což většinou nebývá pravdou) a šance na uhodnutí kombinace Transaction ID a čísla zdrojového portu je 1 ku 4 milardám.  Útočník se může pokoušet vygenerovat i takovýto počet podvržených DNS odpovědí, ale šance, že se mu povede trefit se se správnou odpovědí je výrazně menší a provoz, který tímto  vygeneruje jen těžko zůstane bez povšimnutí.

Útok, který předvedl Dan Kaminsky, na vyrovnávací pamět DNS serveru je po instalaci opravných aktualizací nepravděpodobný, ale stále možný. Podle kalkulací, které proběhly poštovní konferencí namedroppers, je pravděpodobnost takového útoku po 24 hodinách cca 64%. Takový útok by si ovšem vyžádal generování obrovského množství podvržených DNS odpovědí a u méně výkonných instalací by spíše způsobil zahlcení a přerušení provozu. Tak než jsem stihl napsat tento příspěvek do blogu, tak se objevil první úspěšný útok v laboratorních podmínkách na DNS server s náhodnými zdrojovými porty, který byl schopný vložit do DNS falešnou adresu během 10 hodin.

Jediné řešení, které DNS servery ochrání před tímto stylem DNS útoků je v současné době technologie DNSSEC.

Prezentaci Dana Kaminského z konference BlackHat USA 2008 naleznete na jeho stránkách DoxPara.

Autor:

Komentáře (12)

  1. Jakub Vrána říká:

    Nemělo by být v ADDITIONAL SECTION uvedeno spíše www.dnssec.cz místo www.nic.cz?

  2. rsaf říká:

    neni mi uplne jasna jedna vec, co kdyby utok vypadal takto:

    Příklad:
    Útočník se zeptá DNS serveru, na který útočí, na 007.fakedns.cz, doména fakedns.cz je zřízená útočníkem a její DNS server pošle odpověď: Odpověď 007.fakedns.cz neznám, ale zná ho
    server www.dnssec.cz s IP adresou 192.168.1.1.

    Razem mam v cache naprosto libovolny (i neexistujici) zaznam, bez jakehokoliv „zavodeni“ podvrzenych packetu… Ale je me naprosto jasne, ze jsem neco prehlid a takto to nefunguje ;-)

  3. Ondřej Surý říká:

    2 rsaf: tenhle útok taky fungoval, ale musel byste se vrátit hodně zpátky časem, cca tak do roku 1997.

  4. Igor Lazo říká:

    rsaf: protoze v tvem pripade o domene dnssec.cz neco tvrdi stroj, ktery s ni nema nic spolecneho.

  5. Michal Kára říká:

    Jen tak teoreticky: Je spravny muj dojem, ze kdyby GLUE nemohlo prepisovat zaznam ziskany primym dotazem, tak by to tenhle utok silne ztizilo? A rozbila by tahle uprava chovani neco?

  6. Ondřej Surý říká:

    Úplné nepřepisování by určitě něco rozbilo. Jak byste do té cache vůbec ten záznam získaný přímým dotazem dostal? Viděl jsem nějaké návrhy na to, aby záznamy získané z jiných než ANSWER sekcí měly u sebe uložený i kontext, jak byly získány, ale spíš to byl takový brainstorming než cokoli jiného.

    A bohužel to není jenom GLUE. Další varianta je vrátit:

    02b.dnssec.cz IN A 1.2.3.4
    dnssec.cz IN NS 02b.dnssec.cz

    Jsem si docela jistý, že zákaz toho příkladu by toho nejspíš rozbil spoustu. Bohužel nekonzistence mezi záznamy v nadřazené doméně (třeba .cz) a záznamy v konkrétní doméně (třeba dnssec.cz) jsou relativně běžné.

  7. pht říká:

    „Útočník se zeptá DNS serveru, na který útočí, na 007.dnssec.cz“

    nemelo by to byt tak, ze s timto ho DNS server posle do haje, anzto z utocnikovy IP adresy neni povolena rekurze?

  8. vladki říká:

    Taky by me zajimalo jak se ten utok provadi pokud neni utocnikovi povolena rekurze, nebo dokonce firewallem blokovany port 53, tak aby se na nej dostali jen opravneni uzivatele.

  9. Ondřej Surý říká:

    Kaminsky ve své prezentaci uvádí několik příkladů… když pominu ty úplně zjevné (koupím si připojení nebo housing serveru, napadený server nebo stanice s Windows), tak se dá DNS dotaz například vyvolat tak, že se připojíte na mail server a uvedete do HELO/EHLO nebo MAIL FROM adresu, na kterou chcete, aby se DNSko zeptalo. Mnoho dnešních poštovních serverů dělá DNS lookup na domény, které jsou v envelope. Nebo uvedete něco pěkného do PTR (reverzního) záznamu… a připojíte se – opět to vyvolá lookup – společně s nulovým TTL pak takových lookupů můžete vyvolat libovolné množství. Podobných příkladů půjde vymyslet určitě více – nebo mě napadá nějaký IFRAME ve webové stránce – může se to tvářit jako legitimní reklama, ale zároveň to může vyvolávat DNS lookupy – ať už různým přesměrováváním nebo například nějaký flashem, který se bude pokoušet „stahovat“ data z různých webových stránek…

    Už to není tak triviální jako přímý dotaz, ale také to není neřešitelné.

Zanechte komentář