Analiza Kaminsky DNS napada

Sigurnosni stručnjak Dan Kaminsky je 2008. godine otkrio propust u DNS-u koji je omogućavao napadačima da izvedu napad trovanje priručne memorije na gotovo svim poslužiteljima imena. Većina aplikacija baziranih na uporabi Interneta upotrebljavala je DNS za lokaciju usluga čime su postali mogući razni napadi, uključujući lažno predstavljanje web stranica, presretanje emailova te zaobilaženje autentifikacije uporabom “Zaboravili ste lozinku?” funkcije na mnogim stranicama. Nakon otkrivanja ranjivosti, iskorištavanje ranjivosti je značajno otežano, ali nije onemogućeno.

DNS (Domain Name System) je distribuirani hijerarhijski sustav Internet poslužitelja u kojem se nalaze informacije povezane s domenskim nazivima, tj. informacije o povezanosti IP adresa i njihovih logičkih (simboličkih) imena. DNS omogućava da se uporabom URLa (Uniform Resource Locator) adresiraju uređaji na internetu. U veljači 2008. godine, Dan Kaminsky otkrio je ranjivost u DNS-u čijim iskorištavanjem bi se mogao poremetiti standardan način funkcioniranja DNS-a. Ranjivost je omogućila napad čijim izvođenjem bi napadnuti DNS poslužitelj davao pogrešnu IP adresu za dani URL.

Ključne riječi: Kaminsky, DNS, DNS napad, DNS ranjivost

Ništa ne sprječava bilo koji poslužitelj imena da poslužuje bilo koju zonu, uključujući i onu koju ne bi trebao posluživati. Napadač može postaviti poslužitelj imena i konfigurirati ga da određenu autoritativnu zonu, ali to neće imati bilo kakvog utjecaja budući da niti jedan poslužitelj imena na višoj razini mu neće delegirati zahtjev.

Grafički prikaz DNS upita:

Opis DNS upita:

1. Klijent šalje zahtjev prema stranici kojoj želi pristupiti (npr. www.unixwiz.net). Taj zahtjev je usmjeren na poslužitelj imena (eng. nameserver) kojeg klijent ima postavljenog u svojim mrežnim postavkama računala, najčešće je to poslužitelj imena njegovog pružatelja internetskih usluga. Zahtjev traži A zapis što označava IP adresu. Poslužitelj imena pružatelja internetskih usluga nije autoritativan za unixwiz.net pa nema njen zapis, a također ju nema niti u priručnoj memoriji budući da joj nije nedavno pristupio.
2. Svi rekurzivni poslužitelji imena imaju unaprijed konfiguriranu listu od 13 korijenskih poslužitelja. Poslužitelj imena odabire jednog korijenskog poslužitelja i šalje mu zahtjev za A zapis stranice www.unixwiz.net.
3. Korijenski poslužitelj ne zna IP adresu stranice www.unixwiz.net, ali zna koji je poslužitelj zadužen za .net domenu. Uz popis poslužitelja zaduženih za tu domenu, korijenski poslužitelj šalje IP adrese tih poslužitelja. Odgovor je u formi NS zapisa te sadrži dvije sekcije - autoritativnu sekciju u kojoj su navedeni poslužitelji te dodatnu sekciju u kojoj su navedeni psolužitelji i njihove IP adrese.
4. Poslužitelj imena pružatelja internetskih usluga odabire jedan od autoritativnih poslužitelja te mu šalje zahtjev za A zapisom stranice www.unixwiz.net.
5. Odabrani poslužitelj ne zna odgovor na upit, ali zna poslužitelji koji bi to mogli znati. Poslužitelj odgovara sa listom NS zapisa koji sadrži poslužitelje i IP adrese.
6. Poslužitelj imena pružatelja internetskih usluga opet odabire jedan od autoritativnih poslužitelja te mu šalje zahtjev za A zapisom stranice www.unixwiz.net.
7. Za razliku od prethodnih slučajeva, ovaj poslužitelj imena ima A zapis stranice www.unixwiz.net. Uz zapis, autoritativni poslužitelj u odgovoru postavlja zastavicu AA koja označava da je to autoritativni odgovor.
8. Poslužitelj imena pružatelja internetskih usluga je dobio IP adresu te ju prosljeđuje klijentu. Poslužitelj imena pružatelja internetskih usluga sprema dobivenu informaciju u svoju priručnu memoriju. Ukoliko neki klijent bude tražio IP adresu stranice www.unixwiz.net poslužitelj imena pružatelja internetskih usluga će ju imati u priručnoj memoriji, ali odgovor neće označiti sa zastavicom AA budući da iako je tu informaciju dobio od autoritativnog poslužitelja on sam nije autoritativni poslužitelj.

