CI/CD: Nasazení webshellu do produkčního prostředí

Zranitelnost:

V našem komplexním hodnocení zabezpečení jsme identifikovali kritickou zranitelnost, na kterou by si měl dát pozor každý vývojář: možnost nasadit škodlivý kód přímo do produkčního prostředí. Nejedná se pouze o hypotetické úvahy, protože jsme byli při nasazení úspěšní.

Podrobnosti:

Nesprávně nakonfigurovaný pracovní postup nasazení: (Continuous Integration/Continuous Deployment). Tento klíčový proces postrádal ochranná opatření nezbytná k zajištění toho, aby každý nasazený kus kódu byl důkladně zkontrolován a schválen. Absence těchto ochranných opatření dává útočníkům velkou moc a příležitost k útoku. Zneužívání zranitelností:

Zneužitím zranitelností CI/CD se nám podařilo do produkčního prostředí nasadit webshell NodeJS - typ škodlivého kódu, který útočníkovi poskytuje vzdálené rozhraní příkazového řádku k webovému serveru. Nejednalo se o běžné produkční prostředí, ale o prostředí umístěné v rámci clusteru OCP4 (OpenShift Container Platform 4), který je typický svými robustními bezpečnostními funkcemi.

Proč se to stalo?

K této zranitelnosti přispělo několik faktorů:

• Dohled při konfiguraci CI/CD: ve fázi nastavení byly vynechány nebo nesprávně nakonfigurovány klíčové bezpečnostní kroky.
• Podcenění schvalovacích procesů: procesům určeným k zajištění ověření každého nasazení
• nebyla přikládána potřebná váha.
• Mezery ve znalostech: v týmu odpovědném za tyto systémy mohlo dojít k nedostatečnému pochopení nebo uvědomění si závažných hrozeb, které představuje nekontrolované nasazení.

Jak zmírnit následky:

Chcete-li tuto bezpečnostní díru odstranit, doporučujeme provést následující kroky:

• Povinná kontrola a schvalování: stanovte pevné pravidlo, že žádný kód nepůjde do výroby, aniž by prošel přísným procesem kontroly a schvalování.
• Audity: rutinně procházejte CI/CD a hledejte chybné konfigurace nebo bezpečnostní kroky, které mohly být opomenuty.
• Vzdělávání a informovanost: podpora kultury bezpečnosti prostřednictvím vzdělávání vývojových a provozních týmů o rizicích nekontrolovaného nasazení.
• Automatizované bezpečnostní nástroje: Používejte pokročilé nástroje, které automaticky detekují a blokují všechny neoprávněné nebo neobvyklé změny během procesu vývoje a nasazení.

Tento incident poukazuje na nutnost ostražitosti a přísných bezpečnostních protokolů v dnešním digitálním prostředí. Je to výzva pro organizace, aby přezkoumaly a posílily své strategie kybernetické bezpečnosti.

Skryté nebezpečí nalezení neschválených citlivých dat v úložištích GitHubu

GitHub je titánem v oblasti správy zdrojových kódů, který spravuje miliony úložišť kódu. Je však velmi důležité vědět, jak data v úložištích ukládat. Nedávný bezpečnostní audit/test upozornil na významnou bezpečnostní chybu: chybějící správně nakonfigurované tajné skenování. Toto nedopatření poukazuje na důležitost dodržování osvědčených postupů při správě úložišť, aby byla zajištěna integrita a bezpečnost dat.

Zranitelnost:

Naše posouzení zabezpečení odhalilo, že tajné skenování, automatická funkce služby GitHub (https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning) určená k odhalování citlivých informací, jako jsou hesla a soukromé klíče, nebylo povoleno. Kromě toho nebyla zavedena žádná ochrana nebo detekce, která by zabránila ukládání citlivých údajů do úložišť, takže úložiště organizací byla zranitelná vůči náhodnému vyzrazení citlivých údajů.

Podrobnosti:

• Odhalení citlivých údajů: Bez skenování mohou být citlivá data neúmyslně nahrána na veřejná nebo soukromá úložiště, což představuje významné bezpečnostní riziko.

Možné dopady:

• Únik dat: odhalená tajemství jsou pro útočníky zlatým dolem, který může vést k úniku dat a neoprávněnému přístupu k dalším službám.
• Ohrožení infrastruktury: Přístupové tokeny, klíče SSH a další pověření mohou být zneužity, čímž dojde k ohrožení nejen úložišť, ale také infrastruktury a služeb, s nimiž komunikují.

