Subdomain takeover: saugumo spraga

Kai kurios saugumo problemos atrodo gana nekaltai, kol neįvyksta realus incidentas. Subdomain takeover – viena tokių spragų, kuri dažnai lieka nepastebėta, bet gali sukelti rimtų pasekmių. Įsivaizduokite situaciją: jūsų įmonės subdomeną, kuris anksčiau buvo naudojamas marketingo kampanijai, staiga perimą kažkas pašalinis ir pradeda platinti kenkėjišką kodą arba rinkti slaptažodžius. Skamba blogai? Na, taip ir yra.

Ši spraga nėra nauja – apie ją kalbama jau gerą dešimtmetį, bet vis dar matome atvejų, kai net stambios kompanijos tampa aukomis. Problema ta, kad subdomenų valdymas dažnai būna chaotiškas, ypač didesnėse organizacijose, kur skirtingi skyriai kuria savo infrastruktūrą nekoordinuotai.

Kaip iš tikrųjų veikia subdomain takeover

Pati sąvoka skamba gana technikiškai, bet principas iš tikrųjų paprastas. Subdomain takeover įvyksta, kai domenų vardų sistemos (DNS) įrašas nurodo į išorinį servisą, kuris nebėra aktyvus arba nebėra jūsų kontroliuojamas. Pavyzdžiui, jūsų įmonė sukūrė subdomeną blog.jusuimone.lt ir nukreipė jį į GitHub Pages puslapį. Vėliau tas GitHub Pages projektas buvo ištrintas, bet DNS įrašas liko. Dabar bet kas gali užregistruoti tą patį GitHub Pages pavadinimą ir perimti jūsų subdomeną.

Techniškai tai atrodo taip: DNS įraše yra CNAME įrašas, kuris nurodo į išorinį resursą, pavyzdžiui:

blog.jusuimone.lt CNAME jusuimone.github.io

Jei jusuimone.github.io nebėra užregistruotas arba nebeegzistuoja, bet CNAME įrašas vis dar aktyvus, atsiranda spraga. Puolėjas gali užregistruoti tą patį GitHub Pages vardą ir efektyviai kontroliuoti, kas rodoma jūsų subdomene.

Kodėl tai iš tikrųjų pavojinga

Kai kurie galėtų pamanyt: „Na ir kas, tegu kažkas perimą seną subdomeną, kurią seniai nenaudojame”. Problema ta, kad pasekmės gali būt daug rimtesnės nei atrodo iš pirmo žvilgsnio.

Pirma, slapukai (cookies). Daugelis svetainių naudoja slapukus, kurie galioja visam domenui, įskaitant subdomenus. Tai reiškia, kad puolėjas, kontroliuojantis subdomeną, gali gauti prieigą prie sesijos slapukų ir potencialiai perimti vartotojų sesijas. Jei jūsų pagrindinis domenas nustato slapuką su domain=.jusuimone.lt, tas slapukas bus prieinamas ir blog.jusuimone.lt.

Antra, pasitikėjimas. Vartotojai mato, kad URL prasideda jūsų įmonės domenu, ir natūraliai pasitiki turiniu. Puolėjas gali naudoti tai phishing atakoms, kenkėjiško kodo platinimui arba reputacijos žalojimui. Įsivaizduokite naujienų antraštę: „Žinoma įmonė X platina virusus per savo svetainę” – net jei tai tik subdomeną perimą puolėjas.

Trečia, SEO ir paieškos rezultatai. Jei subdomeną buvo indeksuotas Google, puolėjas gali išnaudoti jūsų domeno autoritetą savo tikslams – nuo spam nuorodų iki klaidinančio turinio.

Populiariausi taikiniai ir platformos

Ne visos platformos vienodai pažeidžiamos. Subdomain takeover dažniausiai pasitaiko su šiomis paslaugomis:

GitHub Pages – viena populiariausių. Jei ištrinote savo GitHub Pages projektą, bet DNS įrašas liko, bet kas gali užregistruoti tą patį vardą ir perimti subdomeną. GitHub bando kovoti su šia problema, bet ji vis dar aktuali.

