Wat kann falsch goen CI/CD pipelines?

Kontinuéierlech Integratioun a kontinuéierlech Liwwerung (CI/CD) pipelines sinn d'Grondlag vun all Softwareorganisatioun, déi Software op eng "modern" Manéier baut. Automatiséierung bitt grouss Kraaft, awer déi meescht Entwéckler verpassen d'Verantwortung, déi se mat sech bréngt.

programméierenJo, mir huelen CI/CD Sécherheet eescht huelen an eng staark Kontroll iwwer d'Code-Ënnerhalter hunn, iwwerpréiwen commits virun Fusiounen; Aarbechtsplazen an pipelines gi vu Senior Mataarbechter ënnerhalen, si suergen dofir, datt keng Geheimnisser an der pipelines. An den Tool gouf vu Personal installéiert, dat sech mat der Saach auskennt. Wat kann falsch lafen?

Léiwen Entwéckler, CI/CD Systemer si komplex. Seng breet Attackfläch huet béiswëlleg Akteuren ugezunn. Sidd besser virsiichteg a sidd ni ze selbstsécher.

Standardkonfiguratioun gëtt heiansdo bäibehalen a gëtt zum beschte Frënd vun Hacker. Kritesch Feeler kënnen an CI/CD pipeline Quellen, an der Konfiguratioun vum System, oder ronderëm de Prozess an de Kontext vun der pipeline a wéi et ausgeléist gëtt.

An dësem Beitrag wäerte mir eis an d'Schong vun de schlechte Schauspiller setzen. Stellt Iech vir, mir géifen d'Gedanken vun ... liesen. M3M3N70 (Memento Mori?) an Sumpfrost iergendwou am däischteren Web, wahrscheinlech an enger net-westlecher Sprooch, awer vergiesst net, datt d'Béist weltwäit verbreet ass.

 

An de gudden ale Zäiten war et sou einfach…

M3M3N70Zréck an déi gutt al Zäiten war eist Geschäft sou einfach… Nulldeeg ware wéineg Sue fir eis, Apps ware wäit oppe mat einfach ausnotzbare Vulner, a mir konnten eis séier seitlech beweegen.

Sumpfrost: Fu#@Hell! E puer Verréckter sinn nach dobaussen, mee d'Saachen hunn sech geännert. Déi Grouss hunn vill Sue fir dee AppSec-Dreck investéiert.

M3M3N70Jo. Mee déi nei Narren sinn d'Entwéckler. Fir eis war et méi einfach, sech fir d'Tools ze entscheeden, déi dës Leit benotzen. Den CI, besonnesch, ass eng Goldminn! Cloud-Zougangs-Tokens, SCM Umeldungsinformatiounen, Passwierder fir d'Produktiounsdatebank, privat SSH-Schlësselen, d'Umeldungsinformatioune vun anere CI-Benotzer… De Sprong vun de langweilegen Entwécklungssaachen zum richtege Kär war zimmlech trivial.

Automatiséierung fir Software ze bauen, ze testen an ze deployéieren mat engem CI/CD Tools mussen dacks Geheimnisser a Schrëtt un d'Kommandoen weiderginn. An dacks gi se geleakt, mat berüchtegten Konsequenzen.

Pipelinebrauch Geheimnisser, déi heiansdo geleckt ginn

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.

Vläicht war et an der gudder aler Zäit, an der Git-Geschicht eppes ze fannen .env Datei (den Entwéckler huet vergiess se derbäizesetzen .gitignore):

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

déi an engem GitHub Workflow benotzt gouf .github/deploy.yaml déi sou eppes enthält huet:

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: wow! Déi AWS-Tasten hunn funktionéiert! Mir hunn als éischt eng onschiedlech Ännerung an der App getest, an duerno de Sting derbäigesat, well déi Leit schéngen et net bewosst ze sinn. Bingo! Wat eng Kampagne…

De béise Schauspiller huet einfach d'AWS-Schlësselen benotzt fir eng modifizéiert Applikatioun mat Malware eropzelueden an huet dann den deploy-Kommando mat dëse Login-Umeldungsinformatiounen ausgeféiert. Déi geleakt Geheimnisser, zesumme mat den Informatiounen, déi an der pipeline„Wat eng Kampagne!“ bedeit wahrscheinlech, datt Memento dem aarme Affer Chaos ugericht huet.

