CI/CD: Nasadenie webshellu do produkčného prostredia

Zraniteľnosť:

V našom komplexnom hodnotení zabezpečenia sme zistili kritickú zraniteľnosť, na ktorú by si mal dať pozor každý vývojár: možnosť nasadiť škodlivý kód priamo do produkčného prostredia. Nenachádzame sa len v hypotetickej rovine, nakoľko sme v nasadení boli úspešní.

Podrobnosti:

Nesprávne nakonfigurovaný pracovný postup nasadenia: (Continuous Integration/Continuous Deployment). V tomto kľúčovom procese chýbali ochranné opatrenia potrebné na zabezpečenie toho, aby bol každý nasadený kus kódu dôkladne skontrolovaný a schválený. Absencia týchto zabezpečení dáva útočníkom veľkú moc a možnosť útoku.

Zneužitie zraniteľností:

Využitím medzier v CI/CD sa nám podarilo do produkčného prostredia nasadiť NodeJS webshell - typ škodlivého kódu, ktorý útočníkovi poskytuje vzdialené rozhranie príkazového riadka k webovému serveru. Nešlo pritom o obyčajné produkčné prostredie, ale o prostredie nachádzajúce sa v rámci klastra OCP4 (OpenShift Container Platform 4), ktorý je zvyčajne známy svojimi robustnými bezpečnostnými funkciami.

Prečo sa to stalo?

K tejto zraniteľnosti prispelo niekoľko faktorov:

• Dohľad počas konfigurácie CI/CD: Počas fázy nastavovania boli vynechané alebo nesprávne nakonfigurované kľúčové bezpečnostné kroky.
• Podcenenie schvaľovacích procesov: Procesom určeným na zabezpečenie overenia každého nasadenia sa neprikladala potrebná váha.
• Medzery vo vedomostiach: V tíme zodpovednom za tieto systémy mohlo dôjsť k nedostatočnému pochopeniu alebo uvedomovaniu si vážnych hrozieb, ktoré predstavuje nekontrolované nasadenie.

Ako zmierniť následky:

• Ak chcete odstrániť túto dieru v zabezpečení, odporúčame vykonať nasledujúce kroky:
• Povinné preskúmanie a schválenie: Zaviesť železné pravidlo, že žiadny kód sa nedostane do výroby bez toho, aby prešiel prísnym procesom kontroly a schvaľovania.
• Audity: Vytvorte si rutinnú prax, aby ste prechádzali CI/CD a hľadali chybné konfigurácie alebo bezpečnostné kroky, ktoré mohli byť vynechané.
• Vzdelávanie a informovanosť: Podporujte kultúru bezpečnosti vzdelávaním vývojových a prevádzkových tímov o rizikách nekontrolovaného nasadenia.
• Automatizované bezpečnostné nástroje: Používajte pokročilé nástroje, ktoré automaticky zisťujú a blokujú akékoľvek neoprávnené alebo neobvyklé zmeny počas procesu vývoja a nasadenia.

Tento incident zdôrazňuje potrebu ostražitosti a prísnych bezpečnostných protokolov v dnešnom digitálnom prostredí. Je to výzva pre organizácie, aby prehodnotili a posilnili svoje stratégie kybernetickej bezpečnosti.

Skryté nebezpečenstvo nájdených neschválených citlivých dát v repozitároch GitHub

V oblasti správy zdrojového kódu je GitHub titánom, ktorý spravuje milióny úložísk kódu. Je však veľmi dôležité vedieť, ako ukladať údaje do repozitárov. Nedávny bezpečnostný audit/test poukázal na významnú bezpečnostnú chybu: absenciu správne nakonfigurovaného tajného skenovania. Toto nedopatrenie zdôrazňuje dôležitosť dodržiavania osvedčených postupov pri správe úložísk na zabezpečenie integrity a bezpečnosti údajov.

Zraniteľnosť:

Naše hodnotenie zabezpečenia odhalilo, že tajné skenovanie, automatická funkcia v službe GitHub (https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning) určená na zisťovanie citlivých informácií, ako sú heslá a súkromné kľúče, nebola povolená. Okrem toho nebola použitá žiadna ochrana ani detekcia proti ukladaniu citlivých údajov do úložísk. Úložiská organizácií sú tak zraniteľné voči náhodnému odhaleniu citlivých údajov.

