Securitate serioasă: cum ar putea îmbunătăți securitatea DNS typO-urile deliberate

De-a lungul anilor, am scris și vorbit pe Naked Security de multe ori despre problema spinoasă a DNS piratarea.

DNS, după cum probabil știți, este prescurtarea pentru numele domeniului, și îl veți auzi adesea descris ca „director telefonic” sau „gazetteer” al internetului.

Dacă nu ești familiarizat cu cuvântul gazeter, se referă la indexul din spatele unui atlas în care te uiți în sus, de exemplu, Monrovia, Liberia într-o listă alfabetică convenabilă și scrie ceva de genul 184 - C4. Aceasta vă spune să treceți direct la pagina 184 și să urmați liniile grilei în jos de la litera C din partea de sus a hărții și vizavi de numărul 4 din stânga. Acolo unde liniile se întâlnesc, vei găsi Monrovia.

Pentru majoritatea utilizatorilor, cele mai multe căutări DNS apar care conțin un nume de server, cerând un răspuns care să includă ceea ce este cunoscut sub numele de înregistrarea A sau înregistrarea AAAA.

(Înregistrările A sunt folosite pentru numerele de internet IPv32 pe 4 de biți, cum ar fi 203.0.113.42; Înregistrările AAAA sunt răspunsurile echivalente pentru adrese IPv128 pe 6 de biți, cum ar fi 2001:db8:15a:d0c::42 – în acest articol, vom folosi doar înregistrări A și numere IPv4, dar aceleași probleme de securitate se aplică procesului de căutare în ambele cazuri.)

Iată un exemplu în care căutăm numele de domeniu imaginar naksec.test printr-un server DNS care a fost creat special pentru a urmări și a vă învăța despre traficul DNS.

Am folosit instrumentul Linux de școală veche dig, scurt pentru domeniu internet groper, pentru a genera o cerere DNS simplă (dig implicit să caute înregistrări A) pentru serverul pe care îl dorim:

$ dig +noedns @127.42.42.254 naksec.test ;; SECȚIUNEA DE ÎNTREBĂRI: ;naksec.test. IN A ;; SECȚIUNEA RĂSPUNSURI: NAKSEC.TEST. 5 IN A 203.0.113.42 ;; Timp de interogare: 1 ms ;; SERVER: 127.42.42.254#53(127.42.42.254) (UDP) ;; CÂND: Luni 23 ian 14:38:42 GMT 2023 ;; MSG SIZE rcvd: 56

Iată cum a tratat serverul nostru DNS cererea, arătând un dump hexadecimal al cererii primite și răspunsul cu succes care a revenit:

---> Solicitare de la 127.0.0.1:57708 la 127.42.42.254:53 ---> 00000000 62 4e 01 20 00 01 00 00 00 00 00 00 06 6b | .........nak| 61 6 00000010 73 65 63 04 74 65 73 74 00 00 01 |sec.test..... | Căutare DNS: A-record pentru naksec.test ==> A=00 <--- Răspuns de la 01:203.0.113.42 la 127.42.42.254:53 <--- 127.0.0.1 57708 00000000e 62 4 84 0 00 01 00 01 00 00 b 00 00 06 6e 61 6b |bN...........nak| 00000010 73 65 63 04 74 65 73 74 00 00 01 00 01 06 4e 41 |sec.test......NA| 00000020 4b 53 45 43 04 54 45 53 54 00 00 01 00 01 00 00 |KSEC.TEST.......| 00000030 00 05 00 04 cb 00 71 2a |......q* |

Rețineți că, din motive de performanță, majoritatea solicitărilor DNS folosesc UDP, the protocol de datagramă utilizator, care funcționează pe bază de trimitere și speranță: declanșați un pachet UDP la serverul cu care doriți să vorbiți, apoi așteptați să vedeți dacă vă întoarce un răspuns.

Acest lucru face UDP mult mai simplu și mai rapid decât vărul său mare TCP, the Protocol de control al transmisiei, care, după cum sugerează și numele, se ocupă automat de o mulțime de detalii pe care UDP nu le face.