Proč se to stalo?

Nedostatečná konfigurace skenování citlivých dat může být důsledkem:

• Nedostatečná informovanost: vývojáři a správci úložišť si nemusí být vědomi funkce nebo jejího významu.
• Chybná konfigurace: během procesu nastavení úložiště nebo při migraci mezi systémy mohlo dojít k přehlédnutí konfigurací, jako je skenování citlivých dat.
• Náklady a odborné znalosti: organizace si musí zakoupit licenci na funkci skenování citlivých dat Githubu, což může být nákladné a vést k méně bezpečnému prostředí. V kontextu CI/CD a zabezpečení jsou důležité odborné znalosti, takže odborníci jsou zodpovědní za kontrolu a dodržování zásad, aby byla zajištěna nejvyšší úroveň zabezpečení.

Jak zmírnit následky:

Ke zmírnění této zranitelnosti by měla být okamžitě přijata následující opatření:

• Povolení skenování citlivých dat: trhy nabízejí různá řešení, která mohou vyhovovat vašim preferencím.
• Vzdělávání a školení: Zajistěte školení vývojářů o bezpečném kódování a o tom, jak je důležité udržovat tajemství mimo úložiště kódu.
• Automatizace mazání citlivých dat: implementujte nástroje pro automatické mazání a opětovné vydávání odhalených citlivých dat.
• Řešení zásad: Zavedení zásad, které zakazují zahrnutí citlivých údajů do kódu, a jejich prosazování prostřednictvím automatických kontrol.

Je nutné si uvědomit, že zabezpečení úložišť kódu je stejně důležité jako zabezpečení infrastruktury, na které jsou nasazena.

Obcházení ochrany větve Github: Odhalena vysoce riziková zranitelnost

Nedávno se nám podařilo zneužít funkci GitHub Actions Branch Protection Rules, která je klíčová pro zachování integrity kódu ve více vývojových prostředích, pomocí známého řešení.

Zranitelnost:

Tato zranitelnost se v podstatě týká neoprávněného obejití mechanismů ochrany větví služby Github. Pravidla ochrany větví mají zásadní význam pro zajištění toho, aby změny v důležitých větvích vyžadovaly řádnou kontrolu a schválení. Známé řešení, které jsme v systému GitHub použili, umožňuje zneužít funkci GitHub Actions k obejití procesu povinného přezkoumání. Toto porušení umožňuje neoprávněné vložení nepřezkoumaného kódu do zabezpečené větve. Taková mezera může vést k neúmyslnému použití škodlivého kódu jinými uživateli nebo k jeho neúmyslnému začlenění do produkčního prostředí.

Podrobnosti:

Mechanismus obcházení: Proces zneužití zahrnoval využití oprávnění Github Actions. Využitím oprávnění k zápisu na koncovém bodě API žádosti o stažení jsme byli schopni vytvořit žádost o stažení a začlenit škodlivý kód do chráněné větve. Ačkoli takový požadavek na stažení obvykle nelze sloučit bez schválení, bot Github Actions spojený s GITHUB_TOKEN jej mohl schválit. Vzhledem k tomu, že bot není členem organizace, ale přesto je používán pro účely schvalování, umožňuje útočníkovi požadavek na stažení nezávisle schválit, čímž účinně obejde ochranné mechanismy větve. Tato skutečnost umožňuje neoprávněné vložení neschváleného kódu do zabezpečené větve. Taková mezera nás vede k neoprávněnému zařazení kódu do produkčního prostředí.

Rizika a hrozby:

• Neoprávněné změny kódu v chráněných větvích.
• Nasazení škodlivého kódu do produkčních a jiných prostředí.
• Integrita a spolehlivost aplikace jsou ohroženy.
• Podkopávání důvěry v proces zavádění a celkovou infrastrukturu.

Proč se to stalo?

Tento problém vznikl kvůli mezeře v nastavení Githubu, která umožňovala akcím GitHubu schvalovat žádosti o stažení, což bylo ve stávajících organizacích nebezpečné. Jak zmírnit následky:

K řešení tohoto významného rizika jsou navržena následující řešení:

• Aktualizace nastavení Githubu: Použijte nastavení Githubu, které zakazuje schvalování žádostí o stažení v akcích Githubu. Aby bylo toto nastavení účinné, musí být nastaveno v celé organizaci.

