Dan Kaminsky a jeho útok na DNS servery

Systém DNS je tu s námi už 25 let a jeho první implementace byla napsána v roce 1983. Patří do stejné skupiny jako například poštovní protokol SMTP. Mají několik společných vlastností: jsou velmi jednoduché, velmi staré, velmi rozšířené a také velmi nezabezpečené.

V době, kdy tyto protokoly vznikaly, se nepředpokládalo, že by jejich použití narostlo do dnešních rozměrů a jejich vývojáři tak příliš neřešili autentizace, zabezpečení, kontrolu podvržených informací a podobně. Přestože byly protokoly i jejich implementace postupem času vylepšovány, ještě dnes se může objevit zcela nový způsob útoku.

Klasické otrávení DNS

Než si popíšeme samotný Kaminského útok, musíme se nejprve věnovat „tradičnímu“ napadení DNS, kterému se anglicky říká „DNS cache poisoning“ neboli otrávení DNS cache. Po úspěšném provedení jsme schopni dlouhodobě přesměrovat uživatele na jiný server, než na který standardně míří původní doména.

Využívá se při tom několika slabých vlastností DNS protokolu a existence takzvaných DNS cache serverů. Ty jsou obvykle umístěny u internetových poskytovatelů a obsahují jen velmi malé množství informací o DNS, které byly získány dřívějšími dotazy uživatelů.

Chceme-li navázat komunikaci s počítačem na konkrétní doméně, kontaktujeme náš DNS server, který je u poskytovatele a dotážeme se na IP adresu stroje, který nás zajímá. Protože DNS cache samotná adresu nezná, zeptá se příslušných DNS v internetu. Nakonec nám odpoví a zjištěnou odpověď si zapamatuje. Příště už na stejný dotaz odpoví přímo.

Útočník, který chce přesměrovat uživatele například ze serveru elektronického bankovnictví na svůj vlastní počítač (na kterém je falešný přihlašovací formulář) může zmíněnou DNS cache otrávit tak, že jí podvrhne falešné informace o DNS záznamech. Ty si cache zapamatuje a pak je předává svým uživatelům, kteří netuší, že dostávají doopravdy zcela jiné IP adresy, než které patří bankovní instituci.

Technicky probíhá komunikace klienta s cache takto:

1. Klient kontaktuje svou DNS a požádá o přeložení doménového jména. Komunikace probíhá po UDP a dotaz obsahuje: zdrojový port, IP adresu a transakční ID.
2. Klientova DNS odpověď nezná a proto se rekurzivními dotazy (stejným UDP protokolem) zeptá serverů na internetu.
3. Odpověď je vrácena klientovi a je uložena jak u klienta, tak i u samotné cache.

Podstatné ovšem je, že ve třetím kroku se kontroluje správnost transakčního ID, což je dodatkový bezpečnostní mechanismus, který zabraňuje jednoduchému podvržení informací. Kromě toho se kontroluje také zmíněný zdrojový port a zdrojová IP adresa odpovědi. Tyto tři informace fungují jako jednoduchá autorizace.

Transakční ID sehrává důležitou roli, jedná se o dvoubajtové číslo a každý požadavek je tak označen jedním ze 65536 možných ID. Pokud se číslo v dotazu a odpovědi neshoduje, považuje žadatel odpověď za podvrženou a zahodí ji.

Útočník tedy musí čekat, až se server začne dotazovat na neznámý záznam a může se pokusit odpověď podvrhnout a doufat při tom, že se trefí do správného ID, portu a dalších údajů.

Tento typ DNS cache útoku je znám už velmi dlouho a vyplývá z principu samotného protokolu a chování DNS. Není považován za příliš velkou hrozbu, protože vzhledem k údajům, které musí útočník zaslat a uhodnout, je velmi nepravděpodobné, že se útok zdaří.

Navíc existuje relativně krátká doba, během které je třeba útok provést. To je doba, během které serveru vyprší údaj TTL, což je hodnota, která udává, jak dlouho může být záznam v cache udržován. Poté musí být znovu načten ze serveru. Zasypávat server falešnými odpověďmi v době, kdy zná správný údaj, je zcela zbytečné.

Varianta Dana Kaminského

Dan Kaminsky odhalil podstatné vylepšení u výše uvedeného útoku tím, že při aplikaci jeho postupu není třeba čekat na vypršení TTL, ale falešný záznam se podaří do DNS cache propašovat v podstatě kdykoliv, kdy je to potřeba.

