Subdomain takeover: cum îl detectați și cum îl preveniți

Cum se ajunge la o preluare

Echipele îndreaptă constant subdomenii către servicii găzduite: docs.example.com către un furnizor de site-uri statice, shop.example.com către o platformă de comerț electronic, assets.example.com către un bucket de stocare. Înregistrarea DNS este de obicei un CNAME către un nume atribuit de furnizor, de exemplu example-docs.hosting.example.net. Când serviciul este anulat, resursa se șterge, însă CNAME-ul rămâne de cele mai multe ori în zonă. Cu timpul se uită cine a adăugat înregistrarea și pentru ce proiect, iar nimeni nu se mai simte responsabil să o curețe.

Înregistrarea rămasă astfel se numește dangling DNS, adică o înregistrare DNS orfană. Dacă furnizorul permite oricărui client să creeze o resursă cu același nume, cine revendică primul acel nume decide ce servește docs.example.com. În bara de adrese a browserului apare în continuare domeniul dumneavoastră, iar mulți furnizori emit chiar și un certificat TLS valid pentru acel nume. Pentru vizitator pagina arată, inclusiv prin lacătul afișat, ca și cum v-ar aparține.

Tipuri de înregistrări care pot rămâne orfane

Delegările NS sunt cazul cel mai grav din această listă. Controlul zonei delegate înseamnă controlul fiecărei înregistrări de sub acel nume, inclusiv MX, TXT și înregistrările de verificare, nu doar al unei singure pagini web. În schimb, delegările NS sunt mai rare și mai ușor de auditat, pentru că în majoritatea zonelor delegările către servere de nume externe nu sunt ceva obișnuit. De aceea, parcurgerea una câte una a tuturor înregistrărilor NS dintr-un export de zonă vă ia de obicei doar câteva minute.

De ce contează

Conținutul servit pe un subdomeniu moștenește încrederea care aparține organizației dumneavoastră. Utilizatorii văd login.example.com și presupun că este al dumneavoastră; filtrele de securitate și listele de permisiuni care au încredere în *.example.com îl lasă să treacă fără nicio verificare. Amploarea pagubei depinde de ce altceva mai are încredere în numele domeniului dumneavoastră. De aceea evaluarea impactului trebuie să pornească nu de la pagina preluată, ci de la lista sistemelor care au încredere în domeniu.

• Phishing cu un nume de domeniu real și un certificat valid.
• Furt de cookie-uri atunci când cookie-urile de sesiune sunt setate cu Domain=example.com, ceea ce le trimite către fiecare subdomeniu.
• Ocolirea CSP și CORS atunci când politicile permit https://*.example.com.
• Abuz de OAuth și de redirecționări atunci când adresele de redirecționare permise includ subdomenii wildcard.
• Abuz de e-mail prin înregistrări MX sau NS orfane, inclusiv primirea mesajelor de resetare a parolei pentru adresele de pe acel nume.
• Pierderea reputației atunci când de pe domeniul dumneavoastră se servesc malware sau spam și numele ajunge pe liste negre.

Cum găsiți înregistrările orfane din zonele dumneavoastră

Porniți de la propriile date autoritative: exporturile de zonă de la fiecare furnizor de DNS pe care îl folosiți, inclusiv zonele administrate de alte echipe și de agenții. Scanarea doar a numelor pe care vi le amintiți ratează exact înregistrările care duc la preluări. Apoi verificați una câte una fiecare înregistrare a cărei țintă se află în afara controlului dumneavoastră.

1. Exportați toate zonele și listați fiecare înregistrare CNAME, NS, MX și A/AAAA.
2. Pentru înregistrările CNAME, rezolvați ținta. Un NXDOMAIN pentru țintă sau o țintă aflată sub un domeniu neînregistrat este un semnal puternic.
3. Pentru ținte aflate la furnizori de găzduire, cereți subdomeniul peste HTTPS și HTTP și căutați pagina "not found" sau "no such site" a furnizorului.
4. Pentru delegările NS, interogați direct serverele de nume delegate pentru înregistrarea SOA a subdomeniului; un răspuns REFUSED sau SERVFAIL sugerează că zona găzduită a dispărut.
5. Pentru ținte MX și CNAME aflate sub alte domenii, verificați cu interogarea WHOIS dacă acele domenii mai sunt înregistrate.
6. Pentru înregistrările A care indică intervale din cloud, confirmați că adresa IP este în continuare alocată contului dumneavoastră.

# where does it point?
dig +short CNAME docs.example.com
example-docs.hosting.example.net.

# does the target still exist?
dig +short example-docs.hosting.example.net A
dig example-docs.hosting.example.net A | grep -E 'status: (NXDOMAIN|NOERROR)'

