Integrazio Jarraitua eta Hedapen Jarraitua (CI/CD) pipelinefuntsezko zeregina dute softwarearen garapen arrazionalizatua errazteko. Hala ere, hauek bezala pipelinegero eta garrantzitsuagoak diren heinean, ahultasunetatik babesteko beharra areagotzen da. Ikerketa sakon honek OWASP Top-10ean identifikatutako arrisku nabarmen bati aurre egitean jartzen du arreta. CI/CD Segurtasun arriskuak: pozoituta Pipeline Exekuzioa (EPI).
Zer da pozoituta? Pipeline Exekuzioa (PPE)
OWASP Top-10en arabera CI/CD Segurtasun Arriskuak, “Pozoituta Pipeline Execution (PPE) arriskuak erasotzaile batek iturburu-kontrol sistemetarako sarbidea duen eta eraikuntza-ingurunera sarbiderik ez duen gaitasunari egiten dio erreferentzia. eraikuntza-prozesua manipulatzeko, kode/komando gaiztoak eraikuntzan txertatuz. pipeline konfigurazioa, funtsean 'pozoitzea' pipeline eta kode gaiztoa exekutatzea eraikuntza prozesuaren barruan”
Hitz gutxitan, pozoituta Pipeline Exekuzioa (PPE) sortzen da noiz erasotzaileak alda dezake pipeline logika.
Badira bi aldaera:
- EPI zuzena (D-PPE): D-PPE eszenatoki batean, erasotzaileak CI konfigurazio fitxategia aldatzen du sarbidea duten biltegi batean, aldaketa zuzenean biltegiko urruneko adar babestu gabe batera bultzatuz, edo adar edo adar batetik aldaketarekin PR bat bidaliz. CItik aurrera pipeline exekuzioa aldatutako CI konfigurazio fitxategiko komandoek definitzen dute, erasotzailearen komando gaiztoak eraikuntza-nodoan exekutatzen dira eraikuntza amaitutakoan pipeline aktibatzen da.
- Zeharkako EPI (I-PPE): Zenbait kasutan, D-PPE aukera ez dago eskuragarri sarbidea duen aurkari batentzat SCM biltegia (adibidez, baldin eta pipeline CI konfigurazio fitxategia biltegi bereko adar babestu eta bereizi batetik ateratzeko konfiguratuta dago). Egoera horretan, pozoitu beharrean pipeline bera, erasotzaile batek kode gaiztoa txertatzen du erreferentziatutako fitxategietan pipeline (adibidez: barruan erreferentziatutako scriptak pipeline konfigurazio fitxategia)
Bi kasuetan, GitHub-ek aldatutakoa exekutatuko du pipeline aurretiko berrikuspen edo onespenik behar izan gabe.
EPIen detekzio goiztiarra
Nola detektatu dezakegu ahultasun mota hau?
Ikus dezagun adibide hau pipeline :
name: PR CI
on:
pull_request:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
jobs:
pr_build_test_and_merge:
runs-on: ubuntu-latest
steps:
# checkout PR code
- name: Checkout repository
uses: actions/checkout@v4
# Simulation of a compilation
- name: Building ...
run: |
echo $MY_SECRET
mkdir ./bin
touch ./bin/mybin.exe
# Simulation of running tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh "${{ github.event.pull_request.user.login }}" "${{ github.workflow }}"
echo Tests executed.
Eta shell script faltsu baten edukia (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0
The pipeline nahiko sinplea da: bere helburua berrikusleari hasierako aholku batzuk ematea da Pull Request (PR) onarpen prozesua:
- Aktibatuko da eskaera_atera (hau da, PR bat sortzen den bakoitzean)
- PR kodea (hau da, lagundutako kodea) egiaztatzen du.
- Eraikuntza egingo du.
- Kode lagunduan probak egingo ditu (adibidez, shell script bat exekutatuz)
3. urratsak (eraikuntza egin) eta 4. urratsak (proba exekutatu) huts egingo dute kodea konpilatzen ez bada edo probak gainditzen ez baditu. Beraz, urrats hauek baldintza gisa balio dute PR onartzeko, baina ez nahikoa. Arrakasta izanez gero, biltegiko administratzaileak ekarpen-kodea berrikusiko du eta, horretan oinarrituta, PR onartu/baztertu/iruzkindu egingo du.
Xygeni eskanerra
Xigenoa CLI bat eskaintzen du ("Xygeni eskanerra") batean txertatu daitekeena pipeline edo komando-lerro batean exekutatu. Xygeni eskanerrak prozesatuko du pipelineahultasunak egiaztatzeko erabiltzen da eta, GitHub PAT bat ematen bada, GitHub-era konektatuko da org/repo mailan ahultasunak aurkitzeko.
Xygeni inbentarioa
Xygeni Scanner biltegi honetan exekutatzen dugunean, aktibo multzo erabilgarri bat aurkitzen du (hau da, Xygeni inbentarioa). Inbentarioa mota askorekin beteko da CI/CD aktibo, Hala nola:
- The SCM Sistema non gordetzen den biltegia
- The SCM Pluginak instalatuta/erabilia
- The Kode Biltegia bera
- The SCM Erakundea biltegia non dagoen
- The CI/CD Pipelines eta Lanpostuak
- The CI/CD Sistema exekutatzen pipelines
- IaC Baliabideak biltegian definituta.
- Kanpoko menpekotasunak
- eta abar ..
Gure adibidean, Inbentarioa aktibo mota espezifiko baten arabera iragaz dezakegu (SCM- eta CICDri lotutako aktiboak), beraz, ikus dezakegu:
- SCM sistema GitHub Cloud da
- Biltegia GitHub Cloud-en gordeta dago eta GitHub erakunde espezifiko bati dagokio.
- Badira bi pipelineGitHub-ek bultzatuta (CI/CD sistema)
- Bakoitzak pipeline urrats zehatz bat dauka
Goikoa hautatuz. pipeline ahultasun batzuk ikus ditzakegu:
- At pipeline mailan, biekiko zaurgarria da zuzeneko Zeharkako EPIak.
Pozoitutakoen xehetasunak ikus ditzakegu Pipeline Exekuzio ahultasunak
Xygenik detektatzen du hori dela D-PPEarekiko zaurgarria batean aktibatzen delako Pull Request gertaera eta ez dago segurtasun-kontrol gehigarririk, beraz, edozein biltegiko erabiltzailek alda dezake pipeline eta aldaketa horiek berrikuspen edo onarpenik gabe exekutatuko dira.
Zentzu berean, Xygeni-k ere detektatzen du hau dela I-PPEarekiko zaurgarria shell script-era egindako deiagatik pipelineEdozein biltegiko erabiltzailek alda dezake shell script-a eta aldaketa horiek berrikuspen edo onarpenik gabe exekutatuko dira.
Gehiago jakin nahi duzu?
EPIak ustiatzea
EPIa ustiatzeko, demagun egoera bat non dauden bi biltegi erabiltzaile mota:
- An barne erabiltzailea (biltegi horretan lanean ari den barne garatzaile bat), biltegian idazteko baimenak dituena
- An kanpoko erabiltzailea (biltegi horretan lanean ari den baina biltegian irakurtzeko baimenak dituen kanpoko garatzaile bat), hau da, biltegia adarkatzeko baimenik ez duena eta adarkadura batean lan egitera behartuta.
Imajina dezagun biak erasotzaile gaiztoak direla (edo eragile gaizto batek imitatzen dituela). Biltegiak sekretu bat dauka eta biek nahi dute... biltegiko sekretua lapurtzeko eta hacker batek kontrolatutako zerbitzari batera bidali. Horretarako, Poisoned-en abantailak erabiliko dituzte Pipeline Exekuzio ahultasunak pipeline.
Bi kasuetan (kanpoko eta barneko erabiltzailea), irekitzen dute Pull Request aldaketa berdinekin:
- The pipeline eta shell script-a aldatuta daude to irakurri sekretua. ingurunetik eta bidali hacker batek kontrolatutako zerbitzari batera
Aldaketak honako hauek izan daitezke:
Bi erabiltzaileek sortuko dute Pull Request aldaketekin.. PR-a sortu zenean, GitHub-ek bi aldaketak exekutatuko ditu (aurretik berrikuspen edo baimenik beharrik gabe), honako hau lortuz:
Gauza bera idazteko eta irakurtzeko erabiltzaileentzat, bi kasuetan D-PPE eta I-PPE gauzatzen dira, aldearekin Irakurle erabiltzaileak ezin ditu sekretuak atzitu. (!!!!)
Arrazoi hau zera da, PR bat adar batetik datorrenean, GitHub-ek ez du biltegiko sekretuetarako sarbidea baimentzen. Irakurle erabiltzaileak ezin baditu sekretuak irakurri, beste edozein programa exekutatu dezake. Eraso-adibide tipiko bat kripto-meatzari bat deskargatzen duten PRak sortzea da, beraz, GitHub-eko exekutatzaileak kripto-meatzaria exekutatuko du pozoitutako programa bat exekutatzean. pipeline.
Hau ez da ingurune segurua, noski!! Zer egin dezake biltegiaren administratzaileak hori saihesteko?
Google-n bilaketa batzuk egin ondoren, biltegiko administratzaileak aldatzea erabakitzen du pipeline batean abiaraztea. eskaera_tiratzeko_helburua gertaera. Zergatik? Zeren eta pipelinepull_request_target-en aktibatutako s-ek ez dute exekutatzen uzten pipeline aldaketak, hau da, erabiltzaileak egindako edozein aldaketa gorabehera, "jatorrizkoa" pipeline exekutatuko da.
Gure adibideari jarraituz, erasoa aurreko berdina izango da. Zer gertatuko da orduan honen ondoren? pipeline aldaketa?
Espero zen bezala, D-PPE ez da gauzatu baina, I-PPE oraindik hor dagoenez, Irakurle erabiltzaileak biltegiko sekretua atzitu dezake orain!!!
Zergatik du irakurleak sekretuetarako sarbidea orain? Nahiz eta... pipeline ezin da aldatu, baina oraindik posible da shell script-a aldatzea. Denean pipeline pull_request_target-en abiarazten bada, modu pribilegiatuan exekutatuko da so shell script-a ere izango da, eta ondorioz shell script-ak biltegiko sekretuetarako sarbidea izango du!!
Prebentzio Neurriak
GitHub-ek PR gaiztoen aurka babesteko neurri batzuk eskaintzen ditu.
Adarrak babesteko arauak
GitHub-ekin hautatutako adarretan adarren babes arauak defini ditzakezu.
Babestutako adarretarako, politika bat zehaztu dezakezu a eskatzen du pull request batu aurretik (baita baldintza gehigarriak ere, hala nola baimen kopuru beharrezkoa, kodearen jabeen berrikuspenak, etab.)
Kontuan hartu beharreko baldintza pare bat hauek dira:
- "Baimendu aktore zehatzei beharrezkoak saihestea pull requests".
- "Ez utzi goiko ezarpenak saihestea"
Baldintza gehienek zorrotzagoa egiten dioten arren politikari, hauek maltzurrago egiten dute eta horrek ateak ireki ditzake jarduera gaiztoetarako, adibidez, "pribilegiodun" aktoreek kredentzialak lapurtzen badituzte.
Mugatu GITHUB_TOKEN baimenak (gutxieneko pribilegioa)
Mugatu GitHub tokenaren baimenak beharrezkoetara soilik; horrela, erasotzaileek zure datuak arriskuan jartzea lortu arren. pipeline, ez dute gauza handirik egin ahal izango.
Saihestu kateen interpolazioa erabiliz pipeline ingurune aldagaiak
Sarrerako aldagai batzuk erabiltzen dituzunean pipeline, kontuan izan lehenespenez "fidagarri ez diren" datutzat hartu behar direla (haien edukia azken erabiltzaileak kontrolatzen du). Ikusi Ekintza eta lan-fluxu fidagarriak seguruak Ikasi Github ekintzak.
Script-en barruan sarrera-aldagaiak txertatzeko beti ingurune-aldagaiak erabili beharko zenituzke, kate-interpolazioa erabili beharrean.
Lan-fluxuen exekuzioak eta onarpen-baldintzak
for publikoa biltegiak, GitHub-ek zehazteko aukera ematen du nola lan egin "kanpoko" PRekin.
GitHub-eko erakundearen ezarpenek (“Erakundea >> Ezarpenak >> Ekintzak >> Orokorra”) kanpoko PRak nola kudeatu zehazten uzten dute:
Berez, GitHub-ek PR onarpena eskatuko die lehen aldiz kolaboratzen dutenei, eta horrek eskaera gaiztoen erasoak konplikatuagoak bihurtzen ditu. Hala ere, erasotzaileak proiektuaren mantentzaileen konfiantza lor dezake, adibidez, informazio errugabea emanez. pull request benetako erasoa baino lehen.
Zentzu horretan, 3. aukerak (kanpoko kolaboratzaile guztien onarpena eskatzea) kontrol maila handiagoa gehitzen du.
for pribatua biltegiak, GitHub-ek kontrol lagungarria ere eskaintzen du bai erakunde mailan bai biltegi mailan.
"Lan-fluxuak exekutatu hemendik: Pull Requests" (lehenespenez ez da markatuta) erabiltzaileei fork PRetatik lan-fluxuak exekutatzeko aukera ematen die (GITHUB_TOKEN bat erabiliz irakurtzeko baimenak dituena eta sekretuetarako sarbiderik gabe). Aukera hau azkenarekin batera hautatuta ("Beharrezkoa da PR lan-fluxuetarako onarpena sardexka") , biltegi pribatuetarako politika antzekoa lor dezakezu (goian erakusten den bezala).
Irakurketa erabiltzaile baten PPE ustiapenean ikusi dugun bezala, lan-fluxuak fork-etik exekutatzea ahalbidetzen pull requests ez da segurua!!
Gainerako aukerak (“Bidali idazketa-tokenak lan-fluxuetara bidegurutzetik pull requests"Eta"Bidali sekretuak eta aldagaiak lan-fluxuetara -tik pull requests") segurtasun maila jaitsi sardexkako PRei aplikatua.
Adarkadura-politika hau Erakunde Mailan edo Biltegi mailan defini dezakezu. Politika erakunde mailan desgaituta badago, ezin da biltegi mailan gaitu. Baina, politika erakunde mailan gaituta badago, biltegi mailan desgaitu daiteke.
Laburpena
Espero dugu batzuk edukitzearen ondorioak ikusi izana pipeline pozoitutakoarekiko zaurgarria Pipeline Exekuzioa. Oso erraza da commit zaurgarri bat pipeline, eta zaila da seguru bat idaztea.
Beraz, oso baliotsua da Xygeni eskanerra erabiltzea ahultasun horien berri izateko.
Ezin duzu zaurgarri bat konpondu haren existentziaz jabetu ezean!!
Baina… Oraindik galdera bat dago zintzilik… Nola saihestu I-PPE?
Hau izango da gure hurrengo argitalpenaren gaia 🙂 … Zeharkako pozoitzea Pipeline Exekuzioa (I-PPE) !!