Podrobnosti:

Odhalené citlivé dáta: Bez skenovania môžu byť citlivé údaje neúmyselne odovzdané do verejných alebo súkromných úložísk, čo predstavuje značné riziko pre bezpečnosť.

Potenciálne vplyvy:

• Porušenie ochrany údajov: Odhalené tajomstvá sú pre útočníkov zlatou baňou, ktorá môže viesť k úniku údajov a neoprávnenému prístupu k iným službám.
• Kompromitácia infraštruktúry: Prístupové tokeny, kľúče SSH a iné poverenia by mohli byť zneužité, čím by sa ohrozili nielen úložiská, ale aj infraštruktúra a služby, s ktorými komunikujú.

Prečo sa to stalo?

Nedostatočná konfigurácia skenovania citlivých dát môže vyplývať z:

• Nedostatok informovanosti: Vývojári a správcovia úložísk si nemusia byť vedomí funkcie alebo jej dôležitosti.
• Nesprávna konfigurácia: V procese nastavovania úložiska alebo pri migrácii medzi systémami sa mohli prehliadnuť konfigurácie, ako napríklad skenovanie citlivých dát.
• Výdavky a odbornosť: Organizácia si musí zakúpiť licenciu na funkciu skenovania citlivých dát z Githubu, čo môže byť nákladné a viesť k menej bezpečnému prostrediu. Odbornosť je dôležitá v súvislosti s CI/CD a bezpečnosťou, preto sú odborníci zodpovední za kontrolu a dodržiavanie pravidiel na zabezpečenie najvyššej úrovne bezpečnosti.

Ako zmierniť následky:

• Na zmiernenie tejto zraniteľnosti by sa mali okamžite prijať nasledujúce opatrenia:
• Povolenie skenovania citlivých dát: Trhy ponúkajú rôzne riešenia, ktoré môžu vyhovovať vašim preferenciám.
• Vzdelávajte a školte: Zabezpečte školenie pre vývojárov o postupoch bezpečného kódovania a dôležitosti udržiavania tajomstiev mimo úložísk kódu.
• Automatizácia odstránenia citlivých dát: Implementujte nástroje na automatické zrušenie a opätovné vydanie odhalených citlivých dát.
• Uznesenie pravidiel: Zavedenie zásad, ktoré zakazujú zahrnutie citlivých dát do kódu, a ich presadzovanie pomocou automatických kontrol.

Je nevyhnutné uvedomiť si, že zabezpečenie úložísk kódu je rovnako dôležité ako zabezpečenie infraštruktúry, do ktorej sa nasadzujú.

Obchádzanie ochrany vetiev Githubu: Odhalená zraniteľnosť s vysokým rizikom

Nedávno sme pomocou známeho obídenia dokázali zneužiť funkciu GitHub Actions Branch Protection Rules, ktorá je kľúčová pre zachovanie integrity kódu vo viacerých vývojových prostrediach.

Zraniteľnosť:

Táto zraniteľnosť sa v podstate týka neoprávneného obídenia mechanizmov ochrany vetiev v službe Github. Pravidlá ochrany vetiev sú kľúčové pri zabezpečovaní toho, aby zmeny v dôležitých vetvách vyžadovali riadne preskúmanie a schválenie. Známe obídenie, ktoré sme použili v systéme GitHub, umožňuje zneužitie funkcie GitHub Actions na obídenie procesu povinného preskúmania. Toto porušenie umožňuje neoprávnené vloženie nerecenzovaného kódu do zabezpečenej vetvy. Takáto medzera by mohla viesť k neúmyselnému použitiu škodlivého kódu inými používateľmi alebo k jeho neúmyselnému začleneniu do produkčného prostredia.

Podrobnosti:

Mechanizmus bypassu: Proces zneužitia zahŕňal využitie oprávnení Github Actions. Využitím oprávnení na zápis na koncovom bode API pull requestov sme mohli vytvoriť pull request na zlúčenie škodlivého kódu do chránenej vetvy. Hoci takúto žiadosť o stiahnutie zvyčajne nemožno zlúčiť bez schválenia, bot Github Actions, spojený s GITHUB_TOKEN, ju mohol schváliť. Keďže bot nie je členom organizácie, ale stále sa používa na účely schvaľovania, umožňuje útočníkovi samostatne schváliť požiadavku na vytiahnutie, čím účinne obíde mechanizmy ochrany vetvy. Táto skutočnosť umožňuje neoprávnené vloženie neschváleného kódu do zabezpečenej vetvy. Takáto medzera nás vedie k neoprávnenému začleneniu kódu do produkčného prostredia.

Riziká a hrozby:

• Neoprávnené zmeny kódu v chránených vetvách.
• Nasadenie škodlivého kódu do produkčných a iných prostredí.
• Narušená integrita a spoľahlivosť aplikácie.
• Oslabenie dôvery v proces zavádzania a celkovú infraštruktúru.

Prečo sa to stalo?

Tento problém vznikol v dôsledku medzery v nastaveniach služby Github, ktorá umožňovala, aby akcie GitHubu schvaľovali žiadosti o stiahnutie, čo v existujúcich organizáciách nebolo bezpečné.

Ako zmierniť následky:

Na riešenie tohto významného rizika sa navrhujú tieto riešenia:

• Aktualizácia nastavení Githubu: Použite nastavenie Githubu, ktoré zakazuje schvaľovanie žiadostí o stiahnutie v rámci akcií Githubu. Aby bolo toto nastavenie účinné, musí byť nastavené v rámci celej organizácie.

• Schválenia preskúmania: Vykonajte preskúmanie žiadostí o stiahnutie od vlastníkov kódu, aby ste sa uistili, že všetky zmeny boli overené oprávnenými pracovníkmi.
• Zvýšenie požiadaviek na schválenie: Zmeniť počet požadovaných schválení na dve alebo viac, čo pridáva ďalšiu úroveň bezpečnosti tým, že vyžaduje viacero kontrolórov.

Táto zraniteľnosť zdôrazňuje zásadný význam neustálej ostražitosti a pravidelných aktualizácií bezpečnostných konfigurácií vo všetkých aspektoch vývojových operácií. Implementáciou odporúčaných zmien môžu organizácie ochrániť svoj kód pred takýmito zneužitiami a posilniť dôveru v procesy nasadenia.

Konfigurácia služby Artifactory - otvorený prístup k údajom

Integrita každého vývojového prostredia závisí od zabezpečenia a kontrolovaného prístupu k jeho artefaktom. Pri nedávnom hodnotení zabezpečenia, ktoré sme vykonali, sa nám podarilo využiť dieru v službe Artifactory na prihlásenie bez explicitných oprávnení.

Zraniteľnosť:

Služba Artifactory umožňuje prihlásenie ľubovoľnému používateľovi domény bez toho, aby vyžadovala výslovné oprávnenia. Po prihlásení si používateľ môže prezerať, sťahovať artefakty a kontrolovať správy o zraniteľnostiach zo skenovania Xray súvisiace s úložiskami.

Podrobnosti:

Príliš povoľujúce kontroly prístupu: Predvolená konfigurácia umožňovala prístup k službe Artifactory každému používateľovi v rámci domény. Takáto konfigurácia zanedbáva the Least Privilege princíp, ktorý je nevyhnutný pri zabezpečení citlivých údajov.

Týmto spôsobom sa každému používateľovi domény sprístupní množstvo citlivých informácií. Schopnosť identifikovať, ktoré aplikácie obsahujú kritické zraniteľnosti, môžu black-hat hackeri využiť na zneužitie týchto zraniteľností. Okrem toho artefakty môžu obsahovať citlivé údaje, pretože neexistuje žiadne predpísané skenovanie týchto údajov.

Riziká a dôsledky:

• Neoprávnený prístup k citlivým artefaktom.
• Potenciálny únik údajov.
• Narušenie integrity údajov.
• Zvýšené riziko vnútorných hrozieb.

Prečo sa to stalo?

Dôvody tejto nesprávnej konfigurácie môžu byť nasledovné:

• Chýbajúce riadenie prístupu na základe rolí (RBAC): Nedostatočne definované roly a oprávnenia používateľov môžu viesť k takémuto širokému prístupu.

Ako zmierniť následky:

• Riešenie tejto zraniteľnosti zahŕňa strategickú revíziu prístupových oprávnení:
• Implementácia RBAC: Definujte presné roly používateľov a prideľte im oprávnenia, ktoré sú v súlade s princípom najmenších privilégií.
• Auditovanie protokolov o prístupe: Pravidelne kontrolujte protokoly o prístupe, aby ste zistili, či nedošlo k neoprávneným pokusom alebo prístupom k službe.
• Priebežné monitorovanie: Implementujte nástroje na monitorovanie v reálnom čase na zisťovanie a upozorňovanie na neobvyklé vzory prístupu.
• Pravidelný check prístupu: Pravidelne kontrolujte prístupové práva používateľov, aby ste sa uistili, že sú primerané úlohe a zodpovednosti každého používateľa.

Riziko vystavenia údajov v službe Artifactory je jasnou pripomienkou toho, že aj tie najdôveryhodnejšie služby v rámci vývojového prostredia organizácie musia byť podrobne preskúmané z hľadiska bezpečnostných nedostatkov. Rozhodnými krokmi na opravu týchto chybných nastavení môžu organizácie posilniť svoju obranu pred vonkajšími aj vnútornými hrozbami.

Nesprávna konfigurácia OpenShift: Neobmedzený prístup k sieti hostiteľa z POD

Agilita a škálovateľnosť, ktoré prostredia poskytujú, môžu tiež predstavovať významné bezpečnostné riziká, ak nie sú riadne spravované. Nedávne posúdenie vrhlo svetlo na závažnú chybnú konfiguráciu v rámci klastra OpenShift a poukázalo na zraniteľnosť, ktorá by mohla mať vážne dôsledky na bezpečnosť siete.

Zraniteľnosť:

V centre pozornosti je konfiguračná chyba v OpenShift, populárnej platforme. Táto chyba v konfigurácii umožnila, aby mali pody (najmenšie nasaditeľné jednotky výpočtovej techniky, ktoré možno v OpenShift vytvoriť a spravovať) možnosť dosiahnuť IP adresu hostiteľského počítača a dokonca celú podsieť hostiteľa. Laicky povedané, ak by bol pod kompromitovaný, útočník by mal neobmedzený prístup k potenciálne citlivým interným sieťovým zdrojom.

Podrobnosti:

Široká viditeľnosť siete: Znamenalo to, že nasadený pod v systéme OpenShift mohol vidieť a potenciálne komunikovať s veľkým množstvom interných systémov. Takýto prístup sa podobá tomu, ako keby ste niekomu dali kľúče od kráľovstva a mohli by ste ho zneužiť s ničivým účinkom.

Riziká a dôsledky:

• Možnosť rozsiahleho prieskumu vnútornej siete prostredníctvom napadnutého modulu.
• Zvýšené riziko bočného pohybu v rámci siete, ktoré vedie k ohrozeniu väčšieho počtu systémov.
• Porušenie ochrany údajov v dôsledku prístupu k citlivým interným systémom.
• Narušená integrita a bezpečnosť siete.

Prečo sa to stalo?

Hlavnou príčinou tejto nesprávnej konfigurácie môže byť:

• Nedostatočné sieťové pravidlá: chýbajú prísne sieťové politiky, ktoré by obmedzovali prístup POD k sieti len na nevyhnutné zdroje a služby v rámci ich vlastnej podsiete.
• Úskalia predvolenej konfigurácie: Predvolené nastavenia, ktoré uprednostňujú jednoduchosť nasadenia pred bezpečnosťou a ktoré nie sú po nasadení revidované a riadne zabezpečené.

Ako zmierniť následky:

Na nápravu tohto nebezpečného nedopatrenia by organizácie mali prijať nasledujúce opatrenia:

• Segmentácia siete: konkrétne definujte, ktoré sieťové pripojenia sú povolené pre každý modul na základe princípu najmenších oprávnení.
• Pravidelné bezpečnostné audity: Vykonávajte pravidelné kontroly sieťových konfigurácií v prostredí OpenShift s cieľom zabezpečiť súlad s osvedčenými bezpečnostnými postupmi.
• Bezpečnostné normy pre pod: Prijať a presadzovať bezpečnostné štandardy podov, ktoré obmedzujú možnosti a prístup k podom, najmä k tým, ktoré sú spustené v produkčnom prostredí.
• Bezpečnostné školenie: Zabezpečte priebežné školenie zamestnancov o potenciálnych rizikách nesprávnej konfigurácie a o dôležitosti postupov bezpečného nasadenia.