În special, TCP se ocupă de detectarea pierderii datelor și de a cere să le refuze din nou; asigurarea faptului că orice fragmente de date ajung în ordinea corectă; și furnizarea unei singure conexiuni de rețea care, odată configurată, poate fi folosită pentru trimitere și primire în același timp.

UDP nu are conceptul de „conexiune”, astfel încât cererile și răspunsurile călătoresc în esență independent:

• O solicitare DNS ajunge la serverul DNS într-un pachet UDP propriu.
• Serverul DNS păstrează o înregistrare din care computer a trimis acel pachet.
• Serverul se apucă să găsească un răspuns pe care să îl trimită înapoi, sau să decidă că nu există.
• Serverul trimite un răspuns către expeditorul inițial, folosind un al doilea pachet UDP.

De la nivelul sistemului de operare sau al rețelei, cele două pachete UDP de mai sus sunt transmisii independente, independente – nu sunt legate împreună ca parte a aceleiași conexiuni digitale.

Este de latitudinea serverului să-și amintească la ce client să trimită fiecare răspuns; și depinde de client să descopere ce răspunsuri se referă la ce solicitări le-a trimis inițial.

Cum poți fi sigur?

În acest moment, în special privind dimensiunea redusă a cererii DNS și a răspunsului de mai sus, probabil că vă întrebați: „Cum poate clientul să fie sigur că se potrivește cu răspunsul corect și nu unul care a fost deranjat în tranzit sau direcționat incorect din greșeală, fie din întâmplare, fie din proiect?”

Din păcate, multe, dacă nu majoritatea, solicitările DNS (în special cele de la server la server, când primul server pe care îl întrebați nu știe răspunsul și trebuie să găsească unul care să o facă pentru a-și formula răspunsul) nu sunt criptate, sau altfel etichetat cu orice fel de cod de autentificare criptografic.

De fapt, în mod implicit, cererile DNS includ o singură „etichetă de identificare”, la care se face referire în documentația formatului de date DNS pur și simplu ca ID.

În mod uimitor, în ciuda faptului că a primit numeroase actualizări și a sugerat îmbunătățiri de-a lungul anilor, RFC oficial de internet (Cerere de comentarii) document care acționează ca specificația DNS este încă RFC 1035 (în prezent suntem în RFC-uri la mijlocul anilor 9000), datând din noiembrie 1987, cu puțin peste 35 de ani în urmă!

Pe atunci, atât lățimea de bandă, cât și puterea de procesare erau reduse: vitezele tipice ale procesorului erau de aproximativ 10MHz; computerele desktop aveau aproximativ 1MB de RAM; Vitezele de acces la internet, pentru organizațiile care se puteau conecta deloc, erau adesea de 56 kbits/sec sau 64 kbits/sec, partajate între toți; iar 1200 biți/sec era alegerea accesibilă pentru conectivitate personală prin modemurile dialup ale zilei.

De aceea, anteturile de solicitare și răspuns DNS au fost – și sunt încă – stricate în 12 octeți, dintre care eticheta de identificare îi ocupă pe primii doi, ca și drăguțul RFC 1035. ASCII art clarifica:

 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 | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Puteți vedea ID-ul în acțiune în imaginile hexadecimale afișate mai sus, unde atât pachetele de solicitare, cât și cele de răspuns încep cu aceleași două caractere bN, care corespund identificatorului de 16 biți 62 4e în hex.

Foarte vag vorbind, acești 16 biți sunt atât de mult cât oferă protocolul DNS oficial prin „autentificare” sau „detecție a erorilor”.

Amestec prin presupuneri

După cum vă puteți imagina, având în vedere simplitatea de la capăt la capăt a traficului DNS obișnuit, oricine are așa-numitul caseta de mijloc or proxy de scanare cine vă poate intercepta, examina și modifica traficul dvs. de rețea se poate amesteca trivial în traficul dvs. DNS.

Aceasta include trimiterea de răspunsuri care vă oferă în mod deliberat informații inexacte, cum ar fi echipa dvs. IT care vă redirecționează departe de serverele despre care știe că sunt pline de malware.