# what does the subdomain serve?
curl -sS -o /dev/null -w '%{http_code}\n' https://docs.example.com/

Instrumentele Interogare DNS și Interogare DNS arată înregistrarea CNAME și rezolvarea ei din afara rețelei dumneavoastră, iar Verificatorul de antete HTTP arată răspunsul și antetele de server ale subdomeniului. Proiectul "can-i-take-over-xyz", întreținut de comunitate pe GitHub, documentează ce furnizori permit revendicarea numelor de resurse șterse și cum arată paginile lor de eroare. Lista aceasta este un bun punct de plecare atunci când decideți dacă o înregistrare găsită este într-adevăr riscantă.

Dacă găsiți una

Primul pas este să ștergeți înregistrarea orfană sau să o îndreptați către ceva ce controlați. Ștergerea înregistrării încheie imediat orice preluare, de îndată ce expiră cache-urile, indiferent dacă cineva a revendicat deja resursa. Nu încercați să revendicați resursa la furnizor ca test; reparați în schimb propriul DNS.

1. Ștergeți sau corectați înregistrarea DNS.
2. Dacă subdomeniul a servit conținutul altcuiva, consemnați ce a servit și când, pentru procesul dumneavoastră de răspuns la incidente.
3. Revocați certificatele emise pentru subdomeniu, dacă le puteți identifica, de exemplu prin jurnalele de transparență a certificatelor.
4. Invalidați sesiunile deschise dacă cookie-urile au fost setate pentru domeniul părinte.
5. Revizuiți listele de permisiuni, setările CSP și cele OAuth care aveau încredere în subdomeniu.
6. Aflați cum a rămas în urmă înregistrarea și reparați procesul care a dus la asta.

Anunțați utilizatorii dacă subdomeniul a fost folosit pentru phishing sau a servit pagini de autentificare. Un anunț scurt și factual, cu datele calendaristice și cu ce au de făcut, de exemplu resetarea parolelor introduse acolo, limitează paguba mult mai bine decât tăcerea.

Jurnalele de transparență a certificatelor sunt utile și pentru investigație: fiecare certificat de încredere publică ajunge în ele, așa că un certificat emis altcuiva pentru subdomeniul dumneavoastră devine vizibil acolo. Monitorizarea jurnalelor CT pentru domeniul dumneavoastră oferă și o avertizare timpurie pentru preluările pe care nu le-ați descoperit încă. Monitorizarea se poate construi cu servicii gratuite și face vizibilă în câteva zile o exploatare care altfel ar rămâne tăcută săptămâni întregi.

Cum preveniți preluările

Ștergeți întâi DNS-ul, apoi resursa

Când dezafectați un serviciu, ștergeți înregistrarea DNS înaintea resursei cloud sau SaaS și așteptați expirarea TTL-ului. Inversarea ordinii creează o fereastră, uneori permanentă, în care înregistrarea indică un nume liber. Treceți această ordine în runbook-uri și în procesele de infrastructură ca și cod, ca să nu depindă de memoria nimănui.

Administrați DNS-ul ca și cod

Când înregistrările DNS stau în același repository cu infrastructura pe care o indică, ștergerea unei resurse și a înregistrării ei se face într-o singură modificare. Procesul de revizuire face vizibil și momentul în care cineva adaugă un CNAME către un serviciu extern, iar înregistrarea primește de la bun început un responsabil.

Folosiți verificarea de domeniu a furnizorului

Multe platforme vă cer să dovediți printr-o înregistrare TXT că dețineți un domeniu personalizat înainte de a începe să îl servească. Acolo unde un furnizor susține acest lucru, un client nou nu vă poate atașa subdomeniul la resursa lui fără să controleze și DNS-ul dumneavoastră. Preferați furnizorii care impun această verificare.

Țineți un inventar și scanați continuu

• Notați un responsabil și un scop pentru fiecare înregistrare care indică în afară.
• Scanați toate zonele, la intervale regulate, pentru semnalele din tabelul de mai sus.
• Includeți și verificări pentru domenii expirate la țintele CNAME, MX și NS.
• Urmăriți jurnalele de transparență a certificatelor pentru certificate neașteptate emise pe numele dumneavoastră.
• Evitați înregistrările DNS wildcard care indică platforme de găzduire partajate.

Migrările de domeniu și schimbările de furnizor sunt momentele în care apar cel mai des înregistrări orfane. Lista de verificare pentru migrarea domeniului include și pasul de curățare, iar ghidul CSP explică de ce listele de permisiuni cu subdomenii wildcard merită o a doua privire. În ambele situații, legați curățarea de o singură persoană; un pas care nu se află pe lista cuiva care cunoaște ordinea corectă este, în practică, un pas nefăcut.

