Pentesting CI/CD Metodologia

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

VCS

VCS oznacza Version Control System, ten system pozwala deweloperom zarządzać swoim kodem źródłowym. Najpopularniejszy to git i zwykle znajdziesz firmy używające go na jednej z następujących platform:

  • Github
  • Gitlab
  • Bitbucket
  • Gitea
  • Gitblit
  • Dostawcy chmurowi (oferują swoje własne platformy VCS)

CI/CD Pipelines

Potoki CI/CD umożliwiają deweloperom zautomatyzowanie wykonywania kodu w różnych celach, w tym budowania, testowania i wdrażania aplikacji. Te zautomatyzowane workflowy są wyzwalane przez konkretne akcje, takie jak pushy kodu, pull requesty lub zaplanowane zadania. Przyspieszają proces od developmentu do produkcji.

Jednak te systemy muszą być uruchamiane gdzieś i zwykle z uprzywilejowanymi poświadczeniami do deployu kodu lub dostępu do wrażliwych informacji.

VCS Pentesting Methodology

Note

Nawet jeśli niektóre platformy VCS pozwalają tworzyć pipelines, w tej sekcji przeanalizujemy tylko potencjalne ataki na kontrolę nad kodem źródłowym.

Platformy, które zawierają kod źródłowy twojego projektu, przechowują wrażliwe informacje i trzeba być bardzo ostrożnym z uprawnieniami przyznawanymi wewnątrz tej platformy. Oto kilka typowych problemów występujących na platformach VCS, które atakujący może wykorzystać:

  • Leaks: Jeśli twój kod zawiera leaks w commitach i atakujący może uzyskać dostęp do repo (ponieważ jest publiczne lub ma dostęp), może odkryć te leaks.
  • Dostęp: Jeśli atakujący uzyska dostęp do konta na platformie VCS, może zdobyć większą widoczność i uprawnienia.
  • Rejestracja: Niektóre platformy po prostu pozwalają zewnętrznym użytkownikom tworzyć konta.
  • SSO: Niektóre platformy nie pozwalają rejestrować się lokalnie, ale umożliwiają dostęp każdemu z ważnym SSO (np. atakujący może użyć swojego konta github, aby się zalogować).
  • Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies… istnieje wiele typów tokenów, które użytkownik może ukraść, aby w jakiś sposób uzyskać dostęp do repo.
  • Webhooks: Platformy VCS umożliwiają generowanie webhooks. Jeśli nie są chronione niewidocznymi sekretami, atakujący może ich nadużyć.
  • Jeśli nie ma żadnego sekretu, atakujący może nadużyć webhooka zewnętrznej platformy.
  • Jeśli sekret jest w URL, dzieje się to samo i atakujący również ma sekret.
  • Code compromise: Jeśli złośliwy aktor ma jakiś rodzaj dostępu zapisu do repo, może spróbować wstrzyknąć złośliwy kod. Aby odnieść sukces, może potrzebować obejść ochronę gałęzi. Te działania mogą być wykonywane z różnymi celami:
    • Skompromitować główną gałąź, aby skompromitować produkcję.
    • Skompromitować główną (lub inne) gałęzie, aby skompromitować maszyny deweloperów (ponieważ zazwyczaj wykonują testy, terraform lub inne rzeczy z repo na swoich maszynach).
  • Skompromitować pipeline (sprawdź następną sekcję)

Pipelines Pentesting Methodology

Najpopularniejszy sposób definiowania pipeline’a to użycie pliku konfiguracyjnego CI przechowywanego w repozytorium, które pipeline buduje. Ten plik opisuje kolejność wykonywanych zadań, warunki wpływające na przepływ i ustawienia środowiska budowania.
Te pliki zwykle mają spójną nazwę i format, na przykład — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) oraz pliki YAML GitHub Actions w .github/workflows. Po wyzwoleniu, job pipeline’a pobiera kod z wybranego źródła (np. commit / branch) i wykonuje komendy określone w pliku konfiguracyjnym CI względem tego kodu.

Dlatego ostatecznym celem atakującego jest w jakiś sposób skompromitować te pliki konfiguracyjne lub komendy, które one wykonują.

Tip

Niektórzy hostowani builderzy pozwalają kontrybutorom wybierać Docker build context i ścieżkę Dockerfile. Jeśli context jest kontrolowany przez atakującego, możesz ustawić go poza repo (np. “..”), aby w trakcie builda załadować pliki hosta i eksfiltrować sekrety. Zobacz:

