Laborator 11
Tematica laboratorului
- Chestiuni generale legate de functionarea DNS si DNSSEC
- Generalitati privind accesarea serviciilor DNS in cadrul Linux
- Atacuri asupra DNS cu acces la mediu
- Atacuri asupra DNS in mod blind
Chestiuni generale legate de functionarea DNS si DNSSEC
Vom descrie in cele ce urmeaza cateva chestiuni de baza utile in explicarea atacurilor asupra DNS, cum ar fi formatele inregistrarilor si ale interogarilor.
Nu ne propunem o descriere integrala a aspectelor legate de functionarea efectiva a DNS sau DNSSEC.
In acest sens recomandam consultarea RFC-urilor asociate.
Serviciul de rezolvare a numelor de domenii e accesabil in mod obisnuit la portul 53 - atat UDP cat si TCP.
Pentru interogarile obisnuite se foloseste in mod normal UDP, in cazul in care raspunsurile depasesc o valoare de 512 octeti acestea fiind in mod normal trunchiate iar interogarea se poate reface prin TCP.
Formatul standard pentru o inregistrare, ce contine informatii despre un nume de domeniu, la nivelul unui server DNS este urmatorul (conform RFC 1035):
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- Name - lungime variabila - numele de domeniu
- Type - 2 octeti - tipul inregistrarii (A - adresa IP asociata numelui, NS - serverul de nume pe un anumit domeniu, etc)
- Class - 2 octeti - clasa inregistrarii (uzual IN - Internet)
- TTL- 4 octeti - timpul in secunde pentru care inregistrarea este considerata valida la nivelul serverului DNS
- RDLength - 2 octeti - lungimea campului de date al inregistrarii
- RData - lungime variabila - continutul efectiv de informatie al inregistrarii
O interogare DNS consta in trimiterea unei cereri pentru o inregistrare (RR) sau mai multe din baza de date DNS de la nivelul serverului. Raspunsul consta fie in respectiva inregistrare, fie in esec. Formatul pachetului atat pentru cerere cat si pentru raspuns este urmatorul:
+---------------------+ | Header | +---------------------+ | Question | the question for the name server +---------------------+ | Answer | RRs answering the question +---------------------+ | Authority | RRs pointing toward an authority +---------------------+ | Additional | RRs holding additional information +---------------------+
Un header pentru un mesaj DNS contine urmatoarele informatii:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- ID - identifica o interogare, si stabileste o corespondenta intre o cerere trimisa si un raspuns primit
- QR - 0 in caz ca e vorba de un mesaj de cerere, 1 in caz ca e vorba de un mesaj de raspuns
- Opcode - tipul de query (0 pentru interogare standard)
- AA - conditia serverului ce furnizeaza raspunsul - 0 daca vine din partea unui server de autoritate pe domeniul respectiv (ce are configurate direct informatiile despre domeniu), 1 in caz contrar (serverul apeleaza la o interogare DNS la randul sau pentru a furniza informatiile)
- TC - bit de trunchiere - 1 in cazul in care raspunsul a fost scurtat la dimensiunea de 512 octeti, caz in care se poate reface interogarea prin TCP, 0 in caz contrar
- RD - 1 indica intr-o cerere faptul ca se doreste ca aceasta sa fie rezolvata recursiv daca exista posibilitatea
- RA - 1 indica intr-un raspuns faptul ca serverul are posibilitatea de interogare recursiva, 0 in caz contrar
- Z - bit rezervat pentru utilizari ulterioare
- AD - specific DNSSEC - Authenticated Data, in esenta indica faptul ca semnaturile au fost verificate; modul de setare si statiile ce pot seta acest bit ce intra in cadrul hopurilor ce trateaza o interogare precum si alte detalii pot fi consultate in RFC 3655
- CD - specific DNSSEC - Checking Disabled, in esenta indica faptul ca un resolver nu va tine cont de verificarile de autenticitate ale serverului DNS (care poate realiza aceasta in special cand e vorba de o interogare recursiva) in ideea ca resolverul e cel ce va realiza aceste verificari
- RCode - codul de eroare pentru un raspuns (0 - in caz de succes)
- Campurile Count - specifica numarul de intrari, din cele patru sectiuni ce urmeaza headerului
In cadrul campului de inregistrari aditionale, in ceea ce priveste functionarea DNSSEC, se utilizeaza extensiile DNS EDNS0 - RFC 2671 - ce permit adaugare de pseudo-inregistrari (OPT RR) in cadrul unui query. Aceste pseudo-inregistrari nu contin informatii ce tin de baza de date DNS ci reprezinta pur si simplu o extensie a headerului, care din motive de portabilitate cu serverele ce nu implementeaza suport pentru extensii e pastrat la 32 de biti. O pseudo-inregistrare are aceeasi structura ca si una normala cu urmatoarele specificatii date de standard:
Field Name Field Type Description
------------------------------------------------------
NAME domain name empty (root domain)
TYPE u_int16_t OPT (41)
CLASS u_int16_t sender's UDP payload size
TTL u_int32_t extended RCODE and flags
RDLEN u_int16_t describes RDATA
RDATA octet stream {attribute,value} pairs
Esential pentru DNSSEC este campul TTL ce are urmatoarea forma - mai exact bitul DO setat - pentru a indica in cererea unui resolver ce include o astfel de pseudo-inregistrare ca suporta extensiile de securitate:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0: | EXTENDED-RCODE | VERSION | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2: |DO| Z | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Inregistrarile specifice (RR) ce pot fi adaugate de DNSSEC pe langa seturile obisnuite de inregistrari sunt urmatoarele:
- DNSKEY - inregistrare de tip cheie publica utilizata pentru verificarea semnaturii asociate seturilor de inregistrari dintr-o anumita zona (mai e denumita si ZSK) cu valoarea flagurilor din campul RDATA 256 sau specifica pentru alte semnari (mai e denumita si KSK) cu valoarea flagurilor 257
- RRSIG - inregistrare de tip signatura asociata altei inregistrari (sau altui set de inregistrari de un anumit tip; uzual pentru un set, de exemplu de inregistrari de tip A, ce au acelasi nume, clasa si tip - deci la un query raspunsul va contine intreg setul - se realizeaza un hash asupra setului, hashul respectiv fiind cel semnat)
- NSEC - inregistrare utilizata ca raspuns ce poate fi autentificat, in cazul in care nu exista informatii despre domeniul solicitat la nivelul serverului
- DS - inregistrare de delegare de semnatura utilizata in autentificarea de chei (descrisa pe scurt in paragraful urmator)
Pe scurt, mecanismul DNSSEC este folosit pentru validarea unui raspuns DNS, prin verificarea semnaturii RRSIG a setului de inregistrari din raspuns pe baza cheii publice din zona respectiva - inregistrarea DNSKEY (ZSK) asociata. Inregistrarile DNSKEY necesita insa validare la randul lor, deci au la randul lor o semnatura RRSIG asociata, ce se verifica folosind cheia publica DNSKEY (KSK) din zona respectiva. Mai departe, pentru validarea acestei chei (DNSKEY KSK), este utilizat un mecanism de tip lant de incredere - chain of trust, bazat pe delegare in ierarhia zonelor DNS. Sumar, mecanismul ar functiona in felul urmator. Fiecare zona, cu exceptia celei de root are o zona parinte, a carei inregistrare DS va contine hashul cheii publice DNSKEY KSK din zona copil. Ca si celelalte seturi, inregistrarile DS sunt semnate cu cheia privata a zonei parinte avand asociata o inregistrare RRSIG. Astfel, in linii mari, pentru a valida cheile DNSKEY KSK, se obtin inregistrile DS si semnatura asociata RRSIG din zona parinte precum si cheia publica DNSKEY ZSK a zonei parinte. Evident, pentru cheia publica a zonei parinte apare aceeasi problema a validarii, aceasta facandu-se in acelasi mod descris mai sus, pana ce se ajunge la o cheie de "incredere" asociata de regula zonei root (.). Mecanismul pentru aceasta cheie de incredere se stabileste in mod uzual prin "trust anchors" in sensul ca pe anumite servere DNS, cheia este facuta disponibila prin alte modalitati decat verificarea ierarhica descrisa (de exemplu plasarea cheii root pe sistem de catre administrator, sau disponibilitatea acesteia implicita in sistemul de operare).
Un exemplu al lantului de verificare a semnaturilor inregistrarilor DNS pentru un raspuns de tip A la o interogare DNS pentru un subdomeniu al example.com este descris in figura de mai jos (sursa - "DNSSEC - how far have we come?", Nick Sullivan - prezentare conferinta Virus Bulletin 2014):
Un tutorial ce prezinta modul de validare a DNSSec este disponibil aici.
Generalitati privind accesarea serviciilor DNS in cadrul Linux
Serverele de DNS in Linux sunt setate prin intermediul intrarilor din cadrul fisierului /etc/resolv.conf
O interogare explicita asupra unui nume de domeniu se poate face de la linia de comanda prin intermediul comenzilor dig sau nslookup urmate de respectivul nume de domeniu.
Fisierul /etc/hosts poate include o serie de mapari de adrese IP pentru anumite nume de domenii care, in functie de aplicatie, sunt folosite in prealabil incercarii efective de rezolvare utilizand o interogare DNS in exterior (de exemplu ping va folosi implicit respectivul fisier). Din aceasta cauza un prim atac simplist asupra rezolvarii DNS ar putea fi considerat coruperea fisierului in cauza (ceea ce ar putea fi posibil din exterior prin orice sesiune remote de genul telnet).
Atacuri asupra DNS cu acces la mediu
La fel ca si atacurile descrise in laboratoarele anterioare, o parte din atacurile asupra DNS au sanse de reusita reala doar in cazul in care exista acces la traficul statiei atacate. Un prim exemplu de atac de acest gen ar consta in falsificarea de raspunsuri DNS pentru o interogare transmisa de utilizator catre un server DNS - DNS User Response Spoofing. Schematic desfasurarea unui atac de acest gen ar putea fi descrisa in urmatorii trei pasi:
- 1.Victima trimite interogarea catre serverul DNS
- 2.Atacatorul intercepteaza interogarea trimisa, falsifica raspunsul ca venind din partea serverului, raspuns ce va consta in principiu in atasarea unui IP controlat de atacator pentru numele de domeniu trimis spre rezolvare, si il trimite catre victima.
- 3.Victima va primi si raspunsul real din partea serverului DNS in cele din urma (dupa primirea celui fals).
Succesul atacului se bazeaza in primul rand pe succesiunea exacta de pasi de mai sus. Daca victima va primi raspunsul real inainte de cel fals atacul esueaza. Doar primul raspuns DNS este luat in considerare, pana la o urmatoare noua interogare pentru domeniul respectiv. In falsificarea raspunsului, atacatorul trebuie evident sa respecte datele din cadrul cererii - adresele IP si porturile serverului DNS si a victimei, acestea fiind parte a headerelor IP si (in general) UDP, precum si ID-ul de tranzactie din headerul DNS, iar numele de domeniu cerut este obligatoriu sa apara si in raspuns in sectiunea Question si rezolvat in sectiunea Answer.
Un alt atac, cu impact mai mare, este orientat direct spre serverul DNS ce ofera raspunsul, nu spre statia ce realizeaza cererea - DNS Server Cache Poisoning. Atacul schematizat urmeaza pasii descrisi mai jos:
- 1.Serverul victima primeste o interogare DNS pentru un nume.
- 2.Numele nu apartine de domeniul serverului victima si acesta nici nu are o intrare in cache referitoare la respectivul nume, iar in consecinta va interoga alt server DNS.
- 3.Atacatorul intercepteaza interogarea serverului victima, falsifica raspunsul ca venind din partea altui server DNS, similar pasului 2 din atacul anterior - raspunsul va contine in principiu un IP controlat de atacator ca rezolvare pentru numele de domeniu cerut.
- 4.Serverul victima va raspunde interogarii userului si a altor utilizatori pentru numele de domeniu "rezolvat" cu IP-ul fals pana ce cacheul serverului va fi reimprospatat (TTL-ul inregistrarilor expira).
- 5.Serverul victima va primi in cele din urma si raspunsul legitim din partea serverului DNS real (dupa primirea celui fals).
La fel ca si in cazul anterior succesul atacului e bazat pe succesiunea pasilor de mai sus (mai exact 3 inainte de 5). Raspunsul primit initial de serverul DNS este pastrat in cacheul acestuia pana la expirare (conform cu TTL-ul asociat), oricare raspuns ulterior fiind ignorat. Aceleasi cerinte ca si la primul atac descris mai sus se pastreaza in ce priveste corespondenta ID-ului de tranzactie si a celorlalte campuri (chestiuni care nu reprezinta o problema atat timp cat atacul e realizat de un atacator ce are acces la mediu).
Atacuri asupra DNS in mod blind
Vom prezenta in cele ce urmeaza o varianta a atacului de "cache poisoning" asupra unui server DNS potential realizabila in mod blind - fara interceptia traficului generat de server - descoperita in 2008.
In mod obisnuit un atacator ar putea incerca varianta de "cache poisoning" descrisa mai sus si in mod blind. Pentru aceasta, in prima faza atacatorul va fi si cel ce va actiona la pasul 1 prin trimiterea unei interogari DNS catre server pentru un nume la care doreste asocierea unui IP fals. Astfel atacatorul va sti ca serverul in principiu (in cazul in care nu are intrarea corespunzatoare in cache) va interoga un alt server pentru numele respectiv - probabil ajungandu-se chiar la serverul de nume corespunzator zonei de care apartine numele. In concluzie atacatorul va cunoaste in principiu ce server de nume sa impersonifice pentru a falsifica mesajul. Problema majora ramane insa ghicirea ID-ului de tranzactie pentru cererea DNS, spatiul de incercari fiind de 65535. Incercarea tuturor variantelor de ID de tranzactie pana la nimerirea celui corect pentru spatiul mentionat este posibila, dar pentru atacator apare problema raspunsului venit de la serverul legitim. Daca acesta ajunge la serverul victima inainte ca atacatorul sa reuseasca ghicirea ID-ului de tranzactie, va fi retinut in cache pentru o anumita durata specificata ce poate fi de nivelul orelor, iar orice alt raspuns va fi ignorat pana la urmatoarea cerere, dupa cum am mentionat de altfel deja si mai sus.
In anul 2008 a fost descoperita o modalitate de a nega acest asa numit efect de caching ce ar ingreuna un atac de tipul celui descris. Atacul are loc in urmatorul mod:
- 1. Atacatorul va interoga serverul DNS victima pentru un nume de domeniu inexistent ce consta intr-un subdomeniu al celui vizat pentru corupere (spre exemplu daca atacatorul urmareste "otravirea" cacheului pentru example.com va trimite interogari de genul randomstring.example.com)
- 2. Serverul va interoga la randul sau alte servere de nume pentru a afla raspunsul
- 3. Serverul legitim responsabil de domeniul interogat va trimite un raspuns
- 4. Atacatorul va trimite in acest timp raspunsuri falsificate prin incercari repetate de ghicire a ID-ului de tranzactie, ce contin mapari atat pentru interogarea solicitata randomstring.example.com cat si pentru numele de domeniu ce se doreste a fi corupt example.com (protocolul DNS permite acest lucru)
- 5-7. Daca raspunsul atacatorului e acceptat (ID-ul de tranzactie e ghicit) inainte ca serverul sa primeasca un raspuns legitim la interogarea facuta, cacheul e "otravit" atat pentru randomstring.example.com cat si pentru domeniul ce se doreste a fi corupt - example.com. In cazul in care raspunsul legitim este primit inainte de server in principiu acesta va fi unul negativ vis-a-vis de domeniul solicitat randomstring.example.com, iar cacheul serverului nu e afectat, deci atacatorul poate relua atacul, nefiind ingradit de un timp de asteptare pana la expirarea intrarilor din cacheul serverului
