Atacul homograf: cum te păcălește un domeniu clonă

Un atac homograf înregistrează un domeniu construit din caractere care arată identic cu cele dintr-un domeniu real, dar nu sunt aceleași - un "a" chirilic în locul unui "a" latin, de exemplu - astfel încât adresa pe care o citește o persoană și adresa pe care o rezolvă un browser sunt două lucruri diferite. Trucul funcționează pentru că sistemul de nume de domenii înțelege doar ASCII, așa că fiecare domeniu non-ASCII este tradus într-o formă ASCII numită punycode, marcată cu un prefix xn--, înainte să ajungă vreodată la DNS. Browserele o decodează înapoi în versiunea lizibilă pentru afișare, iar acest pas de decodare este exact locul unde trăiește înșelăciunea.

Browserele moderne prind acum cazurile evidente și revin la afișarea formei punycode brute atunci când o etichetă amestecă alfabete într-un mod suspect, blocând majoritatea atacurilor simple care funcționau acum un deceniu. Dar această protecție nu depășește bara de adrese a browserului.

Mă ocup de cazuri de falsificare a brandurilor ca meserie, iar falsurile bune încă îmi atrag privirea pentru o jumătate de secundă înainte să înregistrez semnul care le trădează. Acest articol acoperă cum funcționează un atac homograf, unde se oprește apărarea browserului și ce poți face în privința asta - fie că ești pe cale să dai clic, fie că deții domeniul care este falsificat. Pentru întrebarea mai largă legată de cât de sigure sunt linkurile scurte în sine, sunt scurtătoarele de linkuri sigure acoperă acel subiect; acesta este despre domeniul care se află dedesubtul linkului.

Ce este punycode și de ce există

DNS a fost construit pentru ASCII, punct. Nu are niciun mod nativ de a stoca literele accentuate, caracterele chirilice, arabe sau chinezești care alcătuiesc majoritatea sistemelor de scriere din lume, ceea ce a devenit o problemă reală din momentul în care înregistrarea domeniilor s-a deschis în afara piețelor vorbitoare de limba engleză.

Punycode este soluția: o codare reversibilă, standardizată ca RFC 3492, care transformă o etichetă Unicode în litere, cifre și cratime ASCII pe care DNS le poate transporta fără nicio modificare a protocolului de transmisie. O brutărie germană care înregistrează un domeniu cu o umlaut, sau un retailer ucrainean care înregistrează unul în chirilică, obține un nume de domeniu internaționalizat funcțional care se rezolvă exact ca oricare altul, pentru că dedesubt este doar o altă etichetă ASCII. Forma codată începe întotdeauna cu xn--, semnalând "aceasta este punycode, decodeaz-o înainte să o arăți unui om."

Niciunul dintre aceste lucruri nu este o vulnerabilitate în sine - numele de domenii internaționalizate sunt o funcție reală și necesară, nu o soluție de ocolire pe care cineva ar trebui să o dezactiveze. Problema începe un nivel mai sus, în momentul în care browserul decide cum să îți afișeze înapoi acel nume decodat.

Cum funcționează un atac homograf

Un atac homograf exploatează diferența dintre ce conține un domeniu și cum arată odată redat. Există două variante întâlnite în practică, și nu sunt la fel de răspândite.

Versiunea cu alfabet întreg înregistrează un domeniu complet într-un alfabet non-latin ale cărui forme de litere seamănă întâmplător cu brandul vizat. Este ușor de observat la construire și mai simplu de detectat pentru cei care apără, pentru că întreaga etichetă este străină.

Versiunea cu alfabete amestecate este cea care chiar se folosește, pentru că are nevoie de o singură substituție. Ia un domeniu ca novacloud.com. Înlocuiește "o" latin cu "о" chirilic (U+043E), vizual identic, și obții nоvacloud.com - aceeași formă, aceeași lungime, punct de cod diferit, și un domeniu care se codează ca xn--nvacloud-nbh.com. Tot restul etichetei rămâne neatins, așa că ochiul nu are aproape nimic de semnalat. Cercetătorii în securitate numesc acest tip de pereche similară vizual un "confusable", iar un număr mic dintre ele acoperă majoritatea alfabetului latin.