{{#ref}} docker-build-context-abuse.md {{#endref}}

PPE - Poisoned Pipeline Execution

Ścieżka Poisoned Pipeline Execution (PPE) wykorzystuje uprawnienia w repo SCM do manipulowania CI pipeline i wykonywania szkodliwych komend. Użytkownicy z odpowiednimi uprawnieniami mogą modyfikować pliki konfiguracyjne CI lub inne pliki używane przez job pipeline’a, 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 wykonując atak PPE, musi być w stanie:

  • Mieć dostęp do zapisu na platformie VCS, ponieważ zwykle pipelines są wyzwalane, gdy następuje push lub pull request. (Sprawdź sekcję VCS pentesting methodology dla podsumowania sposobów uzyskania dostępu).
  • Zauważ, że czasami zewnętrzny PR liczy się jako “dostęp do zapisu”.
  • Nawet jeśli ma uprawnienia zapisu, musi mieć pewność, że może zmodyfikować plik konfiguracyjny CI lub inne pliki, na których konfig opiera się.
  • W tym celu może być konieczne obejście ochrony gałęzi.

Istnieją 3 odmiany PPE:

  • D-PPE: Atak Direct PPE występuje, gdy aktor modyfikuje plik konfig CI, który zostanie wykonany.
  • I-DDE: Atak Indirect PPE występuje, gdy aktor modyfikuje plik, na którym plik konfig CI polega (np. makefile lub konfiguracja terraform).
  • Public PPE or 3PE: W niektórych przypadkach pipelines mogą być wyzwalane przez użytkowników bez dostępu zapisu do repo (a którzy mogą nawet nie być częścią organizacji), ponieważ mogą wysyłać PR.
  • 3PE Command Injection: Zazwyczaj pipeline’y CI/CD ustawiają zmienne środowiskowe z informacjami o PR. Jeśli ta wartość może być kontrolowana przez atakującego (np. tytuł PR) i jest używana w niebezpiecznym miejscu (np. wykonywanie komend sh), atakujący może wstrzyknąć tam polecenia.

Korzyści z eksploatacji

Znając 3 odmiany zatruwania pipeline’a, sprawdźmy, co atakujący może uzyskać po udanej eksploatacji:

  • Secrets: Jak wspomniano wcześniej, pipeline’y wymagają uprawnień dla swoich jobów (pobranie kodu, jego budowa, deploy…) i te uprawnienia są zwykle przechowywane w sekretach. Sekrety te są zwykle dostępne przez zmienne env lub pliki wewnątrz systemu. Dlatego atakujący zawsze będzie próbował eksfiltrować jak najwięcej sekretów.
  • W zależności od platformy pipeline atakujący może potrzebować zadeklarować sekrety w konfiguracji. To oznacza, że jeśli atakujący nie może zmodyfikować konfiguracji CI (I-PPE na przykład), może eksfiltrować tylko te sekrety, które pipeline posiada.
  • Obliczenia: Kod jest wykonywany gdzieś — w zależności od miejsca wykonania atakujący może być w stanie pivotować dalej.
  • On-Premises: Jeśli pipeline’y są wykonywane lokalnie (on-premises), atakujący może znaleźć się w wewnętrznej sieci z dostępem do większej liczby zasobów.
  • Cloud: Atakujący może uzyskać dostęp do innych maszyn w chmurze, ale także mógłby eksfiltrować tokeny ról IAM/service accounts, aby uzyskać dalszy dostęp w chmurze.
  • Maszyna platformy: Czasami joby wykonują się na maszynach platformy pipeline, które zazwyczaj są w chmurze i mają brak dodatkowego dostępu.
  • Wybierz ją: Czasami platforma pipeline ma skonfigurowane kilka maszyn i jeśli możesz zmodyfikować plik konfig CI, możesz wskazać, gdzie chcesz uruchomić złośliwy kod. W takiej sytuacji atakujący prawdopodobnie uruchomi reverse shell na każdej możliwej maszynie, aby dalej ją eksploitować.
  • Skompromitować produkcję: Jeśli jesteś wewnątrz pipeline’a i to z niego finalna wersja jest budowana i wdrażana, możesz skompromitować kod, który trafi na produkcję.

Więcej istotnych informacji

Narzędzia & CIS Benchmark

  • Chain-bench to open-source’owe narzędzie do audytu stacku software supply chain pod kątem zgodności bezpieczeństwa oparte na nowym CIS Software Supply Chain benchmark. Audyt skupia się na całym procesie SDLC, gdzie może ujawnić ryzyka od czasu kodu do czasu deployu.

Top 10 CI/CD Security Risk

Sprawdź ten interesujący artykuł o top 10 ryzyk CI/CD według Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

Automatic Tools

  • Checkov: Checkov to narzędzie do statycznej analizy kodu dla infrastructure-as-code.

References

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks