
Shai-Hulud Infostealer Skanon 469 Vende Kredencialesh
GitGuardian zbuloi se një variant i infostealer-it Shai-Hulud tani kontrollon 469 vende kredencialesh, nga 189 më parë, duke treguar se si sulmuesit synojnë aksesin e ripërdorshëm.
Një variant i fundit i krimbit infostealer Shai-Hulud ka zgjeruar numrin e vendeve ku kërkon kredenciale nga 189 në 469, sipas një kërkimi të publikuar nga GitGuardian në fillim të gushtit. Lista e re e synimeve mbulon stacionet e punës të zhvilluesve, sistemet e integrimit të vazhdueshëm dhe dorëzimit të vazhdueshëm (CI/CD), konfigurimet cloud, madje edhe skedarët e konfigurimit të përdorur nga mjetet e zhvillimit të inteligjencës artificiale. Një infostealer është malware i krijuar për të mbledhur fjalëkalime, tokenë aksesi dhe të dhëna të tjera hyrjeje nga një makinë e infektuar, dhe kredencialet janë fjalëkalimet ose tokenët që programet dhe njerëzit përdorin për të provuar identitetin e tyre. Ndryshimi ka rëndësi sepse sulmuesit nuk po përpiqen më të thyejnë barrierat e besimit. Ata po mbledhin kredencialet ekzistuese që tashmë i bëjnë sistemet e besuara softuerike të funksionojnë.
Zinxhirët e furnizimit të softuerit kanë varej gjithmonë nga besimi. Zhvilluesit u besojnë regjistrave të paketave si npm ose Docker Hub. Organizatat u besojnë mirëmbajtësve të projekteve. Sistemet CI/CD u besojnë kredencialeve dhe identiteteve që u jepen, dhe aplikacionet u besojnë varësive që shkarkojnë gjatë një ndërtimi. Sulmuesit e kuptuan se nuk kanë nevojë të thyejnë asnjë nga ato besime. Ata vetëm duhet të gjejnë ku tashmë ndodhen kredencialet dhe privilegjet e përhershme. Kjo është arsyeja pse mbledhja e kredencialeve është bërë elementi kryesor i nevojshëm për suksesin e krimbave infostealer. Shai-Hulud i përket një klase në rritje të sulmeve të zinxhirit të furnizimit që kërkojnë në një mjedis tashmë të komprometuar për çdo kredencial që mund të ndihmojë sulmin të vazhdojë.
Rruga nga një kredencial i vjedhur tek tjetri është e drejtpërdrejtë. Një token i gjetur në një stacion pune zhvilluesi mund të hapë akses në kodin burimor, dhe ai kod burimor mund të përmbajë kredenciale cloud, të cilat më pas mund të japin akses në infrastrukturë. Një token aksesi GitHub, i cili është një varg teksti që i lejon një programi ose personi të hyjë në një llogari GitHub, mund të lejojë akses shkrimi në depo shtesë, ndërsa një kredencial publikimi paketash mund t'i lejojë një sulmuesi të publikojë softuer përmes një kanali që zhvilluesit tashmë e besojnë. Kredencialet bëhen indi lidhës midis një mjedisi të komprometuar dhe tjetrit. Makinat moderne të zhvilluesve përmbajnë shumë më tepër material autentikimi sesa vetë depoja burimore. Kredencialet shfaqen në vende të pritshme si skedarët .env, historia e shell-it dhe konfigurimi i menaxherit të paketave, por ato gjithashtu fshihen në cache-t e ndërfaqes së linjës së komandës, skedarët e konfigurimit CI/CD, cilësimet e mjedisit të zhvillimit të integruar dhe gjithnjë e më shumë në konfigurimin e përdorur nga asistentët e kodimit me AI. Sulmuesi nuk e di gjithmonë se cili kredencial ka më shumë rëndësi para se të fillojë mbledhja, kështu që mbledh atë që është në dispozicion dhe më vonë kupton se çfarë hap secili prej tyre.
Mbrojtësit duhet ta trajtojnë problemin në drejtim të kundërt, sipas analizës së GitGuardian. Ekipet e sigurisë duhet të identifikojnë se cilat kredenciale kanë më shumë rëndësi dhe të adresojnë ekspozimin e tyre përpara se një sulmues t'i përdorë ato. Kredencialet e publikimit të paketave meritojnë vëmendje të veçantë sepse e kthejnë vjedhjen e kredencialeve në shpërndarje softueri. Tokenët që zhvilluesit përdorin për të publikuar paketa mbartin autoritet mbi një paketë të besuar që zhvilluesit, sistemet e ndërtimit dhe organizatat e tjera do ta konsumojnë automatikisht. Ky besim është ajo që sulmuesit abuzojnë. Organizatat duhet të zvogëlojnë numrin e kredencialeve të përhershme të publikimit në dispozicion për t'u vjedhur dhe të kalojnë drejt autentikimit afatshkurtër dhe të verifikuar përmes OpenID Connect (OIDC), një standard që i lejon një shërbimi të verifikojë identitetin pa dorëzuar një fjalëkalim afatgjatë, ose mekanizma të ngjashëm me qëllim të kufizuar. Docker dhe GitHub Actions kanë shtyrë kohët e fundit ekosistemin në këtë drejtim me autentikim më të fortë dhe përdorim më të madh të publikimit të besuar. Çdo kredencial publikimi afatgjatë që mbetet duhet të trajtohet si infrastrukturë shumë e ndjeshme.
Kredencialet gjithashtu lidhin sisteme që ekipet e sigurisë shpesh i menaxhojnë veçmas. Ekipet e sigurisë tradicionalisht mendojnë në terma të sigurisë së kontrollit të burimit, sigurisë CI/CD, sigurisë cloud, sigurisë së pajisjeve fundore dhe sigurisë së aplikacioneve. Por një zhvillues i vetëm mund të autentikohet në GitHub, npm, AWS, Kubernetes (një sistem që ekzekuton aplikacione të kontejnerizuara në shumë makina), API të brendshme dhe infrastrukturë ndërtimi në një ditë normale, dhe tubacionet CI/CD shpesh mbartin një grup po aq të larmishëm kredencialesh. Një kredencial i lënë në një mjedis zhvilluesi mund të përfaqësojë autoritet diku tjetër krejtësisht. Skedari mund të jetë në një laptop ndërsa kredenciali kontrollon një burim cloud ose jep të drejta publikimi paketash. Vendi ku zbulohet një sekret tregon vetëm një pjesë të historisë. Organizatat që synojnë pjekurinë e menaxhimit të sekreteve gjithashtu duhet të dinë nëse kredenciali është i vlefshëm, cilit identitet i përket, cili sistem e pranon atë, çfarë privilegjesh mbart, cilin mjedis arrin dhe kush e zotëron zgjidhjen e tij. Kjo e kthen zbulimin e sekreteve në menaxhim të rrezikut të kredencialeve.
Jo çdo sekret i ekspozuar krijon të njëjtin rrezik. Një listë me 100,000 zbulime sekretesh nuk përfaqëson 100,000 incidente po aq urgjente. Disa kredenciale janë tashmë të pavlefshme, të tjera arrijnë në mjedise zhvillimi të disponueshme, dhe një numër më i vogël siguron akses në bazat e të dhënave të prodhimit, infrastrukturën cloud, sistemet e vendosjes ose publikimin e paketave. Trajtimi i këtyre zbulimeve në mënyrë identike krijon radhë në vend që të zvogëlojë rrezikun. Prioriteti i parë duhet të jetë heqja e çelësave të publikimit të paketave nga teksti i qartë. Zhvilluesit dhe automatizimi i tubacioneve shpesh shkruajnë çelësa autentikimi në skedarë lokalë konfigurimi si pjesë e rrjedhave normale të punës, por një sekret nuk duhet të jetë i angazhuar në Git për të qenë i disponueshëm për malware që ekzekutohet në makinën e zhvilluesit. Kjo është një arsye pse sulmet e fundit të zinxhirit të furnizimit synojnë gjithnjë e më shumë vetë mjedisin e punës së zhvilluesit. Kredenciali më i vështirë i publikimit për një sulmues për të vjedhur është ai që nuk ekziston. Nëse duhet të ekzistojë, sa më e shkurtër të jetë dritarja e aksesit që mund të jepet, aq më mirë. Qëllimi është të eliminohet autoriteti i ripërdorshëm i publikimit në tekst të qartë dhe të kalohet publikimi i paketave drejt mekanizmave afatshkurtër të mbështetur nga identiteti, aty ku mbështetet. Publikimi i besuar i bazuar në OIDC është një shembull. Shumica e platformave cloud po lëvizin drejt shërbimeve federative të tokenëve të sigurisë si AWS STS, të cilat lejojnë verifikimin e ngarkesës së punës nëpër platforma ku shtyhen artefaktet.
Pas kredencialeve të publikimit, organizatat duhet të fokusohen në kredencialet që sigurojnë akses në sistemet kritike të prodhimit. Një kredencial i ekspozuar i lidhur me një mjedis zhvillimi të izoluar mund të krijojë dëm të kufizuar, ndërsa një kredencial i vlefshëm me akses shkrimi në infrastrukturën e prodhimit është një incident tjetër krejtësisht. Një listë e shkurtër e dobishme përfshin llogaritë cloud të prodhimit, bazat e të dhënave që përmbajnë informacion klientësh, infrastrukturën e nënshkrimit, grupet Kubernetes, mjetet e vendosjes dhe ndërfaqet administrative. Pyetja kryesore është se çfarë ndodh nëse një sulmues bën diçka keqdashëse me aksesin e vjedhur. Vlefshmëria është një filtër i dobishëm, dhe përcaktimi i rrezes së vërtetë të shpërthimit ndihmon në prioritizimin e sistemeve për t'u adresuar për të eliminuar sekretet afatgjata ose të paktën për t'i rrotulluar ato. Kredencialet e përbashkëta krijojnë shtigje të fshehura midis mjediseve. Një kredencial i zbuluar në staging mund të autentikohet ende kundër prodhimit. Një token i kopjuar në mjedisin lokal të një zhvilluesi mund të ruajë privilegje të destinuara për automatizim, dhe i njëjti kredencial mund të shfaqet në sisteme të shumta shumë kohë pasi qëllimi i tij origjinal është harruar. Gjetja e sekretit është vetëm hapi i parë; alarmet janë vetëm zhurmë nëse nuk e hartojnë atë përsëri te identiteti, privilegjet, burimet, mjediset dhe pronarët pas tij.
Pasi të trajtohen kredencialet e publikimit të paketave dhe aksesi i dukshëm i prodhimit, organizatat mund të punojnë sistematikisht përmes inventarit të mbetur të kredencialeve. Qëllimi nuk është të rrotullohet gjithçka rastësisht, por të ndërtohet një plan veprimi që vazhdimisht heq kredencialet më të dobishme nga rruga e sulmuesit. Vlefshmëria është një vend i mirë për të filluar. Një kredencial i vlefshëm meriton vëmendje më të menjëhershme sesa një që tashmë ka skaduar ose është revokuar, dhe në shkallë të gjerë dallimi ka rëndësi jashtëzakonisht. Kërkimi i GitGuardian për Gjendjen e Përhapjes së Sekreteve gjeti 28.65 milionë sekrete të reja të vështira të shtuara në angazhimet publike të GitHub vetëm në 2025, një rritje prej 34 përqind nga viti në vit. Vëllime në atë shkallë e bëjnë triazhin manual jorealist. Ekipet duhet të përcaktojnë se cilat zbulime ende përfaqësojnë autentikim të përdorshëm dhe t'i zhvendosin ato në krye të radhës. Vetëm vlefshmëria ende nuk tregon të gjithë historinë. Një kredencial i vlefshëm për një shërbim të përbashkët zhvillimi meriton vëmendje, por një kredencial i vlefshëm me akses administratori në një llogari cloud prodhimi meriton dukshëm më shumë. Prioritizimi duhet të shtojë kontekst: nëse kredenciali është ende i vlefshëm, nëse arrin në prodhim, staging ose zhvillim, çfarë identiteti përfaqëson, çfarë privilegjesh ka ai identitet, cilat burime mund të arrijë, ku tjetër përdoret kredenciali dhe kush e zotëron atë dhe mund ta rrotullojë ose revokojë. Përgjigjet që mund të auditohen e kthejnë një listë dërrmuese të sekreteve të rrjedhura në një plan të vërtetë zgjidhjeje.
Vala më e re e sulmeve Shai-Hulud duhet të çojë në më shumë sesa një pastrim një herë i kredencialeve. Kredencialet do të vazhdojnë të grumbullohen ndërsa zhvilluesit ndërtojnë softuer, shërbimet integrohen, tubacionet evoluojnë dhe mjetet e reja hyjnë në mjedis. Përgjigja duhet të bëhet një cikël i përsëritshëm. Organizatat së pari kanë nevojë për dukshmëri të gjerë në të gjitha kredencialet, duke përfshirë kodin burimor dhe historinë e Git, por sulmet moderne argumentojnë për të parë më tej në sistemet CI/CD dhe mjediset e zhvilluesve ku grumbullohet materiali i autentikimit. Zbulimi duhet të përgjigjet se ku ekziston aktualisht autoriteti i ripërdorshëm, dhe duhet të jetë i auditueshëm në vend që thjesht të pasqyrojë sekretet e njohura tashmë të ruajtura në një kasafortë. Përqindja e sekreteve që ekzistojnë jashtë kasafortës është një metrikë e rëndësishme kur adresohet siguria e sekreteve në shkallë të gjerë, sepse planet e zgjidhjes që nuk llogarisin për sekretet e braktisura në tekst të qartë janë të dënuara të dështojnë. Parandalimi duhet të ndalojë të njëjtin shtresë kredencialesh nga rindërtimi duke bllokuar sekretet e reja të vështira, duke lëvizur rrjedhat e punës drejt kredencialeve afatshkurtra aty ku është e mundur, duke mbrojtur kredencialet në mjediset e zhvilluesve dhe duke kapur ekspozimin e ri përpara se të bëhet një tjetër projekt i madh. Zbulimi, zgjidhja dhe parandalimi duhet të trajtohen si një cikël i vazhdueshëm, jo një përgjigje emergjente e shkaktuar pas një sulmi. Për pronarët e faqeve të internetit dhe ekipet më të vogla pa një funksion sigurie me kohë të plotë, një rishikim i IT dhe infrastrukturës me siguri në radhë të parë si ai i ofruar nga AEU-I mund të ndihmojë në ndërtimin e atij inventari kredencialesh dhe bazës së privilegjeve minimale. Varianti tjetër Shai-Hulud pothuajse me siguri do të shikojë diku tjetër, duke u zgjeruar përtej 469 vendeve të identifikuara tashmë. Sulmuesit do të vazhdojnë të shtojnë shtigje dhe mjete zhvilluesish sepse mjediset moderne të softuerit janë plot me autoritet të ripërdorshëm. Mbrojtësit nuk do të fitojnë duke memorizuar çdo vend ku infostealer-i tjetër mund të shikojë. Ata fitojnë duke hequr privilegjin e përhershëm dhe duke eliminuar kredencialet e ekspozuara kudo që ekzistojnë, në mënyrë që çdo herë që vjen një krimb i ri, të ketë më pak çelësa të gjetur për t'u abuzuar.
Si të Mbroheni
- Përdorni një menaxher fjalëkalimesh për të krijuar dhe ruajtur një fjalëkalim të ndryshëm për çdo faqe interneti dhe aplikacion, në mënyrë që një fjalëkalim i vjedhur të mos mund të zhbllokojë llogaritë tuaja të tjera.
- Aktivizoni vërtetimin me dy faktorë (2FA) për emailin, llogarinë e hostingut dhe çdo llogari publikimi kodi ose paketash, në mënyrë që vetëm fjalëkalimi të mos mjaftojë për të hyrë.
- Përpara se të klikoni një lidhje shkarkimi ose të hapni një bashkëngjitje emaili, ndaluni dhe kontrolloni që ajo vërtet vjen nga një dërgues që njihni, sepse malware infostealer shpesh vjen në atë mënyrë.
- Kontrolloni rregullisht faqen e 'sesioneve aktive' ose 'aplikacioneve të lidhura' në llogaritë që ju interesojnë dhe dilni nga çdo pajisje që nuk e njihni.
- Kurrë mos i ruani fjalëkalimet, çelësat sekretë ose kodet e rikuperimit në skedarë teksti të thjeshtë në kompjuterin tuaj ose në dokumente të përbashkëta online; mbajini ato në një menaxher fjalëkalimesh ose mjet shënimesh të sigurta.
Termat e Shpjeguar
- Infostealer Malware i krijuar për të mbledhur fjalëkalime, tokenë dhe të dhëna të tjera hyrjeje nga një kompjuter i infektuar.
- Credential Një fjalëkalim, token aksesi ose informacion tjetër që provon se kush është një përdorues ose program dhe u jep atyre akses.
- CI/CD Shkurtim për integrim të vazhdueshëm dhe dorëzim të vazhdueshëm; një proces i automatizuar për ndërtimin, testimin dhe publikimin e softuerit.
- OpenID Connect (OIDC) Një mënyrë standarde që një shërbim të verifikojë se kush është një përdorues ose program pa dorëzuar një fjalëkalim afatgjatë.
- Hardcoded secret Një fjalëkalim, çelës ose token i shkruar direkt në kodin e softuerit ose në një skedar konfigurimi në vend që të ruhet në mënyrë të sigurt.
- .env file Një skedar teksti i thjeshtë ku zhvilluesit shpesh ruajnë vlera private si fjalëkalime dhe çelësa API për një aplikacion.
- GitHub token Një varg i shkurtër teksti që i lejon një programi ose personi të hyjë në një llogari ose depo GitHub.
- Kubernetes Një sistem për menaxhimin dhe ekzekutimin e aplikacioneve të kontejnerizuara në shumë makina; shpesh mban të drejta aksesi të ndjeshme.