Poate include, de asemenea, ISP-ul dvs. care respectă legislația din țara dvs. care impune ca unele servere să fie raportate ca inexistente, chiar dacă sunt vii și funcționează bine, deoarece se află pe o listă blocată de conținut ilegal, cum ar fi materialele abuzive asupra copiilor.

Dar, la prima vedere, acest tip ultra-slab de etichetare ID DNS pare să o facă, de asemenea, banală chiar și pentru atacatorii care nu au deloc vizibilitate asupra traficului dvs. de rețea pentru a lansa răspunsuri DNS false către utilizatorii sau serverele dvs....

…cu o șansă periculos de mare de succes.

La urma urmei, dacă atacatorii știu că cineva din rețeaua ta îi place să viziteze în mod regulat naksec.test, serverul respectiv ar putea părea un loc suculent pentru a implanta știri false, actualizări dubioase sau cod JavaScript necinstite.

Și dacă atacatorii nu sunt capabili să pirateze naksec.test serverul propriu-zis, ce ar fi dacă ar lansa în mod regulat și frecvent pachete UDP la serverul dvs. DNS, folosind o etichetă ID inventată, care pretindea că răspunde la întrebarea „Pentru ce este înregistrarea A naksec.test„?

În acest fel, ei ar putea fi capabili să deturneze cererea DNS, să ofere un răspuns fals și, prin urmare, să vă direcționeze greșit următoarea vizită pe site - în esență, deturnând site-ul în sine fără a fi nevoie să atace vreodată naksec.test server la toate.

E nevoie de ceva noroc

Ar trebui să fie puțin norocoși, desigur, deși ar putea încerca din nou și din nou pentru a-și crește șansele generale, având în vedere că trebuie să reușească o singură dată, în timp ce trebuie să obțineți un răspuns DNS adevărat de fiecare dată.

Pentru a reuși, ar trebui să trimită răspunsul lor DNS necinstit:

• Într-o perioadă în care propriul tău server nu știa deja răspunsul la întrebare. Răspunsurile DNS includ un număr pe 32 de biți numit TTL, prescurtare pentru timpul sa traiesti, care spune cât timp celălalt capăt poate continua să refolosească răspunsul. Dacă tu sau oricine altcineva din rețeaua ytour ai cerut naksec.test recent, serverul dvs. DNS ar putea avea răspunsul în memoria cache. Nu ar fi nevoie de o căutare suplimentară și nu ar exista nicio solicitare de ieșire ca atacatorii să deturneze.
• Între momentul în care ați trimis solicitarea și răspunsul oficial a venit din afară. Chiar și în vremurile de demult, timpii de căutare DNS rareori durau mai mult de câteva secunde. Astăzi, ele sunt cel mai bine măsurate în milisecunde.
• Cu numărul potrivit în primii 16 biți. Puteți monta 65536 (2¹⁶) valori diferite în 16 biți, așa că atacatorii ar trebui să fie oarecum norocoși. Dar la lățimile de bandă ale rețelei de astăzi, trimiterea a 65536 de răspunsuri false diferite simultan, acoperind astfel toate numerele de identificare posibile, durează o mică fracțiune de secundă.

Din fericire, serverele DNS decente fac un pas suplimentar pentru a face deturnarea dificilă în mod implicit.

Cel puțin, asta fac ei din aproximativ 2008, când răposatul Dan Kaminsky a subliniat că pe atunci multe servere DNS nu erau doar configurate să asculte cererile primite pe un port UDP fix (aproape întotdeauna portul 53, atribuit oficial DNS)...

…dar și pentru a primi răspunsuri de intrare pe un port fix, deseori și portul 53, chiar dacă doar pentru a crea o simetrie plăcută în trafic.

Motivul utilizării unui port fix în ambele direcții a fost probabil inițial pentru simplitatea programării. Ascultând întotdeauna răspunsurile pe același număr de port UDP, nu trebuie să urmăriți ce porturi ar trebui să fie deschise pentru care răspunsuri. Aceasta înseamnă că componentele de gestionare a cererilor și generatorul de răspunsuri ale software-ului dvs. DNS pot funcționa independent. Ascultătorul solicitării nu trebuie să-i spună expeditorului răspunsului: „Acest răspuns special trebuie să se întoarcă pe un port special, nu pe cel obișnuit”.