Prípad nesprávnej konfigurácie OpenShift slúži ako varovný príbeh o kritickej potrebe dôsledných postupov zabezpečenia siete v kontajnerových prostrediach. Vďaka starostlivej správe a neustálej ostražitosti môžu organizácie chrániť svoje siete pred takýmito zraniteľnosťami.

Chyby konfigurácie služby GitHub: Brána k neautorizovaným nasadeniam

Zraniteľnosť:

Nedávne posúdenie bezpečnosti poukázalo na očividný problém v rámci konfigurácie úložiska GitHub, kde boli zdrojové kódy aplikácií uložené v rámci organizácie GitHub, čo otvára dvere zraniteľnosti, ktorá by mohla viesť k neoprávnenému a potenciálne škodlivému nasadeniu.

Podrobnosti:

Jadro tohto problému spočíva v permisívnosti predvolených konfigurácií úložísk a v nedostatku prísnych mechanizmov kontroly toku. Keďže neexistujú žiadne pravidlá ochrany vetiev, žiadne prostredia s pravidlami ochrany a citlivých údajov, táto situácia umožňuje komukoľvek s prístupom k zápisu do úložiska vykonávať potenciálne škodlivé činnosti, ako je čítanie všetkých citlivých dát, vytváranie akýchkoľvek artefaktov (vrátane škodlivých), odstraňovanie kontrol statickej analýzy zdrojového kódu v pipeline a potenciálne zneužívanie samo-hostiteľských runnerov.

Riziká a dôsledky:

• Prístup k akémukoľvek tajomstvu, ktoré má úloha CI k dispozícii, napríklad k citlivým dátam vloženým ako premenné prostredia alebo k ďalším dátam uloženým v CI. Keďže sú systémy CI/CD zodpovedné za vytváranie kódu a nasadzovanie artefaktov, zvyčajne obsahujú desiatky poverení a tokenov s vysokou hodnotou - napríklad k poskytovateľovi cloudu, k registrom artefaktov a k samotnému SCM.
• Prístup k externým prostriedkom, ku ktorým má runner oprávnenia, napríklad k súborom uloženým v súborovom systéme uzla alebo k povereniam do cloudového prostredia prístupného prostredníctvom základného hostiteľa.
• Možnosť posielať kód a artefakty ďalej v rámci potrubia pod rúškom legitímneho kódu vytvoreného procesom zostavovania.

Prečo sa to stalo?

Tento problém často vyplýva z:

• Nevhodné nastavenia úložiska: Predvolené nastavenia, ktoré sú zamerané na pohodlie a nie na bezpečnosť, môžu spôsobiť, že úložiská budú zraniteľné.
• Zanedbanie kontroly toku: Nedostatočné opatrenia na zabezpečenie toho, aby zmeny pred zlúčením alebo nasadením prešli prísnym schvaľovacím procesom.

Ako zmierniť následky:

Na zabránenie takýmto neoprávneným nasadeniam a na posilnenie bezpečnosti sa odporúčajú nasledujúce kroky:

• Konfigurácia pravidiel ochrany pobočiek: Vykonajte pravidlá, ktoré vyžadujú preskúmanie pred zlúčením požiadaviek na stiahnutie, najmä do kritických vetiev.
• Chráňte prostredie: Nastavte pravidlá ochrany prostredí na riadenie nasadenia, napríklad povolenie nasadenia len z chránených pobočiek.
• Bezpečné citlivé dáta v prostredí: Ukladajte všetky citlivé dáta v rámci prostredí, aby ste obmedzili prístup len na schválené úlohy.
• Používanie súborov pravidiel úložiska GitHub: poskytujú správcom organizácie lepšiu kontrolu a funkcie, ako je jednotná konfigurácia a zameranie na vetvy. (https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)
• Povinný pracovný postup analýzy kódu: Implementujte požadované pracovné postupy pre statickú analýzu kódu na žiadosti o stiahnutie vo všetkých pobočkách v rámci organizácie.

