Pentesting CI/CD Methodology
VCS
VCS oznacza System Kontroli Wersji, ten system pozwala deweloperom na zarządzanie swoim kodem źródłowym. Najczęściej używanym jest git i zazwyczaj znajdziesz firmy korzystające z niego na jednej z następujących platform:
Github
Gitlab
Bitbucket
Gitea
Dostawcy chmurowi (oferują własne platformy VCS)
Pipelines
Pipelines pozwalają deweloperom na automatyzację wykonywania kodu (do celów budowania, testowania, wdrażania...) po wystąpieniu określonych akcji: push, PR, cron... Są niezwykle przydatne do automatyzacji wszystkich kroków od rozwoju do produkcji.
Jednak te systemy muszą być wykonywane gdzieś i zazwyczaj z uprzywilejowanymi poświadczeniami do wdrażania kodu.
VCS Pentesting Methodology
Nawet jeśli niektóre platformy VCS pozwalają na tworzenie pipelines, w tej sekcji będziemy analizować tylko potencjalne ataki na kontrolę kodu źródłowego.
Platformy, które zawierają kod źródłowy twojego projektu, zawierają wrażliwe informacje i ludzie muszą być bardzo ostrożni z uprawnieniami przyznawanymi w tej platformie. Oto niektóre powszechne problemy w platformach VCS, które atakujący mogą wykorzystać:
Wycieki: Jeśli twój kod zawiera wycieki w commitach, a atakujący ma dostęp do repozytorium (ponieważ jest publiczne lub ma dostęp), może odkryć te wycieki.
Dostęp: Jeśli atakujący może uzyskać dostęp do konta w platformie VCS, może zyskać więcej widoczności i uprawnień.
Rejestracja: Niektóre platformy pozwalają tylko zewnętrznym użytkownikom na tworzenie konta.
SSO: Niektóre platformy nie pozwalają użytkownikom na rejestrację, ale pozwalają każdemu na dostęp z ważnym SSO (więc atakujący mógłby użyć swojego konta github, aby wejść na przykład).
Poświadczenia: Nazwa użytkownika + hasło, tokeny osobiste, klucze ssh, tokeny Oauth, ciasteczka... istnieje kilka rodzajów tokenów, które użytkownik mógłby ukraść, aby uzyskać dostęp do repozytorium w jakiś sposób.
Webhooks: Platformy VCS pozwalają na generowanie webhooków. Jeśli nie są chronione niewidocznymi sekretami, atakujący może je wykorzystać.
Jeśli nie ma sekretu, atakujący może wykorzystać webhook z platformy trzeciej.
Jeśli sekret jest w URL, to samo się dzieje i atakujący również ma sekret.
Kompromentacja kodu: Jeśli złośliwy aktor ma jakikolwiek rodzaj dostępu do zapisu w repozytoriach, może spróbować wstrzyknąć złośliwy kod. Aby odnieść sukces, może potrzebować obejść zabezpieczenia gałęzi. Te działania mogą być wykonywane z różnymi celami na myśli:
Kompromitacja głównej gałęzi w celu kompromitacji produkcji.
Kompromitacja głównej (lub innych gałęzi) w celu kompromitacji maszyn deweloperów (ponieważ zazwyczaj wykonują testy, terraform lub inne rzeczy w repozytorium na swoich maszynach).
Kompromitacja pipeline (sprawdź następną sekcję)
Pipelines Pentesting Methodology
Najczęstszym sposobem definiowania pipeline jest użycie pliku konfiguracyjnego CI hostowanego w repozytorium, które pipeline buduje. Ten plik opisuje kolejność wykonywanych zadań, warunki wpływające na przepływ i ustawienia środowiska budowy. Te pliki zazwyczaj mają spójną nazwę i format, na przykład — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) oraz pliki YAML GitHub Actions znajdujące się w .github/workflows. Po wyzwoleniu, zadanie pipeline pobiera kod z wybranego źródła (np. commit / gałąź) i wykonuje polecenia określone w pliku konfiguracyjnym CI na tym kodzie.
Zatem ostatecznym celem atakującego jest w jakiś sposób kompromitacja tych plików konfiguracyjnych lub poleceń, które wykonują.
PPE - Wykonanie Zatrutego Pipeline
Ścieżka Wykonania Zatrutego Pipeline (PPE) wykorzystuje uprawnienia w repozytorium SCM do manipulacji pipeline CI i wykonywania szkodliwych poleceń. Użytkownicy z niezbędnymi uprawnieniami mogą modyfikować pliki konfiguracyjne CI lub inne pliki używane przez zadanie pipeline, aby zawierały złośliwe polecenia. To "zatruwa" pipeline CI, prowadząc do wykonania tych złośliwych poleceń.
Aby złośliwy aktor odniósł sukces w przeprowadzeniu ataku PPE, musi być w stanie:
Mieć dostęp do zapisu w platformie VCS, ponieważ zazwyczaj pipeline są wyzwalane, gdy wykonany jest push lub pull request. (Sprawdź metodologię pentestingu VCS, aby uzyskać podsumowanie sposobów uzyskania dostępu).
Zauważ, że czasami zewnętrzny PR liczy się jako "dostęp do zapisu".
Nawet jeśli ma uprawnienia do zapisu, musi być pewny, że może zmodyfikować plik konfiguracyjny CI lub inne pliki, na których opiera się konfiguracja.
W tym celu może potrzebować być w stanie obejść zabezpieczenia gałęzi.
Istnieją 3 smaki PPE:
D-PPE: Atak Bezpośredni PPE występuje, gdy aktor modyfikuje plik konfiguracyjny CI, który ma być wykonany.
I-DDE: Atak Pośredni PPE występuje, gdy aktor modyfikuje plik, na którym opiera się plik konfiguracyjny CI, który ma być wykonany (jak plik make lub konfiguracja terraform).
Public PPE lub 3PE: W niektórych przypadkach pipeline mogą być wyzwalane przez użytkowników, którzy nie mają dostępu do zapisu w repozytorium (i którzy mogą nawet nie być częścią organizacji), ponieważ mogą wysłać PR.
3PE Wstrzykiwanie Poleceń: Zazwyczaj pipeline CI/CD ustawią zmienne środowiskowe z informacjami o PR. Jeśli ta wartość może być kontrolowana przez atakującego (jak tytuł PR) i jest używana w niebezpiecznym miejscu (jak wykonywanie poleceń sh), atakujący może wstrzyknąć polecenia tam.
Korzyści z Eksploatacji
Znając 3 smaki zatruwania pipeline, sprawdźmy, co atakujący mógłby uzyskać po udanej eksploatacji:
Sekrety: Jak wspomniano wcześniej, pipeline wymagają uprawnień do swoich zadań (pobieranie kodu, budowanie go, wdrażanie...) i te uprawnienia są zazwyczaj przyznawane w sekretach. Te sekrety są zazwyczaj dostępne za pośrednictwem zmiennych env lub plików w systemie. Dlatego atakujący zawsze będzie próbował wyeksfiltrować jak najwięcej sekretów.
W zależności od platformy pipeline atakujący może potrzebować określić sekrety w konfiguracji. Oznacza to, że jeśli atakujący nie może zmodyfikować pliku konfiguracyjnego CI (I-PPE na przykład), może tylko wyeksfiltrować sekrety, które ten pipeline ma.
Obliczenia: Kod jest wykonywany gdzieś, w zależności od tego, gdzie jest wykonywany, atakujący może być w stanie dalej pivotować.
Na miejscu: Jeśli pipeline są wykonywane na miejscu, atakujący może skończyć w wewnętrznej sieci z dostępem do większej ilości zasobów.
Chmura: Atakujący mógłby uzyskać dostęp do innych maszyn w chmurze, ale także mógłby wyeksfiltrować tokeny ról IAM/kont usługowych z niej, aby uzyskać dalszy dostęp w chmurze.
Maszyna platformy: Czasami zadania będą wykonywane wewnątrz maszyn platformy pipeline, które zazwyczaj znajdują się w chmurze z brakiem dalszego dostępu.
Wybierz to: Czasami platforma pipeline będzie miała skonfigurowane kilka maszyn, a jeśli możesz zmodyfikować plik konfiguracyjny CI, możesz wskazać, gdzie chcesz uruchomić złośliwy kod. W tej sytuacji atakujący prawdopodobnie uruchomi powrotną powłokę na każdej możliwej maszynie, aby spróbować ją dalej wykorzystać.
Kompromitacja produkcji: Jeśli jesteś wewnątrz pipeline i ostateczna wersja jest budowana i wdrażana z niego, możesz kompromitować kod, który ma być uruchamiany w produkcji.
Więcej istotnych informacji
Narzędzia i Benchmark CIS
Chain-bench to narzędzie open-source do audytowania twojego stosu łańcucha dostaw oprogramowania pod kątem zgodności z bezpieczeństwem, oparte na nowym benchmarku CIS Software Supply Chain. Audyt koncentruje się na całym procesie SDLC, gdzie może ujawnić ryzyka od momentu kodowania do momentu wdrożenia.
Top 10 ryzyk bezpieczeństwa CI/CD
Sprawdź ten interesujący artykuł o 10 największych ryzykach CI/CD według Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
Laboratoria
Na każdej platformie, którą możesz uruchomić lokalnie, znajdziesz, jak uruchomić ją lokalnie, aby skonfigurować ją według własnych potrzeb do testowania.
Laboratorium Gitea + Jenkins: https://github.com/cider-security-research/cicd-goat
Narzędzia automatyczne
Checkov: Checkov to narzędzie do analizy statycznej kodu dla infrastruktury jako kodu.
Referencje
Last updated
