Wat kan er misgaan met CI/CD pipelines?

Continue integratie en continue levering (CI/CD) pipelines vormen de basis van elke softwareorganisatie die software op een ‘moderne’ manier bouwt. Automatisering biedt veel kracht, maar de meeste ontwikkelaars missen de verantwoordelijkheid die dit met zich meebrengt.

Ontwikkelaar: Ja, dat nemen we CI/CD veiligheid serieus nemen en een sterke controle uitoefenen op codebeheerders, beoordeling commits vóór fusies; banen en pipelines worden onderhouden door senior personeel, zij zorgen ervoor dat er geen geheimen in de lekken pipelineS. En de tool werd geïnstalleerd door personeel dat er verstand van heeft. Wat kan verkeerd gaan?

Beste ontwikkelaar, CI/CD systemen zijn complex. Het brede aanvalsoppervlak trok kwaadaardige actoren aan. Wees voorzichtig en wees nooit overmoedig.

Standaardconfiguratie wordt soms behouden en wordt de beste vriend voor hackers. Kritieke fouten kunnen aanwezig zijn in CI/CD pipeline bronnen, in de configuratie van het systeem, of rond het proces en de context van de pipeline en hoe het wordt geactiveerd.

In deze post zullen we onszelf in de schoenen van de slechte acteurs plaatsen. Stel je voor dat we de overpeinzingen van M3M3N70 (Memento Mori?) en Moeras woede ergens op het dark web, waarschijnlijk in een niet-westerse taal, maar mis nooit dat het kwaad zich wereldwijd verspreidt.

 

In de goede oude tijd was het zo gemakkelijk...

M3M3N70: Terug naar de goede oude tijd was ons bedrijf zó eenvoudig... Zero-days waren laaghangend fruit, apps stonden wijd open met gemakkelijk te exploiteren kwetsbaarheden, en we konden in een handomdraai lateraal bewegen.

Moeras woede: Fu#@Hell! Sommigen hadden er nog geen verstand van, maar de dingen veranderden. De grote jongens besteedden veel aandacht aan die AppSec-shit.

M3M3N70: Ja. Maar de nieuwe dwazen zijn de devs. Voor ons is het makkelijker geworden om te gaan voor de tools die deze jongens gebruiken. De CI is in het bijzonder een goudmijn! Cloud access tokens, SCM inloggegevens, wachtwoorden voor productiedatabases, SSH-privésleutels, inloggegevens van andere CI-gebruikers... Van de saaie dev-dingen naar de echte kern springen was vrij triviaal.

Automatisering voor het bouwen, testen en implementeren van software met een CI/CD tool moet vaak geheimen in stappen doorgeven aan opdrachten. En vaak worden ze gelekt, met beruchte gevolgen.

PipelineZe hebben geheimen nodig die soms worden gelekt

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

