An eisem viregten Artikel, Mir hunn gesinn, wéi een direkt Vergëftung erkennt a sech dovunner schützt Pipeline Ausféierung (D-PPE). Mir hunn och gesinn, wéi een dës Schwachstelle mat Hëllef vun Xygeni Scanner, souwéi e puer Schutzmechanismen.
Gëft gemaach Pipeline Ausféierung (PPE) gëtt produzéiert wann den Ugräifer d'Ännerunge maache kann pipeline Logik op zwou Aarte:
- Duerch d'Ännere vun der CI-Konfiguratiounsdatei (den pipeline) -> Direkt PSA (D-PPA)
- Duerch d'Ännere vu Fichieren, op déi vun der pipeline (zum Beispill: Skripter, op déi aus dem Inhalt referenzéiert gëtt) pipeline Konfiguratiounsdatei) -> Indirekt PSA (I-PPE)
An dësem Beitrag wäerte mir eis méi genau mat indirekter perséinlecher Schutzausrüstung beschäftegen. Mee virdrun, an als Ergänzung zu mengem viregten Beitrag, kucke mer eis als éischt un, wéi GitHub d'Ausféierung vun ... geréiert. pipelines a wat sinn d'Schutzmechanismen géint D-PPE.
Wéi schützt GitHub d'Ausféierung vun pipelineKënnt dat vu PRs?
Wéi funktionéiert GitHub wat d'Ausféierung vu modifizéierten pipelines?
geännert pipelines kënne vu Pushes oder Pull Requests (PR) an. Als wichteg Best Practice ass et staark recommandéiert, all direkten "Push" op eng geschützt Branche ze vermeiden an ... ze benotzen Pull Requests als Mechanismus fir eng gewëssen Iwwerpréiwung ze erzwingen, ier iergendeen bäigedroene Code akzeptéiert gëtt.
Pull Requests kann aus zwou verschiddene Quelle kommen:
- PRs kommen vun forcéiert ginn
- PRs kommen vun Agence
PRs vun forcéiert ginn kann entweder vun ëffentlechen or private Dépôten.
Well mir et mat PPE (Vergëftungsausrüstung) ze dinn hunn Pipeline Ausféierung), eisen Haaptpunkt ass net d'"Akzeptanz" vun engem PR, mä d'Ausféierung vun engem modifizéierten pipeline wärend dem Akzeptanz-/Genehmegungsprozess vum PR. Am Kär vun engem PPE-Ugrëff ass eng ongewollt Ausféierung vun engem "béiswëllegen" modifizéierten pipeline.
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.
PRs vun de Gabelen un ëffentlechen Rescht
GitHub erlaabt d'Konfiguratioun vum Verhalen bei der Veraarbechtung PRs, déi vu Forken an ëffentleche Repos kommen.
Wann e PR vun enger Fork kënnt, forcéiert GitHub ëmmer e gewësse Grad vun "Zoustëmmung", ier en ausgefouert gëtt. pipeline am Zesummenhang mat der PRDësen Niveau vun Zoustëmmung wiesselt vun enger schwaacher zu enger strikter Zoustëmmung.
At Organisatiounsniveau (Org>>Astellungen>>Aktiounen>>Allgemeng), kënnt Dir tëscht verschiddenen "Genehmegungs"-Optiounen wielen:
Déi strengst ass déi lescht ("D'Zoustëmmung vun allen externen Zesummenaarbechter verlaangen”) well GitHub ëmmer eng Genehmegung verlaangt, wann d'PR vu Forks vun externen Zesummenaarbechter kënnt.
Mä och an dësem strikte Fall gëtt et Ënnerscheeder tëscht Mataarbechter mat Lies- a Schreifrechter.
- Wann d'PR vun engem kënnt gelies Benotzer, den Ausféierung vun der pipeline ass GESTOPPT bis d'Ännerunge guttgeheescht goufen. Wann d'Genehmegung ok ass, dann déi geännert pipeline gëtt higeriicht.
- Wann d'PR vun engem kënnt schreiwen Benotzer, den Genehmegung ass net néideg an déi geännert pipeline gëtt ëmmer ëmgesat!!
Als Schlussfolgerung sinn PRs, déi vu Forks op ëffentleche Repositories kommen, liicht géint PPE geschützt. Et gëtt e gewësse Schutz géint extern (Lies-) Benotzer, awer näischt wat intern (Schreif-) Benotzer ugeet.
Wouriwwer PRs, déi vu Forken aus private Repos kommen?
PRs vun de Gabelen un private Rescht
An dësem Szenario bitt GitHub e puer nëtzlech Konfiguratiounsastellungen.
Déi uewe genannten Astellunge kënnen entweder op Uergel oder at repo Niveau.
Wéini keng Optioun ass ugeklickt, GitHub wäert froen fir Genehmegung an et wäert déi geännert net ausféieren pipelineDëst ass déi sécherst Konfiguratioun!!
d' onsécherst Konfiguratioun ass wann "Workflows vun enger Fork aus ausféieren pull request„ass iwwerpréiftAn dësem Fall, datselwecht fir Lies- a Schreifbenutzer, wäert Github automatesch déi geännert Funktioun ausféieren. pipeline!! An dës Situatioun kann nach méi verschlechtert wann"Schreiftoken vun der Fork un d'Workflows schécken pull requests"A"Geheimnisser a Variabelen vun der Fork un d'Workflows schécken pull requests„ sinn ugekräizt. Maacht dat net, ausser et ass kloer gerechtfäerdegt!!
Wann “Genehmegung fir Gabel erfuerderlech pull request workflows„ ass ugeklickt, gëtt déi uewe genannte Situatioun e bësse verbessert: GitHub freet ëm Genehmegung an ausféiert déi geännert Versioun net. pipeline fir de Liesbenotzer, awer et wäert et ëmmer nach fir e Schreifbenotzer ausféieren.
Gabelen gesinn, wat ass mat PRs aus Filialen?
PRs vun Agence
Fir dëst Szenario ze schützen, musst Dir Iech drop verloossen Reegele fir de Schutz vun der Filial.
Op Repository-Niveau kënnt Dir Branch-Schutzregelen fir all Branch erstellen. Dës Regele addéieren e puer Restriktioune fir d'Modifikatioun vu geschützte Branchen.
Och wann Dir eng Regel konfiguréiert fir "Verlaangt a pull request virun der Fusioun"A"Genehmegungen erfuerderen", déi modifizéiert pipeline gëtt automatesch beim Erstelle vun engem PR ausgeführtD'„Genehmegung“ gëllt nëmme fir d'Fusiounsaktioun.
Wat mat indirekter Vergëftung? Pipeline Ausféierung
Wéi mir uewe gesinn hunn, kann D-PPE mat Hëllef vun pull_request_target, awer et gëllt net fir I-PSA.
Wann Dir pull_request_target benotzt, ass den Standard-Checkout de Basiscode. Wann Dir awer e puer Kontrollen um bäigedroene Code (PR-Code) validéiere wëllt, musst Dir de PR-Code explizit auschecken. Dofir, wann de PR-Code e Shellskript geännert huet, dat vum ... opgeruff gouf pipeline, d'„Basis“ (sécher) pipeline wäert de "modifizéierten" Shellskript opruffen → Indirekt PPE!!
D'Léisung dofir ass e bësse méi komplizéiert (et gëtt kee magesche Mëttel wéi pull_request_target).
eis pipeline ass elo sécher fir D-PPE well mir pull_request_target benotzen. Mee et ass ëmmer nach vulnérabel fir I-PPE.
An eisem Testbeispill musse mir de PR-Code grondsätzlech ausprobéieren, fir de Build ze maachen, awer d'Tester ginn op dem Artefakt ausgefouert, deen vum Build generéiert gëtt.
Also .. Firwat kuckt Dir net béid Codebasen?
- De PR-Code vum Checkout aus, well et de bäigefügte Code ass, deen mir wëlle bauen an testen.
- Checkout Basiscode fir déi original Versioun vum Programm auszeféieren pipeline an d'Build/Test-Skripter
Dëst kéint gemaach ginn duerch dës Codebasen an ënnerschiddlech Ordner auscheckenDe Basiscode kéint am Root-Ordner ausgecheckt ginn, an de PR an engem aneren Dossier. An dësem Fall géife mir de Build an den Testskript vum Root-Ordner géint de Code ausféieren, deen an den neien Dossier placéiert ass.
Dëst ass natierlech eng einfach Léisung!! Mee, fir Léierzwecker géif ech gären eng zimlech interessant Variant aféieren (...)
GitHub workflow_run Ausléiser-Evenement
Nieft pull_request_target, GitHub bitt en aneren Trigger-Event un: workflow_runDëst Evenement erlaabt Ausféierung vun engem pipeline konditionéiert op eng aner pipelined'Ausféierung.
workflow_run an pull_request_target Ausléiser sinn an engem Aspekt ähnlech: béid ginn am privilegéierte Modus ausgefouert an, trotz de PR-Ännerungen, d'Basis pipeline gëtt higeriicht!!
Loosst eis eis aktuell kucken pipeline:
D'Baupartie ass sécher fir D-PPE, awer d'Testpartie ass nach ëmmer ufälleg fir I-PPE.
d' pipeline selwer ass sécher fir D-PPE wéinst dem pull_request_target ausléisen. Mä den Testschrëtt ass ëmmer nach vulnérabel fir I-PPE wéinst dem Opruff vun engem externen Shellskript.
Vermeiden vun I-PSA
Den Zweck vun der uewen pipeline ass de bäigedroe Code ze bauen an ze testen, andeems se sécher fir perséinlech Schutzausrüstung ass.
Also .. Firwat net opdeelen pipeline an zwee? Een fir ze bauen an een aneren fir ze testen..
- Déi 1. pipeline (CI bauen) géif Kuckt de PR-Code (fir en ze bauen), maacht de Build a generéiert en Artefakt.
- De 2ten pipeline (Test-CI) géif Kuckt de Basiscode (fir Ännerungen am Shell-Skript ze vermeiden). an déi originell Skripter géint den Artefakt ausféieren.
- Fir den Test-CI ze synchroniséieren pipeline fir NO dem Build CI auszeféieren pipeline, mir wäerten de benotzen workflow_run ausléisen.
Op dës Manéier:
- pipeline CI bauen is sécher zu deenen zwee D-PSA (wéinst pull_request_target) an I-PSA (well et de Shell-Skript net méi ausféiert).
- pipeline Test-CI ass och sécher zu deenen zwee D-PSA (wéinst workflow_run) an I-PSA (well et de Basiscode iwwerpréift fir den originelle Shell-Skript ze kréien)
Kucke mer eis de Code vun deenen zwee un pipelines no dësen Modifikatiounen …
1st pipeline (Build-CI):
2nd pipeline (Test-CI):
Wow… schéin Léisung!! Mee ….. Sinn mir sécher? Ech fäerten, datt net 😭
Tatsächlech hu mir eng nei Schwachstelle virgestallt!! Wéi eng? Dat ass den Thema vun eisem nächste Post 🙂 … Bleift drun!!
PS: Entschëllegt, ech kann net roueg bleiwen 🤐 ..Hutt Dir schonn dovunner héieren Artefaktvergëftung ? 😂