Odată ce domeniul este înregistrat, restul atacului este phishing obișnuit: o pagină de autentificare copiată pixel cu pixel, un mesaj urgent care indică spre linkul falsificat, și o țintă care nu are niciun motiv să se îndoiască de o adresă care arată exact cum trebuie.

Ce fac browserele în privința asta astăzi

Producătorii de browsere au închis majoritatea versiunii simple a acestui atac cu ani în urmă, cu o regulă despre ce alfabete sunt permise să se amestece într-o singură etichetă. Politica Chrome, documentată în ghidul său de gestionare IDN, verifică dacă fiecare caracter dintr-o etichetă aparține în mod plauzibil unui singur alfabet, sau unui set restrâns de combinații de alfabete care apar legitim împreună, cum ar fi kanji japonez cu hiragana. Amestecă alfabete în afara acelui set permis și browserul afișează forma xn-- brută în loc să o decodeze - cel mai bun atu al atacului, un domeniu care arată complet normal, se transformă înapoi într-un șir evident codat. Firefox rulează o verificare comparabilă, descrisă în algoritmul de afișare IDN al Mozilla, iar Safari aplică propria sa versiune.

Nu este o protecție completă. O etichetă cu alfabete amestecate, construită doar din caractere dintr-o singură combinație permisă, poate încă trece drept un nume lizibil și înșelător, iar regula este aplicată browser cu browser, fără nicio autoritate comună care să decidă ce contează drept sigur.

Unde se oprește această protecție

Verificarea amestecului de alfabete trăiește în codul de randare a barei de adrese a browserului. Nu călătorește odată cu URL-ul nicăieri altundeva, iar acest gol este exact locul unde un domeniu falsificat mai poate face daune reale.

Clienții de email sunt cea mai mare expunere: un mesaj poate afișa orice text de ancoră peste un link, indiferent de destinație, iar majoritatea aplicațiilor de mail nu rulează deloc vreo verificare de caractere confuzabile. Aplicațiile de chat despăturesc un link partajat într-un card de previzualizare construit din metadatele paginii, nu dintr-un randor conștient de punycode. Codurile QR elimină complet pasul de text, un gol pe care îl acoperim în sunt codurile QR sigure, iar materialele tipărite nu au niciun strat software între ochi și înșelăciune.

Dacă echipa ta trimite linkuri sub un domeniu pe care clienții tăi îl recunosc deja, un domeniu clonă falsificat are mult mai puțin spațiu să te imite convingător pe toate aceste canale simultan. Vezi cum funcționează un domeniu personalizat de brand pe Elido dacă încă trimiți linkuri de pe un domeniu partajat sau generic.

De ce un domeniu de brand este cea mai bună apărare a ta

Un atac homograf funcționează exploatând familiaritatea - are nevoie de un brand recunoscut pentru a-l contraface. Asta sună ca un argument împotriva construirii unui domeniu propriu, recunoscut, dar este exact opusul. Un link scurt de brand distinctiv, pe care publicul tău îl asociază deja cu tine, este ceva cu care poate compara un mesaj suspect; un domeniu de scurtător generic sau împrumutat oferă unui atacator un șablon pe care clienții nu îl pot distinge oricum de furnizorul real, pentru că niciunul dintre ele nu arată ca "tine".

Configurarea unui domeniu personalizat pentru linkuri scurte înseamnă că fiecare link pe care îl trimiți poartă un nume pe care destinatarii îl recunosc, ceea ce ridică ștacheta pentru oricine încearcă să îl contrafacă. Merită separat de mascarea linkurilor și camuflarea URL-urilor, o alegere deliberată și declarată de a ruta linkurile prin propriul tău domeniu. Un atac homograf este mișcarea opusă - ascunde identitatea atacatorului în timp ce o imită pe a ta - iar apărarea este transparența despre care domeniu este cu adevărat al tău.

Controalele de registrar care contează cu adevărat

Două controale fac cea mai mare parte a muncii reale odată ce deții un domeniu care merită protejat, iar ele operează la niveluri diferite ale stivei.

Registrar lock este cel de zi cu zi - un indicator de stare, afișat adesea ca clientTransferProhibited, care blochează cererile automate de rutină de transfer din interiorul propriului tău panou de registrar. Fiecare domeniu pe care îl folosești activ ar trebui să îl aibă activat; nu costă nimic. Registry lock stă un nivel mai sus, implicând direct operatorul registrului, astfel încât orice modificare, transfer sau ștergere necesită verificare manuală, în afara canalului obișnuit - un apel telefonic sau o parolă securizată - înainte să intre în vigoare. Această fricțiune își are locul pe unul sau două domenii unde o modificare neautorizată ar fi cu adevărat costisitoare, ceea ce pentru majoritatea companiilor înseamnă cel puțin domeniul principal de brand.

