Kontinuerlig integration/kontinuerlig utveckling (CI/CD) pipelines kan vara den farligaste potentiella attackytan i mjukvaruförsörjningskedjan, säger forskare, eftersom cyberattackare ökar sitt intresse för att söka efter svagheter.
Attackytan växer också: CI/CD-pipelines är alltmer en fixtur inom företagsprogramvaruutvecklingsteam, som använder dem för att bygga, testa och distribuera kod med hjälp av automatiserade processer. Men övertillstånd, brist på nätverkssegmentering och dåliga hemligheter och patchhantering plågar implementeringen av dem, vilket ger kriminella möjligheten att kompromissa med dem för att fritt kunna variera mellan lokala och molnmiljöer.
På Black Hat USA onsdagen den 10 augusti går Iain Smart och Viktor Gazdag från säkerhetskonsultföretaget NCC Group upp på scenen under "RCE-as-a-Service: Lärdomar från 5 år av verklig CI/CD Pipeline-kompromiss,” för att diskutera mängden framgångsrika supply chain-attacker de har genomfört i produktions-CI/CD-pipelines för praktiskt taget alla företag som företaget har testat.
NCC Group har övervakat flera dussin framgångsrika kompromisser av mål, allt från småföretag till Fortune 500-företag. Dessutom säkerhetsbuggar, säger forskarna att nya missbruk av avsedd funktionalitet i automatiserade pipelines har gjort det möjligt för dem att konvertera pipelines från ett enkelt utvecklarverktyg till remote code execution (RCE)-as-a-service.
"Jag hoppas att folk kommer att ge lite mer kärlek till sina CI/CD-pipelines och tillämpa alla eller åtminstone en eller två rekommendationer från vår session", säger Gazdag. "Vi hoppas också att detta kommer att väcka mer säkerhetsforskning i ämnet."
Tara Seals, Dark Readings chefredaktör för nyheter, slog sig ner med Viktor Gazdag, managing säkerhetskonsult för NCC Group, för att ta reda på mer.
Tara Seals: Vilka är några av de vanligaste säkerhetsbristerna i CI/CD-pipelines, och hur kan dessa missbrukas?
Viktor Gazdag: Vi ser regelbundet tre vanliga säkerhetsbrister som kräver mer uppmärksamhet:
1) Hårdkodade autentiseringsuppgifter i Version Control System (VCS) eller Source Control Management (SCM).
Dessa inkluderar skalskript, inloggningsfiler, hårdkodade referenser i konfigurationsfiler som lagras på samma plats som koden (inte separat eller i hemliga hanteringsappar). Vi hittar också ofta åtkomsttokens till olika molnmiljöer (utveckling, produktion) eller vissa tjänster inom molnet som SNS, Databas, EC2, etc.
Vi hittar också fortfarande referenser för att komma åt den stödjande infrastrukturen eller till CI/CD-pipeline. När en angripare väl får tillgång till molnmiljön kan de räkna upp sina privilegier, leta efter felkonfigurationer eller försöka höja sina privilegier eftersom de redan är i molnet. Med tillgång till CI/CD-pipeline kan de se bygghistoriken, få tillgång till artefakterna och hemligheterna som användes (till exempel SAST-verktyget och dess rapporter om sårbarheter eller molnåtkomsttokens) och i värsta fall, injicera godtycklig kod (bakdörr, SolarWinds) i applikationen som kommer att kompileras, eller få fullständig tillgång till produktionsmiljön.
2) Övertillåtande roller.
Utvecklare eller tjänstekonton har ofta en roll kopplad till sina konton (eller kan anta en) som har fler behörigheter än vad som behövs för att utföra jobbet som krävs.
De kan komma åt fler funktioner, som att konfigurera systemet eller hemligheter som gäller både produktions- och utvecklingsmiljöer. De kanske kan kringgå säkerhetskontroller, såsom godkännande av andra utvecklare, eller modifiera pipelinen och ta bort alla SAST-verktyg som kan hjälpa till att söka efter sårbarheter.
Eftersom pipelines kan komma åt produktions- och testmiljöer, om det inte finns någon segmentering mellan dem, kan de fungera som en brygga mellan miljöer, även mellan on-prem och moln. Detta kommer att tillåta en angripare att kringgå brandväggar eller andra varningar och fritt röra sig mellan miljöer som annars inte skulle vara möjliga.
3) Brist på granskning, övervakning och larm.
Detta är det mest försummade området, och 90 % av gångerna upptäckte vi en brist på övervakning och varning vid eventuella konfigurationsändringar eller användar-/rollhantering, även om granskningen var påslagen eller aktiverad. Det enda som kan övervakas är den framgångsrika eller misslyckade jobbsammanställningen eller konstruktionen.
Det finns också vanligare säkerhetsproblem, såsom bristande nätverkssegmentering, hemlig hantering och patchhantering, etc., men dessa tre exempel är startpunkter för attacker, som krävs för att minska den genomsnittliga tiden för upptäckt av intrång, eller är viktiga att begränsa attacksprängningsradie.
TS: Har du några specifika verkliga exempel eller konkreta scenarier du kan peka på?
VG: Några attacker i nyheterna som relaterade till CI/CD eller pipelineattacker inkluderar:
- CCleaner attack, Mars 2018
- Hembryggt, augusti 2018
- Asus ShadowHammer, Mars 2019
- CircleCI-intrång från tredje part, september 2019
- Solarwinds, December 2020
- Codecovs bash-uppladdningsskript, april 2021
- TravisCI obehörig åtkomst till hemligheter, september 2021
TS: Varför är svagheter i automatiserade pipelines problematiska? Hur skulle du karakterisera risken för företag?
VG: Det kan finnas hundratals verktyg som används i pipeline-steg och på grund av detta är den enorma kunskap som någon behöver känna till enorm. Dessutom har pipelines nätverksåtkomst till flera miljöer och flera referenser för olika verktyg och miljöer. Att få tillgång till pipelines är som att få ett gratis resepass som låter angripare komma åt alla andra verktyg eller miljöer kopplade till pipelinen.
TS: Vilka är några av de attacker som företag kan drabbas av om en motståndare skulle lyckas undergräva en CI/CD-pipeline?
VG: Attackresultat kan inkludera att stjäla källkod eller intellektuell data, backdooring av en applikation som distribueras till tusentals kunder (som SolarWinds), få tillgång till (och fritt röra sig mellan) flera miljöer som utveckling och produktion, både lokalt eller i moln eller båda.
TS: Hur sofistikerade behöver motståndare vara för att kompromissa med en pipeline?
VG: Det vi presenterar på Black Hat är inte nolldagssårbarheter (även om jag hittade några sårbarheter i olika verktyg) eller några nya tekniker. Brottslingar kan attackera utvecklare via nätfiske (kapning av sessioner, bypass av multifaktorautentisering, stöld av autentiseringsuppgifter) eller CI/CD-pipelinen direkt om den inte är skyddad och är vänd mot Internet.
NCC Group gjorde även säkerhetsanalyser där vi till en början testade webbapplikationer. Vad vi hittade är att CI/CD-pipelines sällan loggas och övervakas med varning, annat än mjukvarubyggandet/kompileringsjobbet, så brottslingar behöver inte vara så försiktiga eller sofistikerade för att äventyra en pipeline.
TS: Hur vanliga är dessa typer av attacker och hur bred av en attackyta representerar CI/CD-pipelines?
VG: Det finns flera exempel på verkliga attacker i nyheterna, som nämnts. Och du kan fortfarande hitta t.ex. Jenkins instanser med Shodan på Internet. Med SaaS kan brottslingar räkna upp och försöka brutalt tvinga lösenord för att få åtkomst eftersom de inte har multifaktorautentisering aktiverad som standard eller IP-begränsningar, och är vända mot Internet.
Med fjärrarbete är pipelines ännu svårare att säkra eftersom utvecklare vill ha åtkomst var som helst och när som helst, och IP-begränsningar är inte nödvändigtvis genomförbara längre eftersom företag går mot noll-trust-nätverk eller har ändrade nätverksplatser.
Pipelines har vanligtvis nätverksåtkomst till flera miljöer (vilket de inte borde) och har tillgång till flera referenser för olika verktyg och miljöer. De kan fungera som en brygga mellan on-prem och moln, eller produktions- och testsystem. Detta kan vara en mycket bred attackyta och attacker kan komma från flera ställen, även de som inte har något att göra med själva pipelinen. På Black Hat presenterar vi två scenarier där vi ursprungligen började med webbapplikationstestning.
TS: Varför förblir CI/CD-pipelines en blind fläck för företag?
VG: Mest på grund av bristen på tid, ibland bristen på människor, och i vissa fall bristen på kunskap. CI/CD-pipelines skapas ofta av utvecklare eller IT-team med begränsad tid och med fokus på hastighet och leverans, eller så är utvecklarna helt enkelt överbelastade med arbete.
CI/CD-pipelines kan vara mycket eller extremt komplexa och kan inkludera hundratals verktyg, interagera med flera miljöer och hemligheter och användas av flera personer. Vissa människor skapade till och med en periodisk tabellrepresentation av de verktyg som kan användas i en pipeline.
Om ett företag avsätter tid för att skapa en hotmodell för den pipeline de använder och de stödjande miljöerna kommer de att se sambandet mellan miljöer, gränser och hemligheter och var attackerna kan ske. Att skapa och kontinuerligt uppdatera hotmodellen bör göras, och det tar tid.
TS: Vad är några bästa metoder för att stärka säkerheten för rörledningar?
VG: Tillämpa nätverkssegmentering, använd minsta privilegieprincipen för att skapa roller, begränsa omfattningen av en hemlighet i hemlighetshantering, tillämpa säkerhetsuppdateringar ofta, verifiera artefakter och övervaka och varna om konfigurationsändringar.
TS: Finns det några andra tankar du vill dela med dig av?
VG: Även om molnbaserade eller molnbaserade CI/CD-pipelines är enklare, såg vi fortfarande samma eller liknande problem som övertillåtande roller, ingen segmentering, övergripande hemligheter och brist på varning. Det är viktigt för företag att komma ihåg att de också har säkerhetsansvar i molnet.
