Integrare continuă și implementare continuă (CI/CD) pipelinejoacă un rol esențial în facilitarea dezvoltării eficiente de software. Totuși, deoarece acestea pipelinePe măsură ce riscurile devin din ce în ce mai cruciale, imperativul de a le proteja de vulnerabilități devine și mai pronunțat. Această investigație aprofundată se concentrează pe abordarea unui risc important identificat în Top 10 al OWASP CI/CD Riscuri de securitate: Otrăvit Pipeline Execuție (EIP).
Ce este otrăvit Pipeline Execuție (EIP)
Conform OWASP Top-10 CI/CD Riscuri de securitate, „Otrăvit Pipeline Execuție (EIP) riscul se referă la capacitatea unui atacator cu acces la sistemele de control al sursei – și fără acces la mediul de compilare – pentru a manipula procesul de compilare prin injectarea de cod/comenzi rău intenționate în compilare pipeline configuraţie, in esenta „otrăvirea” pipeline și rularea de cod rău intenționat ca parte a procesului de construire”
În câteva cuvinte, otrăvit Pipeline Execuția (PPE) este produsă atunci când atacatorul poate modifica pipeline logică.
Sunt două variante:
- EIP direct (D-PPE): Într-un scenariu D-PPE, Atacatorul modifică fișierul de configurare CI într-un repozitoriu la care au acces, fie prin trimiterea modificării direct către o ramură la distanță neprotejată din repozitoriu, fie prin trimiterea unui PR cu modificarea dintr-o ramură sau o bifurcație. De la CI pipeline Execuția este definită de comenzile din fișierul de configurare CI modificat, comenzile malițioase ale atacatorului se execută în cele din urmă în nodul de compilare odată ce compilarea pipeline este declanșat.
- EIP indirect (I-PPE): În anumite cazuri, posibilitatea D-PPE nu este disponibilă unui adversar cu acces la un SCM depozit (de exemplu, dacă pipeline este configurat să extragă fișierul de configurare CI dintr-o ramură separată, protejată, din același depozit). Într-un astfel de scenariu, în loc să otrăvim pipeline în sine, un atacator injectează cod rău intenționat în fișierele la care face referire pipeline (de exemplu: scripturi la care se face referire din interiorul pipeline fișier de configurare)
În ambele cazuri, GitHub va executa codul modificat pipeline fără a fi nevoie de o revizuire sau aprobare prealabilă.
Depistarea precoce a EIP-ului
Cum putem detecta acest tip de vulnerabilitate?
Să vedem acest exemplu 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.
Și conținutul unui script shell fictiv (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0
pipeline este destul de simplu: scopul său este de a oferi recenzentului câteva indicii preliminare pentru Pull Request Procesul de acceptare (PR):
- Se va declanșa pe cerere_de_tragere (adică ori de câte ori este creată o PR)
- Verifică codul PR (adică codul contribuit)
- Va face construcția
- Va rula teste pe codul contribuit (de exemplu, prin executarea unui script shell)
Pașii #3 (crearea versiunii) și #4 (rularea testului) vor eșua dacă codul nu se compilează sau nu trece testele. Prin urmare, acești pași reprezintă o condiție necesară, dar nu suficientă, pentru acceptarea cererii de aprobare (PR). Dacă reușește, administratorul depozitului va revizui codul contribuit și, pe baza acestuia, va accepta/respinge/comenta PR-ul.
Scaner Xygeni
Xygeni oferă o interfață de comandă („CLI”)Scaner Xygeni”) care poate fi încorporat într-un pipeline sau rulați într-o linie de comandă. Scanerul Xygeni va procesa pipelines pentru a verifica vulnerabilitățile și, dacă este furnizat un PAT GitHub, se va conecta la GitHub pentru a descoperi vulnerabilități la nivel de organizație/depozit.
Inventar Xygeni
Când executăm Xygeni Scanner pe acest depozit, acesta descoperă un set util de resurse (cel Inventar XygeniInventarul va fi populat cu multe tipuri diferite de CI/CD bunuri, Cum ar fi:
- SCM Sistem și unde este stocat depozitul
- SCM Plugin-uri instalat/utilizat
- Depozitul de coduri în sine
- SCM Organizație unde aparține depozitul
- CI/CD Pipelines și locuri de muncă
- CI/CD Sistem și rularea pipelines
- IaC Resurse definit în depozit
- Extern dependenţe
- etc ..
În exemplul nostru, putem filtra Inventarul după un anumit tip de activ (SCM- și active legate de CICD), deci putem observa că:
- SCM sistemul este GitHub Cloud
- Depozitul este stocat în GitHub Cloud și aparține unei anumite organizații GitHub.
- Sunt două pipelineeste susținut de GitHub (CI/CD sistem)
- Fiecare pipeline conține un pas specific
Prin selectarea celor de mai sus pipeline Putem observa câteva vulnerabilități:
- At pipeline nivel, este vulnerabil la ambele Direct și EIP indirect.
Putem vedea detaliile celor otrăviți Pipeline Vulnerabilități de execuție
Xygeni detectează că este vulnerabil la D-PPE deoarece este declanșat pe o Pull Request eveniment și nu există controale de securitate suplimentare, așa că orice utilizator al depozitului poate modifica pipeline iar acele modificări vor fi executate fără nicio revizuire sau aprobare.
În același sens, Xygeni detectează, de asemenea, că este vulnerabil la I-PPE din cauza apelului către scriptul shell de la pipelineOrice utilizator al depozitului poate modifica scriptul shell, iar aceste modificări vor fi executate fără nicio revizuire sau aprobare.
Vrei să afli mai multe?
Exploatarea EIP-urilor
Pentru a exploata EIP-ul, să luăm în considerare un scenariu în care există două tipuri de utilizatori de repo:
- An utilizator intern (un dezvoltator intern care lucrează la acel depozit), cu permisiuni de scriere asupra depozitului
- An utilizator extern (un dezvoltator externalizat care lucrează la acel depozit, dar cu permisiuni de citire asupra depozitului), adică nu are voie să ramifice depozitul și este obligat să lucreze la o bifurcație.
Să ne imaginăm că ambii sunt atacatori rău intenționați (sau se dau drept un actor rău intenționat). Depozitul conține un secret și ambii vor... să fure secretul depozitului și îl vor trimite către un server controlat de hackeri. Pentru a face acest lucru, vor profita de Poisoned Pipeline Vulnerabilități de execuție ale pipeline.
În ambele cazuri (utilizator extern și intern), aceștia deschid o Pull Request cu aceleași modificări:
- pipeline și scriptul shell sunt modificate la citește secretul din mediu și trimite-l către un server controlat de hackeri
Modificările ar putea fi următoarele:
Ambii utilizatori vor crea o Pull Request cu modificărileLa crearea PR-ului, GitHub va executa ambele modificări (fără a fi nevoie de revizuire sau aprobare prealabilă), rezultând următoarele:
La fel și pentru utilizatorii care scriu și citesc, În ambele cazuri, se execută D-PPE și I-PPE, cu diferența că Utilizatorul care citește nu poate accesa secretele. (!!!!)
Acest motiv este pentru că, În cazul unui PR provenit de la un fork, GitHub nu permite accesul la secretele repo-ului. Deși utilizatorul care citește nu poate citi secretele, acesta poate rula orice alt program. Un exemplu tipic de atac este crearea de PR-uri care descarcă un miner de criptomonede, astfel încât rulerul GitHub va executa minerul de criptomonede atunci când execută un program otrăvit. pipeline.
Acesta nu este un mediu sigur, desigur!! Ce ar putea face administratorul depozitului pentru a evita acest lucru?
După câteva căutări pe Google, administratorul depozitului decide să modifice pipeline să fie declanșat pe o cerere_de_tragere_țintă eveniment. De ce? Pentru că pipelines declanșate la pull_request_target nu permit execuția pipeline modificări, adică în ciuda oricărei modificări a utilizatorului, „originalul” pipeline va fi executat.
Urmând exemplul nostru, atacul va fi același ca înainte. Ce se va întâmpla apoi după aceasta pipeline modificare?
Cum era de așteptat, D-PPE nu este executat dar, pentru că I-PPE este încă acolo, Utilizatorul care citește poate acum accesa secretul depozitului!!!
Care este motivul pentru care utilizatorul care citește are acum acces la secrete? Deși pipeline nu poate fi modificat, este totuși posibil să modificați scriptul shell. Atunci când o pipeline este declanșat pe pull_request_target, va fi executat în mod privilegiat so va fi și scriptul shell, rezultând în accesul scriptului shell la secretele repo!!
Măsuri preventive
GitHub oferă câteva măsuri de protecție împotriva PR-urilor rău intenționate.
Reguli de protecție a ramurilor
Cu GitHub puteți defini reguli de protecție a ramurilor pentru ramurile selectate.
Pentru ramurile protejate, puteți specifica o politică care necesită o pull request înainte de fuziune (precum și condiții suplimentare, cum ar fi un număr necesar de aprobări, recenzii din partea proprietarilor de cod etc.)
Câteva condiții care merită o atenție specială sunt:
- Permiteți actorilor specificați să ocolească cerințele pull requests".
- Nu permiteți ocolirea setărilor de mai susMatei 22:21
Deși majoritatea condițiilor adaugă strictețe politicii, acestea o relaxează, ceea ce ar putea deschide calea către activități rău intenționate, de exemplu, în cazul în care acreditările sunt furate de actori „privilegiați”.
Restricționare permisiuni GITHUB_TOKEN (privilegii minime)
Restricționează permisiunile token-ului GitHub doar la cele necesare; în acest fel, chiar și în cazul în care atacatorii reușesc să compromită datele tale pipeline, nu vor putea face mare lucru.
Evitați interpolarea șirurilor de caractere utilizând pipeline variabile de mediu
Ori de câte ori utilizați anumite variabile de intrare în pipeline, rețineți că acestea ar trebui considerate în mod implicit drept date „neîncrezătoare” (conținutul lor este controlat de utilizatorul final). Consultați Acțiuni și fluxuri de lucru nesigure securizate și Învață acțiunile Github.
Ar trebui să utilizați întotdeauna variabile de mediu pentru a insera variabile de intrare în scripturi, în loc să utilizați interpolarea șirurilor de caractere.
Executarea fluxului de lucru și cerințele de aprobare
Pentru public depozite, GitHub permite specificarea cum să lucrezi cu PR-uri „externe”.
Setările organizației GitHub („Org >> Setări >> Acțiuni >> General”) permit specificarea modului de gestionare a cererilor de reînnoire (PR) externe:
În mod implicit, GitHub va solicita aprobarea PR pentru contribuitorii care contribuie pentru prima dată, ceea ce complică atacurile prin solicitări rău intenționate. Chiar și așa, atacatorul ar putea câștiga încrederea administratorilor proiectului, de exemplu, contribuind cu informații inocente. pull request înainte de adevăratul atac.
În acest sens, A treia opțiune (solicitarea aprobării pentru toți colaboratorii externi) adaugă un nivel mai ridicat de control.
Pentru privat De asemenea, GitHub oferă control util atât la nivel de organizație, cât și la nivel de depozit.
Executare fluxuri de lucru din Pull Requests„(nebifată în mod implicit) permite utilizatorilor să ruleze fluxuri de lucru din PR-uri fork (folosind un GITHUB_TOKEN cu permisiuni doar de citire și fără acces la secrete). Prin selectarea acestei opțiuni împreună cu ultima („Necesită aprobare pentru fluxurile de lucru pentru PR-uri de tip fork”), puteți ajunge la o politică similară pentru depozitele private (așa cum se arată mai sus).
După cum am văzut în exploit-ul PPE de la un utilizator care citește, permițând rularea fluxurilor de lucru din fork pull requests este nesigur!!
Opțiunile rămase („Trimiteți token-uri de scriere către fluxuri de lucru din fork pull requests"Și"Trimiteți secrete și variabile către fluxuri de lucru de la pentru pull requests") reduce nivelul de securitate aplicat PR-urilor de furcă.
Puteți defini această politică de fork fie la nivel de organizație, fie la nivel de depozit. Dacă politica este dezactivată la nivel de organizație, nu poate fi activată la nivel de depozit. Dar, dacă politica este activată la nivel de organizație, poate fi dezactivată la nivel de depozit.
Recapitulare
Sperăm că ați văzut implicațiile faptului că aveți niște pipeline vulnerabil la otrăvit Pipeline Execuție. E prea ușor să commit un vulnerabil pipelineși e dificil să scrii unul sigur.
Așadar, este foarte util să folosiți scanerul Xygeni pentru a fi conștient de astfel de vulnerabilități.
Nu poți rezolva o vulnerabilitate dacă nu ești conștient de existența ei!!
Dar… Mai există o întrebare în așteptare… Cum să eviți echipamentul de protecție individuală (EPI)?
Acesta va fi subiectul următoarei noastre postări 🙂 … Indirect otrăvit Pipeline Execuție (I-PPE) !!
