2. 2
Cuprins
1. Introducere...........................................................................................................................3
2. Generalităţi...........................................................................................................................3
3. Caracteristici . Domenii şi DNS................................................................................................4
4. Pachetul DNS ........................................................................................................................6
5. Cache poisoning....................................................................................................................8
5.1 Detalii teoretice ..................................................................................................................8
5.2 Exemplu de otrăvire a site-ului legitim www.BankOfSteve.com............................................10
5.3 Soluţii pentru a împiedica otrăvirea....................................................................................11
6. Metasploit..........................................................................................................................11
7. Concluzii.............................................................................................................................12
8. Bibliografie .........................................................................................................................12
3. 3
1. Introducere
Marea ştire din domeniul securităţii informatice din vara lui 2008 a fost descoperirea
de către Dan Kaminsky a unei serioase vulnerabilităţi în DNS. Aceasta vulnerabilitate
poate permite unui atacator să redirecteze clienţii reţelei către servere alternative, cel mai
probabil pentru un scop rău intenţionat. Acest fapt a declanşat o adevărată isterie şi
grabă în a securiza serverele DNS din întreaga lume. În acest document, iniţial vom
prezenta câteva noţiuni generale despre serviciul DNS, urmând o explicare teoretică a
atacului (DNS cache poisoning) şi o încercare practică a acestuia.
2. Generalităţi
Un sistem de nume de domeniu (abreviat DNS, în engleză Domain Name System) este
un sistem distribuit de păstrare și interogare a unor date arbitrare într-o structură
ierarhică. Cea mai cunoscută aplicație a DNS este gestionarea domeniilor în Internet. DNS
translatează ("mapează") numele de domeniu (sau nume ale maşinilor de calcul) în adrese
IP şi adresa IP în nume. Translatarea numelui în adresa IP se numeşte "rezolvarea
numelui de domeniu".
Maparea este o simplă asociere între două elemente, în acest caz un nume de maşină,
ca ftp.linux.org, şi IP -ul maşinii (sau adresa) 199.249.150.4. De multe ori, un calculator se
identifică printr-o adresă, unică în Internet, numită adresa IP a calculatorului respectiv.
Totodată calculatorul poate avea asociat şi un nume. Astfel, adresa IP este utilizată la
nivelul programelor de prelucrare în reţea. În schimb, la nivelul utilizatorilor cu acces la
mediul Internet, identificarea calculatoarelor se face printr-un nume de calculator host
gestionat de sistemul DNS.
4. 4
3. Caracteristici .Domenii şi DNS
Caracteristicile sistemului de nume (DNS) sunt:
folosește o structură ierarhizată;
deleagă autoritatea pentru nume;
baza de date cu numele și adresele IP este distribuită.
Sistemul de nume din Internet este structurat pe domenii şi subdomenii. Considerând
un server de nume (name server) curs.ase.ro, domeniul cel mai larg este ro, care include
domeniul ase.ro, iar curs este un computer din cadrul domeniului ase.ro. Deci luând de la
dreapta la stânga un nume, pe cea mai din dreapta poziţie se află domeniul cel mai
general, după care urmează, în ordinea subordonării, restul subdomeniilor. Pe cea mai
din stânga poziţie se află numele computerului.
În Internet există domenii dedicate (standardizate). Iată câteva dintre ele: com
desemnează domeniul comercial, edu desemnează domeniul educaţional, gov - domeniul
guvernamental, mil - domeniul militar, org - alte organizaţii, net - resurse de reţea, int -
resurse internaţionale, etc.
Extinderea Internet-ului în diferite ţări a dus la crearea de domenii pentru fiecare ţară:
ro România, fr Franţa, it Italia, uk Marea Britanie, us USA, etc.
DNS este o bază de date distribuită pe toată reţeaua Internet. Se numeşte distribuită
deoarece nu există un singur server care să aibă toată informaţia necesară traducerii
oricărui domeniu într-o adresă IP. Fiecare server menţine o bază de date cu propriile
domenii pe care sistemele de pe Internet pot să o interogheze.
În Internet există servere (servere DNS) care ţin tabele de corespondenţă între numele
cunoscute de fiecare şi adresele fizice corespunzătoare. Fiecare server DNS are un server
DNS superior cu care face periodic schimb de informaţie. Sigur, trebuie să existe un
sistem care să se asigure că serverele DNS de pretutindeni au acces la aceeaşi informaţie
privind adresele IP ale siturilor şi domeniilor web. De aceea există sistemul de name
servere autoritare şiservere rădăcină.
5. 5
Servere DNS Autoritare: fiecare domeniu trebuie să aibă 2 servere DNS ce
funcţionează ca Autoritar şi Primar. Acestea sunt serverele ce păstrează cea mai
corectă şi adusă la zi informaţie privind adresa IP a unui domeniu. De obicei,
aceste servere DNS sunt operate de către deţinătorii domeniilor în cauză. Alte
servere DNS din internet vor face apel la name serverele autoritare pentru a le
furniza adresa corectă a domeniului pe web.
Servere DNS Rădăcină: următoarea parte a unui sistem DNS, sunt cele 13
servere DNS ce deţin informaţia 'top level' pentru întregul sistem DNS. Aceste
13 sisteme, operate de către mai multe companii private, instituţii academice şi
laboratoare militare, au sarcina de a propaga informaţia privind adresele IP a
fiecărui server autoritar al unui domeniu, către alte servere DNS de pe Internet.
Tipic, procesul de rezoluție a numelor se desfășoară astfel:
1. Name resolverul primește de la o aplicație client TCP/IP un nume; acesta
formulează o interogare primului server de nume din lista serverelor;
2. Serverul de nume (DNS) determină daca este mandatat (autorizat) pentru
domeniul respectiv (dacă există configurată o zonă DNS care conține numele
respectiv);
3. Dacă este autorizat, transmite răspunsul clientului;
4. Dacă nu, transmite o interogare altui server de nume pentru un răspuns
autorizat; obține răspunsul autorizat și transmite clientului un răspuns
neautorizat; totodată stochează răspunsul local pentru a răspunde la alte
cereripentru același nume.
5. Resolverul de nume transmite răspunsul aplicației utilizator și îl păstrează
într-un cache pentru o anumită perioadă;
6. Dacă name resolverul nu primește un răspuns într-un anumit timp, transmite
cererea următorului server de nume din listă. Când lista este epuizată, va
genera o eroare.
6. 6
4. Pachetul DNS
Pachetul DNS conţine foarte
multe informaţii, dar pentru a
explica atacul de tip cache
poisoning nu avem nevoie decât
de anumite câmpuri din pachetul
DNS. Câmpurile importante sunt
marchate în ilustraţie.
SourceDestination IP
address
Reflectă adresele IP ale
device-urilor care trebuie să
primească şi să trimită pachetele.
Este posibilă falsificare adresei
sursă, dar fără rost falsificarea
adresei destinaţie.
SourceDestination
port numbers
Serverele DNS ascultă pe portul 53/udp pentru interogări din exterior, aşa că primul
pachet al oricărui schimb va include întotdeauna 53 udp ca portul destinaţie.
Portul sursă variază considerabil(dar nu îndeajuns): căteodata este chiar 53/udp,
altădată este un port fixat ales aleator de către sistemul de operare, iar uneori este pur şi
simplu un port aleator care este schimbat în permanenţă.
Din punctul de vedere al funcţionalităţii DNS, portul sursă nu contează foarte mult,
atât timp cât mesajele de răspuns sunt rutate corect.
7. 7
Query ID
Acest identificator unic este creat pentru pachetul de interogare care este lăsat
nemodificat de către serverul care trimite un răspuns: permite serverului ce face o
interogare să asocieze răspunsul cu întrebarea.
Un server de nume poate avea mai multe interogari în curs de desfăşurare în acelaşi
timp -- chiar multiple interogări către acelaşi server -- aşa că acest câmp asociază
răspunsul pentru fiecare interogare. Acest câmp mai este numit şi Transaction ID (TXID)
QR (QueryResponse)
Este setat 0 pentru o interogare a clientului şi 1 pentru un răspuns al serverului.
Opcode
Setat 0 pentru o interogare standard.
AA (Authoritative answer)
Setat 1 dacă răspunsul serveruluieste autoritativ si 0 în caz negativ.
TC (Truncated)
Setat 1 dacă răspunsul serverului nu încape în limita de 512-bytes a
răspunsului(datagramă udp); clientul va trebui să reîncerce aceeaşi interogare utilizând
TCP.
RD (Recursion Desired)
Clientul setează acest câmp la valoarea 1 dacă doreşte ca serverul să facă întreagă
căutare a numelui în mod recursiv.
RA (Recursion Available)
Serverul setează valoarea în funcţie de posibilatatea acestuia de a face căutări
recursive(1 sau 0)
8. 8
5. Cache poisoning
5.1 Detalii teoretice
Odată ce am primit un răspuns autoritativ pentru un anumit nume, îl putem salva în
cache-ul local, pentru a satisface interogările viitoare. Otrăvirea cache-ului este
evenimentul în care un utilizator rău intenţionat reuşeşte să injecteze date false în cache-
ul unui server recursiv de nume, făcându-l sa răspundă la interogări ulterioare cu
informaţii incorecte. Clienţii nu bănuiesc nimic.
Nu e atât de simplu ca a trimite doar pachete aleatoare DNS la un server de nume,
deoarece DNS acceptă numai răspunsuri la întrebările în curs; răspunsurile neaşteptate
sunt pur şi simplu ignorate. Cum ştie un server de nume că un packet de tip răspuns este
"aşteptat"?
Răspunsul soseşte pe acelaşi port UDP pe care am trimis interogarea: în caz
contrar, stiva de protocoale nu ar livra la procesul corespunzător serverelui de
nume (este aruncat).
Secţiunea Question (duplicată în răspuns) se potriveşte cu Question din
interogarea în aşteptare.
Câmpul Query IDse potriveşte cu cel din interogare
Secţiunile Authority şi Additional reprezintă nume care se află în acelaşi
domeniu ca şi întrebarea: acest lucru este cunoscut ca "bailiwick checking".
Dacă toate aceste condiţii sunt satisfăcute, un nameserver va accepta pachetul ca
răspuns autentic la interogare, şi va folosi rezultatele conţinute. Dacă un atacator poate
prezice şi falsifica raspunsul DNS, el ar putea cauza un adevărat dezastru pentru victime.
Atacatorul îşi alege în general vicitima prin găsirea unui nameserver ce el crede că este
vulnerabil la otrăvire. Apoi el caută un target domain, unul pe care el doreşte să-l
deturneze. Intenţia acestuia este de a păcăli victimele în a visita site-ul lui maliţios, şi nu
cel real: numele www.goodsite.com va fi rezolvat în adresa ip a atacatorului, iar traficul
userului va vizita site-ul hackerului.
Am menţionat că pachetele ce nu sunt aşteptate sunt pur şi simplu aruncate, astfel, un
atacator nu trebuie să nimerească totul de fiecare dată: trimiţând multe pachete şi
încercând să ghicească câţiva din parametrii cheie este posibil ca la un moment dat să
reuşească.
9. 9
În serverele de nume mai vechi, Query ID-ul este pur şi simplu incrementat cu 1 la
fiecare cerere de tip outgoing, astfel devine foarte uşor să ghicim care va fi următorul atât
timp cât putem intercepta o interogare.
Nu putem întreba direct serverul pentru a afla Query ID-ul, dar îl putem "convinge"
să-l divulge:
1. Atacatorul roagă nameserverul victimă să caută un anumit nume într-o zonă pe
care el o controlează(exemplu test.badguy.com). El ar putea interoga serverul în
mod direct, dacă este permisă recursivitatea de la locaţia acestuia, sau ar putea
convinge un user să caută un nume.
2. Nameserverul victimă primeşte cererea şi porneşte în mod uzual la serverele
root.
3. În cele din urmă, nameserverul victimă va fi direcţionat către nameserverul
atacatorului: doar este autoritativ pentru badguy.com.
4. Atacatorul urmăreşte această căutarea pentru test.badguy.com prin sniffing-ul
traficului îndreptat către calculatorul propriu. Astfel el află ultimul Query ID
folosit şi poate porni otrăvirea cache-ului.
Cu această abilitate de a prezice uşor Query ID-ul şi continuând cu faptul că NS-ul
vicitimă trimite cereride la acelaşi port udp, este foarte uşor cauzarea unor probleme.
10. 10
5.2 Exemplu de otrăvire a site-ului legitim www.BankOfSteve.com
Pasul 1 - Atacatorul trimite o
cerere DNS către NS-ul victimă
pentru numele ce doreşte să-l
deturneze. Acest exemplu
presupune că NS-ul victimă
permite interogări recursive din
exterior.
Pasul 2a - Cunoscând faptul că
victima va întreba în curând
ns1.bankofsteve.com(aşa cum
anunţă serverele root) pentru o
adresă IP, atacatorul începe să
trimită către victimă o serie mare
de răspunsuri DNS falsificate.
Toate apar ca fiind trimise de
ns1.bankofsteve.com, dar includ
răspunsul cu adresa IP dată de
atacator.
Pasul 2b şi 3 - Serverele
ROOT/GTLD furnizează referinţe
către ns1.bankofsteve.com. Acestea
pot fi cererimultiple.
Pasul 4 - Nameserverul victimă îbntreabă ns1.bankofsteve.com pentru adresa IP a
www.bankofsteve.com, folosind Query ID1001 (cu 1 mai mult decât precedenta cerere).
Pasul 5 - Nameserverul adevărat furnizează un răspuns legitim, cu QID=1001. Dar
dacă atacatorul reuşeşte să ghicească QID-ul în pasul 2a, acest răspuns autentifc va fi
primit prea târziu şi ignorat.
Pasul 6 - Adresa IP falsă va fi trimisă către clienţii DNS.
11. 11
Regula este primul răspuns corect căştigă. Majoritatea răspunsurilor falsificate sunt
aruncate deorece Query ID-ul nu se potriveşte, dar dacă doar unul din mesaje este corect,
serverul de nume va accepta răspunsul ca fiind autentic. Astfel, răspunsul adevărat va fi
aruncat deorece ajunge prea târziu. Este evident că numele pe care atacatorul doreşte să-l
otrăvească nu trebuie să se afle în cache.
O metodă evidentă pentru a atenua această situaţie este de a face QID-ul aleator.
Folosind Query ID-uri în mod secvenţial, atacatorul are o gamă foarte limitată de valori
din care să ghicească atunci când poate intercepta un QID.. Dacă el interceptează
QID=999, atunci el poate flooda cu QID-urile 1000-1029 în încercarea de a obţine un
rezultat bun. Experienţa a demonstrat că acest lucru este în general uşor de realizat.
Dar dacă serverul de nume alege QID-ul în mod aleator, atunci atacatorul are o gamă
de 16-bit din care trebuie sa aleagă. Acest lucru înseamnă peste 64000 de valori -- un
lucru mult mai dificil de realizat în perioada scurtă pentru rezoluţia de nume.
5.3 Soluţii pentru a împiedica otrăvirea
Aşa cum s-a evidenţiat, spatiul mic de 16-bit este una din principalele cauze pentru
care acest atac este posibil. Deşi prima soluţia la care o persoană s-ar putea gândi e
mărirea spaţiului, acest lucru nu este posibil fără afectarea întregului sistem DNS din
Internet: aceste câmpuri nu se pot modifica deodată.
O altă sursă care introduce o componentă aleatore este necesară, iar acest lucru se
realizează prin folosirea de port-uri sursă aleatoare. Decăt să folosim un singur port udp
(descoperirea lui se face într-un mod trivial), mai degrabă folosim o gamă mult mai mare
de porturi alocate de către serverul de nume pe care să le folosim în mod aleator în cereri
de tip outbound. Aşa cum ne putem imagina, serverul de nume va trebui să ţină evidenţa
portului sursă pentru fiecare cerere: răspunsurile primite pe portul greşit sunt aruncate
exact ca la problema QID-ului. Serverul DNS al companiei Microsoft poate prealoca 2500
porturi udp pentru cereri aleatoare. Un exemplu ar fi 211 = 2048. Acest lucru duce către
spaţiul mult mai mare de: 21 6 x 211 = 227 = 134 milioane.
Mărirea spaţiului de căutare de la 64k la 134M face ca şansele să scadă pentru atacator.
6. Metasploit -Experiment
Metasploit Framework este un proiect open-source pentru testrarea vulnerabilitățiilor
diferitelor servicii. Cu ajutorul acestui utilitar, utilizatorul poate genera atacuri asemenea
unui hacker și astfel putând identifica breșe de securitate. Utilitarul dispune de module
folositoare pentru generarea unor atacuri specifice, cum ar fi: DNS Cache Poisoning, Man
In The Middle, sniffing etc.
12. 12
Atacul Kaminsky poate fi generat cu ajutorul modului bailiwicked_domain din cadrul
softului Metasploit. Un exemplu de configurare pentru atac este:
msf> use auxiliary/spoof/dns/bailiwicked_host
msf auxiliary(bailiwicked_host)> set hostname www.nume_tinta.com
msf auxiliary(bailiwicked_host)> set newaddr [ip-otravit]
msf auxiliary(bailiwicked_host)> set recons [ip-dns_root]
msf auxiliary(bailiwicked_host)> set rhost [ip_server-tinta]
msf auxiliary(bailiwicked_host)> set srcport 0 (auto)
msf auxiliary(bailiwicked_host)> run
7. Concluzii
Această extrem de serioasă vulnerabilitate subminează încrederea pe care o aveam cu
toţii în DNS, un serviciu care stă chiar la baza Internet-ului. Mulţi experţi cred că dacă nu
poţi avea încredere în DNS, totul este pierdut. Astfel că recomandarea acestora este
schimbarea versiunii serverul DNS pe care un utilizator îl deţine cu una ce nu poate fi
exploatată de această vulnerabilitate.
8. Bibliografie
1. Steve Friedl’s Unixwiz.net Tech Tips – An Illustrated Guide to the Kaminsky Attack
2. DNS and BIND, Fifth Edition – Cricket Liu, Paul Albitz – O’Reilly Media
13. 13
3. DNS & BIND Cookbook – Cricket Liu
4. DNS Cache Poisoning – Chris Racki, CMPT-585 Dr. Robila 8 Dec 2008