Artifactory - nasadenie zraniteľných artefaktov

Ďalším bodom bolo objasnenie zraniteľnosti v spôsobe správy a nasadzovania artefaktov. Ak by sa tento problém neošetril, mohol by pripraviť pôdu pre významné bezpečnostné hrozby v produkčných prostrediach.

Zraniteľnosť:

Počas procesu nasadzovania artefaktov uložených v službe Artifactory sme zistili, že artefakty, dokonca aj tie s kritickými zraniteľnosťami alebo zraniteľnosťami vysokej úrovne, mohli byť nasadené do produkčných prostredí bez akéhokoľvek overenia pred nasadením. Tento nedostatok v procese overovania ponecháva produkčné prostredie otvorené potenciálnym narušeniam bezpečnosti.

Artifactory X-ray: node. Js webshell docker image obsahujúci kritickú zraniteľnosť. Neskôr nasadený do produkcie.

Uvedomujeme si, že zablokovanie všetkých zraniteľných artefaktov by mohlo narušiť proces zostavovania/nasadzovania a mohlo by mať obchodné dôsledky. Napriek tomu by sa tieto zraniteľnosti mali pred nasadením aspoň skontrolovať a schváliť, aby sa znížilo riziko zavedenia bezpečnostných nedostatkov do produkčného prostredia.

Vplyv:

• Potenciálne dôsledky nasadenia zraniteľných artefaktov sú ďalekosiahle a alarmujúce:
• Zvýšené riziko kybernetických útokov: Nasadenie artefaktov so zraniteľnosťami priamo do výroby zvyšuje pravdepodobnosť kybernetických útokov.
• Kompromitácia obchodných operácií: Zneužitie kritických zraniteľností by mohlo narušiť alebo dokonca ohroziť kľúčové obchodné operácie.
• Nedodržiavanie právnych predpisov: Takéto postupy môžu byť v rozpore s priemyselnými normami alebo predpismi, ktoré nariaďujú účinnú správu zraniteľností a záplat.

Riešenie:

Na zmiernenie týchto rizík sa dôrazne odporúčajú tieto opatrenia:

• Proces skenovania zraniteľnosti: Implementujte proces, ktorý pred nasadením do produkčného prostredia skenuje všetky artefakty na vysokú alebo kritickú zraniteľnosť. Tento proces by mal zahŕňať povinné schválenie nasadenia artefaktov s identifikovanými zraniteľnosťami.
• Použitie Xray: V aplikácii Xray nakonfigurujte zásady na identifikáciu problémov s vysokou/kritickou zraniteľnosťou. Spočiatku sa vyhnite aktivitám, ako je zlyhanie zostavenia alebo zabránenie sťahovania, ale namiesto toho sa zamerajte na triedenie jednotlivých porušení.
• Komplexná správa záplat: Zaviesť spoľahlivý systém správy záplat, ktorý zabezpečí včasné odhalenie, posúdenie a odstránenie zraniteľností v artefaktoch.

Záver:

Naším cieľom bolo obísť všetky bezpečnostné opatrenia a nasadiť škodlivý kód do produkčného prostredia s prístupom ku konfigurácii OCP4 ak celej línii CI/CD s prideleným priestorom v klastri. Zistili sme, že scenár je uskutočniteľný využitím reťazca nesprávnych konfigurácií a zraniteľností, ktoré sú konkrétne opísané v nasledujúcich častiach:

• Github - Neoprávnené obchádzanie mechanizmov ochrany vetiev
• Github - Povolená predvolená konfigurácia úložiska a nedostatočné mechanizmy kontroly toku
• Artifactory - nasadenie zraniteľných artefaktov

Nakoniec sa nám podarilo nasadiť škodlivú aplikáciu - NodeJS webshell do produkčného prostredia v rámci clusteru OCP4.

Týmto chceme poukázať na dôležitosť zodpovednosti vývojárov a na to, ako môže kombinácia malých zraniteľností vyústiť do kritickej situácie, kedy môže byť ohrozená celá náročná práca a bezpečnosť klientov.

Nie ste si istí bezpečnosťou vášej Pipeline? Otestujte ju s nami.