Utilizați numerele de port ca ID suplimentar

În zilele noastre, aproape toate serverele DNS bazate pe UDP ascultă pe portul 53, ca întotdeauna, dar țin evidența așa-numitului „port sursă” folosit de solicitantul DNS, despre care se așteaptă să fie ales aleatoriu.

Porturile sursă UDP, care sunt un pic ca un „număr de extensie” într-o centrală telefonică de birou de școală veche, sunt destinate să fie utilizate pentru a vă ajuta pe dvs. și rețeaua să diferențiați cererile unele de altele.

Porturile de protocol Internet (de asemenea le folosește TCP) pot rula de la 1 la 65535, deși majoritatea conexiunilor de ieșire folosesc doar porturile sursă 1024-65535, deoarece numerele de porturi 1023 și mai jos sunt de obicei rezervate pentru procesele cu privilegii de sistem.

Ideea este că expeditorul oricărei căutări DNS nu trebuie doar să introducă un ID de 16 biți cu adevărat aleatoriu la începutul fiecărei cereri, ci și să aleagă un număr de port sursă UDP cu adevărat aleatoriu la care va asculta răspunsul asociat.

Acest lucru adaugă un nivel suplimentar de presupuneri pe care escrocii trebuie să-l adauge la lista lor de „hijack noroc” de mai sus, și anume că trebuie să trimită un răspuns fals care bifează toate aceste casete:

• Trebuie să fie o interogare care a fost solicitată recent, de obicei în ultimele câteva secunde.
• Trebuie să fie o căutare care nu a fost în memoria cache a serverului local, de obicei, ceea ce înseamnă că nimeni altcineva nu a întrebat despre asta în ultimele minute.
• Trebuie să aibă numărul de ID corect pe 16 biți la începutul pachetului de date.
• Trebuie trimis în portul de destinație potrivit la numărul IP al serverului relevant.

Și încă ceva

De fapt, există încă un truc pe care solicitanții DNS îl pot face, fără a schimba protocolul DNS de bază și, astfel, (în cea mai mare parte) fără a întrerupe nimic.

Acest truc, în mod uimitor, a fost mai întâi propuse în 2008, într-o lucrare intitulată glorios Rezistență sporită la falsificarea DNS prin codificarea 0x20 de biți: securitate prin interogări LEET.

Ideea este ciudat de simplă și se bazează pe două detalii din protocolul DNS:

• Toate răspunsurile DNS trebuie să includă secțiunea de interogare originală la început. Interogările, evident, au o secțiune de răspunsuri goală, dar răspunsurile sunt necesare pentru a reflecta întrebarea inițială, ceea ce ajută la asigurarea faptului că cererile și răspunsurile nu se confundă accidental.
• Toate întrebările DNS nu fac distincție între majuscule și minuscule. Fie că ceri naksec.test, Sau NAKSEC.TEST, Sau nAksEc.tESt, ar trebui să primiți același răspuns.

Acum, nu există nimic în protocol care să spună că TREBUIE să utilizați aceeași ortografie în partea din răspuns în care repeți interogarea inițială, deoarece DNS nu-i pasă de majuscule.

Dar, deși RFC 1035 vă solicită să faceți comparații care nu țin cont de majuscule, sugerează cu tărie să nu schimba de fapt cazul a oricăror nume text pe care le primiți în solicitări sau preluați din propriile baze de date pentru a fi utilizate în răspunsuri.

Cu alte cuvinte, dacă primiți o cerere pentru nAKsEC.tEST, iar baza ta de date o are stocată ca NAKSEC.TEST, atunci acele două nume sunt totuși considerate identice și se vor potrivi.

Dar când formulați răspunsul dvs., RFC 1035 vă sugerează nu modificați caracterele majuscule ale datelor pe care le-ați introdus în răspuns, chiar dacă ați putea crede că ar arăta mai îngrijit și chiar dacă s-ar potrivi în continuare la celălalt capăt, datorită comparației fără majuscule cerute de DNS.

