Acest post este, de asemenea, disponibil în: 日本語 (Japonez)
Malware actori s-au folosit de Comanda & Control (C2) canalele de comunicare de-a lungul Domain Name Service (DNS) și, în unele cazuri, chiar au folosit protocolul a datelor exfiltrate. Acest lucru este dincolo de ceea ce ar comunica o conexiune C2 „heartbeat”., Actorii răuvoitori au infiltrat, de asemenea, date/sarcini utile rău intenționate în sistemul victimei prin DNS și, de câțiva ani încoace, unitatea 42 research a descris diferite tipuri de abuz descoperite.DNS este un protocol critic și fundamental al internetului-adesea descris ca „agenda telefonică a internetului” – maparea numelor de domenii la adresele IP și multe altele, așa cum este descris în RFC-urile de bază pentru protocol. Omniprezența DNS (și lipsa frecventă de control) pot permite metode foarte elegante și subtile de comunicare și partajare a datelor, dincolo de intențiile inițiale ale protocolului.,pe lângă exemplele de utilizare DNS menționate deja, există o serie de instrumente care pot permite, printre altele, atacatorilor lor să creeze canale ascunse prin DNS în scopul ascunderii comunicării sau ocolirii politicilor puse în aplicare de administratorii de rețea. Un caz de utilizare populară este de a ocoli hotelul, cafeneaua etc. înregistrarea conexiunii Wi-Fi folosind DNS-ul adesea deschis și disponibil. Mai ales aceste instrumente sunt disponibile gratuit online în locuri precum GitHub și pot fi ușor de utilizat. Mai multe informații despre aceste instrumente pot fi găsite în secțiunea anexă de la sfârșitul acestui raport.,
în acest raport introducem tipurile, metodele și utilizarea infiltrării și exfiltrării datelor bazate pe DNS și oferim câteva indicii către mecanismele de apărare.DNS utilizează portul 53, care este aproape întotdeauna deschis pe sisteme, firewall-uri și clienți pentru a transmite interogări DNS. Mai degrabă decât protocolul de control al transmisiei (TCP) mai familiar, aceste interogări utilizează User Datagram Protocol (UDP) datorită latenței reduse, lățimii de bandă și utilizării resurselor, comparativ cu interogările echivalente TCP., UDP nu are nicio eroare sau capacități de control al fluxului și nici nu are nicio verificare a integrității pentru a se asigura că datele au ajuns intacte.
cum este utilizarea internetului (navigare, aplicații, chat etc.) atât de fiabilă atunci? În cazul în care interogarea DNS UDP eșuează (este un protocol de cel mai bun efort după toate), în primul rând, cele mai multe sisteme vor încerca din nou un număr de ori și numai după mai multe eșecuri, potențial comuta la TCP înainte de a încerca din nou; TCP este, de asemenea, utilizat în cazul în care interogarea DNS depășește limitele de dimensiunea Datagram UDP-de obicei 512,figura 1 de mai jos ilustrează procesul de bază al modului în care funcționează DNS: clientul trimite un șir de interogare (de exemplu, mail.googlecom în acest caz) cu un anumit tip – de obicei A pentru o adresă gazdă. Am omis partea prin care sistemele DNS intermediare ar trebui să stabilească unde există”. com”, înainte de a afla unde poate fi găsit „googlecom” și așa mai departe.
Figura 1., Operațiunea DNS simplificată
odată ce un nume este rezolvat la un IP caching, de asemenea, ajută: rezolvat nume-la-IP este de obicei cache pe sistemul local (și, eventual, pe servere DNS intermediare) pentru o perioadă de timp. Interogările ulterioare pentru același nume de la același client nu părăsesc sistemul local până când nu expiră memoria cache menționată. Desigur, odată ce adresa IP a serviciului de la distanță este cunoscută, aplicațiile pot utiliza aceste informații pentru a permite altor protocoale bazate pe TCP, cum ar fi HTTP, să își facă munca reală, de exemplu, asigurându-se că GIF-urile cat cat pot fi partajate în mod fiabil cu colegii.,
Deci, toate în toate, câteva zeci de plus UDP interogări DNS de la o organizație de rețea ar fi destul de discret și-ar putea permite un cod malițios la far la un adversar; comenzi ar putea fi, de asemenea, a primit de solicitant în cererea pentru prelucrare cu puțină dificultate.
dacă doriți să aprofundați modul în care funcționează DNS – până la tastarea tastelor pentru a scrie numele de domeniu pe care doriți să îl răsfoiți – atunci vă rugăm să citiți acest articol.,la fel ca atunci când navigați pe internet, indiferent dacă pivotați dintr-un rezultat al motorului de căutare sau accesați direct o adresă URL a site-ului web, interogările DNS lasă, de asemenea, o urmă. Cât de mult o urmă depinde de sistemele și procesele implicate de-a lungul drumului, de la interogarea care părăsește sistemul de operare, până la primirea adresei IP rezultate.,
concentrându-se doar pe partea de server și, folosind câteva exemple de bază, este posibil ca serverele DNS – în special cele cu logare extinsă sau de depanare activată – să adune o întreagă gazdă (Fără joc de cuvinte intenționat) de informații despre cerere și clientul care o solicită.,
Acest articol oferă o idee despre tipul de informații care ar putea fi obținute de la server DNS busteni; un adversar funcționare a unui astfel de server primeste IP de la distanță trimite cererea – deși acest lucru ar putea fi ultimul hop sau DNS server IP, nu exact solicita clientului IP – precum și șirul de interogare în sine, și oricare ar fi răspunsul a fost de la server.acum, că avem o comună înțeleagă de DNS, modul în care funcționează într-o rețea, și capabilitățile de urmărire server-side, să sape un pic mai adânc în capacitățile de tunel., În această secțiune vom descrie modul în care beaconii de comandă și control (C2) pot funcționa prin DNS și cum este posibilă exfiltrarea și infiltrarea datelor.
C2
un canal C2 servește adesea două scopuri pentru adversar. În primul rând, poate acționa ca un baliză sau bătăi de inimă care indică faptul că sarcina utilă de la distanță încă funcționează – are încă bătăi de inimă – deoarece este beaconing-out (comunică) cu serverul lor.puteți considera operația DNS de bază, așa cum se arată în Figura 1 de mai sus, ca un exemplu de bătăi de inimă., Dacă implantul rău intenționat din sistemul client trimite în mod repetat o interogare către serverul actorului prin infrastructura DNS, actorul ar putea spune din jurnalele că un implant rulează. Ceea ce devine dificil este distingerea între mai multe victime care sunt infectate cu implantul.
luați în considerare un alt exemplu descris în Figura 2 de mai jos, unde sistemul client este compromis cu malware care construiește șiruri de interogare cu aspect ciudat pentru a trimite prin DNS., Interogări ca acestea încă acționează ca o bătaie de inimă care indică adversarului sarcina lor utilă este încă activă, cu toate acestea, ele oferă, de asemenea, unele meta-date de bază despre victimă și, important, modalități de a identifica în mod unic o victimă de la alta.
Figura 2., Exemplu C2 DNS query operation
numele de utilizator și numele de gazdă nu pot fi întotdeauna unice, iar unele IP-uri pot fi duplicate în mai multe rețele folosind Network Address Translation (nat), cu toate acestea sistemele au identificatori unici universali (UUID) sau alte proprietăți, care, combinate, ar putea crea un identificator unic pentru o anumită gazdă sau victimă.
unele dintre meta-datele de la gazda compromisă ar putea fi trimise ca text clar, dar ar putea părea mai suspecte la prima vedere pentru oricine vede astfel de șiruri într-o interogare DNS., În multe cazuri, datele vor conține caractere care nu sunt acceptate de DNS, caz în care va fi necesară codificarea. În Figura 2 puteți vedea echivalentul codificat base64 pentru meta-date, care este construit folosind o notație delimitată ” – ” pentru parsarea și decodarea simplă pe partea serverului, așa cum se arată în Figura 3 de mai jos.
Figura 3., Figura 3 prezintă un exemplu despre cum poate arăta un jurnal DNS brut dintr-o aplicație server DNS, cu intrări de linie pentru interogarea malware-ului și răspunsul serverului DNS, NXDOMAIN (sau domeniu inexistent), în acest caz.
în unele moduri, un jurnal ca acesta, sau poate o mică bază de date care conține înregistrările decodate de la ei, ar putea fi comparat cu panourile de control botnet cu aspect mai snazzy care permit botnet herder să-și controleze sistemele de victime zombie.
Exfiltrare
deci, ce altceva ar putea fi trimis în interogări DNS?, Ei bine, orice în teorie, atâta timp cât este codificat corect și nu abuzează de limitele de dimensiune UDP. O modalitate de a obține în jurul ultima constrângere ar putea fi de a trimite mai multe mesaje de înregistrare și le-au cusute împreună într-un fel pe partea de server. Complicații ar apărea totuși în datagrame abandonate sau lipsă.spre deosebire de TCP care asigură retransmiterea pachetelor eșuate, UDP nu are un astfel de mecanism., Un algoritm ar fi necesar pentru a înțelege câte mesaje vor fi trimise și pentru a verifica numărul corect, dar mai complicat decât atât, cereți cumva clientului să retransmită din nou anumite segmente ale datelor până când ajunge 100%. În funcție de cantitatea de date de transmis – fiecare PDF din sistem, de exemplu – poate dura o vârstă și poate părea extrem de suspect pentru administratorii de rețea.,
infiltrare
în schimb, infiltrarea datelor, fie că este vorba de cod, comenzi, sau un fișier binar să scadă pe disc și să execute ar putea fi mult mai ușor, în special folosind tipul DNS de Txt (spre deosebire de gazdă de înregistrare de tip A). Tipurile TXT au fost concepute pentru a furniza text descriptiv, cum ar fi detaliile serviciului, numele de contact, numerele de telefon etc. ca răspuns la interogările DNS txt pentru numele de domeniu.
ghici ce arata ca textul? Base64-date non-text codificate!, Figura 4 de mai jos arată interogarea identică trimisă site-ului rău intenționat ca în Figura 2, cu toate acestea, tipul este acum TXT atât pe cerere, cât și pe răspuns, iar datele de răspuns conțin primele 300 de caractere ale unui fișier executabil binar codificat care ar putea fi executat de malware-ul client. Din nou, folosind jurnalele, adversarul ar putea să știe ce client a cerut sarcina utilă și că sarcina utilă a fost trimisă (cine știe dacă a sosit de fapt…).
Figura 4., Exemplu C2 interogare DNS Cu răspuns de tip txt
dar cum știe implantul rău intenționat să schimbe tipul în TXT sau când să solicite orice se află în interiorul datelor „text”? Ar putea fi încorporat în sarcina utilă pentru a interoga la un anumit punct al execuției sale sau după o anumită perioadă de timp, dar, în realitate, va fi condus de actor folosind al doilea scop al unui control al canalului C2.
în exemplele mele anterioare de comunicare DNS C2 răspunsul de la serverul DNS a fost NXDOMAIN., Acest mesaj ajunge în mod evident la sistemul client (și malware) și ar putea fi folosit un mesaj sau o instrucțiune pentru sarcina utilă, dar este limitat fără parametri și detalii. Introduceți NOERROR.NOERROR, după cum sugerează termenul, înseamnă că totul a funcționat bine-cererea dvs. a fost procesată și vă așteaptă un răspuns. Cu un NOERROR vine un răspuns care poate fi procesat. De obicei, aceasta este IPv4 (pentru un tip de cereri) sau IPv6 (pentru cererile de tip AAAA) sau ar putea fi TXT, așa cum se arată în Figura 4 de mai sus., Concentrându – se pe un exemplu simplu – răspunsul adresei IPv4-malware-ul nu are nevoie de un IP real pentru a comunica cu, Spre deosebire de browserul dvs. care a întrebat „Unde este googlecom?”. Malware – ul este deja în comunicare cu destinația sa folosind C2 prin DNS.ceea ce malware-ul poate folosi răspunsul IP este oricare dintre cele 4,294,967,296 posibile comenzi sau instrucțiuni. Din nou, păstrând acest lucru foarte simplu, este posibil ca o anumită valoare în octetul 4 al IP-ului, să zicem, 100, să indice malware-ului să trimită o interogare DNS txt către domeniul actorului pentru a colecta și executa o sarcină utilă., Valoarea 10 din primul octet ar putea însemna dezinstalarea și ștergerea urmelor sarcinii utile rău intenționate din sistemul de operare și jurnalele de evenimente. În mod literal, opțiunile sunt nesfârșite, la fel ca și nivelurile de sofisticare posibilă.având în vedere că adversarul are control asupra serverului DNS și că anumite aplicații de server DNS sau demoni sunt extrem de configurabile, este posibil să trimiteți răspunsuri condiționate înapoi la malware pe sistemele victimelor pe baza cererilor trimise de la acestea.,
de exemplu, dacă interogarea primită conține un anumit steag – un caracter-ca primul subdomeniu al numelui de domeniu, acesta ar putea fi citit de un program care rulează în interiorul serviciului DNS de pe server și să ofere un răspuns personalizat înapoi la client. Acest lucru ar putea fi folosit pentru ca malware-ul să funcționeze automat printr-un set de sarcini și să raporteze în consecință actorilor pentru a primi următoarea sarcină.DNS este un instrument foarte puternic folosit aproape peste tot, permițând aplicațiilor și sistemelor să caute resurse și servicii cu care să interacționeze., DNS oferă o comunicare fundația generice de nivel superior și mult mai puternic protocoale pentru a funcționa, dar pot să spun că e trecut cu vederea din punct de vedere al securității, mai ales atunci când ia în considerare cât de mult malware este livrat prin e-mail protocoale sau descărcat de pe web folosind HTTP.din aceste motive, DNS este alegerea perfectă pentru adversarii care caută un protocol întotdeauna deschis, adesea trecut cu vederea și probabil subestimat pentru a utiliza comunicațiile de la și către gazdele compromise., Unitatea 42 a văzut mai multe cazuri de malware, iar actorii din spatele lor, abuzând DNS pentru a reuși în obiectivele lor, așa cum sa discutat în acest raport.
organizațiile se pot apăra împotriva tunelului DNS în multe moduri diferite, indiferent dacă folosesc platforma de Operare de securitate Palo Alto Networks sau tehnologia Open Source.,lowing:
- blocarea numelor de domenii (sau IP-uri sau regiuni de geolocalizare) pe baza reputației cunoscute sau a pericolului perceput;
- reguli în jurul șirurilor de interogări DNS „cu aspect ciudat”;
- reguli în jurul lungimii, tipului sau dimensiunii ambelor interogări DNS de ieșire sau de intrare;
- întărirea generală a sistemelor de operare client și înțelegerea capabilităților de rezoluție a numelui, precum noi domenii fiind accesate mai ales atunci când metoda de acces și frecvența sunt anormale.,Palo Alto Networks a introdus recent un nou serviciu de securitate DNS axat pe blocarea accesului la nume de domenii rău intenționate.
informații suplimentare pot fi găsite și în documentația ATT & CK framework pe site-ul Mitre. Mai exact, următoarele tehnici se referă la conceptele discutate în acest raport.,>
Thanks to Yanhui Jia, Rongbo Shao, Yi Ren, Matt Tennis, Xin Ouyang, John Harrison and Jens Egger for their input on this report.,
Appendix: Toolkit List
| Tool Name | Description |
| dns2tcp | dns2tcp was written by Olivier Dembour and Nicolas Collignon. It is written in C and runs on Linux. The client can run on Windows. It supports KEY and TXT request types. |
| tcp-over-dns | tcp-over-dns (TCP-over-DNS) was released in 2008., Are un server bazat pe Java și un client bazat pe Java. Se rulează pe Windows, Linux și Solaris. Aceasta susține compresia LZMA și tunelul de trafic TCP și UDP. |
| OzymanDNS | OzymanDNS este scris în Perl, de Dan Kaminsky în 2004. Este folosit pentru a configura un tunel SSH peste DNS sau pentru transferul de fișiere. Cererile sunt codificate base32 și răspunsurile sunt înregistrări TXT codificate base64., |
| iod | iodul este un DNS tunel program lansat în 2006 cu actualizări recent, în 2010. A fost dezvoltat de Bjorn Andersson și Erik Ekman. Iodul este scris în C și rulează pe Linux, Mac OS X, Windows și altele. Iodul a fost portat pe Android. Acesta utilizează o interfață TUN sau robinet pe punctul final. |
| SplitBrain | SplitBrain este o variantă de OzymanDNS., |
| DNScat-P / dnscat2 | DNScat (DNScat-P) a fost inițial lansat în 2004 și cea mai recentă versiune a fost lansat în 2005. A fost scrisă de Tadeusz Pietraszek. DNScat este prezentat ca un instrument” Swiss-Army knife ” cu multe utilizări care implică comunicare bidirecțională prin DNS. DNScat se bazează Java și rulează pe sisteme asemănătoare Unix. DNScat acceptă o înregistrare și CNAME cereri de înregistrare (Pietraszek, 2004)., Deoarece există două utilități numite DNScat, aceasta va fi denumită DNScat-P în această lucrare pentru a o distinge de cealaltă. |
| DNScapy | DNScapy a fost dezvoltat de Pierre Bienaime. Acesta utilizează Scapy pentru generarea de pachete. DNScapy sprijină SSH tunel peste DNS, inclusiv un proxy șosete. Acesta poate fi configurat pentru a utiliza CNAME sau înregistrări TXT sau ambele aleatoriu. |
| TUNS | TUNS, un IP peste DNS tunel, a fost dezvoltat de către Lucas Nussbaum și scris în Ruby., Nu utilizează tipuri de înregistrări experimentale sau rareori utilizate. Utilizează numai înregistrări CNAME. Ajustează MTU utilizat la 140 de caractere pentru a se potrivi cu datele dintr-o solicitare DNS. TUNS poate fi mai greu de detectat, dar vine la un cost de performanță. |
| PSUDP | PSUDP a fost dezvoltat de Kenton Născut. Injectează datele în cererile DNS existente prin modificarea lungimilor IP / UDP., Este nevoie de toate gazdele care participă la rețeaua ascunsă pentru a trimite cererile DNS la un serviciu de Broker care poate stoca mesaje pentru o anumită gazdă până când o solicitare DNS vine de la acea gazdă. Mesajul poate fi apoi trimis în răspuns. |
| Libertatea | HTTPS/UDP/FTP/DNS/ECHO VPN & tunel solutia pentru Windows, Mac OSX, Linux și Android., Bypass proxy-uri și acces la Internet anonim |
| Hexify | Un instrument este dezvoltat de către Infoblox pentru a face penetrarea test pentru DNS tunel., |
Appendix: Malware List
| Malware Name | Description |
| DNS_TXT_Pwnage | A backdoor capable of receiving commands and PowerShell scripts from DNS TXT queries., |
| DNSMessenger | DNSMessenger este Remote Access Trojan (RAT) care se deschide un backdoor, astfel încât hackerii pot controla de la distanță computerul compromis la distanță |
| OilRig – BONDUPDATER | Trojan împotriva unui guvern din orientul Mijlociu poate folosi Un evidențe și înregistrări TXT cadrul DNS protocol de tunelare pentru C2 comunicații |
