Pišemo dodatak za Microsoftov DNS poslužitelj za zaštitu od lažiranja IDN-a. Aktualne metode prijevare danas Zaštita od lažiranja DNS-a

DNS poisoning ili DNS spoofing vrsta je kibernetičkog napada koji iskorištava ranjivosti sustava u DNS poslužitelju za preusmjeravanje prometa s legitimnih poslužitelja na lažne.

Kako funkcionira DNS trovanje ili lažiranje DNS-a

Kod trovanja DNS predmemorije često se nalazi u URL-ovima koji se šalju u spam porukama. U tim porukama napadači pokušavaju prestrašiti korisnike i na taj način ih natjerati da kliknu na priloženu poveznicu koja će zauzvrat zaraziti njihovo računalo. Banneri i slike kao u elektronička pošta, a na sumnjivim stranicama također može preusmjeriti korisnike na ovaj kod. Jednom zaražena računala preusmjeravaju korisnike na lažne stranice koje oponašaju izvorne web stranice, izlažući ih tako rizicima poput infekcije špijunski softver, keyloggeri ili crvi.

rizici

Trovanje DNS-om uzrokuje različite rizike, počevši od krađe podataka. Web stranice banaka i popularne internetske trgovine lako se zamjenjuju, što znači da bilo koja lozinka kreditna kartica ili osobni podaci mogu biti ugroženi. A ako su web stranice pružatelja IT sigurnosnih usluga lažirane, računalo korisnika može biti izloženo dodatne rizike, kao što je infekcija virusima ili trojancima, jer sigurnosni sustavi neće primati legitimna ažuriranja. Naposljetku, rješavanje trovanja DNS predmemorije je vrlo teško, budući da čišćenje zaraženog poslužitelja ne uklanja problem, a čišćenje računala koja se spajaju na kompromitirani poslužitelj uzrokovat će ponovnu zarazu. Ako je potrebno, korisnici mogu riješiti problem brisanjem DNS predmemorije.

Kako bi spriječili trovanje DNS-a, korisnici bi trebali izbjegavati klikanje na nepoznate poveznice i redovito provjeravati svoje računalo malware. To uvijek činite koristeći program instaliran na vašem računalu, a ne on-line verziju, koja se također može lažirati.

IDN spoofing je generiranje naziva domena "sličnih" odabranom, obično se koristi za prisiljavanje korisnika da slijedi poveznicu do resursa napadača. Zatim, pogledajmo konkretniju opciju napada.

Zamislimo da napadnuta tvrtka posjeduje domenu organization.org, a unutar te tvrtke koristi se interni resurs portal.organization.org. Cilj napadača je dobiti vjerodajnice korisnika, a da bi to učinio, šalje poveznicu putem e-maila ili messengera koji koristi tvrtka.

Primivši takvu poruku velika je vjerojatnost da nećete primijetiti da poveznica vodi negdje na krivo mjesto. Nakon klika na poveznicu, tražit će se prijava/lozinka, a žrtva će, misleći da je na internom resursu, unijeti svoje podatke račun. Šanse napadača su posebno velike ako je već probio perimetar, kompromitirajući sustav bilo kojeg zaposlenika, i sada se bori za privilegije administratora sustava.

Nemoguće je ovdje pronaći apsolutnu "zaštitu od grešaka", ali možete pokušati presresti ovaj napad u fazi razlučivanja imena putem DNS zahtjeva.

Radi zaštite, trebat ćemo sekvencijalno pamtiti imena na koja naiđemo u presretnutim DNS zahtjevima. Tvrtka koristi svoje interne resurse, što znači da ćemo je brzo pronaći u zahtjevu na portal.organization.org. Čim naiđemo na ime "slično" prethodnom, možemo zamijeniti DNS odgovor vraćanjem pogreške umjesto IP adrese napadača.
Koji algoritmi mogu postojati za određivanje "sličnosti"?