Deci, dacă amestecați aleatoriu majusculele într-o solicitare DNS înainte de a o trimite, majoritatea serverelor DNS vor reflecta fidel acel amestec ciudat de litere, chiar dacă propria lor bază de date stochează diferit numele serverului, așa cum vedeți aici. :

$ dig +noedns @127.42.42.254 nAkSEc.tEsT ;; SECȚIUNEA DE ÎNTREBĂRI: ;nAkSEc.tEsT. ÎN A ;; SECȚIUNEA RĂSPUNSURI: NAKSEC.TEST. 5 IN A 203.0.113.42 ;; Timp de interogare: 1 ms ;; SERVER: 127.42.42.254#53(127.42.42.254) (UDP) ;; CÂND: Luni 23 ian 14:40:34 GMT 2023 ;; MSG SIZE rcvd: 56

Serverul nostru DNS stochează numele naksec.test toate cu majuscule și astfel secțiunea de răspuns a răspunsului include numele în formular NAKSEC.TEST, împreună cu numărul său IPv4 (înregistrarea A) al 203.0.113.42.

Dar în partea „iată datele de interogare returnate pentru verificare încrucișată” a răspunsului pe care serverul nostru DNS îl trimite înapoi, mashup-ul de caractere cu majuscule utilizat inițial în căutarea DNS este păstrat:

---> Solicitare de la 127.0.0.1:55772 la 127.42.42.254:53 ---> 00000000 c0 55 01 20 00 01 00 00 00 00 00 00 06 6e 41. 6b |. .........nAk| 00000010 53 45 63 04 74 45 73 54 00 00 01 00 01 |SEc.tEsT..... | Căutare DNS: A-record pentru nAkSEc.tEsT ==> A=203.0.113.42 <--- Răspuns de la 127.42.42.254:53 la 127.0.0.1:55772 <--- 00000000 0 c55 84 0 00 01 00 01 00 00 00 00 06 6 41 6 00000010 53 45e 63 04b |.U...........nAk| 74 45 73 54 00 00 01 00 01 06 4 41 00000020 4 53 45e 43 |SEc.tEsT......NA| 04 54b 45 53 54 00 00 01 00 01 00 00 00000030 00 05 00 04 |KSEC.TEST.......| 00 71 2 XNUMX XNUMX cb XNUMX XNUMX XNUMXa |......q* |

Etichetare suplimentară de securitate, gratuită

Bingo!

Există mai multe „etichete de identificare” pe care o căutare DNS le poate adăuga!

Împreună cu valoarea de aproximativ 15 biți ai portului sursă ales aleatoriu și 16 biți de date ale numerelor de identificare alese aleatoriu, solicitantul poate alege majuscule versus minuscule pentru fiecare caracter alfabetic din numele domeniului.

Și naksec.test conține 10 litere, fiecare dintre acestea putând fi scrisă cu litere mari sau mici, pentru încă 10 biți de „etichetare” aleatoriu.

Cu acest detaliu suplimentar de ghicit, atacatorii ar trebui să aibă noroc cu timpul lor, numărul portului UDP, valoarea etichetei de identificare și scrierea cu majuscule a numelui de domeniu, pentru a injecta un „răspuns de deturnare” fals pe care serverul solicitant. ar accepta.

Apropo, numele codificare 0x20 mai sus este un pic de glumă: 0x20 în headecimal este 00100000 în binar, iar bitul solitar din acel octet este ceea ce diferențiază literele majuscule și minuscule în sistemul de codificare ASCII.

