Kontinuéierlech Integratioun a kontinuéierlech Asaz (CI/CD) pipelines spillen eng zentral Roll bei der Erliichterung vun enger rationaliséierter Softwareentwécklung. Awer, well dës pipelineWann et ëmmer méi wichteg gëtt, gëtt den Imperativ, se viru Schwachstelle ze schützen, ëmmer méi ausgeprägt. Dës detailléiert Enquête konzentréiert sech op d'Adresséiere vun engem prominente Risiko, deen an den OWASP Top-10 identifizéiert gouf. CI/CD Sécherheetsrisiken: Vergëft Pipeline Ausféierung (PPE).
Wat ass vergëft Pipeline Ausféierung (PPE)
Laut der OWASP Top-10 CI/CD Sécherheetsrisiken, "Gëft gemaach Pipeline Ausféierung (PPE) Risiko bezitt sech op d'Fäegkeet vun engem Ugräifer mat Zougang zu Quellkontrollsystemer – an ouni Zougang zu der Buildëmfeld – de Buildprozess ze manipuléieren andeems béiswëlleg Code/Kommandoen an de Build agebruecht ginn pipeline Konfiguratioun, wesentlech 'Vergëftung' pipeline a béiswëlleg Code als Deel vum Bauprozess auszeféieren"
An e puer Wierder, Vergëft Pipeline Ausféierung (PPE) gëtt produzéiert wann den Ugräifer kann änneren pipeline Logik.
Et ginn zwou Varianten:
- Direkt PSA (D-PSA): An engem D-PPE Szenario, Den Ugräifer ännert d'CI-Konfiguratiounsdatei an engem Repository, op dat se Zougang hunn, entweder andeems se d'Ännerung direkt op eng ongeschützt Remote Branch um Repo pushen, oder andeems se eng PR mat der Ännerung vun enger Branch oder enger Fork ofginn. Zënter dem CI pipeline D'Ausféierung gëtt duerch d'Kommandoen an der modifizéierter CI-Konfiguratiounsdatei definéiert, déi béiswëlleg Kommandoen vum Ugräifer lafen schlussendlech am Build-Knuet aus, soubal de Build fäerdeg ass. pipeline ausgeléist gëtt.
- Indirekt PSA (I-PSA): A bestëmmte Fäll ass d'Méiglechkeet vun D-PPE net fir e Géigner verfügbar, deen Zougang zu engem SCM Repository (z.B. wann de pipeline ass konfiguréiert fir d'CI-Konfiguratiounsdatei vun enger separater, geschützter Branche am selwechte Repository ze kréien). An esou engem Szenario, anstatt ze vergëften, pipeline selwer, en Ugräifer sprëtzt béiswëlleg Code an Dateien, op déi vum pipeline (zum Beispill: Skripter, op déi aus dem Inhalt referenzéiert gëtt) pipeline Konfiguratiounsdatei)
A béide Fäll, GitHub wäert déi geännert Datei ausféieren pipeline ouni datt eng virdrun Iwwerpréiwung oder Genehmegung néideg ass.
Fréizäiteg Detektioun vu perséinlecher Schutzausrüstung
Wéi kënne mir dës Zort vu Schwachstelle feststellen?
Kucke mer eis dëst Beispill un pipeline :
An den Inhalt vun engem Dummy-Shell-Skript (runtests.sh):
d' pipeline ass zimmlech einfach: säin Zil ass et, dem Rezensent e puer virleefeg Hiweiser fir den Pull Request (PR) Akzeptanzprozess:
- Et gëtt ausgeléist op pull_request (dh ëmmer wann e PR erstallt gëtt)
- Et kontrolléiert de PR-Code (dh de bäigefügte Code)
- Et wäert de Bau maachen
- Et wäert Tester op bäigedroenem Code ausféieren (z.B. andeems e Shell-Skript ausgefouert gëtt)
Schrëtt Nr. 3 (de Build maachen) an Nr. 4 (Test ausféieren) scheiteren, wann de Code net kompiléiert oder d'Tester net besteet. Dës Schrëtt sinn also eng néideg, awer net genuch Viraussetzung fir d'PR ze akzeptéieren. Wann et erfollegräich ass, iwwerpréift den Administrateur vum Repository de bäigedroene Code an, baséierend drop, akzeptéiert/ofleent/kommentéiert hien/si d'PR.
Xygeni Scanner
Xygeni bitt e CLI (den "Xygeni Scanner"), déi an en integréiert kënne ginn pipeline oder an enger Kommandozeil ausféieren. Den Xygeni Scanner veraarbecht d' pipelines fir op Schwachstellen ze kontrolléieren an, wann e GitHub PAT geliwwert gëtt, verbënnt et sech mat GitHub fir Schwachstellen op der Organisatiouns-/Repo-Niveau z'entdecken.
Xygeni Inventar
Wann mir Xygeni Scanner op dësem Repo ausféieren, entdeckt en e nëtzleche Set vu Ressourcen (den Xygeni Inventar). Den Inventar gëtt mat villen ënnerschiddlechen Zorten gefëllt CI/CD Verméigen, sou wéi:
- d' SCM System wou de Repo gespäichert ass
- d' SCM Plugins installéiert/benotzt
- d' Code-Repository selwer
- d' SCM Organisatioun wou de Repo gehéiert
- d' CI/CD Pipelines an Aarbechtsplazen
- d' CI/CD System lafen den pipelines
- IaC Ressourcen am Repo definéiert
- extern Ofhängegkeet
- etc ..
An eisem Beispill kënne mir den Inventar no engem spezifeschen Aktivatyp filteren (SCM- an CICD-bezunn Verméigen), sou datt mir gesinn, datt:
- SCM De System ass GitHub Cloud
- De Repo gëtt an der GitHub Cloud gespäichert a gehéiert enger spezifescher GitHub Organisatioun.
- Et ginn zwou pipelineugedriwwe vu GitHub (CI/CD System)
- all pipeline enthält ee spezifesche Schrëtt
Duerch d'Auswiel vun den uewe genannten pipeline mir kënnen e puer Schwachstelle gesinn:
- At pipeline Niveau, et ass ufälleg fir béid direkten an Indirekt PSA.
Mir kënnen d'Detailer vun deenen Vergëfte gesinn Pipeline Ausféierungsschwachstelle
Xygeni erkennt, datt et ufälleg fir D-PSA well et ausgeléist gëtt op engem Pull Request Event an et gëtt keng zousätzlech Sécherheetskontrollen, sou datt all Repository-Benotzer d'Ännerunge maache kann pipeline an dës Ännerunge ginn ouni Iwwerpréiwung oder Genehmegung duerchgefouert.
Am selwechte Sënn erkennt Xygeni och, datt et ufälleg fir I-PSA wéinst dem Opruff un de Shell-Skript vun der pipelineAll Repo-Benotzer kënnen de Shell-Skript änneren an dës Ännerunge ginn ouni Iwwerpréiwung oder Genehmegung ausgefouert.
Wëllt Dir méi wëssen?
Ausnotzung vu perséinlecher Schutzausrüstung
Fir d'PSA auszenotzen, betruechte mer e Szenario wou et gëtt zwou Zorte vu Repo-Benotzer:
- An intern Benotzer (en internen Entwéckler, deen un deem Repo schafft), mat Schreifrechter um Repo
- An externen Benotzer (en ausgelagerten Entwéckler, deen un deem Repo schafft, awer mat Liesrechter um Repo), d.h. net erlaabt de Repo ze branchéieren a gezwongen, un engem Fork ze schaffen.
Loosst eis virstellen, datt béid béiswëlleg Attacker sinn (oder vun engem béiswëllegen Akteur imitéiert ginn). De Repo enthält e Geheimnis a béid wëllen fir de Geheimnis vum Repository ze klauen an et un en Hacker-kontrolléierte Server schécken. Fir dat ze maachen, wäerte si de Vergëfte ausnotzen. Pipeline Ausféierungsschwachstelle vun der pipeline.
An zwou Fäll (externen an internen Benotzer) maachen si e Pull Request mat deene selwechte Modifikatiounen:
- d' pipeline an de Shell-Skript gëtt geännert ze maachen liest de Geheimnis aus der Ëmwelt an et op en Hacker-kontrolléierte Server schécken
Ännerunge kéinte wéi follegt sinn:
Béid Benotzer erstellen eng Pull Request mat de ModifikatiounenBei der Grënnung vun der PR, GitHub wäert béid Modifikatioune ausféieren (ouni Viraussetzung fir eng Iwwerpréiwung oder Genehmegung), wat zu Folgendem féiert:
Datselwecht gëllt fir Schreif- a Liesbenotzer, an zwou Fäll ginn D-PPE an I-PPE ausgeführt, mat dem Ënnerscheed, datt De Liesbenutzer kann net op d'Geheimnisser zougräifen. (!!!!)
Dëse Grond ass well, Am Fall vun engem PR, deen vun enger Fork kënnt, erlaabt GitHub keen Zougang zu de Repo-Geheimnisser. Och wann de Liesbenutzer d'Geheimnisser net liesen kann, kann hien/si ëmmer nach all aner Programm ausféieren. E typescht Beispill vun engem Attack ass d'Erstelle vu PRs, déi e Krypto-Miner eroflueden, sou datt de GitHub-Runner de Krypto-Miner ausféiert, wann e vergëfte ... ausféiert. pipeline.
Dëst ass natierlech keng sécher Ëmwelt!! Wat kéint de Repo-Administrateur maachen, fir dat ze vermeiden?
No e bëssen Googelen decidéiert de Repository-Administrateur, d'Ännerung ze maachen. pipeline ausgeléist ze ginn op engem pull_request_target Event. Firwat? Well pipelines ausgeléist op pull_request_target erlaben keng Ausféierung pipeline Modifikatioune, d.h. trotz all Ännerung vum Benotzer den "Original" pipeline gëtt higeriicht.
No eisem Beispill wäert den Ugrëff dee selwechte sinn wéi virdrun. Wat geschitt dann duerno pipeline Modifikatioun?
Wéi erwaart, D-PPE gëtt net ausgeféiert mee, well I-PPE nach ëmmer do ass, De Liesbenutzer kann elo op de Geheimnis vum Repository zougräifen!!!
Wat ass de Grond, firwat de Liesbenotzer elo Zougang zu Geheimnisser huet? Och wann den pipeline kann net geännert ginn, et ass ëmmer nach méiglech de Shell-Skript z'änneren. Wann eng pipeline op pull_request_target ausgeléist gëtt, gëtt et am privilegéierte Modus ausgefouert. so et wäert och de Shell-Skript sinn, wat dozou féiert, datt de Shell-Skript Zougang zu de Repo-Geheimnisser huet!!
Präventiv Moosnahmen
GitHub bitt e puer Moossname fir géint béiswëlleg PRs ze schützen.
Reegele fir de Schutz vun der Filial
Mat GitHub kënnt Dir Branch Protection Rules iwwer ausgewielte Branchen definéieren.
Fir Är geschützt Filialen kënnt Dir eng Politik spezifizéieren, déi verlaangt eng pull request virun der Fusioun (souwéi zousätzlech Konditiounen, wéi eng erfuerderlech Zuel vun Genehmegungen, Bewäertunge vun de Codeinhaber, etc.)
E puer Konditiounen, déi besonnesch Opmierksamkeet verdéngen, sinn:
- "Erlaabt spezifizéiert Akteuren, déi néideg Ufuerderungen ze ëmgoen pull requests".
- "Erlaabt net, déi uewe genannten Astellungen ze ëmgoen"
Wärend déi meescht Konditioune d'Politik verschäerfen, entspanen dës d'Politik an dat kéint eng Dier oppe fir béiswëlleg Aktivitéiten mat sech bréngen, zum Beispill am Fall wou Umeldungsinformatioune vun "privilegéierten" Akteuren geklaut ginn.
GITHUB_TOKEN-Rechter limitéieren (manner Privilegien)
Beschränkt d'GitHub-Token-Rechter nëmmen op déi néideg; op dës Manéier, och am Fall wou den Ugräifer et fäerdeg bréngt, Är ... ze kompromittéieren pipeline, si wäerten net vill maache kënnen.
Vermeit Stringinterpolatioun andeems Dir pipeline env Variablen
Wann Dir e puer Inputvariablen an Ärem pipeline, sollt Dir Iech bewosst sinn, datt se standardméisseg als "net vertrauenswierdeg" Donnéeën ugesi solle ginn (hiren Inhalt gëtt vum Endbenotzer kontrolléiert). Kuckt Net vertrauenswierdeg Aktiounen a Workflows sécher an Léiert Github Aktiounen.
Dir sollt ëmmer Ëmweltvariablen benotzen fir Inputvariablen an Skripter anzeféieren, anstatt Stringinterpolatioun ze benotzen.
Workflow-Ausféierungen an Ufuerderunge fir d'Zustimmung
fir ëffentlechen Repos, GitHub erlaabt et ze spezifizéieren wéi een mat "externen" PRs schafft.
D'Astellungen vun der GitHub Organisatioun ("Org >> Astellungen >> Aktiounen >> Allgemeng") loossen spezifizéieren, wéi extern PR'en verwalt ginn:
Standardméisseg verlaangt GitHub eng PR-Zoustëmmung fir Éischtkéiersbäiträger, wat béiswëlleg Ufroattacken méi komplizéiert mécht. Trotzdem kéint den Ugräifer d'Vertraue vun de Projetbetreiber gewannen, zum Beispill andeems hien onschëlleg bäidréit. pull request virum richtegen Ugrëff.
An dësem Sënn ass de Déi 3. Optioun (Zoustëmmung fir all extern Mataarbechter verlaangen) füügt e méi héije Kontrollniveau derbäi.
fir private Repos, GitHub bitt och hëllefräich Kontroll souwuel op Organisatiouns- wéi och op Repos-Niveau.
"Workflows ausféieren Pull Requests„(net standardméisseg ugeklickt) erlaabt et de Benotzer, Workflows vu Fork-PRs auszeféieren (mat engem GITHUB_TOKEN mat Liesrechter an ouni Zougang zu Geheimnisser). Wann dës Optioun zesumme mat der leschter ausgewielt gëtt („Genehmegung fir Fork PRs Workflows erfuerderen”), kënnt Dir eng ähnlech Politik wéi privat Repos erreechen (wéi uewe gewisen).
Wéi mir am PPE-Exploit vun engem Liesbenutzer gesinn hunn, erlaabt Workflows aus der Fork auszeféieren pull requests ass onsécher!!
Déi reschtlech Optiounen ("Schreiftoken vun der Fork un d'Workflows schécken pull requests"A"Geheimnisser a Variabelen un Workflows schécken vun for pull requests") de Sécherheetsniveau erofsetzen op Gabel-PRs ugewannt.
Dir kënnt dës Fork-Politik entweder op Organisatiounsniveau oder op Repo-Niveau definéieren. Wann d'Politik op Organisatiounsniveau deaktivéiert ass, kann se net op Repo-Niveau aktivéiert ginn. Awer wann d'Politik op Organisatiounsniveau aktivéiert ass, kann se op Repo-Niveau deaktivéiert ginn.
Begleedung
Mir hoffen, Dir hutt d'Konsequenze vun e puer pipeline ufälleg fir Vergëftung Pipeline Ausféierung. Et ass ze einfach fir commit eng vulnérabel pipeline, an et ass schwéier eng sécher ze schreiwen.
Et ass also ganz wäertvoll, den Xygeni Scanner ze benotzen, fir sech iwwer sou Schwachstelle bewosst ze sinn.
Dir kënnt e Vulner net léisen, ausser Dir sidd Iech vu senger Existenz bewosst!!
Mä… Et gëtt nach ëmmer eng Fro déi nach net ofgeschloss ass… Wéi kann een I-PPE vermeiden?
Dëst ass den Thema vun eisem nächste Post 🙂 … Indirekt Vergëftung Pipeline Ausféierung (I-PPE) !!
