Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
VCS oznacza System Kontroli Wersji, ten system pozwala deweloperom na zarządzanie swoim kodem źródłowym. Najbardziej powszechny to 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 CI/CD umożliwiają deweloperom automatyzację wykonywania kodu w różnych celach, w tym budowania, testowania i wdrażania aplikacji. Te zautomatyzowane przepływy pracy są wyzwalane przez konkretne akcje, takie jak push kodu, pull requesty lub zaplanowane zadania. Są przydatne do usprawnienia procesu od rozwoju do produkcji.
Jednak te systemy muszą być wykonywane gdzieś i zazwyczaj z uprzywilejowanymi poświadczeniami do wdrażania kodu lub dostępu do wrażliwych informacji.
Nawet jeśli niektóre platformy VCS pozwalają na tworzenie pipelines, w tej sekcji przeanalizujemy 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 i 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 utworzenie 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 żadnego sekretu, atakujący może wykorzystać webhook z platformy trzeciej.
Jeśli sekret jest w URL, dzieje się to samo i atakujący również ma sekret.
Kompromentacja kodu: Jeśli złośliwy aktor ma jakiś 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ę).
Najbardziej powszechny sposób definiowania pipeline, to użycie pliku konfiguracyjnego CI hostowanego w repozytorium, które pipeline buduje. Ten plik opisuje kolejność wykonywanych zadań, warunki, które wpływają na przepływ, oraz ustawienia środowiska budowania. 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 uruchamia polecenia określone w pliku konfiguracyjnym CI na tym kodzie.
Dlatego ostatecznym celem atakującego jest w jakiś sposób kompromitacja tych plików konfiguracyjnych lub poleceń, które wykonują.
Ś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 dodać 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.
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 ma ten pipeline.
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 i 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ć uruchomiony w produkcji.
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.
Sprawdź ten interesujący artykuł o 10 największych ryzykach CI/CD według Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
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
Checkov: Checkov to narzędzie do analizy statycznej kodu dla infrastruktury jako kodu.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
