Integratio Continua et Distributio Continua (CI/CD) pipelinepartes maximas agunt in faciliore evolutione programmatum. Attamen, cum hae pipelineCum res magis magisque necessariae fiant, necessitas ea a vulnerabilitatibus protegendi magis eminet. Haec investigatio profunda in periculo insigni, quod in OWASP Top-10 identificatum est, tractando intendit. CI/CD Pericula Securitatis: Venenatum Pipeline Executio (PPE).
Quid est venenatum? Pipeline Executio (PPE)
Secundum OWASP Top-10 CI/CD Pericula SecuritatisVenenatus Pipeline supplicium (PPE) periculum ad facultatem aggressoris cum accessu ad systemata moderationis fontis – et sine accessu ad ambitum constructionis – refertur. Ad processum constructionis manipulandum per iniectionem codicis/mandatorum malitiosorum in constructionem. pipeline configuratione, per se venenationem pipeline et codicem malitiosum currendo ut partem processus constructionis"
Paucis verbis, Venenatus Pipeline Executio (PPE) producitur cum aggressor modificare potest pipeline logicae.
Ibi sunt duo Fortunam:
- PPE directa (D-PPE): In condicione D-PPE, Impetrator fasciculum configurationis CI mutat. in repositorio ad quod accessum habent, vel mutationem directe ad ramum remotum non protectum in repositorio impellendo, vel relationem postalem cum mutatione ex ramo vel furca submittendo. Cum CI pipeline Exsecutio per mandata in fasciculo configurationis CI modificato definitur, mandata maligna aggressoris tandem in nodo constructionis currunt, postquam constructio peracta est. pipeline Urguet.
- PPE indirecta (I-PPE): In quibusdam casibus, possibilitas D-PPE adversario cum accessu ad SCM repositorium (e.g. si pipeline `configuratum est ut fasciculum configurationis CI ex ramo separato et protecto in eodem repositorio extrahat`. In tali casu, potius quam venenum pipeline ipsum, aggressor codicem malitiosum in fasciculos a referto iniicit pipeline (exempli gratia: scripta ex intra referuntur) pipeline fasciculus configurationis)
Utrimque, GitHub mutatum exsequetur. pipeline sine necessitate prioris recensionis vel approbationis.
Detectio praecox PPE
Quomodo huiusmodi vulnerabilitatem detegere possumus?
Videamus hoc exemplum pipeline :
Et contenta scripti simulati testae (runtests.sh):
quod pipeline satis simplex est: propositum eius est recensenti nonnulla indicia praeliminaria praebere ad Pull Request Processus acceptationis (PR):
- Incitabitur in petitio_extrahenda (id est, quotiescumque PR creatur)
- Codicem PR (id est, codicem contributum) examinat.
- Aedificabit
- Experimenta in codice contributo perficiet (exempli gratia, scriptum testae exsequendo).
Gradus tertii (aedificatio perficere) et quarti (experimentum currere) deficient nisi codex compilatur aut experimentis non satisfacit. Itaque hi gradus ut condicio necessaria, sed non sufficiens, ad PR accipiendam funguntur. Si prospere eveniunt, administrator repositorii codicem contributum recensere perget et, secundum hoc, PR accipiet/reiecit/commentarium addet.
Xygeni Scanner
Xygeni praebet CLI (quae est "Xygeni Scanner") quae in includi potest pipeline vel in linea mandatorum curre. Xygeni Scanner tractabit pipelinead vulnerabilitates inspiciendas et, si GitHub PAT praebetur, cum GitHub coniungetur ad vulnerabilitates in gradu organizationis/repositorii detegendas.
Inventarium Xygeni
Cum Xygeni Scanner in hoc repositorio exsequimur, utilem copiam bonorum invenit (quae...) Inventarium Xygeni). Inventarium multis generibus variis implebitur CI/CD bonorumSicut;
- quod SCM ratio ubi repositorium servatur
- quod SCM plugins installatus/usus
- quod Repositorium Codicis ipsum
- quod SCM Organizationem ubi repositorium pertinet
- quod CI/CD Pipelineet Munera
- quod CI/CD ratio currit the pipelines
- IaC Resources in repositorio definitum
- external aut meritis colligati
- etc ..
In exemplo nostro, Inventarium secundum genus quoddam bonorum specificum filtrare possumus (SCM- et bona ad CICD pertinentia), ita videre possumus:
- SCM Systema est GitHub Cloud
- Repositorium in Nube GitHub repositum est et ad certam Organizationem GitHub pertinet.
- Ibi sunt duo pipelinea GitHub sustentatur (CI/CD systema)
- Omnis pipeline unum gradum specificum continet
Eligendo supradicta pipeline quasdam vulnerabilitates videre possumus:
- At pipeline gradu, vulnerabile est ad utrumque direct et PPE indirecta.
Videre possumus singula eorum Venenati. Pipeline Vulnerabilitates executionis
Xygeni detegit id esse vulnerabilis ad D-PPE quia incitatur in Pull Request eventum et nullae sunt aliae moderationes securitatis, ita quilibet usor repositorii modificare potest pipeline et illae modificationes sine ulla recognitione aut approbatione exsequentur.
Eodem sensu, Xygeni etiam detegit id esse vulnerabilis ad I-PPE propter vocationem ad scriptum testae ab pipelineQuilibet usor repositorii scriptum testae modificare potest et hae modificationes sine ulla recognitione vel approbatione exsequentur.
Visne plura scire?
PPE Exploitans
Ad PPE utendum, consideremus condicionem ubi sunt Duo genera usorum repositorii:
- An usor internus (internus programmator in illo repositorio laborans), cum permissione scribendi in repositorio
- An usor externus (fabricator externus in illo repositorio laborans sed cum permissione legendi in repositorio), id est non licet repositorium ramificare et coactus est in furca laborare.
Fingamus ambos esse aggressores maliciosos (vel ab actore malicioso imitatos). Repositorium arcanum aliquod continet et ambo volunt. secretum repositorii furari et ad servum a pirata informatico moderatum mittent. Ad hoc faciendum, Venenato utentur. Pipeline Vulnerabilitates executionis pipeline.
In utroque casu (usori externo et interno), aperiunt... Pull Request cum eisdem modificationibus:
- quod pipeline et scriptum testae mutantur ut lege secretum ex ambiente et mitte ad servum a pirata informatico moderatum
Mutationes tales esse possunt:
Ambo usores creabunt Pull Request cum modificationibusPost creationem PR, GitHub ambas modificationes exsequetur. (sine necessitate prioris recensionis vel approbationis), quod sequentia efficit:
Idem pro usoribus scribentibus et legentibus, In utroque casu D-PPE et I-PPE perficiuntur., ea differentia quod Usor legens secreta accedere non potest. (!!!!)
Haec causa est quia, In casu relationis privatae (PR) ex furca venientis, GitHub aditum ad secreta repositorii non permittit. Quamquam usor qui legit secreta legere non potest, tamen aliud quodlibet programma exsequi potest. Exemplum impetus typicum est creatio PR quae fossorem cryptographicum detrahunt, ita cursor GitHub fossorem cryptographicum exsequetur cum programma venenatum exsequitur. pipeline.
Hic non est locus tutus, scilicet! Quid administrator repositorii facere posset ut id vitaret?
Post aliquam investigationem in Google, administrator repositorii statuit modificare... pipeline excitari in petitionem_extrahendi_scopum eventum. Cur? Quia pipeline`s` in pull_request_target excitatae exsecutionem non permittunt. pipeline modificationes, id est, quamvis quavis modificatione ab usore facta, "originale" pipeline supplicio afficietur.
Exemplo nostro, impetus idem erit ac antea. Quid igitur post hoc fiet? pipeline modificatio?
As expected, D-PPE non exsequitur sed, quia I-PPE adhuc ibi est, Usor legens nunc secretum repositorii accedere potest!!!
Quae est causa cur usor legens nunc ad secreta aditum habeat? Quamquam... pipeline mutari non potest, scriptum testae mutare tamen licet. cum pipeline Si in pull_request_target incitatur, in modo privilegiato exsequetur. so scriptum testae quoque erit...quod efficit ut scriptum testae ad secreta repositorii accessum habeat!!
Praecaventur mensuras
GitHub nonnullas mensuras praebet ad protegendum contra PRs malignas.
Regulae tutelae ramorum
Cum GitHub, regulas tutelae ramorum super ramos selectos definire potes.
Pro ramis tuis protectis, rationem specificare potes quae postulat a pull request ante coniunctionem (necnon condiciones additionales, ut numerus approbationum requisitus, recognitiones a possessoribus codicis, etc.)
Paucae condiciones quae peculiari consideratione merentur sunt:
- "Permitte actoribus specificatis requisitum praeterire pull requests".
- "Noli permitte praeterire supra scriptas optiones."
Dum pleraeque condiciones severitatem politicae addunt, hae politicam relaxant, quod ianuam apertam actionibus malignis implicet, exempli gratia, si testimonia ab actoribus "privilegiatis" furantur.
Permissiones GITHUB_TOKEN restringe (minimum privilegium)
Permissiones tesserae GitHub tantum ad necessarias restringe; hoc modo, etiam si impetratores securitatem tuam violare contigerint. pipeline, non multum efficere poterunt.
Interpolationem litterarum vitare utendo pipeline variabiles ambitus
Quotiescumque variabiles aliquas inputatas in tuo uteris pipeline, scito ea pro datis "non fidis" (eorum contenta ab usore finali moderantur) per default habenda esse. Vide Actiones et Operationes Non Fiduciariae Securae et Actiones Github disce.
Semper variabiles ambientales ad variabiles inputatas intra scripta inserendas uti debes loco interpolationis litterarum.
Cursus operis et requisita approbationis
quia publicae repositoria, GitHub permittit specificare Quomodo cum PR "externis" laborare.
Optiones Organizationis GitHub ("Org >> Optiones >> Actiones >> Generalia") permittunt specificare quomodo relationes publicas externae administrandae sint:
GitHub, per default, approbationem relationum publicarum (PR) pro contributoribus primis requiret, quod impetus petitionum malitiosarum magis complicatos reddit. Etiam sic, aggressor fiduciam curatorum propositi adipisci potest, exempli gratia contribuendo aliquid innocente. pull request ante verum impetum.
In hoc sensu, the Tertia optio (approbationem omnium collaboratorum externorum requirens) gradum maiorem imperii addit.
quia private In repositoriis, GitHub etiam utile imperium et in gradu Organizationis et in gradu Repositorii praebet.
"Currere fluxus operis ex Pull Requests" (non selectum per default) permittit utentes fluxus operis ex PR furcis exsequantur (GITHUB_TOKEN utentes cum permissionibus legendi tantum et sine accessu ad secreta). Hac optione una cum ultima deligendo ("Approbationem requirunt pro processibus functionum PR furcarum.") , similem rationem repositorii privati (ut supra demonstratum est) attingere potes.
Ut in vulneratione PPE ab usore legente vidimus, permittens currere fluxus operis ex furca pull requests non est tutum! (or) periculosum est!
Optiones reliquae (“Tesseras scribendi ad fluxus operandi ex furca mitte. pull requests" et "Secreta et variabiles ad fluxus operandi mitte ab "for" pull requests") gradum securitatis minuere ad PR furcae applicatum.
Hanc rationem furcae vel in gradu organizationis vel in gradu repositorii definire potes. Si ratio in gradu organizationis inactiva est, in gradu repositorii activari non potest. Sed si ratio in gradu organizationis activa est, in gradu repositorii inactivari potest.
Recap
Speramus te vidisse consequentias habendi aliquas pipeline vulnerabilis ad venenatum Pipeline Suppletio. Nimis facile est commit vulnerabilis pipeline... et difficile est tutum scribere.
Itaque magni momenti est Xygeni Scanner uti ad tales vulnerabilitates cognoscendas.
Vulnus solvere non potes nisi eius existentiam conscius sis!!
Sed… adhuc quaestio pendens manet… Quomodo I-PPE vitare?
Hoc erit argumentum proximi nostri nuntii 🙂 … Veneno Indirecto Pipeline Executio (I-PPE) !!
