Nepārtraukta integrācija un nepārtraukta izvietošana (CI/CD) pipelinespēlē izšķirošu lomu racionalizētas programmatūras izstrādes veicināšanā. Tomēr, tā kā šie pipelinekļūst arvien svarīgāki, nepieciešamība tos aizsargāt no ievainojamībām kļūst vēl izteiktāka. Šī padziļinātā izmeklēšana koncentrējas uz ievērojama riska novēršanu, kas identificēts OWASP Top-10 sarakstā. CI/CD Drošības riski: Saindēts Pipeline Izpilde (IAL).
Kas ir saindēts Pipeline Izpilde (IAL)
Saskaņā ar OWASP Top-10 CI/CD Drošības riski, “Saindējies Pipeline Izpildīšana (Individuālā Aizsardzība) risks attiecas uz uzbrucēja spēju ar piekļuvi pirmkoda kontroles sistēmām — un bez piekļuves izveides videi — manipulēt ar būvēšanas procesu, ievadot tajā ļaunprātīgu kodu/komandas pipeline konfigurācija, būtībā saindēšana pipeline un ļaunprātīga koda palaišana kā daļa no izstrādes procesa”
Dažos vārdos, saindēts Pipeline Izpilde (IAL) tiek veikta, kad uzbrucējs var modificēt pipeline loģika.
Ir divi varianti:
- Tiešie individuālie aizsardzības līdzekļi (D-IAL): D-IAL scenārijā uzbrucējs modificē CI konfigurācijas failu repozitorijā, kuram viņiem ir piekļuve, vai nu tieši nosūtot izmaiņas uz neaizsargātu attālu repozitorija atzaru, vai iesniedzot PR ar izmaiņām no atzara vai atzara. Kopš CI pipeline izpildi nosaka komandas modificētajā CI konfigurācijas failā, uzbrucēja ļaunprātīgās komandas galu galā tiek palaistas būvēšanas mezglā pēc būvēšanas pipeline tiek aktivizēts.
- Netiešie individuālie aizsardzības līdzekļi (I-IAL): Dažos gadījumos pretiniekam, kuram ir piekļuve D-IAL, nav pieejama iespēja izmantot SCM krātuve (piemēram, ja pipeline ir konfigurēts tā, lai izgūtu CI konfigurācijas failu no atsevišķas, aizsargātas filiāles tajā pašā repozitorijā). Šādā scenārijā, tā vietā, lai saindētu pipeline pats uzbrucējs ievada ļaunprātīgu kodu failos, uz kuriem atsaucas pipeline (piemēram: skripti, uz kuriem ir atsauces no iekšpuses pipeline konfigurācijas fails)
Abos gadījumos GitHub izpildīs modificēto pipeline bez nepieciešamības pēc iepriekšējas pārskatīšanas vai apstiprinājuma.
IAL agrīna atklāšana
Kā mēs varam atklāt šāda veida ievainojamību?
Apskatīsim šo piemēru pipeline :
Un fiktīva čaulas skripta (runtests.sh) saturs:
The pipeline ir pavisam vienkāršs: tā mērķis ir sniegt recenzentam dažus sākotnējos norādījumus par Pull Request (PR) pieņemšanas process:
- Tas tiks aktivizēts, pull_request (t. i., ikreiz, kad tiek izveidots PR)
- Tas pārbauda PR kodu (t.i., pievienoto kodu)
- Tas veicinās būvniecību
- Tas veiks testus ar iesniegto kodu (piemēram, izpildot čaulas skriptu).
3. darbība (veidot būvējumu) un 4. darbība (testa palaišana) neizdosies, ja kods nekompilējas vai neiztur testus. Tātad šīs darbības darbojas kā nepieciešams, bet nepietiekams nosacījums PR pieņemšanai. Ja tas ir veiksmīgi, repozitorija administrators pārskatīs iesniegto kodu un, pamatojoties uz to, pieņems/noraidīs/komentēs PR.
Xygeni skeneris
Ksigēni nodrošina CLI (“Xygeni skeneris”), ko var iestrādāt pipeline vai palaist komandrindā. Xygeni skeneris apstrādās pipelines, lai pārbaudītu ievainojamības, un, ja tiek norādīts GitHub PAT, tas izveidos savienojumu ar GitHub, lai atklātu ievainojamības organizācijas/repozitorija līmenī.
Xygeni inventārs
Kad šajā repozitorijā tiek palaists Xygeni Scanner, tas atrod noderīgu resursu kopu ( Xygeni inventārs). Inventārā tiks iekļauti daudzi un dažādi veidi. CI/CD aktīvi, Piemēram, kā:
- The SCM sistēma kur tiek glabāts repozitorijs
- The SCM plugins uzstādīts/lietots
- The Kodu krātuve pati
- The SCM organizēšana kur pieder repo
- The CI/CD Pipelineun darbavietas
- The CI/CD sistēma darbojas pipelines
- IaC resursi definēts repo
- Ārējs Atkarīgas
- utt ..
Mūsu piemērā mēs varam filtrēt inventāru pēc kāda konkrēta aktīvu veida (SCM- un ar CICD saistītie aktīvi), tāpēc mēs varam redzēt, ka:
- SCM sistēma ir GitHub Cloud
- Repozitorijs tiek glabāts GitHub mākonī un pieder konkrētai GitHub organizācijai.
- Ir divi pipelinenodrošina GitHub (CI/CD sistēma)
- Ik pipeline satur vienu konkrētu soli
Izvēloties iepriekš minēto pipeline mēs varam redzēt dažas ievainojamības:
- At pipeline līmenī, tas ir neaizsargāts pret abiem Virzīt un Netiešie individuālie aizsardzības līdzekļi.
Mēs varam redzēt informāciju par saindētajiem Pipeline Izpildes ievainojamības
Ksigeni atklāj, ka tas ir neaizsargāti pret D-IAL jo tas tiek aktivizēts uz a Pull Request notikums, un nav papildu drošības kontroles, tāpēc jebkurš repozitorija lietotājs var to modificēt pipeline un šīs izmaiņas tiks veiktas bez jebkādas pārskatīšanas vai apstiprināšanas.
Tādā pašā nozīmē Xygeni arī nosaka, ka tas ir neaizsargāti pret I-PPE jo tiek izsaukts čaulas skripts no pipelineJebkurš repozitorija lietotājs var modificēt čaulas skriptu, un šīs modifikācijas tiks izpildītas bez jebkādas pārskatīšanas vai apstiprināšanas.
Vai vēlaties uzzināt vairāk?
Individuālo aizsardzības līdzekļu izmantošana
Lai izmantotu individuālos aizsardzības līdzekļus (IAL), aplūkosim scenāriju, kurā ir divu veidu repo lietotāji:
- An iekšējais lietotājs (iekšējais izstrādātājs, kas strādā pie šī repozitorija) ar rakstīšanas atļaujām repozitorijā
- An ārējais lietotājs (ārpakalpojumu izstrādātājs, kas strādā ar šo repozitoriju, bet ar lasīšanas atļaujām repozitorijā), t. i., nav atļauts veidot repozitorija atzarojumu un ir spiests strādāt pie atzarojuma.
Iedomāsimies, ka abi ir ļaunprātīgi uzbrucēji (vai arī ļaunprātīgs dalībnieks tos iemieso). Repozitorijs satur kādu slepenu informāciju, un abi vēlas nozagt repozitorija noslēpumu un nosūtīt to uz hakeru kontrolētu serveri. Lai to izdarītu, viņi izmantos Saindēto Pipeline Izpildes ievainojamības pipeline.
Abos gadījumos (gan ārējais, gan iekšējais lietotājs) viņi atver Pull Request ar tām pašām modifikācijām:
- The pipeline un čaulas skripts ir modificēts uz izlasi noslēpumu no vides un nosūtīt to uz hakeru kontrolētu serveri
Modifikācijas var būt šādas:
Abi lietotāji izveidos Pull Request ar modifikācijāmPēc PR izveides GitHub izpildīs abas modifikācijas (bez iepriekšējas pārskatīšanas vai apstiprinājuma), kā rezultātā rodas sekojošais:
Tas pats attiecas uz rakstīšanas un lasīšanas lietotājiem. abos gadījumos tiek izpildīti D-PPE un I-PPE, ar atšķirību, ka Lietotājs, kuram ir piešķirta lasīšanas atļauja, nevar piekļūt noslēpumiem. (!!!!)
Šis iemesls ir tāpēc, ka, Ja PR nāk no atzarojuma (fork), GitHub neļauj piekļūt repo noslēpumiem. Lai gan lietotājs, kurš nolasīja slepenos datus, nevar nolasīt, viņš/viņa joprojām var palaist jebkuru citu programmu. Tipisks uzbrukuma piemērs ir tādu PR izveide, kas lejupielādē kriptovalūtu ieguves programmu, tāpēc GitHub palaidējs izpildīs kriptovalūtu ieguves programmu, izpildot saindētu programmu. pipeline.
Protams, šī nav droša vide!! Ko repozitorija administrators varētu darīt, lai no tā izvairītos?
Pēc nelielas meklēšanas Google, repozitorija administrators nolemj modificēt pipeline tikt iedarbinātam uz a pull_request_target pasākums. Kāpēc? Tāpēc, ka pipelines, kas aktivizēti, izmantojot pull_request_target, neļauj izpildīt pipeline izmaiņas, t. i., neskatoties uz jebkādām lietotāja veiktām izmaiņām, “oriģināls” pipeline tiks izpildīts.
Sekojot mūsu piemēram, uzbrukums būs tāds pats kā iepriekš. Kas notiks pēc tam? pipeline modifikācija?
Kā gaidīts, D-IAL netiek izpildīts bet, tā kā I-PPE joprojām ir tur, Lasīšanas lietotājs tagad var piekļūt repozitorija slepenajam kodam!!!
Kāpēc lasītājam tagad ir piekļuve slepenajiem datiem? Lai gan pipeline nevar modificēt, joprojām ir iespējams modificēt čaulas skriptu. Kad pipeline tiek aktivizēts, izmantojot pull_request_target, tas tiks izpildīts privileģētā režīmā so Tas būs arī čaulas skripts, kā rezultātā čaulas skriptam ir piekļuve repo noslēpumiem!!
Preventīvie pasākumi
GitHub nodrošina dažus pasākumus aizsardzībai pret ļaunprātīgām PR.
Filiāļu aizsardzības noteikumi
Izmantojot GitHub, varat definēt filiāļu aizsardzības noteikumus atlasītajām filiālēm.
Aizsargātajām filiālēm varat norādīt politiku, kas prasa a pull request pirms apvienošanas (kā arī papildu nosacījumi, piemēram, nepieciešamais apstiprinājumu skaits, koda īpašnieku pārskatīšanas utt.)
Pāris nosacījumu, kuriem jāpievērš īpaša uzmanība, ir šādi:
- "Atļaut norādītajiem dalībniekiem apiet nepieciešamo pull requests".
- "Neļaut apiet iepriekš minētos iestatījumus"
Lai gan lielākā daļa nosacījumu palielina politikas stingrību, šie nosacījumi to atvieglo, un tas varētu pavērt durvis ļaunprātīgām darbībām, piemēram, ja akreditācijas datus nozog “privileģētas” personas.
Ierobežot GITHUB_TOKEN atļaujas (vismazākās privilēģijas)
Ierobežojiet GitHub tokena atļaujas tikai līdz nepieciešamajām; tādā veidā pat tad, ja uzbrucējiem izdodas apdraudēt jūsu pipeline, viņi daudz ko nevarēs izdarīt.
Izvairieties no virkņu interpolācijas, izmantojot pipeline vides mainīgie
Ikreiz, kad izmantojat dažus ievades mainīgos savā pipeline, ņemiet vērā, ka tie pēc noklusējuma jāuzskata par “neuzticamiem” datiem (to saturu kontrolē gala lietotājs). Skatīt Neuzticamas darbības un darbplūsmas ir drošas un Apgūstiet Github darbības.
Skriptos ievades mainīgo ievietošanai vienmēr jāizmanto vides mainīgie, nevis virkņu interpolācija.
Darbplūsmas izpildes un apstiprināšanas prasības
Par valsts repozitoriji, GitHub ļauj norādīt Kā strādāt ar “ārējiem” PR.
GitHub organizācijas iestatījumos (“Org >> Iestatījumi >> Darbības >> Vispārīgi”) var norādīt, kā pārvaldīt ārējos PR:
Pēc noklusējuma GitHub pirmreizējiem dalībniekiem pieprasīs sabiedrisko attiecību pārstāvju apstiprinājumu, kas sarežģī ļaunprātīgu pieprasījumu uzbrukumus. Pat ja tā, uzbrucējs varētu iegūt projekta uzturētāju uzticību, piemēram, pievienojot kaut ko nevainīgu. pull request pirms īstā uzbrukuma.
Šajā ziņā, Trešā iespēja (prasība par visu ārējo līdzstrādnieku apstiprināšanu) nodrošina augstāku kontroles līmeni.
Par privāts GitHub nodrošina arī noderīgu kontroli gan organizācijas, gan repozitoriju līmenī.
"Palaist darbplūsmas no Pull Requests” (pēc noklusējuma nav atzīmēts) ļauj lietotājiem palaist darbplūsmas no atzarojuma PR (izmantojot GITHUB_TOKEN ar tikai lasīšanas atļaujām un bez piekļuves slepenajiem datiem). Atlasot šo opciju kopā ar pēdējo (“Nepieciešams apstiprinājums atzarojuma PR darbplūsmām”), jūs varat sasniegt līdzīgu politiku kā privātajos repo darījumos (kā parādīts iepriekš).
Kā redzējām PPE izmantotājā no nolasīta lietotāja, ļaujot darbplūsmas palaist no fork pull requests ir nedroši!!
Atlikušās iespējas (“Sūtīt rakstīšanas žetonus darbplūsmām no atzarojuma (fork) pull requests"Un"Nosūtīt noslēpumus un mainīgos uz darbplūsmām no priekš pull requests") samazināt drošības līmeni piemērots dakšas PR.
Šo atdalīšanas politiku var definēt organizācijas līmenī vai repozitorija līmenī. Ja politika ir atspējota organizācijas līmenī, to nevar iespējot repozitorija līmenī. Taču, ja politika ir iespējota organizācijas līmenī, to var atspējot repozitorija līmenī.
Atgādinājums
Mēs ceram, ka esat redzējuši sekas, kas rodas, ja jums ir daži pipeline neaizsargāti pret saindēšanos Pipeline Izpilde. Tas ir pārāk viegli commit neaizsargāts pipeline, un ir grūti uzrakstīt drošu.
Tāpēc ir ļoti vērtīgi izmantot Xygeni skeneri, lai apzinātos šādas ievainojamības.
Jūs nevarat atrisināt ievainojamību, ja vien neesat informēts par tās esamību!
Bet… Joprojām ir neatbildēts jautājums… Kā izvairīties no I-PPE lietošanas?
Šī būs mūsu nākamā ieraksta tēma 🙂 … Netieši saindēts Pipeline Izpilde (I-IAL) !!