• Schvalování revizí: Proveďte revizi žádostí o stažení kódu od vlastníků kódu, abyste se ujistili, že všechny změny byly ověřeny oprávněnými pracovníky.
• Zvýšení požadavků na schválení: Změňte počet požadovaných schválení na dvě nebo více, což přidává další úroveň zabezpečení tím, že vyžaduje více kontrolorů.

Tato zranitelnost zdůrazňuje zásadní význam neustálé ostražitosti a pravidelných aktualizací bezpečnostních konfigurací ve všech aspektech vývojových operací. Zavedením doporučených změn mohou organizace ochránit svůj kód před takovými zneužitími a posílit důvěru v procesy nasazení.

Konfigurace služby Artifactory - otevřený přístup k datům

Integrita každého vývojového prostředí závisí na bezpečném a kontrolovaném přístupu k jeho artefaktům. Při nedávném posouzení zabezpečení, které jsme provedli, se nám podařilo zneužít díru ve službě Artifactory k přihlášení bez výslovných oprávnění.

Zranitelnost:

Služba Artifactory umožňuje přihlášení libovolnému uživateli domény bez nutnosti explicitního oprávnění. Po přihlášení může uživatel prohlížet a stahovat artefakty a kontrolovat zprávy o zranitelnostech z prověřování Xray týkající se úložišť.

Podrobnosti:

Příliš permisivní řízení přístupu: výchozí konfigurace umožňovala přístup ke službě Artifactory každému uživateli v doméně. Tato konfigurace opomíjí princip nejmenších oprávnění, který je pro zabezpečení citlivých dat zásadní.

Tímto způsobem je každému uživateli domény zpřístupněno mnoho citlivých informací. Schopnost určit, které aplikace obsahují kritické zranitelnosti, mohou využít hackeři typu black hat ke zneužití těchto zranitelností. Kromě toho mohou artefakty obsahovat citlivé údaje, protože neexistuje předepsané skenování těchto údajů.

Rizika a důsledky:

• Neoprávněný přístup k citlivým artefaktům.
• Potenciální únik dat.
• Porušení integrity dat.
• Zvýšené riziko vnitřních hrozeb.

Proč se to stalo?

Důvody této chybné konfigurace mohou být následující:

• Nedostatečné řízení přístupu na základě rolí (RBAC): špatně definované role a oprávnění uživatelů mohou vést k takto širokému přístupu.

Jak zmírnit následky:

Řešení této zranitelnosti zahrnuje strategickou revizi přístupových oprávnění:

• Implementace RBAC: Definujte přesné uživatelské role a přidělujte oprávnění, která jsou v souladu s principem nejmenších oprávnění.
• Kontrola protokolů o přístupu: pravidelně kontrolujte protokoly o přístupu a zjišťujte, zda nedošlo k neoprávněným pokusům nebo přístupům ke službě.
• Průběžné monitorování: implementujte nástroje pro monitorování v reálném čase, abyste zjistili neobvyklé vzorce přístupu a upozornili na ně.
• Pravidelná kontrola přístupu: pravidelně kontrolujte přístupová práva uživatelů, abyste se ujistili, že odpovídají jejich roli a odpovědnosti.

Riziko odhalení dat ve službě Artifactory je jasnou připomínkou toho, že i ty nejdůvěryhodnější služby v rámci vývojového prostředí organizace je třeba pečlivě prověřit z hlediska bezpečnostních nedostatků. Rozhodnými kroky k opravě těchto chybných nastavení mohou organizace posílit svou obranu proti vnějším i vnitřním hrozbám.

Chybná konfigurace systému OpenShift: neomezený přístup k hostitelské síti z PODu

Agilita a škálovatelnost, které prostředí poskytují, mohou také představovat významné bezpečnostní riziko, pokud nejsou správně řízeny. Nedávné hodnocení osvětlilo závažnou chybu v konfiguraci clusteru OpenShift a upozornilo na zranitelnost, která může mít vážné důsledky pro bezpečnost sítě.

Zranitelnost:

Jde o chybu konfigurace populární platformy OpenShift. Tato konfigurační chyba umožňovala, aby pody (nejmenší nasaditelné výpočetní jednotky, které lze v OpenShift vytvářet a spravovat) měly možnost dosáhnout na IP adresu hostitelského počítače, a dokonce na celou podsíť hostitele. Laicky řečeno, pokud byl pod kompromitován, útočník měl neomezený přístup k potenciálně citlivým interním síťovým zdrojům.

Podrobnosti:

Široká viditelnost sítě: To znamená, že nasazený pod v systému OpenShift může vidět a potenciálně komunikovat s velkým počtem interních systémů. Tento přístup se podobá tomu, jako kdybyste někomu dali klíče od království a mohli je zneužít s ničivým účinkem.

