Geautomatiseerde CI/CD-pijplijnen (Continuous Integration/Continuous Delivery) worden gebruikt om de ontwikkeling te versnellen. Het is geweldig om triggers of planningen te hebben die uw code nemen, samenvoegen, bouwen, testen en automatisch verzenden. Omdat ze echter zijn gebouwd voor snelheid en gebruiksgemak, betekent dit dat de meeste pijpleidingen niet inherent zijn gebouwd met het oog op veiligheid. Omdat de pipelines meestal toegang moeten hebben tot internet om afhankelijkheden te downloaden, en om uw verschillende geheimen te uploaden naar uw productieomgeving, betekent dit dat zodra een dergelijke pipeline wordt gecompromitteerd, de aanvaller een breed scala aan opties heeft om uw werking te verstoren of informatie of geheimen te exfiltreren.
Alle verhalen in dit artikel beschrijven inbreuken op prominente CI/CD-tools. Het feit dat de meeste bedrijven op dergelijke tools vertrouwen, betekent dat, net als vele andere software supply chain-aanvallenHet enige wat de slechte acteurs nodig hebben is een enkel doelwit te doorbreken om een enorme ontploffingsradius te krijgen.
Laten we eens kijken naar enkele prominente verhalen van de afgelopen jaren die de kwetsbaarheden aantonen die inherent zijn aan deze aanvalsvector. Aan het einde van dit artikel zal ik zeker mijn aanbevelingen doen om uw pijpleidingen te verharden en te beschermen, ongeacht welke tools u gebruikt.
De CircleCI-inbreuk
In januari 2023 maakte CircleCI, een platform voor continue integratie en levering, een inbreuk op de beveiliging waardoor een aanvaller ongeautoriseerde toegang kon krijgen tot de infrastructuur van het bedrijf. De aanval werd geïnitieerd door een phishing-e-mail die een werknemer ertoe verleidde zijn inloggegevens te delen, die de aanvaller vervolgens gebruikte om toegang te krijgen tot de systemen van het bedrijf. De werknemer maakte gebruik van 2FA, maar de aanvaller kon een sessiecookie bemachtigen zodra de werknemer al bij het systeem was ingelogd, waardoor hij zich kon voordoen als de werknemer en uiteindelijk de toegang tot een subset van de productiesystemen van CircleCI kon escaleren.
De aanvaller heeft toegang gekregen tot bepaalde klantgegevens, waaronder namen, e-mailadressen en factuurgegevens. Het bedrijf meldde dat er geen toegang was tot code of intellectueel eigendom en dat geen enkele klant enige ongeoorloofde toegang tot hun accounts of gegevens meldde.
CircleCI reageerde snel op de inbreuk, voerde een onderzoek uit en werkte samen met wetshandhavings- en cyberbeveiligingsexperts om de omvang van de aanval te identificeren en de kwetsbaarheden te verhelpen waardoor deze kon plaatsvinden. Het bedrijf heeft ook alle inloggegevens van medewerkers en klanten gereset en aanvullende beveiligingsmaatregelen geïmplementeerd, zoals een betere monitoring van zijn systemen.
DevOps verstoord: de Argo CD-beveiligingsinbreuk
Argo CD is een populaire open-sourcetool voor de continue implementatie van applicaties op Kubernetes-clusters. In februari 2022 werd een er is een nieuwe kwetsbaarheid ontdekt in Argo CD waarmee niet-geverifieerde gebruikers toegang konden krijgen tot gevoelige informatie over Kubernetes-applicaties die door de tool worden beheerd. Het beveiligingslek werd veroorzaakt door een verkeerde configuratie in de API-server van Argo CD, waardoor ongeautoriseerde gebruikers verzoeken aan de API konden uitvoeren en informatie konden ophalen, zoals geheimen, configuraties en metagegevens van applicaties. Zolang de aanvaller toestemming had om applicaties te maken of bij te werken en het volledige pad naar een bestand met een geldige YAML kende of kon raden, konden ze een kwaadaardig Helm-diagram maken en YAML-bestanden als waarden blijven gebruiken totdat ze een sappig stukje gegevens vonden dat normaal gesproken ontoegankelijk zou zijn.
De kwetsbaarheid kreeg een CVSS-score van 7.5 (hoog ernst) en trof alle versies van Argo CD tot en met versie 2.1.4. Argo CD heeft in versie 2.1.5 een patch voor de kwetsbaarheid uitgebracht en gebruikers werd geadviseerd zo snel mogelijk naar deze versie te upgraden.
De kwetsbaarheid werd bijzonder zorgwekkend geacht omdat Argo CD vaak wordt gebruikt om kritieke applicaties en infrastructuur in productieomgevingen te beheren. Door het lekken van gevoelige informatie had een aanvaller toegang kunnen krijgen tot gevoelige gegevens of andere kwaadaardige acties kunnen ondernemen die de beschikbaarheid of veiligheid van de applicaties zouden kunnen beïnvloeden.
Het blootleggen van de Codecove-inbreuk: geleerde lessen
Codecov is een tool voor het volgen en analyseren van codedekking die wordt gebruikt in CI/CD-pijplijnen waarmee ontwikkelaars de effectiviteit van hun tests kunnen meten en analyseren. Zoals gepubliceerd in Codecov's Beveiligingsupdate:
“Op donderdag 1 april 2021 vernamen we dat iemand zich ongeautoriseerd toegang had verschaft tot onze Bash-uploader script en wijzigde het zonder onze toestemming. De acteur kreeg toegang vanwege een fout in het Docker-imagecreatieproces van Codecov, waardoor de acteur de inloggegevens kon extraheren die nodig zijn om ons Bash Uploader-script aan te passen.”
De Bash Uploader wordt door klanten gebruikt om hun codedekkingsrapporten naar het Codecove-platform te uploaden. Met deze toegang heeft de aanvaller het Bash Uploader-script aangepast door kwaadaardige code toe te voegen die tijdens het uploadproces omgevingsvariabelen, authenticatietokens en andere gevoelige gegevens van het systeem van de gebruiker verzamelde. Deze gegevens werden vervolgens naar een externe server gestuurd die door de aanvaller werd beheerd.
Volgens Codecove had de inbreuk gevolgen voor ongeveer 1% van het klantenbestand, waaronder grote bedrijven in de technologie-, financiële en gezondheidszorgsector. Het bedrijf bevestigde dat er tijdens de inbreuk geen klantcode of codedekkingsrapporten zijn gewijzigd, maar dat tokens voor gebruikersauthenticatie en andere gevoelige informatie mogelijk in gevaar zijn gekomen.
Codecove heeft onmiddellijk actie ondernomen om de kwaadaardige code te verwijderen en getroffen klanten te waarschuwen om hun authenticatietokens opnieuw in te stellen en andere beveiligingsmaatregelen te nemen. Het bedrijf startte ook een onderzoek naar het incident en schakelde samen met wetshandhavings- en cyberbeveiligingsexperts om de bron van de aanval te identificeren.
Hoe kunt u uw pijpleiding verdedigen?
Zoals hierboven vermeld, zijn CI/CD-pijplijnen gebouwd voor snelheid en automatisering, niet noodzakelijkerwijs voor veiligheid. Het feit dat drie grote en gerespecteerde bedrijven allemaal het slachtoffer zijn geworden van een of andere aanval, waarbij mogelijk de informatie van hun klanten openbaar wordt gemaakt, toont de kwetsbaarheid van uw eigen pijplijn en gegevens aan.
Welke tools of welk CI/CD-platform u ook gebruikt, u kunt een aantal dingen doen om uw beveiliging te verbeteren en de mogelijke schade te beperken als een kwaadwillende actor erin slaagt toegang te krijgen tot uw pijplijn of netwerk.
- Modellering van bedreigingen – Bedreigingsmodellering is een gestructureerde aanpak voor het identificeren van potentiële veiligheidsbedreigingen voor een systeem of applicatie en het ontwerpen van passende tegenmaatregelen om deze bedreigingen te beperken. Stel je als oefening voor dat iemand toegang heeft gekregen tot jouw pijpleiding. Tot welke omgevingen hebben ze nu toegang? Welke geheimen en sleutels kunnen ze zien en gebruiken? Kunnen ze je code aanpassen? Invloed testen? Bestanden van internet halen of een omgekeerde shell uitvoeren? Zelfs als u denkt dat u uw pijplijn hebt opgeschoond en de netwerktoegang op de juiste manier hebt gesegmenteerd, kan het geen kwaad om u dit voor te stellen en vervolgens te controleren, zodat u op de hoogte bent van een worstcasescenario. Het zal u misschien verbazen welke geheimen en toegangsopties in uw pijplijnplatform of tooling verborgen zijn.
- Netwerksegmentatie – Netwerksegmentatie is de praktijk waarbij een groter netwerk wordt opgedeeld in kleinere, veiligere subnetwerken of segmenten, elk met zijn eigen beveiligingscontroles en beleid. Het doel van netwerksegmentatie is om de veiligheid van het totale netwerk te vergroten door de omvang van een potentiële inbreuk op de beveiliging te beperken en de potentiële impact van een aanval te minimaliseren. Het opdelen van een netwerk in kleinere segmenten beperkt de zijdelingse beweging van aanvallers en verkleint het risico op ongeoorloofde toegang of gegevenslekken.
Met de toenemende populariteit van phishing-aanvallen kan al uw ontwikkelaars of andere werknemers het slachtoffer worden van een dergelijke oplichting – we zijn allemaal mensen. Ervan uitgaande dat de inloggegevens van uw ontwikkelaars door kwaadwillende actoren kunnen worden gebruikt, moet u ervoor zorgen dat de overgrote meerderheid van de ontwikkelaars niet het soort toegang krijgt waarmee ze in hun eentje geheimen kunnen exfiltreren, kwaadaardige code in een productie-image kunnen implanteren, of gewoon hun eigen versie van een productiecode onbetwist pushen. Het is tijdrovend om ervoor te zorgen dat elk individu zo min mogelijk toegang heeft voor zijn of haar werk, en de verleiding om iedereen gewoon beheerderstoegang te geven is groot. Laat je niet verleiden door de duistere kant – volg de regels van zero trust en minimale privileges. - Bewaken en waarschuwen – In navolging van het laatste punt: zelfs als u uw ontwikkelaars grondig hebt geoefend om phishing en andere social engineering-fraude te vermijden, kan er nog steeds een inbreuk plaatsvinden. Je weet niet wanneer of hoe, maar je moet er op zijn minst op voorbereid zijn om er meer over te weten te komen. Omdat de meeste pijplijnomgevingen kortstondig zijn, betekent dit dat zodra de klus is geklaard, er geen spoor van bewijs meer te vinden is over wat er is gebeurd, tenzij u zelf dergelijke sporen maakt.
Zorg ervoor dat u alles registreert wat er in uw pijplijnen gebeurt, bij elke uitgevoerde PR, samenvoeging, bouw en test. Zorg ervoor dat de gebruikersinformatie ook wordt geregistreerd, zodat deze kan worden beoordeeld als een probleem een dergelijke controle vereist. Eventuele wijzigingen in configuratiebestanden of de omgeving zelf moeten ook worden geregistreerd. Het doel hier is om een duidelijke autopsie uit te kunnen voeren op een breuk, zodat je kunt vertellen wat er is gebeurd en hoe. Bepaal vooraf welke gebeurtenissen een waarschuwing moeten rechtvaardigen en zorg ervoor dat de juiste mensen die waarschuwing krijgen. Zorg ervoor dat u mensen niet overspoelt met nutteloze of valse waarschuwingen; dat zou alertheidsmoeheid veroorzaken die er alleen maar toe zou leiden dat ze de waarschuwingen zouden negeren of veel later zouden reageren dan wenselijk was. Het is duidelijk dat geen van deze logboeken open geheimen of sleutels mag bevatten – wat leidt tot het volgende punt:
- Beheer van geheimen – Zorg ervoor dat u een of ander hulpmiddel voor geheimbeheer gebruikt. Het zou het op zijn minst gemakkelijker maken om uw geheimen en wachtwoorden te rouleren als er toch een inbreuk plaatsvindt. Het zou ook het werk moeten doen van het redigeren van open geheimen en toegangssleutels die in de pijplijn worden aangetroffen uit eventuele logboekregistratie op het systeem. Op geen enkel moment mag iemand die onbevoegd is toegang hebben tot dergelijke informatie en deze mag zeker niet worden gewijzigd.
Het beheer van geheimen wordt steeds belangrijker omdat organisaties steeds meer afhankelijk zijn van cloudgebaseerde services, containerapplicaties en andere gedistribueerde omgevingen die het veilig delen en beheren van geheimen tussen verschillende systemen en applicaties vereisen. - Gebruik het RBAC-principe gecombineerd met de minste privileges – Het principe van Role-Based Access Control (RBAC) is het verlenen van toegang tot systeembronnen op basis van de aan een gebruiker toegewezen rol of functie binnen een organisatie. In RBAC krijgen gebruikers rollen toegewezen die de machtigingen en toegangsrechten definiëren die zij hebben voor verschillende systeembronnen, zoals bestanden, mappen of toepassingen. Het principe van Least Privilege daarentegen is de praktijk waarbij gebruikers het minimale toegangsniveau en de minimale rechten worden verleend die nodig zijn om hun taken uit te voeren. Dit betekent dat gebruikers alleen toegang hebben tot de bronnen die ze nodig hebben om hun specifieke taken uit te voeren, en niet meer. RBAC en Least Privilege worden vaak samen gebruikt als complementaire beveiligingsprincipes. In RBAC krijgen gebruikers rollen toegewezen die het juiste toegangsniveau hebben tot de bronnen die ze nodig hebben om hun taken uit te voeren, en het principe van Least Privilege zorgt ervoor dat gebruikers alleen toegang hebben tot het minimale niveau aan bronnen dat nodig is om hun specifieke taken uit te voeren. Samen helpen deze principes bij het onderhouden van een veilig en goed beheerd systeem met een minimaal risico op ongeoorloofde toegang of datalekken. Als extra stukje beveiliging kunt u het zo instellen dat voor kritieke acties in het systeem meerdere gebruikersautorisaties nodig zijn. Deze aanpak moet met voorzichtigheid worden gevolgd, omdat deze het ontwikkelingswerk aanzienlijk kan vertragen. Voor kritieke updates, zoals het verwijderen van een hoofdvertakking of het wijzigen van een afhankelijkheidslijst, moet u het echter zo maken dat ten minste twee mensen met de juiste toegang deze moeten goedkeuren.
Uitkijken naar
Niemand zal stoppen met het gebruik van CI/CD en andere automatiseringstools om hun werk te versnellen. We leven in een wereld waarin we voortdurend streven naar steeds snellere code-updates. We moeten er alleen voor zorgen dat we dit op een veiligheidsbewuste manier doen en daarbij onze code en productieomgeving niet in gevaar brengen.
Een van de belangrijkste dingen die u kunt doen, is nadenken over wat er kan gebeuren als onbevoegden toegang krijgen. Zodra u zich bewust wordt van het gevaar en de verschillende plaatsen in uw pijpleidingen en netwerk die kwetsbaar zijn, vertrouw ik erop dat u de juiste stappen kunt nemen om de potentiële lekken te dichten.
Scribe is een beveiligingsbedrijf voor softwaretoeleveringsketens waarvan het platform is ontworpen om u transparantie te bieden over wat er gebeurt in uw ontwikkelingsproces en pijplijn. Voor meer informatie over hoe Scribe u kan helpen uw pijpleidingen te beveiligen contact met ons op..
Deze inhoud wordt u aangeboden door Scribe Security, een toonaangevende aanbieder van end-to-end software supply chain-beveiligingsoplossingen die state-of-the-art beveiliging levert voor codeartefacten en codeontwikkelings- en leveringsprocessen in de software supply chain. Meer informatie.