URL Ofuscatuak: Esteka Kaltegarriak Ezkutatzeko Arteaz
Celia Catalán
Sarrera
Mehatxuaren egungo panoraman, URL ofuskatuek baliabide errepikakorra dira kanpaina kaltegarrien barruan. Mehatxu aktoreek teknika hau ez dute helburu gisa erabiltzen, baizik eta ihes egiteko eta iraunkortasun mekanismo gisa, beren erasoen eraginkortasuna maximizatzeko.
Estekak ofuskatzeak segurtasun kontrol tradizionalak saihestea errazten du, hala nola posta iragazkiak, antimalware motorrak edo web gateway-ak, eta murrizten du analista edo azken erabiltzaile batek arriskua azkar identifikatzea. Honek URLak erasotzeko bektore malgu eta kudeatzea zaila bihurtzen ditu, eta erraz egokitu daitezke eszenatoki desberdinetara: spear phishing kanpaina zuzendutatik hasi eta malware banaketa ezkutura edo azpiegitura komprometitutako barruko mugimendu lateralera arte.
Erasotzaileek ofuskazioa nola erabiltzen duten ulertzea funtsezkoa da zibersegurtasunaren aldeko edozein erakunderentzat: detekzio goiztiarraren gaitasunak indartzen ditu, threat hunting arauak egokitzen eta analisi forentseko prozesuak hobetzen laguntzen du. Gainera, teknikak ikusgarri egiteak laguntzen du iruzur digitalaren bilakaeran eta gaur egun gehien erabiltzen diren saihesbide mekanismoetan joerak aurreikusten.
Ofuskazioaren teknika ohikoenak
Atal honetan URL ofuskazioaren teknika ohikoenetako batzuk aztertuko ditugu, segurtasun taldeentzat erronka jarraitua izan direnak urteetan. Itxuraz mekanismo sinpleak diruditen arren, asmoz aplikatuta tresna oso eraginkorrak bihurtzen dira erasotzaile maliziosoen eskuetan. Teknikek ez dute erabiltzaile amaiera engainatzea bakarrik bilatzen, baita kontrol automatikoak saihestu eta defentsa korporatiboen analisi eta detekzio lana zailtzea ere.
URL laburtzaileen erabilera
Esteka laburtzaileak asmo onarekin sortutako tresnak dira: helbide luze eta konplexuak kudeagarriago bihurtzea. bit.ly edo tinyurl bezalako zerbitzuak oso ezagunak bihurtu ziren esteka garbi eta erraz gogoratzeko aukera ematen dutelako. Arazoa da ezaugarri hori urteetan erasotzaileek baliatu dutela helmuga kaltegarriak itxura arruntekin ezkutatzeko.
Esteka bat laburtuta dagoenean, ia ezinezkoa da begiratu hutsez non amaituko den jakitea. Hori da erasotzaileek bilatzen dutena: erabiltzaileak susmorik gabe klik egitea. Hortik aurrera, aukerak zabala da: phishing orri ondo egina, malware deskarga edo birbideratze anitz bidezko saltoak segurtasun kontrolak saihesteko.
Zibersegurtasun taldeentzat erronka gehigarri bat da hau. Esteka laburtua ebaztea denbora eta tresnak eskatzen ditu, eta ez da beti erraza prozesua eskalatzeko automatizatzea.
Birbideratze anitzak
Begiratu hutsez alferrikakoak dirudite, baina taktikak helburu oso argi bat du: detekzioa eta analisia zailtzea. Salto bakoitza domeinu legezko batean egon daiteke, zerbitzu hodei zaindu gabeko batean edo orrialde efimeroetan, ordu batzuen buruan desagertzen direnak. Horrela, esteka mota bateko “matrioska” digital bihurtzen da: edukira iristeko geruza askotako estalkiak kendu behar dira.
Segurtasun taldeentzat arazoa argia da. Sandbox batek edo posta iragazle batek lehen saltoan detektatu eta blokeatu dezake, baina bigarren edo hirugarrenean huts egin dezake, eta horixe da payload-a edo phishing orria itxaroten duen lekua. Gainera, analisi forentsean, birbideratze kate osoa berreraikitzeak denbora hartzen du eta batzuetan bitarteko domeinuak ez daude erabilgarri, ikerketa zailtzen duelarik.
Horregatik, kontrol automatizatuetatik haratago, erakunde askok ebazpen dinamikoaren teknikak, mehatxu adimena eta DNS/HTTP trafikoaren monitorizazioa konbinatzen dituzte patroia hauek identifikatzeko. Birbideratze anitz bat detektatzeak ez du beti esan nahi kaltegarria denik, baina zalantzarik gabe alerta seinale bat da eta arreta berehala merezi du.
Azpidomeinuen erabilera
Azpidomeinuen gehiegikeriak beste ofuskatze teknika ohiko bat osatzen du, eta agian erabiltzaile distraitu bat engainatzeko eraginkorrenetako bat. Ideia sinplea da: domeinu legitimo bat URL luze baten barruan txertatzea, baina domeinu nagusiaren posizioan ez dagoena, ikuspegi hutsez konfiantzazkoa dirudien moduan.
Adibide klasiko bat honelakoa da:
login.banco.com.seguro-online[.]xyz
Lehen begiratuan, askok “login.banco.com” soilik irakurtzen dute eta bankuaren atariaren aurrean daudela ematen dute. Hala ere, benetako domeinua “seguro-online[.]xyz” da, eta aurreko guztia konfiantza sortzeko diseinatutako azpidomeinu bat baino ez da.
Erasotzaileek patroia ustiatzen dute erabiltzaile gehienak ez daudelako prestatuta URL bat ezkerretik eskuinera irakurtzeko, hau baita erro domeinua identifikatzeko modu zuzena. Segurtasun taldeentzat, engainu mota honek erronka suposatzen du, izan ere, egiazko azpiegitura legitimoekin (CDN-ak, hodeiko zerbitzuak edo SaaS plataformak) batera bizi daitezke, azpidomeinu luze eta nahasgarriekin modu guztiz baliagarrian.
Arrisku hau murrizteko erabiltzailearen hezkuntza, domeinu-patroien analisi automatikoa eta nabigazio-politika zorrotzak konbinatu behar dira. Gainera, enpresa-inguruneetan, komeni da domeinu kritikoen zerrenda zuriak aplikatzea eta masiboki sortutako azpidomeinu susmagarrien ikusgarritasuna indartzea.
Unicode karaktereak / IDN homografoak
Ikuspegi hutsez detektatzea zailak eta engainagarriak diren teknikaetako bat Unicode karaktereak erabiltzea da domeinuetan, IDN homografoen eraso bezala ere ezaguna (Internationalized Domain Names). Oinarria sinplea da: alfabeto desberdinetako letra batzuk (kirilikoa, grekoa, etab.) erabiltzea, ikusmenari dagokionez latineko alfabetoaren antzekoak direnak.
Adibidez, erasotzaile batek domeinu bat erregistratu dezake honela:
раypal.com
Lehen begiratuan dirudi paypal.com, baina hasierako “p” kirilikoan idatzita dago, latinean ez. Giza begiarentzat eta askotan oinarrizko kontrol automatikoentzat desberdintasuna ia ikusezina da.
Ofuskatze mota hau bereziki arriskutsua da ikusmen-konfiantza zuzenean eskatzen duelako. Erabiltzaileek uste dute leku legitimo batean daudela, beren kredentzialak sartzen dituzte eta ez dute engainuaz susmatzen ere egiten. Segurtasun taldeentzat, kasu hauek detektatzea iragazketa klasiko batetik haratago joatea eskatzen du: mekanismoak behar dira punycode subyacente (xn--...) eta antzeko ikusizko itxurak susmagarriak identifikatzeko gai izan daitezen.
Enpresa inguruneetan, homografoekin egindako erasoak honetarako erabil daitezke:
- Phishing Langileengan zuzendutako (spear phishing) erasoak.
- Brand abuse kanpainak, domeinu legitimo baten aldaera kaltegarriak erregistratuz.
- Datuen exfiltrazio ezkutua, C2 endpointak domeinu itxuraz legitimoetan kamuflatuz.
Mehatxu hau arintzeko konbinatutako ikuspegi bat behar da: domeinu antzekoen erregistroen jarraipen aktiboa (typosquatting), barne kontzientziazioa eta trafiko web eta posta elektronikoan patroien detekzioa ahalbidetzen duten motorren ezarpena.
URLen kodifikazioa
URLen kodifikazioa ofuskazio teknikarik zaharrenetakoa da, baina oraindik eraginkorra. Printzipioa sinplea da: benetako helburua ezkutatzea testu edo helbide ordezkarien bidez, nabigatzaileek interpretatzen dakitenak, baina begi gizatiar batentzat ez direnak.
Ohikoenak honako hauek dira:
IP helbideen kodifikazioa formatu alternatiboetan Notazio hamartar klasikoa erabiltzeko ordez (http://192.168.0.1), erasotzaileek IPa honela idatz dezakete:
- Hexazehar →http://0xC0.0xA8.0x00.0x01
- Okta →http://0300.0250.0000.0001
- Hamartar oso bakarra (DWORD) →http://3232235521
- Nahasketak →http://0xC0.0250.0x00.1
Aldaketa hauek guztiak helburu bera adierazten dute, baina esteka askoz gutxiago ezagutzeko modukoa bihurtzen dute.
Karaktere-kodifikazioa hexazeharrean edo UTF-8an URLko karaktere bakoitza bere ASCII edo Unicode balio gisa adierazi daiteke, adibidez:
http://%65%78%61%6D%70%6C%65.com → baliokidea da http://example.com
Honek azterketa azkarra zailtzen du eta nahas dezake URLa aztertu aurretik normalizatzen ez duten sistemak.
Konbinazio hibridoak URL berak hainbat metodo nahas ditzake (adibidez: domeinua hexazekalez + parametroak Base64an), irakurtzea eta eskuz aztertzea are zailago bihurtuz.
Teknika honen helburua argia da: helmuga benetakoa identifikatzea zailtzea eta detekzio mekanismoen aurrean denbora irabaztea. Segurtasun taldeentzat, honek URLak normalizatu eta automatikoki dekodetzea eskatzen du aztertu aurretik. Pauso hau baztertzeak adierazle garrantzitsuak kanpoan utz ditzake, batez ere phishing kanpainetan, web bidez banatutako malwarean edo C2 komunikazioetan.
Schema abusua
URLen ofuskazioan ohiko beste baliabide bat schema abusua da (URLaren hasierako zatia, protokoloa adierazten duena, hala nola http://,https://,ftp://, etab.) ikurrarekin konbinatuta @ Ikur honek baliozko helburu bat badu URLen sintaxian erabiltzailearen kredentzialak eta hosta bereiztea, praktikan ia inoiz ez da erabiltzen web nabigazio modernoan. Eta zehazki arrarotasun hori da bere jantzi bikaina bihurtzen duena.
Adibidea:
https://banco.com@malicioso.com/login
Ikuspegi arruntean, erabiltzaile askok irakurtzen dute banco.com eta uste dute esteka bankuaren atari legitimoari dagokiela. Hala ere, aurretik agertzen den guztia @ kredentzial gisa tratatzen da, eta nabigatzaileak konektatzen den benetako domeinua malicioso.com da.
Truku hau phishing kanpainetan erabili da urteetan zehar, kognizio patroia aprobetxatzen duelako: begi gizatiarrak URLaren hasierako zatian jartzen du arreta, eta ez benetan garrantzitsua den zatian (eskuineko erro domeinuan).
Segurtasun taldeentzat, ofuskazio mota honek erronka dakar, izan ere, ez da beti detektatzen azterketa gainazaleko baten bidez, eta erabiltzaile askok ez dute arriskua ezagutzeko prestakuntzarik. Izan ere, nabigatzaile moderno batzuek jada ohartarazpenak erakusten dituzte edo estekak blokeatzen dituzte @ susmagarri diren testuinguruetan, baina teknika horrek indarrean jarraitzen du, batez ere posta elektronikoetan, mezularitza aplikazioetan eta dokumentu ofuskatuekin.
Arintzeak URLak normalizatzea eskatzen du haiek aztertu aurretik, erabiltzaileak heztea eskuinetik ezkerrera irakurtzeko domeinuak eta erabilera patroien blokeoa @ esteketan, beharrezkoa ez denean modu legitimoan.
Ofuskazioaren adibide praktikoa (POC)
Ofuskazio teknikarik ohikoenak deskribatu ondoren, hurrengo pausoa praktikan jartzea da. Atal honetan ikusiko dugu nola konbinatu edo egokitu daitezkeen egoera konplexuago eta errealistagoak sortzeko. Helburua ez da erasotzaileen sormena erakustea soilik, baizik eta taktika hauek teknikarik gabeko erabiltzaileentzat zein profesional esperientziadunentzat nabaritu gabe pasatzen direla frogatzea.
Egia da, ondo aplikatuta, teknika hauek askotan zailak direla detektatzeko, baita segurtasun talde trebatuek ere, eta horrek erakusten du euren egokitasuna eta arriskua enpresa inguruneetan.
POC honen helburu gisa, postetako gunea erreferentziatzat hartuko dugu, www.flu-project.com, eta kasu hipotetiko gisa erabiliko dugu. POC honetan ez dugu dominio erreala erregistratuko, baina hala balitz bezala tratatuko dugu. Horretarako, postean aipatutako tekniketako bat erabiliz dominio bat sortzea simulatuko genuke: IDN homografoak erabiliz bisualki antzeko dominio bat sortzea.
Nabigatzaile moderno gehienek jatorriz Punycode deszifratzeko gaitasuna dutela azpimarratu behar da, eta horrek teknika mota honen eraginkortasuna mugatzen du. Ondorioz, erasotzaileek metodo alternatiboak edo konbinazio sofistikatuagoak erabili behar dituzte ofuskazio maila bera lortzeko.
El dominio n marra bat izan dezake ahal izango lirateke karaktereak aprobetxatuz, hala nola Figure Dash ordezkatzeko:
Jatorrizkoa: www.flu-project.com
Dominio maltzurra poc errealean erabiliko dugu (evil.com): www.flu‒project.com
Bigarren pausoa bezala, da erabiliko du URL laburtzaile bat erabiltzea esteka laburrago bat sortzeko, eta horrek zailtzen du azken domeinua begi-bistaz identifikatzea:
Kasuan, sortutako URL-a hau izan zen:
https://rb.gy/4hz4za
Nahaspenerako modu eraginkorrago bat schema abusatzea litzateke, adibidez:
https://www.flu-project.com@rb.gy/4hz4z
hobekuntzarako nahaspena ulertu behar da aurretik @ URL batean ez dira espazioak onartzen, @, /, ?, #, : ezta kontrol karaktererik ere, eta horrek mugatzen digu aukera bat egitea nahaspena "aurreratuago" n teoria.
Hori hobe parametroak ikustea litzateke GET web-aren,
kasuan ez dago asko, blog sinple bat izanik, beraz da inventarioa bat bidea edo login esteka, adibidez:
https://www.flu-project.com/signin/id?as=S33687126557826461780271839
&authuser=0
&client_id=2389046141273-dfgshadfh347828679adap.apps.flu-project.com
&flowName=GeneralOAuthFlow
&response_type=code
&scope=email%20profile%20openid
&state=Af3fG5H7Jk9L1Mn2Op3Q
&nonce=Zx1Cv2Bn3Mq4Lp5R
&redirect_uri=
www.flu-project.com
&session_state=a
idus42
3def456ghi789jkl0
&prompt=select_account
&hd=flu-project.com
&login_hint=user%40flu-project.com
&include_granted_scopes=true
&code_challenge=
Z2!FpJ7nK0qR4xXvT8cB1sM6y-_LdE3wF9oP5hGvQ(
&code_challenge_method=S256
&utm_source=newsletter
&utm_medium=email
&csrf_token=098f6bcd4621d373cade4e832627b4f6
GET parametro asko daudenez, daiteke payload-a errazago paketatzeko aukera ematen duten batzuk. Hala ere, aurretik aipatu bezala, / eta ? bezalako karaktereek schema abusua hautsi dezakete @ bidez. Horregatik, zentzuzkoa da jatorrizko karaktereetara ahalik eta gehien antzekoak direnak erabiltzea, URLaren egitura oztopatzen dutenak saihestuz.
Daude orrialdeak non aurki dezakegun antzeko karaktereak:
? --> https://symbl.cc/en/003F/
/ -->https://symbl.cc/en/002F/
Karaktere hauek interesgarriak dira, izan ere, itxura aldetik jatorrizkoak dirudite, baina protokoloa ez dute hautsi egingo, ez direlako berdinak. Hau kontuan hartuta, erabaki dezakegu zein GET parametro ofuskatuko dugun lURL kaltegarri batean. Kasu honetan, erabiliko da parametroa code_challenge.
Ondoren, da aplikatuko da payload-ari URL kodeketa aplikatuz, modu horretan ikusgarritasuna murrizteko. Gainera, da kodeztatuko du URL kaltegarria, kodeztatu gabe utziz @ eta # amaieran, payload-aren ondorengo parametro guztiak baztertzeko, honela geratuko litzateke:
- URL kaltegarria: rb.gy/4hz4za
- GET parametroarentzat prestaturiko URL kaltegarria: @%72%62.%67%79/4hz4za#
- Parametro amaiera:&code_challenge=Z2%21FpJ7nK0qR4xXvT8@%72%62.%67%79/4hz4za#cB1sM6y%2D%5FLdE3wF9oP5hGvQ%28
Ikusten denez, begi hutsez detektatzea nahiko zaila da. Orain, aipatutako karaktereak haien baliokide seguruengatik ordezkatu besterik ez dago, protokoloa ez hausteko.
Karakterea ? ordezka daiteke ‽. Karaktereari dagokionez /, dilema bat sortzen da: iturri edo sistema bakoitzak slash mota hau modu desberdinean interpretatzen du, beraz, hainbat aldaera probatu behar dira kasu bakoitzean zein den onena zehazteko. Plataforma bakoitzak karaktere hauek modu ezberdinean kudeatzen ditu, beraz, hautaketa ingurune zehatzera egokitu behar da.
Kasuan honetan sdaiteke Chrome-n nola ikusiko liratekeen behatzea, antzekotasun handiena zein den zehazteko:
Kasuan honetan, erabakitzen da azken aukera erabili, “Big Solidus” (https://symbl.cc/en/29F8/). Hau guztia kontuan hartuta, da pdaiteke URL maliziotsu azkena sortzeko, honela geratuko litzateke:
- URL Maliziotsu Azkena: https://www.flu-project.com⧸signin⧸id‽as=S33687126557826461780271839&authuser=0&client_id=2389046141273-dfgshadfh347828679adap.apps.flu-project.com&flowName=GeneralOAuthFlow&response_type=code&scope=email%20profile%20openid&state=Af3fG5H7Jk9L1Mn2Op3Q&nonce=Zx1Cv2Bn3Mq4Lp5R&redirect_uri=www.flu-project.com&session_state=abc123def456ghi789jkl0&prompt=select_account&hd=flu-project.com&login_hint=user%40flu-project.com&include_granted_scopes=true&code_challenge=Z2%21FpJ7nK0qR4xXvT8@%72%62.%67%79/4hz4za#cB1sM6y%2D%5FLdE3wF9oP5hGvQ%28&tracking_id=UA-12345678-9&utm_source=newsletter&utm_medium=email&csrf_token=098f6bcd4621d373cade4e832627b4f6
Nola da aipatu zuen lehenago, slash-en itxura aldatu daiteke URL non erakusten den arabera. Chrome-n ondo ikusten bada ere, beste plataformek okertu dezakete, beraz, aldaera desberdinak probatu behar dira ikuspegi onena ziurtatzeko.
Geldituz hala nabigatzailean:
Edge-n bideo demostrazioa:
Ondorioa:
Laburbilduz, post honetan erakutsi da nola erasotzaileek URLen ofuskazio teknika anitz erabil ditzaketen lotura baten benetako helmuga ezkutatzeko eta detekzioa zailtzeko. Laburtzaile eta birbideratze anitzak erabiltzetik hasi eta azpidomeinuak manipulatzera, IDN homografoak, karaktere aurreratuen kodifikazioa eta URL eskema abusua, metodo bakoitzak abantaila eta erronka propioak ditu portaera kaltegarriak identifikatu nahi dutenentzat.
Barne dagoen POCak modu praktikoan erakusten du nola teknika hauek konbinatzeak lotura itxuraz kaltegabeak sortu ditzakeen, eta baita erabiltzaile eta zibersegurtasun profesionalak nahastu ere. Honek garrantzizko kontu bat azpimarratzen du: segurtasuna ez da erabiltzailearen ezagutzaren menpe bakarrik, baizik eta monitoreaketa tresnak, trafikoaren analisia eta URLen balidazio politikak indartzea beharrezkoa da edozein erakundetan.
Testuinguru zabalago batean, teknika hauek ulertzea eta dokumentatzea segurtasun taldeek erasotzaile sofistikatuen aurrean aurrea hartzea eta defentsa eraginkorragoak diseinatzea ahalbidetzen du, arriskuak minimizatuz eta enpresaren zibersegurtasun posturaren indarra handituz. Hezkuntza, esperimentazio kontrolatua eta metodologi hauek dokumentatzea funtsezkoak dira erasotzaileen aurretik egoteko.
Félix Sánchez, Zerolynx enpresako erasotzaile zibersegurtasun analista Cybertix-en.