AWS S3 buckets – jei subdomeną nukreiptas į S3 bucket’ą, kuris buvo ištrintas, puolėjas gali sukurti naują bucket’ą su tuo pačiu vardu. AWS tam tikrais atvejais tai apsunkina, bet ne visada.

Heroku – klasikinis pavyzdys. Jei jūsų aplikacija Heroku buvo ištrinta, bet DNS įrašas liko, puolėjas gali užregistruoti tą patį aplikacijos vardą.

Azure – panašiai kaip AWS, Microsoft Azure servisai taip pat gali būti pažeidžiami, ypač kai kalbame apie CloudApp.azure.com arba azurewebsites.net.

Fastly, Shopify, Tumblr – šios platformos taip pat buvo naudojamos subdomain takeover atakoms. Kiekviena turi savo specifiką, bet principas tas pats.

Kaip aptikti pažeidžiamus subdomenus

Gera žinia ta, kad subdomain takeover spragos gana lengvai aptinkamos, jei žinote, ko ieškoti. Yra keletas būdų, kaip tai padaryti.

Pirmas žingsnis – inventorizuoti visus subdomenus. Tai skamba akivaizdžiai, bet daugelis organizacijų neturi pilno sąrašo. Galite naudoti įrankius kaip Sublist3r, Amass arba subfinder, kurie automatiškai suranda subdomenus naudodami įvairius šaltinius – nuo DNS įrašų iki sertifikatų skaidrumo logų.

Antras žingsnis – patikrinti, ar subdomenai nurodo į aktyvius resursus. Čia praverčia įrankiai kaip SubOver arba subjack. Jie automatiškai tikrina, ar CNAME įrašai nurodo į neegzistuojančius resursus populiariose platformose. Pavyzdžiui, subjack gali patikrinti šimtus subdomenų per kelias minutes ir išskirti tuos, kurie potencialiai pažeidžiami.

Trečias būdas – rankinė analizė. Kartais automatiniai įrankiai praleidžia dalį atvejų. Jei matote DNS klaidas kaip „NXDOMAIN” arba HTTP klaidas kaip „404 – Not Found” su specifiniais pranešimais (pvz., „There isn’t a GitHub Pages site here”), tai raudonos vėliavėlės.

Praktinis patarimas: sukurkite reguliarų procesą subdomenų auditui. Tai neturėtų būti vienkartinė užduotis, o nuolatinė praktika. Bent kartą per ketvirtį peržiūrėkite savo DNS įrašus ir patikrinkite, ar visi subdomenai vis dar aktyvūs ir kontroliuojami.

Prevencijos strategijos ir geriausia praktika

Geriausia apsauga nuo subdomain takeover – neleisti jai įvykti. Skamba kaip kapitono akivaizda, bet yra konkrečių žingsnių, kuriuos galite imtis.

DNS įrašų valdymas – tai pagrindas. Kai ištrinate išorinį resursą (pvz., GitHub Pages projektą ar Heroku aplikaciją), iš karto ištrinkite ir atitinkamą DNS įrašą. Skamba paprasta, bet praktikoje dažnai užmirštama, ypač kai infrastruktūrą valdo skirtingi žmonės ar komandos.

Dokumentacija – turėkite aiškų subdomenų registrą. Kas sukūrė? Kokiam tikslui? Kas atsakingas? Į ką nurodo? Kai subdomenų yra dešimtys ar šimtai, be dokumentacijos greitai pasimeta.

Automatizuotas monitoringas – integruokite subdomain takeover tikrinimą į savo saugumo procesus. Galite naudoti įrankius kaip Nuclei su atitinkamais template’ais arba sukurti savo skriptus, kurie reguliariai tikrina subdomenų būseną.

CAA įrašai – nors tai tiesiogiai neapsaugo nuo subdomain takeover, CAA (Certification Authority Authorization) įrašai gali apriboti, kas gali išduoti SSL sertifikatus jūsų domenui. Tai apsunkina puolėjo galimybes sukurti patikimą atrodančią svetainę perimtame subdomene.