• UTS39 Confusable Detection (http://www.unicode.org/reports/tr39/#Confusable_Detection) Unicode nije samo vrijedna tablica simbola, već i hrpa standarda i preporuka. UTS39 definira algoritam za normalizaciju unicode nizova, u kojem će se nizovi koji se razlikuju u homoglifima (na primjer, ruski "a" i latinski "a") svesti na isti oblik
• Riječi koje se razlikuju preraspodjelom unutarnjih slova. Lako je pobrkati organization.org i orgainzation.org
• Zamjena domene prve razine. Prva razina naziva obično nema nikakvo značenje i zaposlenik tvrtke koji vidi "organizaciju" može zanemariti razliku u .org ili .net, iako su ovdje moguće iznimke

Za razumijevanje metodologije bit će potrebno poznavanje PE formata; Izvršna datoteka sastoji se od zaglavlja, tablice odjeljaka i samih odjeljaka. Sami odjeljci su blok podataka koje bootloader mora preslikati u memoriju na relativnoj adresi (Relativna virtualna adresa - RVA), a svi resursi, kod i drugi podaci sadržani su unutar odjeljaka. Također unutar zaglavlja postoje veze (RVA) na niz tablica potrebnih za rad aplikacije; za potrebe ovog članka dvije će biti važne - tablica uvoza i tablica izvoza. Tablica uvoza sadrži popis funkcija koje su potrebne za rad aplikacije, ali se nalaze u drugim datotekama. Tablica izvoza je tablica "natrag" koja sadrži popis funkcija koje se izvoze iz te datoteke ili, u slučaju prosljeđivanja izvoza, naziv datoteke i naziv funkcije za rješavanje ovisnosti.

Napravit ćemo dll injekciju bez dosadnog CreateRemoteThreada. Odlučio sam koristiti PE prosljeđivanje izvoza - to je već odavno poznata tehnika kada se za učitavanje u željeni proces u direktoriju s exe datotekom kreira dll s imenom jednakim nazivu bilo koje dll iz importa tablica exe datoteke (najvažnije je ne koristiti HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Control\Session Manager\KnownDLLs). U stvorenoj dll kopira se tablica izvoza iz ciljne dll, ali umjesto pokazivača na kod eksportirane funkcije, trebate napisati RVA u niz naprijed poput "endpoint!sendto". Sam microsoft dns poslužitelj implementiran je kao servis HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\DNS koji se nalazi u %systemroot%\system32\dns.exe

Konačni algoritam ubacivanja u DNS poslužitelj bit će ovakav:

• Napravite direktorij %systemroot%\system32\dnsflt (bilo koji drugi direktorij je moguć, nije potrebno locirati direktorij u system32).
• Tamo kopirajte %systemroot%\system32\dnsapi.dll - ovo je dll iz kojeg dns.exe uvozi nešto, možete odabrati bilo koji drugi "nepoznati dll".
• Preimenujte kopirani dll u endpoint.dll - koristit ćemo ovo ime u prvom redu.
• Uzimamo naš umetnuti dll i dodajemo mu ispravnu tablicu izvoza, kopiramo naš dll u %systemroot%\system32\dnsflt
• U ključu registra HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\DNS promijenite novu binarnu adresu %systemroot%\system32\dnsflt\dns.exe u ImagePath
• Stvorite simboličku vezu od %systemroot%\system32\dnsflt\dns.exe do %systemroot%\system32\dns.exe

Nakon učitavanja u proces iz DllMain-a, možete stvoriti nit i postaviti presretanje. U najjednostavnijem slučaju, naša dns usluga će klijentu reći IP adresu za ime slanjem UDP paketa s porta 53 putem funkcije sendto iz ws2_32.dll. Standard sugerira da se TCP port 53 može koristiti ako je odgovor prevelik, a presretanje sendto očito bi bilo beskorisno u ovom slučaju. Međutim, moguće je riješiti slučaj s tcp-om na sličan način, iako je to zahtjevnije. Za sada ću vam reći najjednostavniji slučaj s UDP-om. Dakle, znamo da će kôd u dns.exe uvesti funkciju sendto iz ws2_32.dll i koristiti je za odgovor na DNS zahtjev. Također postoji dosta funkcija za presretanje različite načine, klasičan je splacing, kada se prve sendto instrukcije zamjenjuju s jmp u njegovoj funkciji, a nakon njenog završetka prelazi se na prethodno spremljene sendto instrukcije pa unutar sendto funkcije. Spajanje će raditi čak i ako se GetProcAddress koristi za pozivanje sendto umjesto tablice uvoza, ali ako se koristi tablica uvoza, lakše je koristiti IAT spojnicu umjesto spajanja. Da biste to učinili, morate pronaći tablicu uvoza u preuzetoj slici dns.exe. Sama tablica ima pomalo zbunjujuću strukturu i za detalje ćete morati otići na opis PE formata.

Glavna stvar je da će tijekom procesa učitavanja slike sustav upisati pokazivač na početak funkcije sendto u tablici uvoza. To znači da za presretanje sendto poziva jednostavno trebate zamijeniti adresu originalnog sendto u tablici uvoza adresom vaše funkcije.

Dakle, postavili smo prisluškivanje i počeli primati podatke. Prototip funkcije sendto izgleda ovako:

Int sendto(_In_ SOCKET s, _In_ const char *buf, _In_ int len, _In_ int zastavice, _In_ const struct sockaddr *to, _In_ int tolen);
Ako je s utičnica na portu 53, tada će buf pokazivač sadržavati dns odgovor veličine len. Sam format je opisan u RFC1035, ja ću ukratko opisati što je potrebno napraviti da bi se došlo do podataka od interesa.

Struktura poruke u standardu opisana je na sljedeći način:

Zaglavlje sadrži potrebne informacije: vrstu poruke, kod greške i broj elemenata u odjeljcima. Samo zaglavlje izgleda ovako:

Struct DNS_HEADER ( uint16_t id; // identifikacijski broj uint8_t rd: 1; // željena rekurzija uint8_t tc: 1; // skraćena poruka uint8_t aa: 1; // autoritativni odgovor uint8_t opcode: 4; // svrha poruke uint8_t qr: 1; // zastavica upita/odgovora uint8_t ra: 1; // broj unosa pitanja uint16_t; broj unosa resursa);
Odjeljak Pitanje morat će se rastaviti kako bi se došlo do Odgovora. Sama sekcija sastoji se od broja blokova navedenih u zaglavlju (q_count). Svaki blok se sastoji od naziva, tipa i klase zahtjeva. Ime je kodirano kao slijed nizova, od kojih svaki počinje bajtom duljine niza. Na kraju se nalazi string nulte duljine. Na primjer, naziv homedomain2008.ru izgledat će ovako:

Odjeljak Odgovori izgleda slično: blok se sastoji od imena, tipa, klase, ttl-a i dodatnih podataka. IP adresa bit će sadržana u dodatku. podaci. Još jedna poteškoća nastaje prilikom raščlanjivanja imena. Očigledno, da biste smanjili veličinu poruke, umjesto duljine oznake, možete pronaći poveznicu na drugo područje podataka. Kodira se na sljedeći način: ako su 2 najznačajnija bita duljine jednaka 11, tada se sljedeći bajt, kao i najmanje značajni bitovi duljine, trebaju tumačiti kao pomak u bajtovima u odnosu na početak poruka. Daljnje raščlanjivanje imena mora se izvršiti prelaskom ovog pomaka.

Dakle, presreli smo traženi API, analizirali DNS odgovor, sada moramo donijeti odluku: preskočiti dalje ovaj odgovor ili vratiti pogrešku. Za svako ime koje još nije u bazi podataka potrebno je iz odgovora provjeriti je li “sumnjivo” ili ne.
Smatrat ćemo "sumnjivim" ona imena za koja se rezultat kosturne funkcije iz Unicode tehničkog standarda tr39 podudara s rezultatom bilo kojeg imena iz baze podataka ili ona imena koja se razlikuju od onih prisutnih u bazi preuređivanjem unutarnjih slova . Za provedbu provjera, pohranit ćemo 2 tablice. Prva će se sastojati od kosturnih rezultata za sva imena iz baze podataka, u drugu tablicu ćemo upisati retke koji su dobiveni iz redaka baze podataka uklanjanjem prvog i zadnjeg znaka iz svake oznake osim prve razine, a zatim sortiranje preostalih znakova svake oznake. Sada, ako je novo ime uključeno u jednu od dvije tablice, smatramo to sumnjivim.

Svrha kosturne funkcije je odrediti sličnost dva niza; za to se znakovi normaliziraju za svaki niz. Na primjer, Xlœ će se pretvoriti u Xloe i tako, usporedbom rezultata funkcije, možete utvrditi sličnost unicode nizova.

Primjer implementacije navedenog možete pronaći na githubu.
Očito je da navedeno rješenje ne može pružiti normalnu zaštitu u praksi, jer osim min tehnički problemi kod presretanja je još veći problem otkrivanje "sličnih" imena. Bilo bi lijepo rukovati:

• Kombinacije permutacija i homoglifa.
• Dodavanje\zamjena znakova koje kostur ne uzima u obzir.
• UTS tr39 nije ograničen na kostur; također može ograničiti miješanje skupova znakova u jednoj oznaci.
• Japanska točka pune širine i drugi razdjelnik oznaka.
• I također tako divne stvari kao što su

DNS spoofing

DNS sustav ( Sustav naziva domene) pretvara naziv domene (npr. www.test.com) u njegovu IP adresu (npr. 192.168.0.1) i obrnuto. Ovaj napad koristi tehnologiju za slanje lažnih odgovora na DNS upite žrtve. Napad se temelji na dvije glavne metode.

Spoofing DNS ID-a

Zaglavlje paketa DNS protokola sadrži identifikacijsko polje za usklađivanje zahtjeva i odgovora. Cilj lažiranja DNS ID-a je slanje odgovora na DNS upit prije nego što pravi DNS poslužitelj odgovori. Da biste to učinili, morate predvidjeti ID zahtjeva. Lokalno se to provodi jednostavnim slušanjem mrežni promet. Međutim, obavljanje ovog zadatka na daljinu mnogo je teže. Postoje razne metode:

provjera svih dostupnih vrijednosti polja za identifikaciju. Nije baš praktično jer je ukupan broj mogućih vrijednosti 65 535 (veličina polja 16 bita);

slanje nekoliko stotina DNS upita ispravnim redoslijedom. Očito ova metoda nije baš pouzdana;

pronalaženje poslužitelja koji generira predvidljive identifikatore (na primjer, povećanje za 1). Ova vrsta ranjivosti svojstvena je nekim verzijama Binda i Windows sustavi 9x.

U svakom slučaju, potrebno je odgovoriti pravom DNS poslužitelju. To se može postići, na primjer, izvođenjem napada uskraćivanjem usluge protiv poslužitelja.

Da bi izveo uspješan napad, napadač mora kontrolirati DNS poslužitelj (ns.attaquant.com) koji je mjerodavan za zonu attaquant.com. Ciljani DNS poslužitelj (ns.cible.com) navodno generira prediktivne ID brojeve (povećavaju se za 1 sa svakim zahtjevom).

Napad zahtijeva četiri koraka:

Kao rezultat toga, predmemorija ciljanog DNS poslužitelja sadržavat će podudaranje koje je potrebno napadaču, a sljedeći klijenti koji zatraže adresu www.spoofed.com dobit će adresu napadačevog stroja. Može ugostiti kopiju prave web stranice, uz pomoć koje napadač može ukrasti povjerljive informacije.

Promjena DNS Cache Poisoning

DNS poslužitelji koriste predmemoriju za pohranu rezultata prethodnih upita tijekom vremena. Ovo se radi kako bi se izbjeglo stalno ponavljanje zahtjeva ovlaštenim poslužiteljima odgovarajućih domena. Druga vrsta napada usmjerenog na lažiranje DNS-a je promjena predmemorije DNS poslužitelja. Evo primjera:

Koristimo iste podatke kao u prethodnom primjeru. Evo ključnih točaka ove opcije napada:

poslati DNS zahtjev za rješavanje naziva www.attaquant.com DNS poslužitelju domene cible.com;

ciljni DNS poslužitelj šalje zahtjev za rješavanje imena www.attaquant.com napadačevom DNS poslužitelju;

DNS spoofing jednostavna je metoda zavaravanja DNS sustava, blok razlučivanja DNS imena pomoću lažnih informacija primljenih od glavnog računala koje nije odgovorno za te informacije. Svaki DNS paket ima 16-bitni ID broj, ID broj je dio DNS paketa koji vam omogućuje identifikaciju svakog DNS paketa koji prolazi kroz port 53, a zahtjev se također može uputiti više puta. ID je jedini način za razlikovanje različitih dns zahtjeva i povezan je s onim što dns poslužitelji koriste za utvrđivanje izvornog zahtjeva. U slučaju BIND-a, ovaj broj se povećava za 1 razinu za svaki zahtjev. Može se izvesti napad sličan TCP seq id-u, iako je teži. Čak i ako BIND ne može predmemorirati informacije koje šaljete, on će proslijediti odgovor izvornom hostu. U slučaju da ircd napravi PTR zahtjev kao odgovor na host koji se povezuje na njega, paket odgovora može se formulirati tako da sadrži dodatne informacije iz kojih će ircd izvršiti interno predmemoriranje. Za ovaj napad potreban je root pristup za in-addr.informacije idspace. Da biste lažirali svoj dns na DALNet-u, morate poslati 65 000 generiranih zahtjeva ns serveru, čim računalo primi odgovor na zahtjev, morat ćete pročitati paket, a ispravan id će biti zapisano u njemu. Čim dobijete id, morate pronaći bilo koji "paket" alat za stvaranje"napraviti DNS paket. Ostaje samo lažirati DNS pakete, poslati ih na ns. dal. net i dobiti spoofing TCP vezu.

Općeniti prikaz problema U vezi s brzim rastom interneta, problem zaštite izvori informacija postaju sve važniji. Ako ste spojeni na internet, vaš sustav može biti napadnut. Pogledajmo kako radi DNS. Adresiranje izvan segmenta provodi se korištenjem IP adresa, ali se pristup poslužiteljima obično provodi korištenjem imena domena. S tim u vezi kreiran je sustav za pretvaranje (mapiranje) imena domena u IP adrese – DNS poslužitelji (Domain Name System). Ovaj sustav je odgovoran za pronalaženje IP adrese udaljenog računala prema njegovom imenu. Princip rada DNS sustava je sljedeći: udaljeni host šalje poseban zahtjev na IP adresu najbližeg DNS poslužitelja u kojem se navodi ime poslužitelja čiju IP adresu treba pronaći. Po primitku zahtjeva, DNS poslužitelj pretražuje svoju bazu podataka za prisutnost traženog naziva domene. Ako je ime pronađeno, DNS poslužitelj vraća odgovor koji označava traženu IP adresu. Ako DNS poslužitelj ne pronađe naziv naveden u zahtjevu u svojoj bazi imena, DNS poslužitelj šalje DNS zahtjev jednom od korijenskih DNS poslužitelja i postupak opisan u ovom paragrafu se ponavlja dok se ne pronađe ime. Razmotrimo opću shemu rada lažnog DNS poslužitelja: čekanje DNS zahtjeva; nakon što je primio DNS zahtjev, izvukao potrebne informacije iz njega i odašiljao lažni DNS odgovor preko mreže hostu koji je zatražio zahtjev, u ime (s IP adrese) pravog DNS poslužitelja, koji označava IP adresu lažnog DNS poslužitelja ; u slučaju primanja paketa od glavnog računala, mijenjanje njegove IP adrese u IP zaglavlju paketa u IP adresu lažnog DNS poslužitelja i prijenos paketa na poslužitelj (tj. lažni DNS poslužitelj radi s poslužiteljem na svoje ime); u slučaju primanja paketa od poslužitelja, mijenjanje njegove IP adrese u IP zaglavlju paketa u IP adresu lažnog DNS poslužitelja i prijenos paketa na host (za host, lažni DNS poslužitelj je pravi poslužitelj ).

Preduvjet za ovu opciju napada je presretanje DNS zahtjeva. To je moguće samo ako je napadač ili na putu glavnog prometa ili u segmentu stvarnog DNS poslužitelja. Ispunjavanje jednog od ovih uvjeta za lokaciju napadača na mreži čini takav udaljeni napad teško izvedivim u praksi (napadač najvjerojatnije neće moći ući u segment DNS poslužitelja, a još više u međusegmentni komunikacijski kanal ). Međutim, ako su ovi uvjeti ispunjeni, moguće je izvršiti daljinski napad između segmenata internetska mreža. Rezultat ovog napada je uvođenje nametnute korespondencije između IP adrese i naziva domene u predmemoriju DNS poslužitelja. Kao rezultat uspješnog napada, svi DNS korisnici na sjeveru dobit će netočne informacije o imenima domena i IP adresama. Ovaj napad karakterizira veliki broj DNS paketa s istim nazivom domene. To je zbog potrebe odabira nekih parametara DNS razmjene.

Kao što pokazuje analiza postojećih obrambenih tehnika, suprotstavljanje napadima može se izvesti pomoću sljedećih metoda. Prebacivanjem DNS-a na TCP Prijelaz s UDP-a na TCP donekle će usporiti sustav. Kod korištenja TCP-a potrebno je kreirati virtualnu vezu, a također vrijedi uzeti u obzir da krajnji mrežni OS prvo pošalje DNS zahtjev koristeći UDP protokol, a ako dobije poseban odgovor od DNS poslužitelja, onda mrežni OS će poslati DNS zahtjev koristeći TCP. Korištenje TCP protokola otežat će napad lažiranjem paketa, ali će usporiti operaciju. Analizom DNS prometa. Napadima se možete suprotstaviti analizom prometa. Lažni paketi s lažnim IP adresama stalno se šalju DNS poslužitelju. Ako primljeni lažni paket odgovara vrijednostima zahtjeva, tada se lažni IP prihvaća kao istinit. Ako nijedan paket nije presretnut s poslužitelja, tada je napad karakteriziran velikim brojem DNS paketa s istim imenom. To je zbog potrebe odabira nekih parametara DNS razmjene. Analizom DNS prometa možete ignorirati takve pakete kako biste izbjegli krivotvorenje IP adrese.

Zaključci Nakon što ste proučili rad DNS poslužitelja, to možete vidjeti trenutna verzija prilično je suboptimalan i ranjiv na razne vrste napada. Napadima se može suprotstaviti analizom DNS prometa ili prebacivanjem DNS rada s UPD na TCP. Nijedna od metoda ne daje puna zaštita od napada, obje metode samo otežavaju izvođenje napada. Obje metode zahtijevaju dodatne resurse poslužitelja. U slučaju prelaska DNS poslužitelja na TCP povećava se i vrijeme razmjene između poslužitelja jer je UDP protokol brži od TCP protokola. Na u trenutku, predloženi modeli protudjelovanja su najučinkovitiji i preporučljivo ih je koristiti u kombinaciji kako bi se postigla najveća moguća sigurnost.

Izvornik: Cyber ​​​​napadi objašnjeni: DNS invazije
Autor: Prashant Phatak
Datum objave: 22. veljače 2012
Prijevod: A. Panin
Datum prijevoda: 8. prosinca 2012

Često vidimo stranice koje su oštećene, čije su glavne stranice zamijenili napadači. Kako hakeri uspijevaju izvesti takve napade i kako možemo zaštititi našu mrežnu infrastrukturu od njih? Ovaj članak objašnjava kako napadači mogu ometati DNS (Domain Name System). DNS napadi su tehnički složeni i opasni za mrežnu i web infrastrukturu. Mrežni administratori trebali bi biti svjesni ove vrste napada i poduzeti sve moguće mjere kako bi osigurali sigurnost infrastrukture koju održavaju.

Kao što znamo, razlog postojanja DNS-a je činjenica da se osoba ne može sjetiti mnogo IP adresa za pristup stranicama, ali se lako može sjetiti imena stranica koja se sastoje od slova i brojeva. DNS sustav je dizajniran u vrijeme kada su Internet koristili prijateljski raspoloženi ljudi, što je dovelo do nekih značajki sustava u moderno doba.

Slika 1 prikazuje temeljna načela usluge razlučivanja imena mreže. Kada aplikacija (kao što je preglednik) želi uspostaviti vezu s udaljenom uslugom, postavlja upit DNS poslužitelju za IP adresu. Ovaj zahtjev u obliku paketa šalje se preko UDP porta broj 53, nakon čega poslužitelj vraća odgovor u obliku paketa. (Imajte na umu da budući da je veličina podataka UDP datagrama ograničena na 512 bajtova, stog protokola automatski koristi TCP za slanje zahtjeva i primanje odgovora.) Kada klijent prihvati odgovor, dodaje podatke u svoju lokalnu predmemoriju, što ubrzava naknadne odgovore na istu domenu. Stavke lokalne predmemorije automatski se uništavaju nakon što im istekne životni vijek (parametar TTL (Time to Live)).

Slika 1: Rješavanje naziva domene

DNS sustav koristi vrste zapisa kao što su A, CNAME, SOA, MX i drugi. Iako je opisivanje ovih vrsta zapisa izvan opsega ovog članka, važno je da administratori sustava budu svjesni kada i kako ih treba koristiti, te treba provesti istraživanje prije njihove upotrebe za buduću sigurnost sustava. Prije nego pogledamo napade na DNS sustav, moramo pogledati dvije vrste upita - iterativne i rekurzivne.

• Iterativni DNS upiti: Dok klijent postavlja upit DNS poslužitelju kako bi dobio informacije o domeni, DNS poslužitelj može, ali i ne mora imati informacije o toj domeni. Ako DNS poslužitelj nema odgovor, umjesto dovršavanja zahtjeva, klijentu šalje ime najvišeg DNS poslužitelja koji može imati potrebne informacije. Taj se proces obično naziva DNS preporuka. Klijent šalje zahtjev sljedećem (određenom) poslužitelju; ako nema odgovora, klijentu šalje ime glavnog poslužitelja. Ovaj proces se nastavlja sve dok klijent ne primi ili IP adresu ili poruku o pogrešci da se zahtjev ne može dovršiti.
• Rekurzivni DNS upiti: U ovom slučaju, proces počinje tako što klijent upućuje zahtjev za razrješenje naziva domene izravno DNS poslužitelju. Ako DNS poslužitelj nema odgovor, od njega se očekuje da će obaviti posao komunikacije s poslužiteljima više razine umjesto da jednostavno dostavi njihova imena klijentu. Opet, ako uzvodni poslužitelj nema informacije za odgovor na zahtjev, prosljeđuje zahtjev uzvodnom poslužitelju. Ovaj proces se nastavlja sve dok zahtjev ne dođe do korijenskog DNS poslužitelja, koji mora imati potrebne informacije i odgovor se vraća klijentu, a ako traženo ime ne postoji, vraća se poruka o grešci klijentu duž lanca poslužitelja. Za razliku od iterativne metode, rekurzivni upit se smatra agresivnijim u dobivanju rezultata.

Iterativne upite obično postavljaju DNS poslužitelji, dok rekurzivne upite postavljaju klijenti, budući da ova vrsta upita eliminira potrebu za složenom obradom preusmjeravanja DNS upita. Iz perspektive sigurnosti sustava, administratori trebaju razumjeti osnove DNS sustava jer organizacija može imati više pokrenutih DNS poslužitelja koji sinkroniziraju zapise zona kako bi održali dosljednost podataka.

DNS podaci se povremeno sinkroniziraju bez potrebe za ponovnim pokretanjem servisa sustava, a kada se izvrše promjene na korijenskom poslužitelju, automatski šalje promjene poslužiteljima nizvodno. Vrijeme potrebno za sinkronizaciju podataka je postavljeno parametrom trajanja svakog zapisa. U slučaju geografski raspoređenih DNS poslužitelja, period sinkronizacije podataka može trajati cijeli dan, budući da svaki od poslužitelja u lancu koristi vlastitu predmemoriju kako bi ubrzao obradu upita.

Napadi na DNS sustave

Uočeno je da administratori sustava provode puno vremena razvijajući sigurnosne sustave za aplikacije, poslužitelje i druge komponente infrastrukture, ali, nažalost, zaboravljaju na sigurnosne sustave za DNS poslužitelje. Razmotrite sliku 2 koja prikazuje moguće slabosti DNS poslužitelja koje ih čine ranjivima na napade. DNS je dizajniran tako da se većina komunikacije odvija preko UDP-a, nema ugrađenu sigurnost i nema ugrađenu podršku za autentifikaciju, što ga sve čini ranjivijim na napade od ostalih mrežnih usluga. Pogledajmo nekoliko tipova najčešćih DNS napada.

Slika 2: Moguće slabosti DNS poslužitelja

Trovanje predmemorije DNS-a

Ovaj napad omogućuje vam da utječete na proces rješavanja imena na dva načina. Prvom metodom napadač instalira zlonamjerni softver (rootkit ili virus) koji bi trebao kontrolirati lokalnu DNS predmemoriju na klijentovom računalu. Unosi u lokalnoj DNS predmemoriji zatim se modificiraju tako da pokazuju na različite IP adrese.

Na primjer, ako preglednik pokuša pristupiti stranici s adresom http://www.cnn.com/, umjesto primanja IP adrese CNN-a, prima adresu koju je postavio napadačev softver, a koja obično upućuje na stranicu koja se nalazi na poslužitelju u vlasništvu napadača, a sadrži zlonamjerni softver ili poruku koja je uvredljiva za korisnika.

Drugi, opasniji način je da napadač napadne DNS poslužitelj i modificira njegovu lokalnu predmemoriju, stoga će svi poslužitelji koji koriste ovaj poslužitelj za razlučivanje imena dobiti netočne IP adrese, što će u konačnici dovesti do njihovog kršenja i može rezultirati gubitak ili krađu informacija.

U vrlo rijetkim slučajevima, napadači mogu dobiti pristup korijenskom DNS poslužitelju, koji pohranjuje glavne zapise korijenske domene kao što su .com, .net ili zapise sustava naziva domena specifične za zemlju. Hakeri mogu mijenjati zapise na ovom poslužitelju, a drugi će poslužitelji automatski primati izmijenjene podatke, što može dovesti do globalnih prekida rada komercijalnih mrežnih servisa i stranica. Iako su takve situacije vrlo rijetke, ipak se događaju - ne tako davno sličan napad poremetio je rad velike društvene mreže.

Zamjena DNS poslužitelja (otmica DNS-a)

Ovaj se napad također često koristi za promjenu načina rada DNS sustava. U tom slučaju ne rade se nikakve promjene u klijentovoj DNS predmemoriji, ali se mijenjaju postavke, nakon čega se svi zahtjevi za razrješenje imena upućuju na napadačev osobni DNS poslužitelj. Tipično, ovaj napad nema za cilj krađu podataka, već prikupljanje statističke informacije s računala klijenta. Svi zahtjevi za razrješenjem naziva koji se šalju napadačevom poslužitelju ispravno su ispunjeni, ali napadač prima informacije o stranicama koje je klijent posjetio.

Te se informacije mogu naknadno koristiti za prikazivanje klijentu kontekstualno oglašavanje. Neki hakeri koriste preusmjeravanje korisnika na svoje web stranice ili tražilice primati novac od oglašavanja ili jednostavno krasti podatke i koristiti tehnike društveni inženjering. U slučajevima kada ovu značajku DNS se ne može koristiti za osobnu korist; koriste ga mnoge poznate stranice i internetski provajderi za prikupljanje statističkih podataka o resursima koje korisnik posjećuje.

lažiranje DNS-a

Ovaj napad je napad ljudskog otimanja u kojem napadač preuzima kontrolu nad mrežom na kojoj je pokrenut DNS poslužitelj i modificira ARP predmemoriju koristeći lažiranje paketa. Nakon što se uspostavi kontrola nad mrežom na razini MAC adrese, napadač otkriva IP adresu DNS poslužitelja i počinje nadzirati i mijenjati upite namijenjene tom poslužitelju.

Svi zahtjevi s mreže prolaze kroz računalo napadača i dolaze do pravog DNS poslužitelja. Ovaj napad može imati ozbiljne posljedice, budući da sva računala na mreži ni na koji način neće registrirati činjenicu napada i slat će sve DNS zahtjeve na adresu računala napadača.

postoji alternativni način Ovaj napad se naziva DNS ID spoofing. Svaki DNS zahtjev i odgovor ima jedinstvene identifikatore dizajnirane za razlikovanje zahtjeva poslanih DNS poslužitelju u isto vrijeme. Ovi jedinstveni identifikatori često se formiraju od MAC adrese, datuma i vremena kada je zahtjev napravljen, a automatski ih stvara stog protokola.

Napadač koristi njuškalo za hvatanje jednog ili više zahtjeva i odgovora s njihovim odgovarajućim identifikatorima, a zatim stvara zahtjev s odgovarajućim identifikatorom i lažnom IP adresom. Kao rezultat ovih radnji, lažna IP adresa pohranjuje se u lokalnu predmemoriju napadnutog sustava. Nakon toga može doći do oštećenja napadnutog sustava postavljanjem zlonamjernog uređaja na poslužitelj s adresom navedenom u zahtjevu. softver.

Ponovno povezivanje DNS-a

Ovaj napad se također naziva "DNS pinning" i posebno je sofisticiran napad. Tijekom ovog procesa, napadač prvo registrira svoje vlastito ime domene, zatim postavlja minimalnu životnu vrijednost unosa koja sprječava da se informacije o tom nazivu domene pohrane u predmemoriju.

DNS napadi uskraćivanjem usluge

Kao što smo naučili u prvom članku u nizu, bombardiranje porta 53 poplavom UDP ili TCP paketa zahtjeva može uzrokovati da poslužitelj doživi uskraćivanje usluge. Druga metoda izvođenja ovog napada je napad s poplavom ping paketa ili TCP SYN segmenata. Glavna ideja koja stoji iza ovih radnji je maksimalno povećati korištenje resursa poslužitelja ( središnji procesor I OVAN) kako biste spriječili poslužitelj da odgovori na zahtjeve. Iako su DNS poslužitelji zaštićeni vatrozidom, ako DNS UDP priključci nisu blokirani od pristupa s nepouzdanih mreža, sustav razlučivanja naziva domene postaje dostupan ove vrste napadi.

Povećano opterećenje znači opterećenje DNS poslužitelja zadacima koje poslužitelj nije u stanju izvršiti. Postoje brojni načini za učitavanje poslužitelja i na kraju ga učiniti neupotrebljivim. Jedna metoda koristi zlonamjerni softver (trojanac) za izmjenu lokalne DNS predmemorije više hostova. Nakon ovih radnji, svi čvorovi s modificiranom predmemorijom počinju slati zahtjeve određenom poslužitelju imena, prethodno odabranom od strane napadača.

Svaki poslužitelj može odgovoriti samo na ograničeni broj zahtjeva u ograničenom vremenu (ovisno o CPU performansama i konfiguraciji) i na kraju počinje dodavati zahtjeve u red čekanja. Što su klijenti više izloženi modifikacijama lokalne DNS predmemorije, to više zahtjeva bit će poslani u red čekanja i na kraju će poslužitelj biti paraliziran.

U drugoj vrsti ovog napada, napadač modificira predmemoriju DNS poslužitelj; Umjesto zamjene IP adresa koje odgovaraju A ili CNAME zapisima, nazivi domena se mijenjaju. Da zakomplicira situaciju, duljina svake naziv domene može doseći nekoliko stotina ili tisuća znakova. Proces sinkronizacije podataka koji počinje nakon što su napravljene promjene uključuje slanje mnogo kilobajta podataka s glavnog poslužitelja imena do poslužitelja nizvodno i na kraju do klijenata.

Nakon što TTL istekne, proces sinkronizacije podataka počinje ponovno i može rezultirati kvarom jednog ili više DNS poslužitelja u lancu. Ovi utjecaji predmemorije simuliraju distribuirani napad uskraćivanja usluge, koji je opasan i teško ga je kontrolirati.

Zaštita sustava temeljenih na slobodnom softveru

U svijetu besplatnih sustava postoji implementacija usluge razlučivanja naziva domena, poznate u cijelom svijetu zbog najveće brzine rada u usporedbi s analogima. Ovo je najrašireniji i poznato rješenje je usluga Bind. Međutim, zbog činjenice da je većina napada na DNS usluge iskorištavaju nedostatke protokola, zadatak zaštite slobodnih sustava uslugama razlučivanja imena domena postaje teži.

Prvi korak u razvoju sigurnosnog sustava trebao bi biti blokiranje na mrežnoj razini. Osim luka za održavanje poslužitelju, samo portovi za DNS zahtjeve trebaju ostati otvoreni, a svi ostali portovi trebaju biti blokirani i na vatrozidu i izravno na poslužitelju koji koristi operativni sustav.

Sljedeći važan korak je osigurati da na poslužitelju nije instaliran nikakav softver osim usluge razlučivanja naziva domene. Ovu mjeru opreza posebno treba poduzeti kada radite s korporativnim korijenskim poslužiteljem za razrješenje naziva koji podržava razrješenje svih internih naziva domena i uslužuje sve zahtjeve za razrješenjem imena vanjskim poslužiteljima za lokalnu mrežu.

Često se događa da ranjivost u program treće strane omogućuje vam prodor u poslužitelj razlučivanja imena. Iako su najvažniji dijelovi mrežne infrastrukture zaštićeni vatrozid, objedinjeni kontrolni uređaji (Unified Threat Management) i moćni antivirusni programi, često je potrebno poboljšati zaštitu sustavom za otkrivanje upada. Omogućuje vam odbijanje napada 2 i 3 OSI razine, kao što su ARP spoofing, IP spoofing, sniffer napadi i druge vrste napada.

Uz gore opisane bitne mjere opreza, postoji nekoliko naprednih tehnika koje također treba primijeniti. Kao što smo ranije naučili, svaki zahtjev ima svoj jedinstveni identifikator i šalje se u UDP paketu. Nažalost, zbog dizajna DNS skupa opisanog u RFC standardima, ovi su identifikatori lako predvidljivi, pa je upotreba nasumičnih brojeva za generiranje identifikatora dobra ideja za sprječavanje napada lažiranja. Isto tako, broj UDP porta na kojem poslužitelj za razlučivanje imena prihvaća zahtjeve i odgovara je također lako predvidljiv i može se promijeniti u nasumični.

Za te namjene postoje programi otvorenog koda. izvorni kod, ali kada ih koristite, trebali biste imati na umu da unose malo vremensko kašnjenje u proces obrade zahtjeva. Relativno nova i popularna sigurnosna tehnologija je DNSSEC (DNS Security Extensions). Štiti klijente i poslužitelje od napada koji mijenjaju predmemoriju DNS-a potpisujući zapise korištenjem enkripcije s javnim ključem. Radeći slično SSL-u, podnositelj zahtjeva i odgovarač međusobno uspostavljaju pouzdanu vezu, a nakon što se to uspostavi, započinje proces rješavanja imena.

Nakon što je proces rješavanja imena dovršen, sesija se poništava i na taj način održava sigurnost obiju strana. DNSSEC tehnologija implementirana je na većini poslužitelja pružatelja internetskih usluga u svijetu.

DNS smetnje su uobičajena vrsta napada. Započinje iskorištavanjem grešaka u protokolu i dovodi do toga da napadač dobije pristup IT infrastrukturi ili koristi računala za izvođenje drugih vrsta napada, kao što je phishing. Sustavi temeljeni na besplatnom softveru također su osjetljivi na ove napade, pa administratori sustava moraju razumjeti i koristiti tehnike za zaštitu svoje infrastrukture od gubitka ili krađe podataka.

Ovaj je članak dio serije članaka o cyber napadima koje je napisao isti autor (Prashant Phatak). Ostali članci u ovoj seriji.