Format poruke trećeg koraka:

/* Authority section */
NET.                 IN  NS A.GTLD-SERVERS.NET.
                     IN  NS B.GTLD-SERVERS.NET.
                     IN  NS C.GTLD-SERVERS.NET.
                     ...
                     IN  NS M.GTLD-SERVERS.NET.

/* Additional section - "glue" records */
A.GTLD-SERVERS.net.  IN  A  192.5.6.30
B.GTLD-SERVERS.net.  IN  A  192.33.14.30
C.GTLD-SERVERS.net.  IN  A  192.26.92.30
...
M.GTLD-SERVERS.net.  IN  A  192.55.83.30

Ništa ne sprječava bilokoji poslužitelj imena da poslužuje bilokoju zonu, uključujući i onu koju ne bi trebao posluživati. Napadač može postaviti poslužitelj imena i konfigurirati ga da određenu autoritativnu zonu, ali to neće imati bilokakvog utjecaja budući da niti jedan poslužitelj imena na višoj razini mu neće delegirati zahtjev.

Za razumijevanje načina funkcioniranja napada potrebno je znati sadržaj DNS paketa. Slika ispod prikazuje polja DNS paketa te su žutom bojom označena polja koja su bitna za razumijevanje ranjivosti.

• Source / Destination IP address - predstavlja IP adrese uređaja koji šalju / primaju paket
• Source / Destination port number - DNS poslužitelj sluša na portu 53/udp, za upite iz vanjskog svijeta, a izvorišni port nema dogovorenu predodređenu vrijednost
• Query ID (transaction ID) - unikatni identifikator pomoću kojeg pošiljatelj zahtjeva kada dobije odgovor od DNS poslužitelja zna na koji upit je dobio odgovor

U prethodnim primjerima, poslužitelj imena pružatelja internetskih usluga je morao proslijediti dobiveni upit te se nije mogao osloniti na prethodno znanje, osim informacija o korijenskim poslužiteljima. U praksi, često prosljeđivanje upita nije potrebno budući da kada poslužitelj imena dobije autoritativni odgovor za određenu web stranicu on ju pohranjuje u svoju priručnu memoriju kako idući put kada dobije isti zahtjev može odmah odgovoriti na njega.

Kada se DNS odgovor pohranjuje, on se ne može spremiti zauvijek jer bi to dovelo do netočnog usmjeravanja budući da se IP adrese web stranica mjenjaju. Administrator zone određuje koliko dugo se u priručnu memoriju pohranjuje svaki zapis. To vrijeme se zove Time To Live (TTL) te je izraženo u sekundama. TTL može biti od nekoliko sekundi do nekoliko tjedana - sve ovisi o administratoru te zone.

U priručnu memoriju se ne pohranjuju samo zapisi tipa A već i zapisi tipa NS koji imaju svoj vlastiti TTL. Zapisi tipa A označavaju IP adresu za danu domenu dok zapisi tipa NS označavaju koji DNS poslužitelj je autoritativan za tu domenu. TLL zapisi u NS zapisima služe tome da ako je istekao TLL zapisu tipa A, ali nije istekao TTL zapisu tipa NS koji sadrži informacije o autoritativnom serveru za neku stranicu moguće je odmah poslati zahtjev nekom od autoritativnih servera, a nije potrebno raditi cijeli postupak koji započinje slanjem upita korijenskom poslužitelju.

