Sigurnost i propusti u DNS infrastrukturi
Sadržaj |
Uvod
Domain Name System (DNS) je tehnička uzdanica interneta,
ali se suočava sa značajnim izazovima koji su prisutni zbog rasta i osiguranja.
Internet ovisi o DNS-u; kada ne radi, ne radi ni internet.
Organizacije današnjice ne ovise samo o internet DNS-u več i o vlastitom DNS-u,
i kad im se DNS sistem poremeti, ruše se i njihove aplikacije.
Problem rasta
Kako su "pametni" telefoni postali sveprisutni kroz zadnje desetlječe,
broj internet korisnika povečao se 5 puta, na broj od oko 2.6 milijardi.
Forrester predviđa da do 2016. godine, diljem svijeta će biti preko milijarda "pametnih" telefona,
i velika količina aplikacija koja će se koristiti 4G i LTE mrežama će dovesti do velikog porasta u DNS prometu.
Povečani broj stranica za zabavu, socijalnih servisa, pretraživača i online kupnje
također stavlja pritisak na DNS. U zadnjih 5 godina, količina DNS upita narasla je 200%
-prosječna dnevna količina upita u prvom kvartalu 2011 je bila nevjerovatnih 57 milijardi.
Kako stranice i aplikacije postaju bogatije sadržajem i sofisticiranije, teret na DNS se povečava.
Za primjer, na modernoj web stranici, svaka slika, botun, dodatak, poveznica,
ikona i drugi ugrađeni sadržaj ima potencijal da mu se IP adresa mora potražiti.
Nije rijetko da jedna stranica zahtjeva preko 20 različitih DNS upita.
Uzmimo za primjer cnn.com, ta stranica koristi preko stotinu DNS zahtjeva.
Dakle velike, kompleksnije stranice zahtjevaju povečan broj upita.
Problem sigurnosti
Gotovo se svi klijenti oslanjaju na DNS prilikom pristupa potrebnim servisima,
što čini DNS najkritičnijim i najviše izloženim servisom.
DNS prekidi utječu na sve vanjse servise podatkovnih centara, a ne samo jedne aplikacije.
Baš to što je jedna točka za sve prekide, skupa sa arhitekturom kojom je izvedena,
posebno u podatkovnim centrima, je čine jako privlačnom metom za DNS napade.
Postao je drugi najčešči oblik DDoS napada, što tjera organizacije na pojačane mjere opreza.
Jednako važna je činjenica da financijski najopasniji napadi, kao što su phishing,
i MITM napadi počinju manipuliranjem DNS-a. DNSSEC (domain name system security extensions)
cilja na adresiranje tih problema, ali dodana kompleksnost se pokazuje kao teret organizacijama
koje se ionako več muče s problemima ubrzanog rasta i obranom od Ddos napada.
Tradicionalne mjere opreza, kao blokatori preko alatnih traka se oslanjaju na DNS servise,
pa kada su ti servisi ometani, mjere sigurnosti mogu zakazati.
Isti problemi do neke mjere postoje sa SSL certifikatima.
Organizacije moraju uzeti u obzir sva riješenja da bi osigurali neomatane performanse
i sigurnost interneta današnjice, ali i budučnosti.
(izvor: David Holmes, Senior Technical Marketing Manager)
Terminologija
Prije nego se upoznamo s radom DNS-a, moramo definirati neke termine radi lakšeg razumijavanja.
Neki propušteni detalji neće biti važni za razumijevanje daljnjeg teksta.
Zona
Možemo misliti o ovome kao o domeni: kolekcija naziva servera/IP adresa skupa spojenih.
"Nameserver"
ovo je serverski software koji odgovara na DNS upite, kao što su "koja je IP adresa za www.foi.hr?".
Ponekad nameserver zna odgovor direktno (ako je "autoritativan" u toj zoni),
u drugim slučajevima mora ići vani u internet i raspitivati se da bi našao odgovor
(ukoliko je riječ u rekurzivnom Nameserveru).
Postoje razni softveri koji izvršavaju ovu uslugu: BIND, PowerDNS, djbdns i drugi.
Svi odgovaraju na isto pitanje na manje više jednak način.
Autoritativni Nameserver - "Authoritative Nameserver"
Za svaku zonu, netko mora održavati listu imena servera i pripadajučih IP adresa
( "www.foi.hr ima adresu 161.53.120.192", itd.).
To je inače administrativna radnja koju obavlja pojedinac, i u večini slučajeva jedno računalo ima tu datoteku.
Zone s večim brojem javnih Nameservera imaju administrativna uređenja za transfer
zonskih podataka automatski na podređene servere, od kojih je svaki autoritativan.
Razlika između spomenutog nadređenog i podređenog je nebitna za razumijevanje teksta u nastavku.
Resolver
On se nalazi na klijent strani DNS sistema: postavlja pitanje o imenima servera.
Rezolver je najčešće mala knjižnica podataka kompajlirana u programima koji koriste DNS usluge,
i zna tek dovoljno da šalje upite Nameserverima.
Na Linux/UNIX sistemima, lokacija traženih servera se nalazi u file-u: "/etc/resolv.conf",
a u Windows okruženju podešava se u mrežnim konekcijama - kontrolne ploče.
To inače izgleda kao lista IP adresa, kraj kojih se nalaze imena servera.
Rezolveri su inače mali i jednostavni, oslanjaju se zapravo na servere za obavljanje težih zadača.
Rekurzivni Nameserver
To je Nameserver koji izlazi na internet i traži rezultate za zone koje nije autoritativan,
kao servis za svoje klijente. Nisu svi Nameserveri konfigurirani da pružaju uslugu rekurzije,
neki mogu biti i limitirani da pružaju uslugu samo svojim klijentima (pružatelj internet usluge može se ograničiti samo na svoje klijente).
Zapis o resursima - "Resource Record"
Iako će većina pomisliti da DNS služi samo za mapiranje imena servera / IP adrese,
postoje i zapravo i drugi upiti koje ih možemo poslati, što znači da je DNS zapravo baza podataka "zapisa o resursima".
Najčešći tim je IP adresa ("A" zapis), ali postoje i drugi zapisi: NS (Nameserver), MX (mail exchanger), SOA (Start of Authority), itd.
Delegati
Kada Nameserver nema zapise o traženoj zoni, ali zna kako pronači vlasnika zone,
tada daje adresu tog drugog Nameservera. Neformalno radi se o nekakvoj vrsti proslijeđivanja:
"Ja imam podatke o zoni koju tražim, evo ti podaci za daljnju potragu".
--Jglavan 14:47, 12. lipnja 2013. (CEST)
Jednostavan DNS upit
S ovih par objašnjenih pojmova, možemo sada pogledati kako jedan jednostavan rekurzivan upit izgleda,
bez prisutnosti bilo kakvih anomalija, te ćemo kasnije pogledati gdje tu može doći do iskorištavanja.
Iako se Dns paket sastoji od mnogo polja, preskočit ćemo večinu jer nisu bitni za razumijevanje osnovnog načina fukncioniranja sistema.
Vizualiziranje kako delegiranje skače s jednog servera na drugi je od vitalne važnosti da bi razumijeli kako se propusti iskorištavaju.
Na slici vidimo da je korisnik ping-ao web-server, i ping je poslao upit Nameserveru za pregled web-naziva/IP adrese.
To se isto moglo napraviti pisanjem "http://www.unixwiz.net" u adresnoj traci web pretraživača.
Nije nam važno zašto se ime pretražuje već kako.
1. Klijent s nazivom "user's PC" radi zahtjev za "www.unixwiz.net", i usmjeren je na Nameserver kojeg mu pruža ISP.
On traži A zapis, što predstavlja IP adresu. ISP Nameserver zna da nije autoritativan za "unixwiz.net",
te nemože pogledati u lokalnu bazu podataka za taj zapis. Isto tako ne nalazi zapis u svojoj cache-memoriji,
te zna da mora izači vani na internet u potragu.
2. Sve rekurzivni Nameserveri se prekonfigurirani s listom 13 izvornih servera, selekcija izgleda ovako:
*A.ROOT-SERVERS.NET. IN A 198.41.0.4 *B.ROOT-SERVERS.NET. IN A 192.228.79.201 *C.ROOT-SERVERS.NET. IN A 192.33.4.12 *... *M.ROOT-SERVERS.NET. IN A 202.12.27.33
Srečom ove IP adrese se ne mijenjaju često. Nameserver bira nasumično jednu adresu
i šalje joj upit zapisom "www.unixwiz.net"; na primjeru ovdje taj upit se šalje na "b.root-servers.net"
3. Root-server nema nikakve informacije o unixwiz.net-u,
ali će nas rado preusmjeriti na GTLD (global top level domain) servere,
odgovorne za .net domenu. Ovo je oblik NS zapisa liste servera kvalificiranih da odgovore na naš upit:
/* 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
Iako smo tehnički tražili samo imena servera, root-server nam daje i IP adrese svakog servera:
odnosno priljepljuje ih, što nam skračuje vrijeme ponovnog traženja IP adresa.
4. Uz pomoč root-servera, naš Nameserver izabire jednog od autoritativnih servera nasumično,
ovdje je to c.gtld-servers.net - i šalje mu isti upit,
odnosno njega sada pita isto pitanje za A zapis o "www.unixwiz.net"-u.
5. GTLD server nezna točnu adresu za naš upit, ali zna kako da nas približi cilju.
Kao i root-serveri, šalje nam nazad listu NS zapisa, koji će vjerovatnije imati podatke koji nama trebaju.
*/* Authority section */
unixwiz.net. IN NS cs.unixwiz.net.
IN NS linux.unixwiz.net.
/* Additional section - "glue" records */
cs.unixwiz.net. IN A 8.7.25.94
linux.unixwiz.net. IN A 64.170.162.98
6. Ponovno kao i prije naš Nameserver prati lanac referentnih servera na zahtjev klijenta,
i opet nasumično izabire jednog od Nameservera i po treči put šalje upit, koji je isti kao i prošli.
7. Za razliku od drugih odgovora, koji prebacuju upit na druge Nameservere,
ovaj zapravo ima informaciju koju mi tražimo: te nam daje A zapis za "www.unixwiz.net".
U dodatku na tu informaciju, šalje nam potvrdu da se radi o autoritativnom odgovoru,
što indicira da je odgovor došao sa servera koji je odgovoran za tu domenu, i da je neupitno točan.
8. Sada s raspoloživim odgovorom, ISP-ov rekurzivni Nameserver daje odgovor nazad klijentu, i upit je zadovoljen.
Rekurzivni Nameserver isto tako pohranjuje odgovor u cache-memoriju
u slučaju da isti ili neki drugi klijent kasnije bude imao isti upit.
Ali treba napomenuti da odgovor klijentu ne uključuje indikator da se radi o autoritetu,
iako je primljen od strane cs.unixwiz.net, rekurzivni Nameserver se dakle
nemože postavljati klijentu kao izvor autoriteta, te se smatra ne-autoritativnim odgovorom.
Ova procedura se dešava na trilijune puta dnevno, bez da smo svjesni.
Sistem je dosta brz, tako da se ovih 8 koraka izvrši u djeliću sekunde.
Ovo otkriva prirodu DNS arhitekture: ni jedno računalo nema sve informacije,
ali znaju kako doći jedan do drugoga.
--Jglavan 14:54, 12. lipnja 2013. (CEST)
Što je DNS paket?
Sa shvačanjem osnova DNS sistema, idemo malo detaljnije objasniti što je DNS paket:
detalji su potrebni da bi shvatili otrovanje cache-memorije.
Imamo mnogo detalja, ali srečom večina nije potrebna za razumijevanje daljnih problema.
Slika desno prikazuje strukturu jednog DNS paketa podataka,
i prikazuje paket upita ili odgovora.
Source / Destination IP adrese
Prikazuje IP adrese računala koji šalju i primaju zahtjeve.
Moguče je krivotvoriti adresu pošiljatelja, ali je uzaludno krivotvoriti primaoca.
Source / Destination port brojevi
DNS serveri prate port 53/udp za upite iz vani, tako da prvi paket svake izmjene
je uvIjek usmjeren na taj port. Port pošiljatelja dosta varira (ali ne dovoljno što ćemo kasnije vidjeti):
ponekad je to isto port 53/udp, ponekad je fiksni port odabran od strane OS-a, a ponekad je nasumično odabran.
Što se tiče funkcionalnosti DNS-a, port pošiljatelja nije važan dokle god odgovori stižu nazad na njega ispravno.
Vidjet ćemo kasnije da je to srž problema.
ID upita - "Query ID"
Ovo je jedinstven indetifikator kreiran u paketu kojeg server ne mijenja:
omogučuje serveru da spoji odgovor s upitom kasnije.
Nameserver može imati više upita u isto vrijeme - čak i više njih za isti server
- tako da ID upita pomaže pri uparivanju odgovora s pitanjem.
Upit / Odgovor - "Q/R"
Vrijednost je 0 za upit od klijenta, 1 za odgovor od servera.
"Opcode"
Vrijednost je 0 za standardan upit.
Autoritativni odgovor - "AA"
Vrijednost je 1 ako je izvor autoritativan, 0 za obrnuto.
"TC" (Truncated)
Vrijednost je 1 ako ako odgovor servera nemože stati u 512-bitni okvir UDP odgovora;
što znači da klijent mora pokušati ponovno sa TCP upitom, koji ima drugačija ograničenja.
Rekurzija - "RD" (Recursion Desired)
Klijent stavlja vrijednost na 1 ako želi da server obavi cijelu pretragu rekurzivno,
ili 0 ako želi samo najbolju informaciju koju server ima a klijent će dalje nastaviti potragu sam.
Samo neki serveri imaju omogučenu rekurziju, Root serveri nisu među njima za primjer.
Rekurzija na raspolaganju - "RA (Recursion Available)"
Vrijednost 0 ili 1, što indicira mogučnost servera za rekurziju.
Z - rezervirano
Rezerviran znak, mora biti 0.
"rcode"
Odgovor od servera, označava uspjeh ili neuspjeh.
Broj upita - "Question record count"
Klijent ispunjava s upitom, odnosno što on traži zapravo:
uključuje ime (www.unixwiz.net), tip (A, NS, MX, itd.), i klasu koja je inače IN=Internet.
Server ponavlja pitanje u "response" paketu, tako da je "question count" gotovo uvjek 1.
"Answer/authority/additional record count"
Postavljeno od strane servera, pruža razne odgovore na upit klijenta.
"DNS Question/Answer data"
U ovom dijelu se nalaze podatci spomenuti iz "Question count" polja prije spomenutog.
Tipovi zapisa
Možemo reči da je DNS oblik distribuirane baze podataka, i svaki upit ili odgovor uključuje ime,
tip, i vrijednost odgovora.
Tipovi zapisa imaju različite namjene, i razumijevanje DNS-a nije moguče bez da znamo sve o njima.
Postoje deseci tipova zapisa, iako se samo njih par koristi.
Ostali su eksperimentalni, zastarjeli ili služe za neke stvari koje se jako rijetko koriste.
Najčešći tipovi DNS zapisa
A Ovaj zapis predstavlja IP adresu, i najočitiji je podržani tip.
Mnogi korisnici ni neznaju da se DNS koristi i za druge stvari.
NS Predstavlja zapis o Nameserveru odgovornom za domenu koju tražimo.
MX MX zapis čuva informacije o Mail Exchangeru, sistemu odgovornom za rukovanje e-mailom za danu domenu.
Više MX zapisa može biti pruženo za jednu domenu.
SOA „Start of Authorities“ – Opisuje i pruža neke ključne podatke vezane za samu zonu.
Uključuje kontakt adresu administratora, i vrijeme za koje bi računala trebala biti spojena
na zonu ukoliko glavni server nije dostupan.
CNAME „Canonical Name“, poznatiji kao Alias, pruža zamjenski naziv za resurs.
TXT Standardni Text zapis koji pruža opisne podatke o domeni. To su u biti komentari.
Opčenito je dozvoljeno da jedno ime ima više zapisa, čak i više zapisa za isti tip podatka. Čest primjer bi bio zapis za računalo koje ima više IP adresa, za primjer:
www.example.com. IN A 192.168.1.3 www.example.com. IN A 192.168.7.149
Ovdje vidimo da gornji primjer ima dva IP zapisa asociranih za jedno ime, i oba dva zapisa će se vratiti u odgovoru za A upit. Njihov redoslijed nije specificiran, tj. pomiješanog su redoslijeda.
Cache memorija - što se nalazi unutra?
U DNS pretraživanjima koja smo gledali do sad, ISP-ov Nameserver je išao vani na internet
i u potpunosti riješio svaki naš upit, ne oslanjajuči se na ikakvo znanje osim na pomoč od root-servera.
Ali u praksi cijeli taj krug operacija nije potreban: jednom kad dobijemo autoritativan odgovor za traženi naziv,
možemo taj isti odgovor pohraniti u lokalnom cacheu, da bi sljedeće upite izravno zadovoljili.
Što veći broj klijenata uslužen od strane Nameservera, veća je korist od cache-a,
istina je da treba veča količina memorije, međutim korist je velika.
Vrijeme trajanja - "TTL"
Kada se DNS odgovor pohrani u lokalnu memoriju, nemože ga čuvati tamo viječno:
to bi moglo voditi zastarjelih podataka i oštetiti uključene domene.
Srečom, rekurzivni Nameserver netreba pogađati koliko dugo da čuva podatke:
administrator zone specificira potrebnu informaciju za svaki zapis. To vrijeme zovemo TTL.
Na slici ispod vidimo različita vremena trajanja TTL-a, koje može trajati od par sekundi,
do tjedna ili više. Što je još bitno za napomenuti da možemo čuvati i podatke o drugim vrstama zapisa.
Trovanje cache-memorije
S doneklim razumijevanjem funkcioniranja DNS-a, vrijeme je da pogledamo gdje stvari prestaju funkcionirati.
Trovanje memorije je gdje napadač uspjeva ubaciti neispravne podatke u memoriju rekurzivnog servera,
što uzrokuje da isti taj server daje neispravne podatke klijentima.
Nije toliko jednostavno kao slanje DNS paketa Nameserveru,
pošto DNS prihvača samo odgovore za več poslane upite; neočekivani odgovori bivaju ignorirani.
Ovo nije "phishing" !!!
S DNS trovanjem memorije, sama priroda DNS-a samog je potkopana na način da rezultatima
hostname-IP upita nemožemo više vjerovati.
Stranice koje tada posječujemo su ispravne, ali se preusmjerava s njih na neki drugi server:
to se nemože detektirati pregledom linkova i HTML koda.
Kako nameserver zna da treba očekivati odgovor?
- odgovor dolazi na isti UDP port s kojeg je poslan: u suprotnom paket se ignorira
- sekcija "question" koja se duplicira u odgovoru odgovara "question"-u poslanog paketa
- "Query ID" odgovara jedno drugomu
- vrijednosti polja "Authority" i "Additional sections" odgovaraju imenima domena pitanja
Što onemogučuje ns.unixwiz.net da odgovori na adresu "www.unixwiz.net" s nekim drugim adresama također.
Ako su svi uvijeti zadovoljeni, Nameserver će prihvatiti paket kao izvorani odgovor na upit,
i iskoristiti informaciju iz paketa.
Ali ako napadač može predvidjeti i krivotvoriti DNS odgovor može prouzročiti svakakve probleme žrtvama.
Napadač inače prvo izabire žrtvu tako da nađe Nameserver za koji vjeruje da je ranjiv na trovanje:
u tom postupku svi drugi korisnici koji pripadaju istom Nameserveru trpe posljedice.
Zatim odabire domenu koju želi preuzeti. Namjera mu je da zavara žrtve tako da posječuju njegovu moguče malicioznu
stranicu umjesto pravu.
Pogađanje ID-a upita
Na starim Nameserverima ID upita se jednostavno povečavao za jedan za svaki izlazni zahtjev, i to čini pogađanje dosta lakšim.
Nemožemo direktno pitati NS za trenutni "query ID", ali ga možemo izazvati da nam ga kaže:
- Napadač šalje upit NS-u za ime u zoni koju on kontrolira ("test.badguy.com")
Može poslati upit direktno, ako NS dozvoljava rekurziju s njegove lokacije,
ili može na neki način nagovoriti korisnika da pristupi toj istoj stranici. - Žrtvin NS prima zahtjev i koristi se klasičnim koraciam da riješi upit.
- Eventualno, žrtvin NS će biti usmjeren na NS napadača: na poslijetku on je autoritativan za njegovu stranicu.
- Napadač na razne načine nadzire pakete sa svog NS-a, i ulazi u trag "port"-u i "query ID"-u korištenom.
U ovom trenutko napadač ima potrebne informacije za krenuti u napad! ---> CHARGEEEE !!!
Početak trovanja
S potrebnim informacijama, napadač sada može krenuti u napad.
Napadač šalje DNS upit žrtvinom NS-u za stranicu koju želi "preoteti".
Potrebna je rekurzija na dotičnom NS-u. Znajuči da će žrtvin NS poslati upit root/GTLD serverima, on počinje bombardiranje s krivotvorenim paketima.
Dok NS čeka "ispravne odgovore" od tih servera, postoji mogučnost da je jedan od DNS paketa napadača uspio zavarati
sistem, te je cache memorija uspješno zaražena.
Jer pravilo kaže, prvi ispravan odgovor pobijeđuje. Večina paketa napadače ispadne,
jer imaju krivi "Query ID" ali u moru paketa, jedan će biti ispravan,
i NS će ga prihvatiti kao ispravnog.
Postoje neki problemi na koje napadač može naiči, a to su:
- rezultat upita je več u memoriji
- odabir "Query ID" je nasumičan
- brzina odnosno udaljenost NS i tražene domene
Zaključak
Ovo je jako ozbiljna ranjivost sistema, jer potkopava osnovno uzdavanje u DNS sistem i internet, neki kažu ako nemožeš vjerovati DNS-u da je sve izgubljeno, s ćim se možemo i donekle složiti. Ono što možemo reći za kraj:
- zakrpajte servere, jer postoje alati s kojima ih i amateri mogu ugroziti
- autoritativni serveri se nemogu zaraziti, jer ne koriste cache-sistem
- SSL certifikat može biti od koristi, međutim malo tko ide za tim da se radi o krivom certifikatu
Literatura
www.unixwiz.net
--Jglavan 12:14, 12. lipnja 2013. (CEST)