Automatizarea scanării

Un script mic, rulat săptămânal peste exporturile dumneavoastră de zonă, prinde majoritatea înregistrărilor CNAME orfane. Scriptul rezolvă fiecare țintă și le marchează pe cele care nu mai există. Nu trimite în mod deliberat nicio cerere de revendicare și nu sondează sistemele altora dincolo de interogările DNS obișnuite. Păstrarea lui în controlul versiunilor și trimiterea rezultatului pe un canal al echipei împiedică și uitarea verificării odată cu trecerea timpului.

import dns.resolver

records = [
    ("docs.example.com", "example-docs.hosting.example.net"),
    ("status.example.com", "example.status.example.org"),
]

resolver = dns.resolver.Resolver()
resolver.lifetime = 5
for name, target in records:
    try:
        resolver.resolve(target, "A")
        state = "ok"
    except dns.resolver.NXDOMAIN:
        state = "DANGLING: target does not exist"
    except dns.resolver.NoAnswer:
        state = "check: target has no A record"
    except dns.exception.DNSException as error:
        state = f"check: {error.__class__.__name__}"
    print(f"{name:<28} -> {target:<40} {state}")

O țintă care se rezolvă nu este automat sigură, pentru că multe platforme răspund pentru fiecare nume de sub domeniul lor și afișează o pagină de eroare pentru cele nerevendicate. Extindeți scanarea cu o cerere HTTP către fiecare subdomeniu și cu o listă a textelor din paginile de eroare ale furnizorilor pe care îi folosiți. Tratați fiecare rezultat ca pe un tichet pentru responsabilul înregistrării. Astfel scanarea adună în același raport atât țintele cu adevărat șterse, cât și numele care doar par nerevendicate.

Medii de previzualizare și înregistrări wildcard

Lanțurile moderne de livrare creează medii de scurtă durată, de exemplu un site de previzualizare pentru fiecare pull request, la pr-123.preview.example.com. Când lanțul creează automat înregistrări DNS, trebuie să le și șteargă la distrugerea mediului, inclusiv atunci când o sarcină eșuează la jumătate. Altfel înregistrările se acumulează mai repede decât poate ține pasul orice revizuire manuală. De aceea pașii care creează mediul și cei care îl distrug trebuie să stea în aceeași automatizare și sub același responsabil.

Înregistrările wildcard precum *.preview.example.com, care indică o platformă partajată, elimină nevoia de înregistrări separate pentru fiecare mediu, dar aduc propriul risc: fiecare nume de sub wildcard indică platforma, indiferent dacă ați creat sau nu o resursă pentru el. Folosiți wildcard-uri doar pe platforme care impun verificarea proprietății domeniului pentru host-urile personalizate și țineți-le pe un subdomeniu dedicat, nu pe domeniul principal. Un subdomeniu separat trasează din start și limita impactului, dacă apare o problemă.

Cine răspunde de problemă

Preluările stau în golul dintre echipe: DNS-ul este administrat de obicei de infrastructură sau de IT, în timp ce serviciul anulat aparținea marketingului, documentației sau unei echipe de produs. Nimeni nu se simte responsabil pentru o înregistrare pe care nu a creat-o el. Atribuirea unui responsabil pentru fiecare înregistrare externă și includerea curățării DNS în încheierea oricărui contract cu un furnizor închid acest gol.

Un registru ușor al înregistrărilor externe funcționează bine în practică: numele înregistrării, ținta, serviciul, echipa responsabilă și contractul sau tichetul care a dus la crearea ei. Când un contract se încheie, departamentul de achiziții sau responsabilul serviciului declanșează ștergerea înregistrărilor din listă. Registrul răspunde și la prima întrebare din orice incident, adică cine răspunde de acest nume.

Echipele de securitate pot ajuta prin scanări regulate și tratând înregistrările orfane ca pe vulnerabilități, cu o severitate și un termen. Programele de bug bounty raportează în fiecare an numeroase preluări, ceea ce arată cât de răspândită este problema și cât de ieftină este prevenirea față de gestionarea unui incident de phishing pe propriul domeniu. Odată ce faceți această comparație, devine mai ușor să justificați în fața conducerii timpul alocat scanărilor regulate.

Întrebări frecvente

Surse

• Ghidul OWASP de testare a securității web, WSTG-CONF-10: testarea preluării de subdomenii
• Microsoft Learn: preveniți înregistrările DNS orfane și evitați preluarea de subdomenii
• RFC 6265: mecanismul de gestionare a stării în HTTP (atributul Domain al cookie-urilor)
• RFC 6962: transparența certificatelor
• can-i-take-over-xyz (listă comunitară a comportamentului furnizorilor)