Niciunul dintre cele două blocaje nu împiedică pe cineva să înregistreze un domeniu clonă lângă al tău. Asta necesită monitorizare activă: urmărirea înregistrărilor noi de domenii și a jurnalelor publice de transparență a certificatelor pentru nume vizual apropiate de brandul tău, astfel încât să poți raporta la registrar sau să alertezi clienții înainte ca o campanie care îl folosește să ajungă la cineva.

Ce să incluzi într-o politică de protecție a brandului

Dacă deții un domeniu care merită falsificat, secțiunea de securitate a politicii tale de protecție a brandului ar trebui să fie suficient de specifică încât cineva nou în echipă să o poată executa fără să te întrebe mai întâi.

• Blocare de transfer la registrar pe fiecare domeniu deținut de companie, cu registry lock adăugat pe domeniul principal de brand și pe orice gestionează plăți sau autentificări.
• O cadență recurentă de scanare a înregistrărilor noi de domenii și a jurnalelor de transparență a certificatelor, pentru nume vizual apropiate de brandul tău, nu o verificare unică.
• Înregistrarea defensivă a etichetelor clonă cu cel mai mare risc și a domeniilor de nivel superior confuzabile pe care le poți justifica, prioritizate în funcție de cât de aproape se potrivesc cu domeniul tău principal.
• Un responsabil desemnat și un traseu de escaladare pentru raportarea unui domeniu clonă descoperit către registrarul său, plus îndrumări interne astfel încât personalul de suport să recunoască tiparul atunci când un client raportează unul. Lista de verificare a securității pentru alegerea unui furnizor de linkuri acoperă controalele conexe ale furnizorilor.

O rețetă de verificare pe care o poate urma oricine

Nu trebuie să înțelegi punycode ca să verifici un link în siguranță. Patru pași, făcuți în ordine, prind aproape tot pe ce se bazează un atac homograf.

1. Extinde mai întâi linkul, în loc să dai clic direct pe el. Cum vezi unde duce un URL scurt trece în revistă instrumentele pentru asta, iar propriul verificator de linkuri al Elido face același lucru fără să îți ceară să ai încredere în destinație mai întâi.
2. Citește domeniul înregistrabil - partea imediat dinaintea domeniului de nivel superior - nu ce apare înaintea lui. Aceea este partea pe care un atacator trebuie să o controleze în întregime.
3. Verifică dacă există un prefix xn--, fie în URL-ul extins brut, fie în bara de adrese a browserului. Dacă vezi unul acolo unde te așteptai la un nume de brand simplu, oprește-te și tratează-l ca pe un domeniu clonă până la proba contrarie.
4. Confirmă numele din certificatul site-ului de destinație. Un certificat reflectă ce a fost emis efectiv unui proprietar de domeniu, ceea ce este mult mai greu de falsificat convingător decât o etichetă randată.

Niciunul dintre acești pași nu durează mai mult de câteva secunde odată ce devin obiceiuri, și îi poți învăța pe toți patru unui coleg netehnic în timpul necesar pentru a citi această secțiune o singură dată.

Un atac homograf este o problemă de afișare deghizată în problemă de securitate. Punycode face exact ce a fost proiectat să facă; înșelăciunea are loc în golul dintre ce este de fapt un domeniu și ce îți arată în schimb o bucată de software. Browserele au închis cea mai mare parte a acelui gol pentru bara de adrese. Peste tot altundeva golul este încă deschis, motiv pentru care extinderea unui link și citirea domeniului înregistrabil rămâne obiceiul care funcționează indiferent de canalul care ți-a pus linkul în față.

Articole conexe de pe blog

• Sunt scurtătoarele de linkuri sigure? cum verifici un link scurt
• Sunt codurile QR sigure? quishing și cum rămâi protejat
• Lista de verificare a securității pentru scurtătoarele de linkuri
• Configurarea domeniilor personalizate pentru linkurile tale scurte
• Cum vezi unde duce un URL scurt înainte să dai clic