Scrisorile A la I, de exemplu, iese ca 0x41 până la 0x49, în timp ce a la i iese ca 0x61 până la 0x69.

 Diagramă de codificare ASCII ca text ASCII +------+------+------+------+------+------+- -----+------+ |00 ^@ |10 ^P |20 |30 0 |40 @ |50 P |60 ` |70 p | |01 ^A |11 ^Q |21 ! |31 1 |41 A |51 Q |61 a |71 q | |02 ^B |12 ^R |22 " |32 2 |42 B |52 R |62 b |72 r | |03 ^C |13 ^S |23 # |33 3 |43 C |53 S |63 c |73 s | |04 ^D |14 ^T |24 $ |34 4 |44 D |54 T |64 d |74 t | |05 ^E |15 ^U |25 % |35 5 |45 E |55 U |65 e |75 u | |06 ^F |16 ^V |26 & |36 6 |46 F |56 V |66 f |76 v | |07 ^G |17 ^W |27 ' |37 7 | 47 G |57 W |67 g |77 l | |08 ^H |18 ^X |28 ( |38 8 |48 H |58 X |68 h |78 x | |09 ^I |19 ^Y |29 ) |39 9 |49 I |59 Y |69 i |79 y | |0A ^J |1A ^Z |2A * |3A : |4A J |5A Z |6A j |7A z | |0B ^K |1B ^ [ |2B + |3B ; |4B K |5B [ |6B k |7B { | |0C ^L |1C ^ |2C , |3C < |4C L |5C |6C l |7C | | |0D ^M | 1D ^] |2D - |3D = |4D M |5D ] |6D m |7D } | |0E ^N |1E ^^ |2E . |3E > |4E N |5E ^ |6E n |7E ~ | | 0F ^O |1F ^_ |2F / |3F ? |4F O |5F _ |6F sau |7F | +------+------+------+--- ---+------+------+------+------+

Cu alte cuvinte, dacă adăugați 0x41+0x20 pentru a obține 0x61, vă întoarceți A în a; dacă scadeți 0x69-0x20 pentru a obține 0x49, întoarceți i în I.

De ce acum?

S-ar putea, până acum, să te întrebi, „De ce acum, dacă ideea a apărut în urmă cu 15 ani și, oricum, ar face ceva bine?”

Interesul nostru brusc, după cum se întâmplă, vine de la a e-mail public recent de la tehnicieni Google, admițând că experimentele lor din 2022 cu acest truc de securitate vechi au fost implementate în viața reală:

După cum am anunțat anterior, Google Public DNS este în proces de activare a randomizării cu majuscule și minuscule a numelor de interogări DNS trimise la serverele de nume autorizate. L-am implementat cu succes în unele regiuni din America de Nord, Europa și Asia, protejând majoritatea (90%) interogărilor DNS din acele regiuni care nu sunt acoperite de DNS prin TLS.

În mod intrigant, Google sugerează că principalele probleme pe care le-a avut cu această modificare simplă și aparent necontroversată este că, în timp ce majoritatea serverelor DNS fie nu țin cont de majuscule și minuscule (deci acest truc poate fi folosit cu ele) sau nu (deci sunt blocate), asa cum te-ai putea astepta...

… câteva servere maintream intră ocazional în modul „care ține cont de majuscule” pentru perioade scurte, ceea ce sună ca genul de inconsecvență pe care ai spera că ar evita marii furnizori de servicii.

Chiar ajută?

Raspunsul la intrebare, "Merita?" încă nu este clar.

Dacă ai un nume de serviciu lung frumos, cum ar fi nakedsecurity.sophos.com (22 de caractere alfabetice), atunci există multă putere de semnalizare suplimentară, deoarece 2²² valorile majuscule diferite înseamnă 4 milioane de combinații pe care să le încerce escrocii, înmulțite cu cele 65536 de numere de identificare diferite, înmulțite cu aproximativ 32000 până la 64000 de porturi sursă diferite de ghicit...

…dar dacă ați plătit o mică avere pentru un nume de domeniu superscurt, cum ar fi Twitter t.co, atacatorii tăi au doar o muncă de 2x2x2=8 ori mai grea decât înainte.

Cu toate acestea, cred că putem spune „Chapeau” lui Google pentru că a încercat acest lucru.

După cum le place să spună observatorii securității cibernetice, atacurile devin doar mai rapide, așa că orice poate lua un protocol existent și poate adăuga timp de cracare suplimentar, aproape „gratuit”, este o modalitate utilă de a riposta.

---

• Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
• Platoblockchain. Web3 Metaverse Intelligence. Cunoștințe amplificate. Accesați Aici.
• Sursa: https://nakedsecurity.sophos.com/2023/01/23/serious-security-how-deliberate-typos-might-improve-dns-security/