Trovanje priručne memorije je postupak u kojem napadač uspije unijeti proizvoljne podatke u priručnu memoriju rekurzivnog poslužitelja imena. Tada poslužitelj imena klijentima odgovara na upite iz priručne memorije koristeći vrijednosti koje je napadač unio čime klijent može biti usmjeren na pogrešnog poslužitelja.

Trovanje priručne memorije nije izvesti slanjem nasumičnih DNS paketa poslužitelju imena budući da DNS poslužitelj samo prihvaća odgovore koje očekuje, a ostale odgovore ignorira. Poslužitelj imena zna koje odgovore očekuje prema:

1. odgovor je dostavljen na isti UDP port s kojeg je upit poslan
2. Question dio u odgovoru odgovara Question dijelu u poslanom paketu
3. Query ID odgovara Query ID-u nekom od poslanih upita
4. vrši se tzv. bailiwick provjeravanje - provjeravaju se Authority i dodatne sekcije (time se postiže da se sve informacije u odgovoru koje nisu u domeni za koju je postavljen upit zanemarene)

Ako su svi uvjeti zadovoljeni, poslužitelj imena će prihvatiti paket kao odgovor te će koristiti njegove informacije.

U starim poslužiteljima imena, Query ID se povećava za jedan u svakom izlaznom zahtjevu čime se olakšava njegovo pogađanje. Vjerojatno nije moguće direktno pitati poslužitelj imena za Query ID, ali ga je moguće otkriti na drugi način.

Postupak otkrivanja Query ID-a:

1. Napadač šalje zahtjev poslužitelju imena za stranicu čijim poslužiteljem imena on upravlja (npr. test.badguy.com)
2. Žrtvin poslužitelj imena prima zahtjev i izvršava standardni postupak razrješavanja imena.
3. Žrtvin poslužitelj imena će biti usmjeren na napadačev poslužitelj imena budući da je on autoritativan za domenu koju je nadač poslao u zahtjevu
4. Napadač iz odgovora žrtvinog poslužitelja imena može pročitati Query ID

Ilustracija postupka:

Ovim postupkom napadač je otkrio zadnji Query ID i izvorišni port kojeg koristi žrtvin poslužitelj imena. Nakon što se otkrio problem generiranja Query ID-a kao uzastopnih brojeva, većina DNS poslužitelja je prešla na nasumično generiranje Query ID-a. Unatoč nasumičnom generiranju Query ID-a pokazalo se da broj kombinacija od 65536 nije dovoljno velik te da i dalje postoji nezanemariva opasnost da će napadač pogoditi Query ID.

Prije napada, napadač mora konfigurirati poslužitelj imena koji je autoritativan za zonu čiju domenu želi oteti (npr. zonu bankofsteve.com). Općenito, moguće je postaviti poslužitelj imena koji je autoritativan za neku domenu, ali ako nijedan korijenski poslužitelj ne pokazuje na njega on neće dobiti niti jedan upit tj. on ima (potencijalno lažne) odgovore, ali nitko ne postavlja pitanje.

Cilj idućeg postupka je zamijeniti legitimnu IP adresu stranice www.bankofsteve.com sa drugom IP adresom. Napadač je kao pripremu napada poslužitelj imena ns1.bankofsteve.com za domenu bankofsteve.com.

Postupak:

1. Napadač odabire nasumično ime unutar ciljanje domene (npr. www12345678.bankofsteve.com). Cilj je odabrati ime koje se neće nalazi u priručnoj memoriji.

2a. Napadač zna da će žrtva tražiti ns1.bankofsteve.com za IP adresu stranice budući da će joj taj poslužitelj imena vratiti korijenski poslužitelj. Tada napadač šalje veliki broj paketa prema žrtvite delegira odgovor na drugi poslužitelj imena putem polja “Authority records”. Podatci pod tim poljem mogu sadržavati stvarne poslužitelje imena za stranicu bankofsteve.com, ali u dodatnoj sekciji su navedene IP adrese napadača. Tu se događa trovanje priručne memorije jer ako Query ID odgovara onda će žrtva vjerovati da je napadačev poslužitelj imena autoritativan za stranicu bankofsteve.com. Ako napad uspije, napadač je vlasnik cijele zone.

2b. & 3. Žrtvin zahtjev za IP adresu i odgovor korijenskog/GTLD poslužitelja.

4. Žrtva šalje upit poslužitelju imena ns1.bankofsteve.com za IP adresu ww.bankofsteve.com te koristi Query ID = 1001.

5. Poslužitelj imena odgovara na zahtjev sa vrijednošću polja Query ID = 1001 i “ispravnim” odgovoro, ali ako je napadač pogodio Query ID u koraku 2a poruka se odbacuje.

6. U priručnoj memoriji poslužitelja imena se sada nalazi promjenjena IP adresa (npr. od poslužitelja imena napadača)

7. Svi daljnji upiti za kompromitirani poslužitelj imena dobiti će IP adresu poslužitelja imena napadača.

Tada napadač kontrolira cijelu zonu. Cilj procesa je bio uvjeriti žrtvu da je napadač vlasnik domene.

Ilustracija Kaminsky DNS napada:

Napadač će tipično postaviti vrlo veliku TTL vrijednost u trovajućem odgovoru tako da žrtva ima netočne podatke što duže u svojoj priručnoj memoriji.

Nužni uvjet uspjeha ovog napada je da napadačev odgovor mora doći do DNS poslužitelja prije nego stvarni odgovor, ukoliko se to ne dogodi napadačev odgovor će biti odbačen.

U primjeru je prikazano otimanje za jedan upit, ali nije vjerojatno da će ono biti uspješno. Zbog nasumičnog odabira Query ID vrijednosti polja, nije vjerojatno da će napadač uspjeti pogoditi vrijednost.

Napadač tada ponavlja upite, ali svaki put sa drukčijim imenom poddomene kako ne bi dobio odgovor iz priručne memorije. Svaki put napadač šalje određeni broj odgovor u nadi da će pogoditi Query ID.

Posljedice ovakvog napada su katastrofalne. Budući da napadač postaje vlasnik cijele domene, on kontrolira sve što se tiče poslužitelja imena. On može preusmjeravati posjetitelje na njegove poslužitelje te može preusmjeravati emailove na svoje poslužitelje

Akcije koje su poduzete nakon otkrivanja Kaminsky DNS problema nisu u potpunosti rješile problem već su značajno otežali napadaču da njegov odgovor bude prihvaćen. Ovaj napad je bio moguć zbog relativno malog broja vrijednosti polja Query ID.

Potrebno je dodati dodatan izvor nasumičnosti što se ostvarilo odabirom nasumičnog izvornog porta prilikom slanja poruke. Umjesto jednog porta, korišten je puno veći raspon portova alociran od strane poslužitelja imena.

Mircosoftovi DNS poslužitelji su alocirali 2500 UDP portova za izvršavanje upita što je značilo da napadač mora pogoditi jednu od 163840000 kombinacija u odnosu na jednu od 64000 kombinacija koliko je trebao pogoditi prije uvođenja ove promjene.

[1] Steve Friedl. An Illustrated Guide to the Kaminsky DNS Vulnerability

[2] Cory Wright. Understanding Kaminsky's DNS Bug

[3] Alexiou, Basagiannis, Katsaros, Dashpande, Smolka. Formal Analysis of the Kaminsky DNS Cache-Poisoning Attack Using Probabilistic Model Checking. IEEE, 2010.

[4] Gilad, Amir Herzberg, Shulman. Off-Path Hacking: The Illusion of Challenge-Response Authentication. IEEE, 2013.