Jatkuva integrointi ja jatkuva käyttöönotto (CI/CD) pipelines:llä on keskeinen rooli sujuvan ohjelmistokehityksen helpottamisessa. Silti, koska nämä pipelineKoska haavoittuvuuksista tulee yhä tärkeämpiä, niiden suojaamisen välttämättömyys haavoittuvuuksilta korostuu. Tämä perusteellinen tutkimus keskittyy OWASP:n kymmenen tärkeimmän riskin listalla tunnistetun merkittävän riskin ratkaisemiseen. CI/CD Turvallisuusriskit: Myrkytetty Pipeline Toteutus (PPE).
Mikä on myrkytetty Pipeline Toteutus (PPE)
OWASP Top-10 -listan mukaan CI/CD Turvallisuusriskit, "Myrkytetty Pipeline Teloitus (PPE) riski viittaa hyökkääjän kykyyn, jolla on pääsy versionhallintajärjestelmiin – mutta ei pääsyä rakennusympäristöön – manipuloida rakennusprosessia lisäämällä siihen haitallista koodia/komentoja pipeline kokoonpano, pohjimmiltaan myrkyttämällä pipeline ja haitallisen koodin suorittaminen osana rakennusprosessia”
Muutamalla sanalla, myrkytetty Pipeline Toteutus (PPE) tuotetaan, kun hyökkääjä voi muokata pipeline logiikka.
On kaksi variantit:
- Suora henkilönsuojain (D-PPE): D-PPE-skenaariossa hyökkääjä muokkaa CI-määritystiedostoa repositoriossa, johon heillä on pääsy, joko lähettämällä muutoksen suoraan repositorion suojaamattomaan etähaaraan tai lähettämällä muutoksen sisältävän PR:n haarasta tai haaraumasta. Koska CI pipeline Vaikka suoritus määritellään muokatun CI-määritystiedoston komennoilla, hyökkääjän haitalliset komennot suoritetaan lopulta rakennussolmussa, kun rakennus on valmis. pipeline käynnistyy.
- Epäsuorat henkilönsuojaimet (I-PPE): Tietyissä tapauksissa D-PPE:n käyttö ei ole mahdollista vastustajalle, jolla on pääsy SCM arkisto (esim. jos pipeline on määritetty hakemaan CI-määritystiedosto erillisestä, suojatusta haarasta samassa tietovarastossa). Tällaisessa tilanteessa myrkyttämisen sijaan pipeline itse hyökkääjä lisää haitallista koodia tiedostoihin, joihin viittaa pipeline (esimerkiksi: skriptit, joihin viitataan pipeline määritystiedosto)
Kummassakin tapauksessa, GitHub suorittaa muokatun pipeline ilman aiempaa arviointia tai hyväksyntää.
Henkilönsuojainten varhainen havaitseminen
Miten voimme havaita tällaisen haavoittuvuuden?
Katsotaanpa tätä esimerkkiä pipeline :
Ja kokeiluluontoisen komentosarjan (runtests.sh) sisältö:
pipeline on melko yksinkertainen: sen tarkoituksena on antaa arvioijalle joitakin alustavia vihjeitä Pull Request (PR)-hyväksymisprosessi:
- Se laukeaa pull_request (eli aina kun PR luodaan)
- Se tarkistaa PR-koodin (eli lisätyn koodin)
- Se tekee rakentamisesta
- Se suorittaa testejä luodulle koodille (esim. suorittamalla komentosarjan)
Vaiheet 3 (koonnin tekeminen) ja 4 (testin suorittaminen) epäonnistuvat, jos koodi ei käänny tai se ei läpäise testejä. Nämä vaiheet toimivat siis välttämättöminä, mutta eivät riittävinä edellytyksinä PR:n hyväksymiselle. Jos se onnistuu, repositorion ylläpitäjä tarkistaa lähetetyn koodin ja sen perusteella hän hyväksyy/hylkää/kommentoi PR:ää.
Xygeni-skanneri
Xygeni tarjoaa komentoriviliittymän (”Xygeni-skanneri”), joka voidaan upottaa pipeline tai suorita komentoriviltä. Xygeni Scanner käsittelee pipelines tarkistaa haavoittuvuuksia, ja jos GitHub PAT annetaan, se muodostaa yhteyden GitHubiin löytääkseen haavoittuvuuksia organisaatio-/repo-tasolla.
Xygeni-varasto
Kun suoritamme Xygeni Scannerin tälle repositoriolle, se löytää hyödyllisen joukon resursseja ( Xygeni-varasto). Inventaarioon lisätään monia erityyppisiä esineitä CI/CD varat, Kuten esimerkiksi:
- SCM järjestelmä missä repo on tallennettu
- SCM plugins asennettu/käytetty
- Koodivarasto itse
- SCM organisaatio mihin repo kuuluu
- CI/CD Pipelineja työpaikat
- CI/CD järjestelmä käynnissä pipelines
- IaC Esittelymateriaalit määritelty repoon
- Ulkoinen riippuvuudet
- jne..
Esimerkissämme voimme suodattaa varaston tietyn omaisuustyypin mukaan (SCM- ja CICD:hen liittyvät resurssit), joten voimme nähdä, että:
- SCM järjestelmä on GitHub Cloud
- Repo tallennetaan GitHub Cloudiin ja kuuluu tiettyyn GitHub-organisaatioon.
- On kaksi pipelineGitHubin tarjoama (CI/CD järjestelmä)
- Joka pipeline sisältää yhden tietyn vaiheen
Valitsemalla yllä olevan pipeline voimme nähdä joitakin haavoittuvuuksia:
- At pipeline tasolla, se on altis molemmille Suora ja Epäsuorat henkilönsuojaimet.
Voimme nähdä yksityiskohtia myrkytetyistä Pipeline Suoritushaavoittuvuudet
Xygeni havaitsee, että se on altis D-PPE:lle koska se laukeaa Pull Request tapahtumaa eikä muita suojauskontrolleja ole, joten kuka tahansa repon käyttäjä voi muokata sitä pipeline ja nämä muutokset toteutetaan ilman erillistä tarkistusta tai hyväksyntää.
Samassa mielessä Xygeni havaitsee myös, että se on altis I-PPE:lle koska komentosarjakutsu suoritetaan pipelinekuka tahansa repo-käyttäjä voi muokata komentosarjaa, ja muutokset suoritetaan ilman tarkistusta tai hyväksyntää.
Haluatko tietää enemmän?
Henkilönsuojainten hyödyntäminen
Henkilönsuojainten hyödyntämiseksi tarkastellaan tilannetta, jossa on kahdenlaisia repo-käyttäjiä:
- An sisäinen käyttäjä (sisäinen kehittäjä työskentelee kyseisen repositorion parissa) ja hänellä on kirjoitusoikeudet repositorioon
- An ulkoinen käyttäjä (ulkoistettu kehittäjä työskentelee kyseisen repositorion parissa, mutta hänellä on repositorion lukuoikeudet), eli hän ei saa haarautua repositorioon ja hänen on työskenneltävä haarautumisen parissa.
Kuvitellaan, että molemmat ovat pahantahtoisia hyökkääjiä (tai pahantahtoinen toimija esiintyy heinäsi). Säilö sisältää salaisuutta ja molemmat haluavat varastaakseen repo-salaisuuden ja lähettää sen hakkereiden hallitsemalle palvelimelle. Tätä varten he hyödyntävät Poisoned-ominaisuutta. Pipeline Suoritushaavoittuvuudet pipeline.
Molemmissa tapauksissa (sekä ulkoinen että sisäinen käyttäjä) he avaavat Pull Request samoilla muutoksilla:
- pipeline ja komentosarjaa on muokattu että lue salaisuus ympäristöstä ja lähetä se hakkereiden hallitsemalle palvelimelle
Muutokset voivat olla seuraavanlaisia:
Molemmat käyttäjät luovat Pull Request muutosten kanssaPR:n luomisen yhteydessä GitHub suorittaa molemmat muutokset (ilman aiempaa tarkistusta tai hyväksyntää), mikä johtaa seuraavaan:
Sama kirjoitus- ja lukukäyttäjille, Molemmissa tapauksissa D-PPE ja I-PPE suoritetaan, sillä erotuksella, että Lukija ei voi käyttää salaisuuksia. (!!!!)
Tämä syy on se, että Jos PR tulee haarautumasta, GitHub ei salli pääsyä repo-salaisuuksiin. Vaikka lukukäyttäjä ei voi lukea salaisuuksia, hän voi silti suorittaa mitä tahansa muuta ohjelmaa. Tyypillinen hyökkäysesimerkki on kryptolouhintaohjelman lataavien PR:ien luominen, jolloin GitHub-ajoohjelma suorittaa kryptolouhintaohjelman suorittaessaan myrkytettyä ohjelmaa. pipeline.
Tämä ei tietenkään ole turvallinen ympäristö!! Mitä arkiston ylläpitäjä voisi tehdä välttääkseen sen?
Googlattuaan jonkin aikaa arkiston ylläpitäjä päättää muokata pipeline laukaista pull_request_kohde tapahtuma. Miksi? Koska pipelinepull_request_target-komennon laukaisemat eivät salli suorittamista pipeline muutokset, eli käyttäjän tekemistä muutoksista huolimatta "alkuperäinen" pipeline teloitetaan.
Esimerkkiämme seuraten hyökkäys on sama kuin ennen. Mitä sitten tapahtuu tämän jälkeen pipeline muokkaus?
Odotetusti, D-PPE:tä ei ole suoritettu mutta koska I-PPE on edelleen olemassa, Lukija voi nyt käyttää repon salaisuutta!!!
Mikä on syy siihen, että lukuoikeutetulla käyttäjällä on nyt pääsy salaisuuksiin? Vaikka pipeline ei voida muokata, komentosarjaa on silti mahdollista muokata. Kun pipeline laukaistaan pull_request_target-komennolla, se suoritetaan etuoikeutetussa tilassa so se on myös komentosarja, jolloin komentosarjalla on pääsy repo-salaisuuksiin!!
Ennaltaehkäisevät toimenpiteet
GitHub tarjoaa joitakin suojaustoimenpiteitä haitallisilta PR-pyynnöiltä.
Sivukonttorin suojaussäännöt
GitHubin avulla voit määrittää haaran suojaussääntöjä valituille haaroille.
Suojatuille haaroillesi voit määrittää käytännön, joka vaatii a pull request ennen yhdistämistä (sekä lisäehtoja, kuten vaadittu määrä hyväksyntöjä, koodin omistajien tarkastuksia jne.)
Pari erityistä huomiota ansaitsevaa ehtoa ovat:
- "Salli tiettyjen toimijoiden ohittaa pakolliset pull requests".
- "Älä salli yllä olevien asetusten ohittamista"
Vaikka useimmat ehdot lisäävät käytäntöön tiukkuutta, nämä ehdot lieventävät sitä, mikä voi avata oven haitallisille toimille, esimerkiksi jos "etuoikeutetut" toimijat varastavat tunnistetiedot.
Rajoita GITHUB_TOKEN-käyttöoikeuksia (pienin käyttöoikeus)
Rajoita GitHub-tokenin käyttöoikeudet vain tarvittaviin; tällä tavoin, vaikka hyökkääjät onnistuisivatkin murtautumaan tietoihisi pipeline, he eivät pysty tekemään paljoakaan.
Vältä merkkijonojen interpolointia käyttämällä pipeline ympäristömuuttujat
Aina kun käytät joitakin syöttömuuttujia pipeline, huomaa, että niitä tulisi oletusarvoisesti pitää "epäluotettavina" tietoina (niiden sisältöä hallitsee loppukäyttäjä). Katso Epäluotettavat toiminnot ja työnkulut suojattuina ja Opi Github-toiminnot.
Sinun tulisi aina käyttää ympäristömuuttujia syötemuuttujien lisäämiseen komentosarjojen sisällä merkkijonojen interpoloinnin sijaan.
Työnkulun suoritukset ja hyväksymisvaatimukset
varten julkinen GitHub sallii repositorioiden määrittämisen miten työskennellä "ulkoisten" PR-edustajien kanssa.
GitHubin organisaatioasetuksissa (“Organisaatio >> Asetukset >> Toiminnot >> Yleiset”) määritetään, miten ulkoisia PR:iä hallitaan:
Oletusarvoisesti GitHub vaatii PR-hyväksynnän ensikertalaisilta osallistujilta, mikä tekee haitallisista pyyntöhyökkäyksistä monimutkaisempia. Silti hyökkääjä voi saada projektin ylläpitäjien luottamuksen esimerkiksi lisäämällä viatonta sisältöä. pull request ennen varsinaista hyökkäystä.
Tässä mielessä Kolmas vaihtoehto (kaikilta ulkopuolisilta yhteistyökumppaneilta vaaditaan hyväksyntä) lisää hallintaa.
varten yksityinen GitHub tarjoaa hyödyllistä hallintaa sekä organisaatio- että repotasolla repositorioiden osalta.
"Suorita työnkulut osoitteesta Pull Requests” (ei oletusarvoisesti valittuna) sallii käyttäjien suorittaa työnkulkuja haarautuneiden PR:ien kautta (käyttäen GITHUB_TOKENia, jolla on vain luku -oikeudet ja ilman pääsyä salaisuuksiin). Valitsemalla tämän vaihtoehdon yhdessä viimeisen vaihtoehdon kanssa (“Vaadi hyväksyntä haarautuneiden PR-työnkulkujen osalta”) voit saavuttaa samanlaisen käytännön kuin yksityisissä repoissa (kuten yllä on esitetty).
Kuten olemme nähneet PPE:n hyödyntämistapahtumassa luetulta käyttäjältä, työnkulkujen suorittamisen salliminen haarautumisesta pull requests on vaaratonta!!
Loput vaihtoehdot ("Lähetä kirjoitustokenit työnkulkuihin haarautumisesta pull requests"Ja"Lähetä salaisuuksia ja muuttujia työnkulkuihin osoitteesta kohteelle pull requests") alenna suojaustasoa sovellettu haarukan PR-arvoihin.
Voit määrittää tämän haarautumiskäytännön joko organisaatiotasolla tai arkistotasolla. Jos käytäntö on poistettu käytöstä organisaatiotasolla, sitä ei voida ottaa käyttöön arkistotasolla. Mutta jos käytäntö on käytössä organisaatiotasolla, se voidaan poistaa käytöstä arkistotasolla.
Kertaus
Toivomme, että olet nähnyt joidenkin seuraamukset pipeline altis myrkytetyille Pipeline Toteutus. Se on liian helppoa commit haavoittuvainen pipeline, ja turvallisen kirjoittaminen on vaikeaa.
Joten on erittäin arvokasta käyttää Xygeni-skanneria tällaisten haavoittuvuuksien havaitsemiseksi.
Et voi ratkaista haavoittuvuutta, ellet ole tietoinen sen olemassaolosta!!
Mutta… Vielä on yksi kysymys… Miten välttää henkilönsuojainten käyttöä?
Tästä aiheesta kirjoitamme seuraavassa postauksessamme 🙂 … Epäsuora myrkytys Pipeline Toteutus (I-PPE) !!