Používá při tom jiné vlastnosti DNS protokolu: GLUE záznamu a sekcí AUTHORITATIVE a ADDITIONAL. Tyto položky v DNS odpovědi umožňují tazateli přidat další důležité informace jako jsou například údaje o IP adresách DNS serverů, které se starají o konkrétní doménu. DNS server tak může tazateli říci, že odpověď nezná, ale ví o serveru, který ji umí poskytnout.

Bez dodatečných sekcí v odpovědi bychom se ale mohli dostat do situace, kdy se „brejle bez brejlí špatně hledají“. Pokud se například zeptáme kořenového DNS serveru na IP adresu konkrétní domény, ten nám odpoví, že netuší, ale máme se zeptat serveru ns1.example.com. V tu chvíli bychom byli bezradní, protože neznáme IP adresu tohoto serveru, a tak se ho nemůžeme na žádnou IP adresu zeptat (aneb „Jaké má Jirka číslo? Nevím, zavolej mu a zeptej se.“)

Doopravdy by tedy vypadala odpověď serveru asi takto:

;; ANSWER SECTION:
    www.example.com.    120      IN    A    192.168.1.10

;; AUTHORITY SECTION:
    example.com.        86400    IN    NS   ns1.example.com.
    example.com.        86400    IN    NS   ns2.example.com.

;; ADDITIONAL SECTION:
    ns1.example.com.    604800   IN    A    192.168.2.20
    ns2.example.com.    604800   IN    A    192.168.3.30

V AUTHORITY sekci se dozvídáme, které servery se o doménu starají a v ADDITIONAL sekci si pak můžeme přečíst jejich IP adresy. Cesta dál je tedy jasná. Tazatel se dozvěděl (a zapamatoval si), že IP adresa www.example.com je 192.168.1.10.

Kaminsky ovšem přišel na způsob, jak v DNS cache tento záznam kdykoliv změnit, ačkoliv ještě nevypršela jeho platnost. Dejme tomu, že se cache za chvíli zeptá na další adresu: blabla.example.com. Útočník podvrhne následující záznam:

;; ANSWER SECTION:
    blabla.example.com.  120   IN  A    10.10.10.10

;; AUTHORITY SECTION:
    example.com.             86400   IN  NS   www.example.com.

;; ADDITIONAL SECTION:
    www.example.com.        604800   IN  A    10.10.10.20

Všimněte si poslední části. Tou se snažíme DNS cache přesvědčit o tom, že server www.example.com nyní sídlí na nové IP adrese. Pokud se nám to povede, bude si tato cache po 7 dní (604800) sekund tuto informaci držet a bude jí předávat svým uživatelům.

Stále je třeba uhodnout transakční ID, ale už je možné to dělat kdykoliv a navíc dotaz může vyvolat i samotný útočník a tak stačí generovat dotazy dostatečně často (třeba mnohokrát za sekundu) a šance, že se trefíme, je poměrně značná. Výhodou také je, že se můžeme cache ptát na naprosto libovolné (nejlépe neexistující) domény, protože na tvaru dotazu vůbec nezáleží.

Jak se bránit?

Dodavatelé DNS serverů už začali dodávat záplaty, kterými vylepšují své produkty. Kromě transakčního ID je náhodně generován také odchozí port pro DNS požadavky. Většina serverů používá jeden náhodně zvolený port po celou dobu svého běhu. Po aplikaci záplat je každý dotaz vygenerován z jiného portu, kterých může být 65536, stejně jako ID. Počet kombinací nám tedy rázem narůstá na 65536², což jsou více než 4 miliardy možností.

I toto číslo je však konečné a v laboratorních podmínkách už byl proveden úspěšný útok na takto zabezpečený server. Podle autora trval útok 10 hodin.

Jedinou stoprocentní obranou je protokol DNSSEC, jehož podpora bude u nás velmi brzy spuštěna. Tato služba rozšiřuje možnosti DNS a umožňuje záznamy elektronicky podepisovat. Tím zcela zabraňuje jakémukoliv podvržení údajů.

Jsem zranitelný?

Existuje několik nástrojů, s jejichž pomocí si můžete ověřit, jak je na tom váš DNS server: DNS Vulnerability Check a DNS Checker.

Stále existuje řada velkých českých poskytovatelů, kteří záplaty neaplikovali a umožňují tak libovolnému útočníkovi podvrhnout falešné DNS záznamy. Ve světě už se objevily první reálné případy úspěšných útoků.

Odkazy na další informace

• blog Dana Kaminského
• DNS útok podle Kaminského
• An Illustrated Guide to the Kaminsky DNS Vulnerabilit
• články na Google News
• článek o DNSSEC