Ciągła integracja i ciągłe wdrażanie (CI/CD) pipelineodgrywają kluczową rolę w ułatwianiu sprawnego rozwoju oprogramowania. Jednak, ponieważ te pipelineW miarę jak zagrożenia stają się coraz ważniejsze, konieczność ochrony ich przed lukami w zabezpieczeniach staje się coraz bardziej wyraźna. To dogłębne badanie koncentruje się na rozwiązaniu istotnego ryzyka zidentyfikowanego w raporcie OWASP Top-10. CI/CD Zagrożenia bezpieczeństwa: Zatrucie Pipeline Wykonanie (PPE).
Co jest zatrute Pipeline Wykonanie (PPE)
Według OWASP Top-10 CI/CD Zagrożenia bezpieczeństwa,Zatrute Pipeline Egzekucja (PPE) ryzyko odnosi się do zdolności atakującego, który ma dostęp do systemów kontroli wersji – ale nie ma dostępu do środowiska kompilacji – manipulować procesem kompilacji poprzez wstrzykiwanie złośliwego kodu/poleceń do kompilacji pipeline konfiguracja, głównie „zatrucie” pipeline i uruchamianie złośliwego kodu jako części procesu kompilacji”
W kilku słowach, Otruty Pipeline Wykonanie (PPE) jest wykonywane, gdy atakujący może modyfikować pipeline logika.
Istnieją dwa warianty:
- Bezpośrednie środki ochrony indywidualnej (D-ŚOI): W scenariuszu D-PPE, atakujący modyfikuje plik konfiguracyjny CI w repozytorium, do którego mają dostęp, albo poprzez bezpośrednie przesłanie zmiany do niezabezpieczonej zdalnej gałęzi w repozytorium, albo poprzez przesłanie żądania zmiany ze zmianą z gałęzi lub rozwidlenia. Od czasu CI pipeline wykonanie jest definiowane przez polecenia w zmodyfikowanym pliku konfiguracji CI, złośliwe polecenia atakującego są ostatecznie uruchamiane w węźle kompilacji po zakończeniu kompilacji pipeline jest wyzwalany.
- Pośrednie środki ochrony indywidualnej (I-ŚOI): W pewnych przypadkach przeciwnik mający dostęp do środków ochrony indywidualnej nie ma możliwości ich zastosowania. SCM repozytorium (np. jeśli pipeline jest skonfigurowany tak, aby pobierać plik konfiguracji CI z oddzielnej, chronionej gałęzi w tym samym repozytorium). W takim scenariuszu zamiast zatruwać pipeline sam atakujący wstrzykuje złośliwy kod do plików, do których odwołuje się pipeline (na przykład: skrypty, do których odwołuje się użytkownik w ramach pipeline plik konfiguracyjny)
W obu przypadkach, GitHub wykona zmodyfikowaną wersję pipeline bez konieczności wcześniejszego przeglądu lub zatwierdzenia.
Wczesne wykrywanie środków ochrony indywidualnej
Jak możemy wykryć ten rodzaj podatności?
Zobaczmy ten przykład 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.
A oto zawartość skryptu powłoki (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0
pipeline jest dość prosty: jego celem jest dostarczenie recenzentowi wstępnych wskazówek dotyczących Pull Request Proces akceptacji (PR):
- Zostanie to uruchomione żądanie ściągnięcia (tj. za każdym razem, gdy tworzony jest PR)
- Sprawdź kod PR (czyli kod dostarczony)
- To sprawi, że kompilacja będzie
- Będzie uruchamiać testy na dostarczonym kodzie (np. poprzez wykonanie skryptu powłoki)
Kroki nr 3 (wykonanie kompilacji) i nr 4 (uruchomienie testu) zakończą się niepowodzeniem, jeśli kod się nie skompiluje lub nie przejdzie testów. Kroki te stanowią zatem warunek konieczny, ale niewystarczający do zaakceptowania żądania ściągnięcia (PR). W przypadku powodzenia, administrator repozytorium przystąpi do przeglądu przesłanego kodu i na tej podstawie zaakceptuje/odrzuci/skomentuje żądanie ściągnięcia (PR).
Skaner Xygeni
Xygeni zapewnia CLI (tzw. „Skaner Xygeni”), który można osadzić w pipeline lub uruchom w wierszu poleceń. Skaner Xygeni przetworzy pipelinew celu sprawdzenia luk w zabezpieczeniach i, jeśli udostępniono GitHub PAT, nawiąże połączenie z GitHubem w celu wykrycia luk w zabezpieczeniach na poziomie organizacji/repozytorium.
Inwentaryzacja Xygeni
Gdy uruchamiamy skaner Xygeni w tym repozytorium, odkrywa on przydatny zestaw zasobów ( Inwentaryzacja Xygeni). Inwentarz będzie wypełniony wieloma różnymi typami CI/CD majątek, Takie jak:
- SCM Konfiguracja gdzie przechowywane jest repozytorium
- SCM Wtyczki zainstalowany/używany
- Repozytorium kodu samo
- SCM Organizacja gdzie należy repozytorium
- CI/CD Pipelinei praca
- CI/CD Konfiguracja prowadzenie pipelines
- IaC Zasoby zdefiniowane w repozytorium
- Zewnętrzny Zależności
- itp..
W naszym przykładzie możemy filtrować zapasy według pewnego konkretnego typu aktywów (SCM- i aktywa powiązane z CICD), więc możemy zobaczyć, że:
- SCM system to GitHub Cloud
- Repozytorium jest przechowywane w chmurze GitHub i należy do określonej organizacji GitHub
- Istnieją dwa pipelineobsługiwane przez GitHub (CI/CD system)
- Każdy pipeline zawiera jeden konkretny krok
Wybierając powyższe pipeline możemy dostrzec pewne luki:
- At pipeline poziomie jest podatny na oba Skierować oraz Pośrednie środki ochrony indywidualnej.
Możemy zobaczyć szczegóły dotyczące tych otrutych Pipeline Luki w zabezpieczeniach wykonania
Xygeni wykrywa, że to podatny na D-PPE ponieważ jest to uruchamiane na Pull Request zdarzenie i nie ma żadnych dodatkowych kontroli bezpieczeństwa, więc każdy użytkownik repozytorium może modyfikować pipeline a zmiany te zostaną wprowadzone bez żadnego przeglądu ani zatwierdzenia.
W tym samym sensie Xygeni również wykrywa, że podatny na I-PPE z powodu wywołania skryptu powłoki z pipeline:dowolny użytkownik repozytorium może modyfikować skrypt powłoki, a te zmiany zostaną wykonane bez żadnego przeglądu ani zatwierdzenia.
Chcesz wiedzieć więcej?
Wykorzystywanie środków ochrony indywidualnej
Aby wykorzystać środki ochrony indywidualnej, rozważmy scenariusz, w którym dwa rodzaje użytkowników repozytorium:
- An użytkownik wewnętrzny (wewnętrzny programista pracujący nad tym repozytorium) z uprawnieniami do zapisu w repozytorium
- An użytkownik zewnętrzny (zewnętrzny programista pracujący nad tym repozytorium, ale z uprawnieniami do odczytu repozytorium), tzn. nie ma prawa do rozgałęzienia repozytorium i jest zmuszony pracować nad rozwidleniem.
Wyobraźmy sobie, że obaj są złośliwymi atakującymi (lub podszywają się pod nich złośliwi aktorzy). Repozytorium zawiera jakiś sekret i obaj chcą… ukraść sekret repozytorium i wysłać go na serwer kontrolowany przez hakerów. Aby to zrobić, wykorzystają oni zatrute Pipeline Luki w zabezpieczeniach wykonania pipeline.
W obu przypadkach (użytkownik zewnętrzny i wewnętrzny) otwierają Pull Request z tymi samymi modyfikacjami:
- pipeline i skrypt powłoki są modyfikowane do przeczytaj sekret ze środowiska i wysłać go na serwer kontrolowany przez hakerów
Modyfikacje mogą wyglądać następująco:
Obaj użytkownicy utworzą Pull Request ze zmianami. Po utworzeniu PR, GitHub wykona obie modyfikacje (bez konieczności wcześniejszego przeglądu lub zatwierdzenia), co skutkuje następującymi skutkami:
To samo dotyczy użytkowników z uprawnieniami do zapisu i odczytu, w obu przypadkach wykonuje się D-PPE i I-PPEz tą różnicą, że użytkownik odczytujący nie ma dostępu do sekretów. (!!!!)
Powodem jest to, że w przypadku żądania PR pochodzącego z forka, GitHub nie zezwala na dostęp do sekretów repozytorium. Chociaż użytkownik odczytujący nie może odczytać sekretów, nadal może uruchomić dowolny inny program. Typowym przykładem ataku jest tworzenie żądań dostępu (PR), które pobierają program do kopania kryptowalut, dzięki czemu program uruchamiający GitHub uruchomi program do kopania kryptowalut podczas wykonywania zatrutego kodu. pipeline.
Oczywiście, że to nie jest bezpieczne środowisko!! Co może zrobić administrator repozytorium, aby tego uniknąć?
Po pewnym czasie szukania w Google administrator repozytorium decyduje się na modyfikację pipeline zostać uruchomionym na cel_żądania_pociągnięcia wydarzenie. Dlaczego? Ponieważ pipelines wyzwolone w pull_request_target nie zezwalają na wykonywanie pipeline Modyfikacje, tj. pomimo wszelkich modyfikacji użytkownika „oryginał” pipeline zostanie wykonany.
Idąc za naszym przykładem, atak będzie taki sam jak poprzednio. Co się stanie potem? pipeline modyfikacja?
Zgodnie z oczekiwaniami, D-PPE nie jest wykonywane ale ponieważ I-PPE nadal tam jest, użytkownik odczytujący może teraz uzyskać dostęp do sekretu repozytorium!!!
Z jakiego powodu użytkownik odczytujący ma teraz dostęp do sekretów? Chociaż pipeline nie może być modyfikowany, jednak możliwa jest modyfikacja skryptu powłoki. Kiedy pipeline zostanie wyzwolony w pull_request_target, zostanie wykonany w trybie uprzywilejowanym so będzie to również skrypt powłoki, co spowodowało, że skrypt powłoki uzyskał dostęp do sekretów repozytorium!!
Środki zapobiegawcze
GitHub udostępnia pewne środki ochrony przed złośliwymi żądaniami dostępu.
Zasady ochrony oddziałów
Za pomocą GitHub możesz zdefiniować reguły ochrony gałęzi dla wybranych gałęzi.
W przypadku chronionych gałęzi możesz określić politykę, która: wymaga pull request przed połączeniem (oraz dodatkowe warunki, takie jak wymagana liczba zatwierdzeń, opinii właścicieli kodu itp.)
Oto kilka warunków, które zasługują na szczególną uwagę:
- "Zezwól określonym aktorom na ominięcie wymaganych pull requests".
- "Nie zezwalaj na ominięcie powyższych ustawień"
Podczas gdy większość warunków zaostrza zasady, te je łagodzą, co może otworzyć drzwi dla złośliwych działań, na przykład w przypadku kradzieży danych uwierzytelniających przez „uprzywilejowanych” użytkowników.
Ogranicz uprawnienia GITHUB_TOKEN (najmniejsze uprawnienia)
Ogranicz uprawnienia tokena GitHub tylko do wymaganych; w ten sposób, nawet jeśli atakującym uda się naruszyć Twoje dane, pipeline, nie będą mogli wiele zrobić.
Unikaj interpolacji ciągu znaków, używając pipeline zmienne środowiskowe
Za każdym razem, gdy używasz pewnych zmiennych wejściowych w swoim pipeline, pamiętaj, że domyślnie należy je traktować jako dane „niegodne zaufania” (ich zawartość jest kontrolowana przez użytkownika końcowego). Zobacz Niezaufane działania i przepływy pracy Bezpieczne oraz Poznaj działania Github.
Do wstawiania zmiennych wejściowych wewnątrz skryptów zawsze należy używać zmiennych środowiskowych zamiast interpolacji ciągów.
Przebiegi przepływu pracy i wymagania dotyczące zatwierdzenia
Dla litu szacuje się publiczny repozytoria, GitHub pozwala określić jak pracować z PR-ami „zewnętrznymi”.
Ustawienia organizacji GitHub („Organizacja >> Ustawienia >> Akcje >> Ogólne”) pozwalają określić sposób zarządzania zewnętrznymi żądaniami dostępu:
Domyślnie GitHub będzie wymagał zatwierdzenia PR dla osób, które po raz pierwszy wnoszą wkład, co utrudnia ataki oparte na złośliwych żądaniach. Mimo to atakujący może zdobyć zaufanie opiekunów projektu, na przykład poprzez dodanie niewinnych pull request przed prawdziwym atakiem.
W tym sensie Trzecia opcja (wymaganie zgody wszystkich zewnętrznych współpracowników) zapewnia wyższy poziom kontroli.
Dla litu szacuje się prywatny repozytoriów, GitHub zapewnia również przydatną kontrolę zarówno na poziomie organizacji, jak i repozytorium.
"Uruchom przepływy pracy z Pull Requests„(domyślnie niezaznaczone) pozwala użytkownikom uruchamiać przepływy pracy z fork PR (używając GITHUB_TOKEN z uprawnieniami tylko do odczytu i bez dostępu do sekretów). Wybierając tę opcję razem z poprzednią („Wymagaj zatwierdzenia dla przepływów pracy dotyczących rozwidleń PR”), możesz osiągnąć podobną politykę jak w przypadku repozytoriów prywatnych (jak pokazano powyżej).
Jak widzieliśmy w przypadku exploita PPE z poziomu użytkownika odczytującego, umożliwiając uruchamianie przepływów pracy z forka pull requests jest niebezpieczne!!
Pozostałe opcje („Wysyłaj tokeny zapisu do przepływów pracy z forka pull requests"I"Wysyłaj sekrety i zmienne do przepływów pracy z pull requests") obniżyć poziom bezpieczeństwa stosowane do rozwidleń PR.
Tę politykę fork można zdefiniować na poziomie organizacji lub repozytorium. Jeśli polityka jest wyłączona na poziomie organizacji, nie można jej włączyć na poziomie repozytorium. Jeśli jednak polityka jest włączona na poziomie organizacji, można ją wyłączyć na poziomie repozytorium.
Podsumować
Mamy nadzieję, że dostrzegasz konsekwencje posiadania pewnych pipeline podatny na zatrucie Pipeline Wykonanie. To zbyt łatwe. commit wrażliwy pipelinei trudno jest napisać coś bezpiecznego.
Dlatego też bardzo ważne jest korzystanie ze skanera Xygeni, aby być świadomym tego typu luk w zabezpieczeniach.
Nie możesz rozwiązać problemu, jeśli nie jesteś świadomy jego istnienia!!
Ale… Nadal pozostaje jedno pytanie… Jak unikać środków ochrony indywidualnej (I-PPE)?
O tym będziemy pisać w następnym wpisie 🙂 … Pośrednio zatruty Pipeline Wykonanie (I-PPE) !!