Rizika a důsledky:

• Možnost rozsáhlého průzkumu vnitřní sítě prostřednictvím napadeného modulu.
• Zvýšené riziko bočního pohybu v síti, které vede k ohrožení více systémů.
• Únik dat v důsledku přístupu k citlivým interním systémům.
• Ohrožena integrita a zabezpečení sítě.

Proč se to stalo?

Hlavní příčinou této chybné konfigurace může být:

• Nedostatečná síťová pravidla: chybí přísné síťové zásady, které by omezovaly přístup POD k síti pouze na nezbytné zdroje a služby v rámci jejich vlastní podsítě.
• Úskalí výchozí konfigurace: výchozí nastavení, která upřednostňují snadné nasazení před zabezpečením a která nejsou po nasazení zkontrolována a řádně zabezpečena.

Jak zmírnit následky:

Aby organizace napravily toto nebezpečné nedopatření, měly by přijmout následující opatření:

• Segmentace sítě: konkrétně definujte, která síťová připojení jsou povolena pro jednotlivé moduly na základě principu nejmenšího oprávnění.
• Pravidelné bezpečnostní audity: provádějte pravidelné kontroly síťových konfigurací v prostředí OpenShift, abyste zajistili soulad s osvědčenými postupy zabezpečení.
• Bezpečnostní standardy podů: Přijměte a prosazujte bezpečnostní standardy podů, které omezují možnosti a přístup k podům, zejména těm, které jsou provozovány v produkčních prostředích.
• Bezpečnostní školení: průběžně školte zaměstnance o možných rizicích nesprávné konfigurace a o důležitosti bezpečných postupů nasazení.

Případ chybné konfigurace systému OpenShift slouží jako varovný příběh o zásadní potřebě důsledných postupů zabezpečení sítě v kontejnerových prostředích. Při pečlivé správě a neustálé ostražitosti mohou organizace své sítě před takovými zranitelnostmi ochránit.

Chyby v konfiguraci služby GitHub: brána k neautorizovaným nasazením

Zranitelnost:

Nedávné posouzení zabezpečení upozornilo na zjevný problém v konfiguraci úložiště GitHub, kde byl zdrojový kód aplikace uložen v rámci organizace GitHub, což otevíralo dveře zranitelnosti, která mohla vést k neoprávněnému a potenciálně škodlivému nasazení.

Podrobnosti:

Jádro tohoto problému spočívá v permisivitě výchozích konfigurací úložiště a v absenci přísných mechanismů řízení toku. Protože neexistují žádná pravidla ochrany větví, žádná prostředí zásad a žádná citlivá data, umožňuje tato situace komukoli s přístupem k zápisu do úložiště provádět potenciálně škodlivé činnosti, jako je čtení jakýchkoli citlivých dat, vytváření jakýchkoli artefaktů (včetně škodlivých), odstraňování kontrol statické analýzy zdrojového kódu v pipeline a potenciální zneužití samoobslužných běhových programů.

Rizika a důsledky:

Přístup ke všem tajným údajům, které má role CI k dispozici, jako jsou citlivé údaje vložené jako proměnné prostředí nebo jiná data uložená v CI. Vzhledem k tomu, že systémy CI/CD jsou zodpovědné za generování kódu a nasazování artefaktů, obsahují obvykle desítky pověření a tokenů vysoké hodnoty - například k poskytovateli cloudu, k registrům artefaktů a k samotnému SCM.

• Přístup k externím prostředkům, ke kterým má runner oprávnění, například k souborům uloženým v souborovém systému uzlu nebo k pověřením ke cloudovému prostředí, k němuž má přístup prostřednictvím základního hostitele.
• Schopnost posunout kód a artefakty dále do vývojového řetězce pod rouškou legitimního kódu vytvořeného procesem sestavení.

Proč se to stalo?

Tento problém často pramení z:

• Nevhodná nastavení úložiště:Výchozí nastavení, která se zaměřují spíše na pohodlí než na zabezpečení, mohou způsobit zranitelnost úložných zařízení.
• Zanedbání řízení toku: Nedostatečná opatření k zajištění toho, aby změny před sloučením nebo nasazením prošly přísným schvalovacím procesem.

Jak zmírnit následky:

Aby se zabránilo takovému neoprávněnému nasazení a zvýšilo se zabezpečení, doporučujeme provést následující kroky:

• Konfigurace pravidel ochrany větví: Vytvořte pravidla, která vyžadují kontrolu před sloučením požadavků na stažení, zejména do kritických větví.
• Ochrana prostředí: nastavte pravidla pro ochranu prostředí, abyste mohli řídit nasazení, například povolte nasazení pouze z chráněných větví.
• Zabezpečení citlivých dat v prostředí: Uchovávejte všechna citlivá data v prostředí a omezte přístup pouze na schválené úlohy.
• Použití sad pravidel úložiště GitHub: poskytují správcům organizace lepší kontrolu a funkce, jako je jednotná konfigurace a cílení na větve. (https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your- repository/managing-rulesets/about-rulesets)
• Požadovaný pracovní postup analýzy kódu: Implementujte požadovaný pracovní postup pro statickou analýzu kódu u žádostí o stažení ve všech pobočkách organizace.

Artifactory - nasazení zranitelných artefaktů

Dalším bodem bylo objasnění zranitelnosti ve způsobu správy a nasazování artefaktů. Pokud by se tento problém neřešil, mohl by připravit půdu pro významné bezpečnostní hrozby v produkčních prostředích.

Zranitelnost:

Během procesu nasazování artefaktů uložených v databázi Artifactory jsme zjistili, že artefakty, dokonce i ty s kritickými nebo vysoce zranitelnými místy, lze nasadit do produkčního prostředí bez jakéhokoli ověření před nasazením. Tato chyba v procesu ověřování ponechává produkční prostředí otevřené potenciálnímu narušení bezpečnosti.

Artifactory X-ray: node. Js webshell docker image obsahující kritickou zranitelnost. Později nasazen do produkce.

Uvědomujeme si, že zablokování všech zranitelných artefaktů by mohlo narušit proces sestavení/nasazení a mohlo by mít komerční důsledky. Nicméně tyto zranitelnosti by měly být před nasazením alespoň zkontrolovány a schváleny, aby se snížilo riziko zanesení bezpečnostních chyb do produkčního prostředí.

Dopad:

• Potenciální důsledky nasazení zranitelných artefaktů jsou dalekosáhlé a alarmující:
• Zvýšené riziko kybernetických útoků: nasazení artefaktů se zranitelnostmi přímo do výroby zvyšuje pravděpodobnost kybernetických útoků.
• Ohrožení obchodních operací: zneužití kritických zranitelností by mohlo narušit nebo dokonce ohrozit klíčové obchodní operace.
• Nesoulad s předpisy: takové postupy mohou být v rozporu s oborovými normami nebo předpisy, které nařizují účinnou správu zranitelností a záplat.

Řešení:

Ke zmírnění těchto rizik se důrazně doporučují následující opatření:

• Proces skenování zranitelností: implementujte proces, který před nasazením do produkčního prostředí prověří všechny artefakty na přítomnost závažných nebo kritických zranitelností. Tento proces by měl zahrnovat povinné schválení nasazení artefaktů se zjištěnými zranitelnostmi.
• Použití nástroje Xray: V nástroji Xray nakonfigurujte zásady pro identifikaci problémů s vysokou/kritickou zranitelností. Zpočátku se vyhněte činnostem, jako je selhání sestavení nebo zabránění stahování, ale zaměřte se na třídění jednotlivých porušení.
• Komplexní správa záplat: implementujte robustní systém správy záplat, který zajistí včasné odhalení, vyhodnocení a opravu zranitelností v artefaktech.

Závěr:

Naším cílem bylo obejít všechna bezpečnostní opatření a nasadit škodlivý kód do produkčního prostředí s přístupem ke konfiguraci OCP4, pokud by celá linka CI/CD s přiděleným prostorem v clusteru.

Zjistili jsme, že scénář je proveditelný pomocí řetězce chybných konfigurací a zranitelností, které jsou konkrétně popsány v následujících částech:

• Github - Neoprávněné obcházení mechanismů ochrany větví
• Github - povolená výchozí konfigurace úložiště a chybějící mechanismy řízení toku dat
• Artifactory - nasazení zranitelných artefaktů

Nakonec se nám podařilo nasadit škodlivou aplikaci - NodeJS webshell do produkčního prostředí v rámci clusteru OCP4. Chceme tím poukázat na důležitost odpovědnosti vývojářů a na to, že kombinace malých zranitelností může vyústit v kritickou situaci, kdy může být ohrožena veškerá tvrdá práce a bezpečnost klientů.

Nejste si jisti bezpečností vaší pipeline? Otestujte to s námi.