Misschien was de goede oude tijd te vinden in de geschiedenis van Git an .env bestand (de ontwikkelaar vergat het toe te voegen aan .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

die werd gebruikt in een GitHub-workflow .github/deploy.yaml dat bevatte zoiets als dit:

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: wauw! Die aws-toetsen werkten! We hebben eerst een onschuldige wijziging in de app getest en vervolgens de angel toegevoegd omdat die jongens zich er niet van bewust leken. Bingo! Wat een campagne...

De slechterik gebruikte simpelweg de AWS-sleutels om een ​​aangepaste applicatie met malware te uploaden en voerde vervolgens de opdracht Deploy uit met dergelijke inloggegevens. De gelekte geheimen, samen met de informatie in de pipeline. “Wat een campagne!” betekent waarschijnlijk dat Memento grote schade heeft aangericht aan het arme slachtoffer.

Wat Memento ons hier vertelt, is dat zodra er een geheim lek heeft plaatsgevonden, zoals AWS-toegangssleutels in het voorbeeld, je het geheim moet intrekken (de bovenstaande sleutels draaien) per direct. Er is altijd een belichtingsvenster tussen het lekken commit en de geheime invalidatie; het herschrijven van de Git-geschiedenis is moeilijk (zelfs de strengste autoritaire staat probeerde een dergelijke geschiedenisherschrijving tevergeefs) en waarschijnlijk ineffectief (onze vrienden hadden misschien vóór de repository gekloond met het geheime lek commit). Draai de sleutels onmiddellijk en bid terwijl u de activiteitenlogboeken voor het beoogde account leest tijdens de blootstellingsperiode!

Waarschijnlijk zouden organisaties dat wel moeten doen verbod op het gebruik van geheimen op lange termijn in CI/CD pipelinesen vervang ze door tijdelijke referenties. In het vorige voorbeeld met AWS-sleutels in GitHub-acties is het veiliger om een OpenID Connect (OIDC)-provider om kortstondige inloggegevens te verkrijgen die nodig zijn voor acties.

Moeras woede: Je had zoveel geluk! Lekkende scripts met hardgecodeerde sleutels waren vroeger gebruikelijk, zelfs op publiekelijk toegankelijke S3-buckets. Het enige wat je hoeft te doen is de objecten in de emmer doorkruisen en wat greppen doen om interessante dingen te vinden.

Soms was het gebied dat voor de implementatie werd gebruikt (een AWS S3-bucket in dit voorbeeld) open voor lezen door buitenstaanders, vanwege een configuratiefout (die onopgemerkt bleef). Wat Moeras woede gebruikt was zoiets als dit:

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

De bucket is waarschijnlijk gemaakt in een inrichtingssjabloon die automatisch kan worden gescand op beveiligingsfouten.

De standaardconfiguratie van de tool was speelgoed voor ons

Om concrete voorbeelden te geven, laten we het hebben over Jenkins, een van de populairste CI-tools.

Moeras woede: Herinnert u zich dat selectievakje 'Beveiliging inschakelen' in Jenkins, en hoeveel organisaties ervoor kozen dit voor het gemak niet te activeren? En deze "Iedereen kan alles doen'machtigingscombinaties als standaard? En die vervelende Jenkins-plug-ins, zoals de GitHub OAuth-plug-in? De man die het configureerde, selecteerde zowel “Lees-rechten verlenen aan alle geverifieerde gebruikers” als “Gebruik GitHub-repository-rechten”, waardoor we toegang kregen tot al hun projecten.

(Excuses, Jenkins, dat ik jou als voorbeeld heb gesteld 😉

Blijf bedreven (zelfs verslaafd) aan de beveiligingsprincipes. Eén is de Standaard beveiligd principe: controls moeten standaard de meest veilige instellingen hebben. Beveiliging moet ingebouwd zijn CI/CD gereedschappen en pipelineHet is van de grond af aan, in plaats van een bijzaak. Maar gebruiksvriendelijkheid en gemak botsen vaak met veiligheid.

Voor de zaak Jenkins is ingebouwde authenticatie te kwetsbaar: gebruik nooit de ingebouwde authenticatiemechanismen in Jenkins. Kies beter voor een mechanisme van derden (SAML, LDAP, Google …), met een op rollen gebaseerde autorisatiestrategie (“RBAC”) plug-in. En wees uiterst voorzichtig met de admin account.

Zorg voor hoe werk en pipeline bestanden in Jenkins worden afgehandeld. Hetzelfde met Configuratie-als-code-plug-in en de bijbehorende configuratiebestanden, die van toepassing zijn op de Jenkins-configuratie.

Verhuizen van zelf-gehoste CI/CD Door de overstap van systemen naar cloudgebaseerde SaaS-systemen worden enkele potentiële risico's geëlimineerd, waardoor laterale verplaatsing binnen het netwerk van de organisatie mogelijk wordt, maar worden er ook andere risico's toegevoegd, zoals het moeten openen van externe verbindingen tussen bestaande interne systemen en de geëxternaliseerde CI/CD en vermijd negatieve reviews.

Organisaties moeten oefenencisde nodige zorgvuldigheid bij het verharden van de CI/CD systeem, beginnend met de meest beperkende instellingen en geleidelijk opengaand met de minimaal vereiste machtigingen voor de pipeline stappen.

Beveiliging configureren in CI/CD tools kunnen een complexe prestatie zijn. Veel hebben plugins of extensies die de meeste kwetsbaarheden hebben en geüpdatet moeten worden.

Beveiligingsscanners voor dergelijke complexe tools of benchmarks kunnen hierbij helpen.

Code invoegen pipeline commando's voor plezier en winst

M3M3N70: Heeft u ooit Untrusted Code Checkouts gebruikt, waarbij kwetsbare acties en scripts kwetsbaar zijn voor opdrachtinjectie?

Uit dit gedeelte blijkt dat de pipeline zelf kan codeerfouten bevatten die slechte actoren in staat stellen willekeurige code-uitvoering in de pipeline zonder de pipeline bron zelf. Gebruik bijvoorbeeld een PR

Een eerste voorbeeld van een ongelukkige GitHub-workflow:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

De combinatie van pull_request_target workflow-trigger met een expliciete check-out van een niet-vertrouwde PR is een gevaarlijke praktijk die kan leiden tot compromittering van de repository. In het voorbeeld is de ongelukkige combinatie van:

• pull_request_target gebeurtenis, die standaard schrijfrechten heeft voor de doelrepository en doelrepositorygeheimen, zelfs van externe forks, en wordt uitgevoerd in de context van de doelrepository van de PR,
• bekijk de PR-code van de bron, niet-vertrouwde repository,
• activeer elk script dat kan werken op PR-gecontroleerde inhoud, zoals in het geval van npm installen
• geen voorwaarde gebruiken voor de triggering pull_request_target gebeurtenis wordt alleen uitgevoerd als er een soort 'deze PR is doorgelicht'-label is toegewezen aan de PR (externe gebruikers kunnen geen labels aan de PR toewijzen).

Een tweede voorbeeld is niet-vertrouwde invoer (van een probleem, opmerking of pull request) als bron voor argumenten die aan een pipeline opdracht via expressies. Dit is de pipeline versie van de kwetsbaarheid voor het injecteren van commando's in het besturingssysteem.

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

De run-bewerking genereert een tijdelijk shell-script op basis van de sjabloon, met $ vervangen, waardoor het kwetsbaar wordt voor shell-commando-injectie. Een aanvaller met een nep GitHub-account kan een probleem met een titel veroorzaken a"; bad_code_goes_here;#, en boem! 

Moeras woede: Oh, die jongens openden de deur voor commando-injectie door simpelweg een probleem te openen…

Er waren kwetsbaarheden bij het uitvoeren van code in GitHub-acties, zoals gajira-commentaar, nu opgelost. Gelieve te lezen “Niet-vertrouwde invoer in GitHub-workflows” voor meer informatie.

Het moraal van het verhaal: Ga nooit af en bouw PR's op van onbetrouwbare bronnen zonder eerst de PR te bekijken. 'Niet vertrouwd' hier, tenzij onder draconische authenticatie van de herkomst, zou elk potentieel gekaapt ontwikkelaarsaccount kunnen betekenen.

 

Onbedoelde malware-implementatie hier!

Continue inzet is de automatiseringsclimax, maar die climax kan worden gefrustreerd door het ontbreken van passende goedkeuringscontroles op de pipeline stromen.

De risico’s van volledig geautomatiseerde inzet vanaf de bron commit aan productiesystemen omvatten de mogelijkheid dat kwaadaardige code in productieomgevingen wordt geïmplementeerd zonder dat deze wordt gedetecteerd, evenals de mogelijkheid dat fouten in het implementatieproces verstoringen of uitval veroorzaken.

Om deze risico's te beperken, wordt organisaties vaak aanbevolen een ‘hard break’ in hun implementatieproces te implementeren menselijke goedkeuring voordat releases worden geïmplementeerd in eindomgevingen.

Ze sluiten de deuren

Moeras woede: Die vrolijke standaardwachtwoorden in CI/CD gereedschappen worden weggeveegd. Toegang tot de /var/lib/jenkins/secrets/initialAdminPassword is nu een dood spoor. Veel tools bieden nu 2FA, die Covid populair heeft gemaakt, en zelfs de meest luie code-aap die er is, gebruikt het!

M3M3N70: We vechten tegen 2FA, maar zo eenvoudig is het niet. Het is moeilijk om die jongens te spear-phishen, zoals “Scatter Swine” deed het met Twilio. Met WebAuthn-sleutels is het veel moeilijker. Dat kunnen we tenminste proberen cookies stelen om MFA te omzeilen, maar moet inbreken in de ontwikkelaarsbox.

Multi-Factor Authenticatie is een goede stap in de goede richting om het risico op lekken van authenticatiegeheimen te beperken. De meeste moderne DevOps-tools ondersteunen MFA. En authenticatiesleutels onder WebAuthn / U2F (zie FIDO2-project) zijn misschien wel de beste optie voor MFA in DevOps, mits goed beheerd.

Moeras woede: De DevOps-jongens worden wakker. Ze hebben het verdomde ‘minste privilege’ in hun bloed. En het zijn geen code-apen meer. We worden nu op heterdaad betrapt door recensenten.

Eigenlijk, pipelines zijn nu een beetje robuuster dan een paar jaar geleden, waarbij zwakke acties en scripts zijn verwijderd en met extra beveiligingsteststappen die zelfs onze droppers hebben gedetecteerd die verborgen waren in stealth commits en pakketten die we hebben gekaapt.

Vraag voor de lezer: is het proces van het bouwen van de software vanuit bronnen en het implementeren in productie een risicovolle onderneming? Zie jij jouw DevOps in de fase van goede tijden voor de slechteriken?

Laatste aanbevelingen

Waar te beginnen CI/CD pipelines?

De eerste aanbeveling is hier eenvoudig: voorzichtig beoordelen pipelines (zij zijn kritisch bronnen) voor beveiligingsproblemen. Recensies zijn kostbaar, maar noodzakelijk en moeten op de juiste manier worden uitgevoerd. Recensenten moeten weten waar ze naar moeten kijken. Elke stap moet worden gecontroleerd op gebreken.

Misschien kan een combinatie van deskundige reviewers, gewapend met geautomatiseerde scanners voor kwaadaardige code, helpen.

De tweede aanbeveling is om train ontwikkelaars die schrijven pipelines en onderhoud ze op beveiliging. Dingen om te overwegen:

• Hoe u op de juiste manier omgaat met authenticatie bij interne en cloudservices, waarbij u de hinder van het omgaan met inloggegevens voor de lange termijn vermijdt.
• Hoe te beperken pipelines naar de exacte set bronnen waartoe het toegang nodig heeft. Het beginsel van de minste privileges schittert opnieuw.
• Hoe schrijf je de stappen die je moet maken pipelineHet is reproduceerbaar zoals het vastzetten van versies en het vermijden van kwetsbaarheden voor opdrachtinjectie.
• Hoe implementaties goedkeuren vanuit het beveiligingsperspectief (dat zijn andere!): welke beveiliging standards moeten worden gekoppeld en hoe overeenkomstige controles/poorten moeten worden toegevoegd in de pipelines.

Een derde aanbeveling is om configureer het CI/CD systeem met de nodige zorg. Sterke authenticatie, geen standaardwachtwoorden of onveilige instellingen, minimale rechten… Zorg voor kwetsbaarheden in geïnstalleerde plug-ins en extensies. Dit zou de focus kunnen zijn van de volgende berichten, houd het in de gaten.

De vierde aanbeveling is om benutten de CI/CD pipelines voor beveiligingsautomatisering. Broncodeanalyse (SAST), analyse van de broncompositie (SCA), scannen op lekken van geheimen, anti-malwaretools, containerbeveiligingsscanners of geautomatiseerde runtime-detectoren (DAST en malware) kunnen routinematig worden uitgevoerd op de pipeline. En uw organisatie kan dit afdwingen standardgaat over de dekking van beveiligingsscans in CI/CD.

Houd er rekening mee dat deze hulpmiddelen de beoordeling door deskundigen nog steeds niet uit het systeem verwijderen, anders zou u een vals gevoel van veiligheid kunnen hebben.

Als je bedreven bent in OWASP-toptien, is een leuk recent project de OWASP-Top 10 CI/CD Veiligheidsrisico.

Disclaimer Opmerking

(1) De voorbeelden in dit bericht gebruiken GitHub als SCM, AWS als cloudprovider en GitHub Actions of Jenkins als CI/CD tool. Ze zijn niet zwakker/veiliger dan hun alternatieven. Geen slechte persintenties! Deze tools zijn krachtig en moeten op de juiste manier worden gebruikt.

(2) M3M3N70 en Moeras woede zijn fictieve personages. Elke gelijkenis met personen of groepen, levend of dood, berust louter op toeval... of toch niet?

Om meer te lezen

• Haymore, A. et al. “10 echte verhalen over hoe we compromissen hebben gesloten CI/CD pipelines”. NCC Group, januari 2022.
• configure-aws-credentials GitHub-actie en OpenID Connect configureren in Amazon Web Services voor details over het uitvoeren van AWS-opdrachten voor implementatie in GitHub-workflows.
• Lobacevski J. “Uw GitHub-acties en workflows veilig houden Deel 1: Pwn-verzoeken voorkomen”. GitLab Beveiligingslab, december 2020.
• Lobacevski J. “Uw GitHub-acties en workflows veilig houden Deel 2: Niet-vertrouwde invoer”. GitLab Security Lab, januari 2021.
• OWASP. “OWASP-top 10 CI/CD Veiligheidsrisico's”. juli 2022.
• Saltzer J. & Schröder M. “De bescherming van informatie in computersystemen”. April 1975. Beveiligingsprincipes evolueerden met de technologie, maar 47 jaar later zijn de meeste S&S-ideeën nog steeds van kracht.
• Britse NCSC. “Beveilig de bouw en implementatie pipeline". UK National CyberSecurity Center, februari 2019.