Wildcard DNS įrašų vengimas – jei naudojate wildcard įrašus (*.jusuimone.lt), būkite ypač atsargūs. Jie gali sukurti papildomų pažeidžiamumų, ypač jei nurodo į išorinius servisus.

Ką daryti, jei jūsų subdomeną jau perimtas

Jei atradate, kad jūsų subdomeną jau kontroliuoja kažkas kitas, reikia veikti greitai. Pirmas žingsnis – nedelsiant ištrinti arba pakeisti DNS įrašą. Tai sustabdys tolesnę žalą, nors puolėjas gali būti jau padaręs nemažai.

Antras žingsnis – įvertinti žalą. Patikrinkite, ar nebuvo surinkti vartotojų duomenys, ar nebuvo platinamas kenkėjiškas kodas. Jei subdomeną turėjo prieigą prie slapukų ar kitų jautrių duomenų, gali tekti informuoti vartotojus ir rekomenduoti pakeisti slaptažodžius.

Trečias žingsnis – pranešti platformai. Jei puolėjas naudoja GitHub, AWS ar kitą platformą, praneškite jiems apie piktnaudžiavimą. Dauguma platformų turi procesus tokiems atvejams spręsti.

Ketvirtas žingsnis – peržiūrėti procesus. Kaip tai įvyko? Kas nepavyko? Kaip užkirsti kelią ateityje? Naudokite incidentą kaip mokymosi galimybę ir patobulinkite savo saugumo praktikas.

Realūs atvejai ir pamokos iš jų

Subdomain takeover nėra tik teorinė grėsmė. Yra buvę atvejų, kai net stambios kompanijos tapo aukomis. Pavyzdžiui, 2019 metais buvo pranešta apie Uber subdomenų pažeidžiamumą, kai keli jų subdomenai buvo pažeidžiami subdomain takeover. Nors Uber greitai sureagavo, tai parodė, kad net technologijų gigantai ne visada turi tobulą kontrolę.

Kitas įdomus atvejis – Shopify. Dėl platformos specifikos, daugelis e-prekybos svetainių naudojo subdomenus, kurie nukreipė į Shopify. Kai kai kurie verslai persikėlė į kitas platformas, bet paliko DNS įrašus, atsirado galimybė perimti tuos subdomenus.

Pamoka iš šių atvejų paprasta: subdomenų valdymas turi būti sistemiškas ir nuolatinis procesas, ne vienkartinė užduotis. Infrastruktūra keičiasi, projektai ateina ir išeina, bet DNS įrašai dažnai lieka kaip pamiršti artefaktai.

Kai saugumas susiduria su realybe

Subdomain takeover yra viena iš tų saugumo spragų, kuri lengvai išvengiama, bet dažnai ignoruojama. Problema ne technologijose – įrankiai ir žinios yra prieinami. Problema organizaciniuose procesuose ir prioritetuose.

Praktiškai, jums reikia trijų dalykų: gero subdomenų inventoriaus, reguliaraus monitoringo ir aiškių procedūrų, kas daryti kuriant ar trinant subdomenus. Tai nėra raketų mokslas, bet reikalauja disciplinos ir dėmesio.

Jei dar neauditavote savo subdomenų, dabar geras laikas pradėti. Atsisiųskite vieną iš minėtų įrankių, paleiskite skenavimą ir pažiūrėkite, ką rasite. Gali būti, kad atradsite keletą senų, pamirštų subdomenų, kurie laukia, kol kas nors juos perimtų. Geriau, kad tas „kas nors” būtumėte jūs, o ne piktavalis.

Ir atminkite – saugumas nėra vienkartinis projektas, o nuolatinis procesas. Subdomenų valdymas turėtų būti natūrali jūsų infrastruktūros valdymo dalis, kaip ir serverių atnaujinimai ar atsarginių kopijų kūrimas. Kai tai tampa įpročiu, subdomain takeover tampa tiesiog dar viena spraga, apie kurią nereikia nerimauti.

Daugiau

QuestDB: laiko eilučių duomenų bazė