Zəhərlənmiş-Pipeline-İcra

Dərin dalış CI/CD PipelineZəifliklər (I): Zəhərlənmiş Pipeline İcra (Fərdi Mühafizə)

Davamlı İnteqrasiya və Davamlı Yerləşdirmə (CI/CD) pipelines proqram təminatının sadələşdirilməsində mühüm rol oynayır. Lakin, bunlar kimi pipelinegetdikcə daha vacib hala gəldikcə, onları zəifliklərdən qorumaq zərurəti daha da aydınlaşır. Bu dərin araşdırma OWASP Top-10-da müəyyən edilmiş əhəmiyyətli bir riskin aradan qaldırılmasına yönəlib. CI/CD Təhlükəsizlik Riskləri: Zəhərlənmiş Pipeline İcra (Fərdi Mühafizə Vasitələri).

OWASP-top-10-şəkil

Zəhərlənmiş nədir Pipeline İcra (Fərdi Mühafizə)

OWASP Top-10-a görə CI/CD Təhlükəsizlik Riskləri, “Zəhərli Pipeline Icra (PPE) risk, təcavüzkarın mənbə idarəetmə sistemlərinə giriş imkanına və quruluş mühitinə giriş imkanına aiddir. zərərli kod/əmrlər daxil etməklə quruluş prosesini manipulyasiya etmək pipeline konfiqurasiya, mahiyyətcə "zəhərlənmə" pipeline və qurma prosesinin bir hissəsi kimi zərərli kodu işlətmək"

Bir neçə sözlə, Zəhərlənmiş Pipeline İcra (FQV) nə vaxt istehsal olunur təcavüzkar dəyişdirə bilər pipeline məntiq.

İki var variantlar:

  • Birbaşa Fərdi Mühafizə Vasitəsi (D-Fərdi Mühafizə Vasitəsi): D-Fərdi Mühafizə Vasitələri ssenarisində, Təcavüzkar CI konfiqurasiya faylını dəyişdirir depoda, ya dəyişikliyi birbaşa repodakı qorunmayan uzaq bir filiala göndərməklə, ya da bir filialdan və ya çəngəldən dəyişikliklə birlikdə PR təqdim etməklə daxil ola bilərlər. CI-dən bəri pipeline İcra dəyişdirilmiş CI konfiqurasiya faylındakı əmrlərlə müəyyən edilir, təcavüzkarın zərərli əmrləri qurulduqdan sonra nəticədə build qovşağında işləyir. pipeline tetiklenir.
  • Dolayı Fərdi Mühafizə Vasitələri (Fərdi Mühafizə Vasitələri): Müəyyən hallarda, D-Fərdi Mühafizə Vasitələrinə çıxışı olan düşmən üçün D-Fərdi Mühafizə Vasitələrinə (FMV) çıxış imkanı mövcud deyil. SCM depo (məsələn, əgər pipeline CI konfiqurasiya faylını eyni depodakı ayrı, qorunan bir filialdan çəkmək üçün konfiqurasiya edilmişdir). Belə bir ssenaridə zəhərləmək əvəzinə, pipeline özü, təcavüzkar tərəfindən istinad edilən fayllara zərərli kod daxil edir pipeline (məsələn: içəridən istinad edilən skriptlər pipeline konfiqurasiya faylı)

Hər iki halda, GitHub dəyişdirilmiş faylı icra edəcək pipeline əvvəlcədən yoxlamaya və ya təsdiqə ehtiyac olmadan.

CICD-Zəhərlənib-Pipeline-İcra

Fərdi Mühafizə Vasitələrinin Erkən Aşkarlanması

Bu tip zəifliyi necə aşkar edə bilərik? 

Gəlin bu nümunəyə baxaq 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.    
				
			

Və dummy shell skriptinin məzmunu (runtests.sh):

				
					#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0
				
			

The pipeline olduqca sadədir: məqsədi rəyçiyə bəzi ilkin məsləhətlər verməkdir Pull Request (PR) qəbul prosesi:

  • Bu, işə salınacaq pull_request (yəni, PR yaradıldıqda)
  • PR kodunu (yəni töhfə verilən kodu) yoxlayır
  • Quruluşu düzəldəcək 
  • Bu, töhfə verilən kod üzərində testlər aparacaq (məsələn, shell skriptini icra etməklə) 

Kod kompilyasiya edilmədikdə və ya testlərdən keçmədikdə 3-cü (quruluşu yaratmaq) və 4-cü (testi işə salmaq) addımlar uğursuz olacaq. Beləliklə, bu addımlar PR-ı qəbul etmək üçün zəruri, lakin kifayət olmayan şərt kimi çıxış edir. Uğurlu olarsa, repo administratoru töhfə verilmiş kodu nəzərdən keçirəcək və buna əsasən PR-ı qəbul edəcək/rədd edəcək/şərh verəcək.  