Wat Memento eis hei seet, ass datt wann e Geheimnisleck geschitt ass, wéi AWS Zougangsschlësselen am Beispill, musst Dir de Geheimnis zréckzéien (d'Schlësselen uewen rotéieren). direktEt gëtt ëmmer en Beliichtungsfenster tëscht dem Leck commit an déi geheim Ongëltegkeet; D'Git-Geschicht nei ze schreiwen ass schwéier (souguer dee stäerksten autoritäre Staat huet sou eng Geschicht nei geschriwwe probéiert, ouni Erfolleg) a wahrscheinlech ineffektiv (eis Frënn hätten et vläicht virum Archiv mam geheime Leak geklont commit). Dréit d'Tasten direkt a biet wärend Dir d'Aktivitéitsprotokoller fir de gezielte Kont während der Beliichtungsfenster liest!

Wahrscheinlech sollten Organisatiounen Verbuet d'Benotzung vu laangfristege Geheimnisser an CI/CD pipelines, an ersetzt se duerch temporär Umeldungsinformatiounen. Am virege Beispill mat AWS-Schlësselen a GitHub-Aktiounen ass et méi sécher, en ze benotzen OpenID Connect (OIDC) Ubidder fir kuerzfristeg Umeldungsinformatiounen ze kréien, déi fir Aktiounen néideg sinn.

SumpfrostDu hats sou vill Gléck! D'Lecke vu Skripter mat hardcoded Schlësselen war fréier üblech Praxis, och op ëffentlech zougänglechen S3 Buckets. Alles wat Dir maache musst, war d'Objeten am Bucket ze duerchsichen an e bëssen ze gripen fir interessant Saachen ze fannen.

Heiansdo war de Beräich, deen fir den Asaz benotzt gouf (an dësem Beispill en AWS S3 Bucket), op fir vun externen Benotzer ze liesen, wéinst engem Konfiguratiounsfehler (deen net entdeckt gouf). Wat Sumpfrost benotzt gouf eppes wéi dëst:

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 gouf wahrscheinlech an enger Provisioning-Schabloun erstallt, déi automatesch op Sécherheetslücken gescannt konnt ginn.

D'Standardkonfiguratioun vum Tool war e Spillsaach fir eis.

Fir konkret Beispiller ze ginn, loosst eis driwwer schwätzen Jenkins, ee vun de populäersten CI-Tools.

SumpfrostErënners du dech un déi Checkbox "Sécherheet aktivéieren" a Jenkins, a wéi vill Organisatiounen se aus Komfortgrënn net aktivéiere wollten? An déi "Jidderee kann alles maachen"Berechtegungskombinatiounen als Standard? An déi lästeg Jenkins-Plugins, wéi déi GitHub OAuth-PluginDee Mann, deen et konfiguréiert huet, huet souwuel "Grant LIES-Berechtigungen fir all authentifizéiert Benotzer" wéi och "Use GitHub Repository Permissions" ausgewielt, wat eis Zougang zu all senge Projeten gëtt.

(Entschëllegt, Jenkins, datt ech dech als Beispill gesat hunn 😉

Bleift adequat (och süchteg) mat Sécherheetsprinzipien. Ee vun hinnen ass den Séchert par défaut Prinzip: Kontrollen sollen als Standard déi sécherst méiglech Astellungen hunn. Sécherheet soll agebaut ginn CI/CD Tools an pipelines vun Null un, anstatt eng Niewegedanke ze sinn. Awer Benotzerfrëndlechkeet a Komfort kommen dacks a Konflikt mat Sécherheet.

Fir de Fall Jenkins ass déi agebaute Authentifikatioun ze fragil: Benotzt ni déi agebaute Authentifikatiounsmechanismen a Jenkins. Besser e Mechanismus vun Drëttpersounen (SAML, LDAP, Google ...) wielen, mat engem Plugin fir d'Role-baséiert Autorisatiounsstrategie ("RBAC"). A sidd extrem virsiichteg mat der admin Kont.

Passt op, wéi d'Aarbecht an pipeline Dateien a Jenkins ginn behandelt. Datselwecht mat Konfiguratioun-als-Code-Plugin an seng Configuratiounsdateien, déi fir d'Jenkins-Konfiguratioun gëllen.

Wiessel vun engem Selbsthosting-Service CI/CD D'Ëmwandlung vu Systemer op Cloud-baséiert SaaS-Systemer eliminéiert e puer potenziell Risiken, déi lateral Beweegunge bannent dem Organisatiounsnetz erméiglechen, awer füügt aner bäi, wéi d'Opmaache vun externen Verbindungen tëscht existente internen Systemer an den externaliséierten. CI/CD ze benotzen.

Organisatioune sollten sech beméiencise virsiichteg Betreiung beim Härten CI/CD System, ugefaange mat de restriktivsten Astellungen a lues a lues opgemaach mat de minimal erfuerderleche Rechter fir de pipeline Schrëtt.

Sécherheet konfiguréieren an CI/CD Tools kéinte komplex sinn. Vill hunn Plugins oder Extensiounen, déi déi meescht Schwachstelle hunn a mussen aktualiséiert ginn.

Sécherheetsfehlerkonfiguratiounsscanner fir sou komplex Tools oder Benchmarks kënnen hëllefen.

Code injizéieren pipeline Kommandoen fir Spaass a Profit

M3M3N70Hutt Dir jeemools Untrusted Code Checkouts benotzt, déi vulnérabel Aktiounen a Scripten, déi vulnérabel fir Kommando-Injektioun sinn?

Dës Sektioun weist, datt den pipeline selwer kéint Codefeeler hunn, déi et béiswëlleg Akteuren erméiglechen, arbiträr Codeausféierung anzeféieren pipeline ouni d'Ännerung vun der pipeline Quell selwerZum Beispill mat Hëllef vun engem PR

En éischt Beispill vun engem ongléckleche 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 ...

Kombinéieren pull_request_target En Workflow-Ausléiser mat engem expliziten Checkout vun engem net vertrauenswürdege PR ass eng geféierlech Praxis, déi zu enger Kompromëss vum Repository féiere kann. Am Beispill ass déi onglécklech Kombinatioun vun:

• pull_request_target Event, deen standardméisseg Schreifrechter zum Zil-Repository an den Zil-Repository-Geheimnisser huet, och vu externen Forks, a leeft am Kontext vum Zil-Repository vum PR,
• Kuckt de PR-Code vun der Quell, net vertrauenswürdege Repo,
• all Skript ausléisen, deen op PR-kontrolléierten Inhalter funktionéiere kann, wéi am Fall vun npm install, an
• keng Konditioun fir den Ausléiser benotzen pull_request_target D'Evenement leeft nëmme wann eng Zort 'dës PR gouf iwwerpréift' Label dem PR zougewisen ass (extern Benotzer kënnen dem PR keng Labels zouweisen).

En zweet Beispill hëlt net vertrauenswierdeg Input (vun engem Problem, Kommentar oder pull request) als Quell fir Argumenter, déi un e weidergeleet ginn pipeline Kommando iwwer Ausdréck. Dëst ass den pipeline Versioun vun der OS Command Injection Schwachstelle.

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

D'Ausféierungsoperatioun generéiert en temporärt Shellskript baséiert op der Schabloun, mat $ ersat, wat et vulnérabel fir Shell-Kommando-Injektioun mécht. En Ugräifer mat engem gefälschten GitHub-Kont kéint e Problem mat engem Titel erstellen a"; bad_code_goes_here;#, a bumm! 

SumpfrostOh, déi Leit hunn d'Dier fir d'Kommandoinjektioun opgemaach andeems se einfach en Thema opgemaach hunn...

Et gouf Schwachstelle bei der Codeausféierung a GitHub-Aktiounen, wéi z.B. gajira-Kommentar, elo reparéiert. Liest w.e.g. "Onverlässeg Input an GitHub Workflows" fir komplett Detailer.

D'Moral vun der Geschicht: Bestellt ni PRs aus net vertrauenswürdege Quellen a baut se op, ouni d'PR als éischt ze iwwerpréiwen. ''Net vertrauenswierdeg'' kéint hei, ausser ënner drakonescher Authentifikatioun vun der Proveniens, all potenziell gekaapte Entwécklerkont bedeiten.

 

Ongewollt Malware-Installatioun hei!

Kontinuéierlech Détachement ass den Automatiséierungs-Klimapunkt, awer dee Klimax kéint duerch de Manktem u passenden Genehmegungskontrollen op der pipeline ze fléissen.

D'Risike vun enger vollautomatiséierter Installatioun vun der Quell commit Zu de Konsequenze fir Produktiounssystemer gehéiert d'Méiglechkeet, datt béiswëlleg Code a Produktiounsëmfeld implementéiert gëtt, ouni erkannt ze ginn, souwéi d'Méiglechkeet, datt Feeler am Installatiounsprozess Stéierungen oder Ausfäll verursaache kënnen.

Fir dës Risiken ze reduzéieren, gëtt et dacks recommandéiert, datt Organisatiounen eng "Hard Break" an hirem Deployment-Prozess implementéieren, déi erfuerdert Mënsch Genehmegung ier Versiounen an Endëmfeld installéiert ginn.

Si maachen d'Dieren zou

SumpfrostDéi freudvoll Standardpasswierder an CI/CD Tools ginn ofgeläscht. Zougang zu /var/lib/jenkins/secrets/initialAdminPassword ass elo eng dout Streck. Vill Tools bidden elo 2FA, déi Covid populär gemaach huet, an och dee faulste Code-Aff benotzt et!

M3M3N70Mir kämpfen géint 2FA, awer et ass net sou einfach. Et ass schwéier, déi Leit mat Spearphishing ze beschimpfen, well „Scatter Swine“ huet et mam Twilio gemaachMat WebAuthn-Schlësselen ass et vill méi schwéier. Zumindest kënne mir probéieren Cookien klauen fir MFA ze ëmgoen, mee muss an d'Entwécklerbox briechen.

Multi-Faktor-Authentifikatioun ass e gudde Schrëtt an déi richteg Richtung fir de Risiko vu Leckage vun Authentifikatiounsgeheimnisser ze limitéieren. Déi meescht modern DevOps-Tools ënnerstëtzen MFA. An Authentifikatiounsschlësselen ënner WebAuthn / U2F (kuckt ... FIDO2 Projet) sinn vläicht déi bescht Optioun fir MFA an DevOps, wa se richteg geréiert ginn.

SumpfrostD'DevOps-Leit erwächen. Si hunn dat verdammt "mannst Privileg"-Ding am Blutt. A si sinn keng Code-Affen méi. Mir gi vun de Rezensenten op frëscher Dot erwëscht.

Tatsächlech, pipelines sinn elo e bësse méi robust wéi virun e puer Joer, mat ewechgehollene schwaache Aktiounen a Skripter, a mat zousätzleche Sécherheetstestschrëtt, déi souguer eis Dropper, déi am Stealth verstoppt waren, erkannt hunn. commits a Paketen, déi mir gekaapt hunn.

Fro un de Lieser: Ass de Prozess vum Opbau vun der Software aus Quellen an dem Asaz an der Produktioun e riskant Geschäft? Kënnt Dir Är DevOps an der Phase vun ... gesinn? al gutt Zäiten fir déi Béiser?

Schluss Recommandatiounen

Wou ufänken CI/CD pipelines?

Déi éischt Empfehlung ass hei einfach: Vorsicht iwwerpréiwen pipelines (si sinn kritesch Ressourcen) fir Sécherheetsproblemer. Iwwerpréiwunge si käschteg, awer néideg a sollten richteg duerchgefouert ginn. D'Iwwerpréiwer sollten wëssen, op wat se oppasse sollen. All Schrëtt muss op Mängel iwwerpréift ginn.

Vläicht kéint eng Kombinatioun vun Experten, déi mat automatiséierte Scanner fir béiswëlleg Coden bewaffnet sinn, hëllefen.

Déi zweet Empfehlung ass, Entwéckler ausbilden, déi schreiwen pipelines an halen se sécherSaachen, déi Dir berécksiichtege sollt:

• Wéi een d'Authentifikatioun mat internen a Cloud-Servicer richteg handhabt, fir d'Nout vum Ëmgang mat laangfristege Login-Adressen ze vermeiden.
• Wéi een limitéiere kann pipelines op déi genee Rei vu Ressourcen, op déi et Zougang brauch. De Prinzip vun de geringste Privilegien blénkt erëm.
• Wéi schreift een d'Schrëtt fir ze maachen pipelines reproduzéierbar wéi Versiounspinnen, an d'Vermeidung vu Kommando-Injektiounsschwachstellen.
• Wéi een Asätz aus der Sécherheetsperspektiv guttgeheescht (et sinn aner!): wéi eng Sécherheet standards solle passen a wéi een entspriechend Kontrollen/Gaten an derbäisetzt pipelines.

Eng drëtt Empfehlung ass, configuréieren der CI/CD System mat der néideger Suergfalt. Staark Authentifikatioun, keng Standardpasswierder oder onsécher Astellungen, minimal Rechter… Passt op Schwachstelle vun installéierte Plugins an Extensiounen op. Dëst kéint de Fokus vun de folgende Posts sinn, bleift w.e.g. um Lafenden.

Déi véiert Empfehlung ass, profitéieren der CI/CD pipelines fir SécherheetsautomatiséierungQuellcodeanalyse (SAST), Analyse vun der Quellzesummesetzung (SCA), kënnen d'Scanning vu Geheimleckagen, Anti-Malware-Tools, Container-Sécherheetsscanner oder automatiséiert Runtime-Detektoren (DAST a Malware) routineméisseg um ... ausgeführt ginn. pipelineAn Är Organisatioun kann duerchsetzen standardiwwer d'Ofdeckung vum Sécherheetsscannen an CI/CD.

Denkt drun, dës Tools huelen d'Expertenbewäertung awer net aus der Equatioun ewech, soss kéint Dir e falscht Sécherheetsgefill hunn.

Wann Dir Iech mat den OWASP Top-Ten auskennt, ass e flott rezent Projet den OWASP Top 10 CI/CD Sécherheetsrisiko.

Verzichterklärung Note

(1) D'Beispiller an dësem Beitrag benotzen GitHub als SCM, AWS als Cloud-Ubidder, a GitHub Actions oder Jenkins als CI/CD Tool. Si sinn net méi schwaach / méi sécher wéi hir Alternativen. Keng schlecht Pressabsicht! Dës Tools si mächteg a mussen entspriechend benotzt ginn.

(2) M3M3N70 an Sumpfrost sinn fiktiv Personnagen. All Ähnlechkeet mat Persounen oder Gruppen, lieweg oder dout, ass just Zoufall ... oder net?

Fir méi ze liesen

• Haymore, A. et al. 10 Geschichten aus der Praxis, wéi mir Kompromësser gemaach hunn CI/CD pipelines ”NCC Grupp, Januar 2022.
• configure-aws-credentials GitHub-Aktioun an OpenID Connect an Amazon Web Services konfiguréieren fir Detailer doriwwer, wéi een AWS-Kommandoen fir den Asaz a GitHub-Workflows ausféiere kann.
• Lobazewski J. „Är GitHub Aktiounen a Workflows sécher halen Deel 1: Pwn Ufroen verhënneren“GitLab Sécherheetslaboratoire, Dezember 2020.
• Lobazewski J. „Är GitHub Aktiounen a Workflows sécher halen Deel 2: Net vertrauenswierdeg Input“GitLab Sécherheetslaboratoire, Januar 2021.
• OWASP. "OWASP Top 10" CI/CD SécherheetsrisikenJuli 2022.
• Saltzer J. & Schroeder M. "De Schutz vun Informatiounen a Computersystemer"Abrëll 1975. Sécherheetsprinzipie hunn sech mat der Technologie entwéckelt, awer 47 Joer méi spéit bleiwen déi meescht S&S-Iddien a Kraaft.
• UK NCSC. "Séchert de Bau an d'Aféierung" pipeline"National Cybersécherheetszentrum vu Groussbritannien, Februar 2019.