Xygeni Skaneri

Xygenie CLI təmin edir ("Xygeni Skaneri”) daxil edilə bilən pipeline və ya əmr sətri ilə işlədin. Xygeni Skaneri emal edəcək pipelineZəiflikləri yoxlamaq üçün s əmrini işə salın və əgər GitHub PAT təmin edilərsə, o, org/repo səviyyəsində zəiflikləri aşkar etmək üçün GitHub-a qoşulacaq.

Xygen İnventarlaşdırması

Bu repoda Xygeni Scanner-i işə saldığımız zaman, o, faydalı aktivlər dəstini ( Xygen İnventarlaşdırması). İnventarlaşdırma bir çox müxtəlif növlərlə doldurulacaq CI/CD aktivKimi:

  • The SCM Sistem depo harada saxlanılır
  • The SCM Plugins quraşdırılmış/istifadə olunmuş
  • The Kod Anbarı özü
  • The SCM təşkilat deponun aid olduğu yer
  • The CI/CD Pipelines və İşlər
  • The CI/CD Sistem çalışan pipelines
  • IaC Resources depoya daxil edilmişdir
  • Xarici Depozitlər
  • və s ..

Bizim nümunəmizdə, inventarı müəyyən bir aktiv növünə görə süzgəcdən keçirə bilərik (SCM- və CICD ilə əlaqəli aktivlər), buna görə də görə bilərik:

  • SCM sistem GitHub Cloud-dur
  • Repo GitHub Cloud-da saxlanılır və müəyyən bir GitHub Təşkilatına aiddir
  • İki var pipelineGitHub tərəfindən dəstəklənir (CI/CD sistem)
  • Hər pipeline müəyyən bir addımı ehtiva edir
Zəhərli Pipeline İcra (Fərdi Mühafizə)

Yuxarıdakıları seçməklə pipeline bəzi zəiflikləri görə bilərik:

  • At pipeline səviyyədə, hər ikisinə qarşı həssasdır Birbaşa və Dolayı Fərdi Mühafizə Vasitələri.

Zəhərlənənlərin təfərrüatlarını görə bilərik Pipeline İcra zəiflikləri

Zəhərli Pipeline İcra (Fərdi Mühafizə)
Zəhərli Pipeline İcra (Fərdi Mühafizə)

Xygeni bunun olduğunu aşkarlayır D-Fərdi Mühafizə Vasitələrinə qarşı həssasdır çünki o, birində işə salınır Pull Request hadisə və əlavə təhlükəsizlik nəzarəti yoxdur, buna görə də istənilən repo istifadəçisi dəyişdirə bilər pipeline və bu dəyişikliklər heç bir baxış və ya təsdiq olmadan həyata keçiriləcək. 

Eyni mənada, Xygeni də bunun olduğunu aşkarlayır I-Fərdi Mühafizə Vasitələrinə qarşı həssasdır shell skriptinə çağırış səbəbindən pipeline: istənilən repo istifadəçisi shell skriptini dəyişdirə bilər və bu dəyişikliklər heç bir baxış və ya təsdiq olmadan icra ediləcək.

Daha çox bilmək istəyirsiniz?

Fərdi Mühafizə Vasitələrindən İstismar

Fərdi Mühafizə Vasitələrindən istifadə etmək üçün gəlin aşağıdakı ssenariləri nəzərdən keçirək iki növ repo istifadəçisi:

  • An daxili istifadəçi (həmin depo üzərində işləyən daxili geliştirici), depoda yazma icazələri ilə
  • An xarici istifadəçi (həmin repo üzərində işləyən, lakin repoda oxuma icazələri olan autsorsinq edilmiş geliştirici), yəni reponu şaxələndirməyə icazə verilmir və çəngəl üzərində işləməyə məcbur edilir.

Təsəvvür edək ki, hər ikisi zərərli hücumçudur (və ya zərərli aktyor tərəfindən təqlid edilib). Repoda bəzi gizli məlumatlar var və hər ikisi istəyir depo sirrini oğurlamaq və haker tərəfindən idarə olunan serverə göndərin. Bunu etmək üçün onlar Zəhərlənmişlərdən istifadə edəcəklər. Pipeline İcra zəiflikləri pipeline.

cicd-demo-dəqiqə

Hər iki halda (xarici və daxili istifadəçi), onlar a açırlar Pull Request eyni dəyişikliklərlə:

  • The pipeline və shell skripti dəyişdirilib üçün sirri oxuyun ətraf mühitdən və haker tərəfindən idarə olunan serverə göndərin

Dəyişikliklər aşağıdakı kimi ola bilər:

cicd-modifikasiyaları
cicd-istismar

Hər iki istifadəçi bir yaradacaq Pull Request dəyişikliklərləPR yaradıldıqdan sonra, GitHub hər iki modifikasiyanı icra edəcək (əvvəlcədən yoxlama və ya təsdiq tələb olunmur), nəticədə aşağıdakılar yaranır:

Top10-CICD-v1.0-9

Yazmaq və oxumaq istifadəçiləri üçün də eynidir, hər iki halda D-PPE və I-PPE icra edilir, fərqlə ki Oxuyan istifadəçi sirlərə daxil ola bilmir. (!!!!) 

Bunun səbəbi, PR-ın çəngəldən gəlməsi halında, GitHub repo sirlərinə girişə icazə vermir. Oxuyan istifadəçi sirləri oxuya bilməsə də, yenə də istənilən başqa proqramı işlədə bilər. Tipik bir hücum nümunəsi, kripto maynerini yükləyən PR-lar yaratmaqdır, buna görə də GitHub çalışdırıcısı zəhərlənmiş bir kripto maynerini işlədərkən onu işə salacaq. pipeline.

Əlbəttə ki, bura təhlükəsiz mühit deyil!! Bunun qarşısını almaq üçün repozitoriya administratoru nə edə bilər?

Bir az Google-da axtarışdan sonra repo administratoru dəyişiklik etmək qərarına gəlir pipeline birində tetiklenmek çəkmə_sorğusu_hədəf hadisə. Niyə? Çünki pipelinepull_request_target üzərində tetiklenen s əmrlərinin icrasına icazə verilmir pipeline dəyişikliklər, yəni istifadəçi tərəfindən edilən hər hansı bir dəyişiklikdən asılı olmayaraq, "orijinal" pipeline edam ediləcək.

Bizim nümunəmizə əsasən, hücum əvvəlki kimi olacaq. Bundan sonra nə baş verəcək? pipeline modifikasiya? 

PPE

Gözlənildiyi kimi, D-PPE icra edilmir lakin, Fərdi Mühafizə Vasitələri (FMV) hələ də mövcud olduğu üçün, Oxuyan istifadəçi artıq repo sirrinə daxil ola bilir!!! 

Oxuyan istifadəçinin artıq sirlərə çıxışının olmasının səbəbi nədir? Baxmayaraq ki, pipeline dəyişdirilə bilməz, amma shell skriptini dəyişdirmək hələ də mümkündür. Bir pipeline pull_request_target üzərində tetiklenirse, imtiyazlı rejimdə icra ediləcək so bu da shell skripti olacaq, nəticədə shell skriptinin repo sirlərinə girişi var!!

Profilaktik tədbirlər

GitHub zərərli PR-lardan qorunmaq üçün bəzi tədbirlər təqdim edir. 

Filialın qorunması qaydaları

GitHub ilə seçilmiş filiallar üzərində filialların qorunması qaydalarını təyin edə bilərsiniz.

Qorunan filiallarınız üçün bir siyasət təyin edə bilərsiniz ki, tələb edir pull request birləşmədən əvvəl (həmçinin tələb olunan sayda təsdiq, kod sahiblərinin rəyləri və s. kimi əlavə şərtlər)

Xüsusi diqqət yetirilməli olan bir neçə şərt bunlardır:

  • "Müəyyən edilmiş aktyorların tələb olunanları keçməsinə icazə verin pull requests". 
  • "Yuxarıdakı parametrləri keçməyin"

Şərtlərin əksəriyyəti siyasətə sərtlik qatsa da, bunlar siyasəti yumşaldır və bu, məsələn, etimadnamələrin "imtiyazlı" aktyorlar tərəfindən oğurlanması halında zərərli fəaliyyətlərə açıq qapı yarada bilər.

GITHUB_TOKEN icazələrini məhdudlaşdırın (ən az imtiyazlı)

GitHub token icazələrini yalnız tələb olunanlarla məhdudlaşdırın; bu şəkildə, hətta hücum edənlər sizin məlumatlarınızı güzəştə getməyə müvəffəq olsalar belə pipeline, onlar çox şey edə bilməyəcəklər.

İstifadə edərək sətir interpolasiyasından qaçın pipeline ətraf mühit dəyişənləri

Giriş dəyişənlərinizdən istifadə etdiyiniz zaman pipeline, nəzərə alın ki, onlar standart olaraq "etibarsız" məlumatlar kimi qəbul edilməlidir (onların məzmunu son istifadəçi tərəfindən idarə olunur). Bax Etibarsız Əməliyyatlar və İş Axınları Təhlükəsizdir və Github Əməliyyatlarını öyrənin.

Sətir interpolasiyasından istifadə etmək əvəzinə, skriptlərin içinə giriş dəyişənlərini daxil etmək üçün həmişə mühit dəyişənlərindən istifadə etməlisiniz.

İş axınının icrası və təsdiq tələbləri

Üçün ictimai repolar, GitHub müəyyən etməyə imkan verir "Xarici" PR-larla necə işləmək olar. 

GitHub Təşkilat parametrləri (“Təşkilat >> Parametrlər >> Əməliyyatlar >> Ümumi”) xarici PR-ların necə idarə olunacağını müəyyən etməyə imkan verir:

çəngəl-çəkmə-min

Varsayılan olaraq, GitHub ilk dəfə töhfə verənlər üçün PR təsdiqi tələb edəcək ki, bu da zərərli sorğu hücumlarını daha da mürəkkəbləşdirəcək. Buna baxmayaraq, hücumçu, məsələn, bəzi günahsız töhfələr verməklə layihənin dəstəkləyicilərinin etibarını qazana bilər. pull request əsl hücumdan əvvəl. 

Bu mənada 3-cü seçim (bütün kənar əməkdaşlar üçün təsdiq tələb olunur) daha yüksək nəzarət səviyyəsini əlavə edir. 

Üçün xüsusi GitHub, depolarda həm Təşkilat, həm də Depo səviyyəsində faydalı nəzarət təmin edir. 

Çəngəl-çəkmə2

"İş axınlarını buradan işə salın Pull Requests"(standart olaraq işarələnməyib) istifadəçilərə iş axınlarını fork PR-larından (yalnız oxumaq üçün icazələri olan və sirlərə girişi olmayan GITHUB_TOKEN istifadə edərək) işlətməyə imkan verir. Bu seçimi sonuncu ilə birlikdə seçməklə ("Çəngəl PR iş axınları üçün təsdiq tələb edin”), özəl depolara bənzər bir siyasətə (yuxarıda göstərildiyi kimi) çata bilərsiniz. 

Oxunan istifadəçidən PPE istismarında gördüyümüz kimi, iş axınlarının çəngəldən işləməsinə imkan verir pull requests təhlükəlidir!!

Qalan seçimlər ("Fork-dan iş axınlarına yazma tokenləri göndərin pull requests"Və"Sirrləri və dəyişənləri iş axınlarına göndərin pull requests") təhlükəsizlik səviyyəsini azaltmaq çəngəl PR-larına tətbiq olunur. 

Bu fork siyasətini ya Təşkilat Səviyyəsində, ya da Repo səviyyəsində təyin edə bilərsiniz. Əgər siyasət təşkilat səviyyəsində deaktivdirsə, onu repo səviyyəsində aktivləşdirmək mümkün deyil. Lakin, əgər siyasət təşkilat səviyyəsində aktivdirsə, onu repo səviyyəsində deaktiv etmək olar.

OWASP-çəngəl

Recap

Ümid edirik ki, bəzilərinin olmasının nəticələrini görmüsünüz pipeline Zəhərlənməyə qarşı həssasdır Pipeline İcra. Bunu etmək çox asandır commit həssas pipelinevə təhlükəsiz bir şey yazmaq çətindir. 

Buna görə də, bu cür zəifliklərdən xəbərdar olmaq üçün Xygeni Skanerindən istifadə etmək çox dəyərlidir.

Bir zəifliyin mövcudluğundan xəbərdar olmadan onu həll edə bilməzsən!! 

Amma... Hələ də gözlənilən bir sual var... Fərdi Fərdi Mühafizə Vasitələrindən (FMV) necə qaçınmaq olar? 

Növbəti paylaşımımızın mövzusu bu olacaq 🙂… Dolayı yolla zəhərlənib Pipeline İcra (Fərdi Mühafizə Vasitələri) !!

Dolayı yolla zəhərlənib Pipeline İcra (Fərdi Mühafizə Vasitələri)

Dərin dalış CI/CD PipelineZəifliklər (II)​

Artifakt Zəhərlənməsi və Kod Enjeksiyası

Dərin dalış CI/CD PipelineZəifliklər (III)​

Proqram Təsdiqləri Vasitəsilə Artifakt Zəhərlənməsinə Qarşı Qorunma

Dərin dalış CI/CD PipelineZəifliklər (IV)​
sca-tools-proqram-kompozisiya-analiz-alətləri
Proqram təminatı risklərinizi prioritetləşdirin, aradan qaldırın və təhlükəsizləşdirin
Pulsuz Hesabınızı əldə edin.
Kredit kartı tələb olunmur.

Proqram təminatınızın hazırlanmasını və çatdırılmasını təmin edin

Xygeni Məhsul Dəsti ilə