9.3 KiB
Metodologia Pentesting CI/CD
{{#include ../banners/hacktricks-training.md}}
VCS
VCS oznacza System Kontroli Wersji, ten system pozwala deweloperom zarządzać swoim kodem źródłowym. Najpopularniejszym jest git i zwykle znajdziesz firmy korzystające z niego na jednej z następujących platform:
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (they offer their own VCS platforms)
CI/CD Pipelines
CI/CD pipelines umożliwiają deweloperom automatyzację uruchamiania kodu w różnych celach, w tym budowy, testów i deployu aplikacji. Te zautomatyzowane workflowy są wyzwalane przez konkretne akcje, takie jak pushy kodu, pull requesty lub zadania zaplanowane. Ułatwiają one usprawnienie procesu od developmentu do produkcji.
Jednak te systemy muszą być uruchamiane gdzieś i zwykle wymagają uprzywilejowanych poświadczeń do deployu kodu lub dostępu do wrażliwych informacji.
VCS Pentesting Methodology
Note
Nawet jeśli niektóre platformy VCS umożliwiają tworzenie pipeline'ów, w tej sekcji przeanalizujemy tylko potencjalne ataki na kontrolę nad kodem źródłowym.
Platformy zawierające kod źródłowy Twojego projektu przechowują wrażliwe informacje i trzeba być bardzo ostrożnym z uprawnieniami nadawanymi w obrębie tej platformy. Oto kilka powszechnych problemów na platformach VCS, które atakujący może wykorzystać:
- Leaks: Jeśli Twój kod zawiera leaks w commitach i atakujący ma dostęp do repo (bo jest publiczne lub ma dostęp), może odkryć te leaks.
- Access: Jeśli atakujący może uzyskać dostęp do konta na platformie VCS, może zdobyć większą widoczność i uprawnienia.
- Register: Niektóre platformy pozwalają po prostu zewnętrznym użytkownikom na założenie konta.
- SSO: Niektóre platformy nie pozwalają na rejestrację, ale pozwalają każdemu zalogować się za pomocą ważnego SSO (np. atakujący mógłby użyć swojego konta github, żeby wejść).
- Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... istnieje wiele rodzajów tokenów, które użytkownik może ukraść, aby w jakiś sposób uzyskać dostęp do repo.
- Webhooks: Platformy VCS pozwalają tworzyć webhooks. Jeśli nie są chronione niewidzialnymi sekretami, atakujący może je nadużyć.
- Jeśli nie ma sekretu, atakujący może nadużyć webhooka platformy zewnętrznej.
- Jeśli sekret jest w URL, dzieje się to samo i atakujący również ma ten sekret.
- Code compromise: Jeśli złośliwy aktor ma jakiś rodzaj write dostępu do repo, może spróbować wstrzyknąć złośliwy kod. Aby odnieść sukces, może być konieczne obejście ochrony gałęzi. Te działania mogą być wykonywane z różnymi celami po drodze:
- Skompromitować gałąź main, aby skompromitować production.
- Skompromitować main (lub inne gałęzie), aby skompromitować maszyny deweloperów (ponieważ zwykle wykonują testy, terraform lub inne rzeczy w repo na swoich maszynach).
- Compromise the pipeline (zobacz następną sekcję)
Pipelines Pentesting Methodology
Najczęstszym sposobem definiowania pipeline'a jest użycie pliku konfiguracyjnego CI hostowanego w repozytorium, które pipeline buduje. Ten plik opisuje kolejność wykonywanych jobów, warunki wpływające na flow oraz ustawienia środowiska budowy.
Pliki te mają zwykle stałą nazwę i format, np. — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) oraz pliki YAML GitHub Actions znajdujące się pod .github/workflows. Po wyzwoleniu, job pipeline pobiera kod ze wskazanego źródła (np. commit / branch) i uruchamia komendy określone w pliku konfiguracyjnym CI na tym kodzie.
Dlatego ostatecznym celem atakującego jest w jakiś sposób skompromitować te pliki konfiguracyjne lub komendy, które one wykonują.
PPE - Poisoned Pipeline Execution
The Poisoned Pipeline Execution (PPE) path wykorzystuje uprawnienia w repozytorium SCM do manipulacji pipeline'em CI i uruchamiania szkodliwych poleceń. Użytkownicy z odpowiednimi uprawnieniami mogą modyfikować pliki konfiguracyjne CI lub inne pliki używane przez job pipeline, aby dodać złośliwe polecenia. To „truje” CI pipeline, prowadząc do wykonania tych złośliwych poleceń.
Aby złośliwy aktor odniósł sukces wykonując atak PPE, musi:
- Mieć write access to the VCS platform, ponieważ pipeline'y zwykle są wyzwalane przy pushu lub pull requestcie. (Sprawdź VCS pentesting methodology dla podsumowania sposobów uzyskania dostępu).
- Zauważ, że czasami zewnętrzny PR liczy się jako "write access".
- Nawet mając uprawnienia zapisu, musi mieć pewność, że może zmodyfikować plik konfiguracyjny CI lub inne pliki, na których konfiguracja polega.
- W tym celu może być konieczne obejście ochrony gałęzi.
Są 3 odmiany PPE:
- D-PPE: A Direct PPE attack occurs when the actor modifies the CI config file that is going to be executed.
- I-DDE: An Indirect PPE attack occurs when the actor modifies a file the CI config file that is going to be executed relays on (like a make file or a terraform config).
- Public PPE or 3PE: W niektórych przypadkach pipeline'y mogą być wyzwalane przez użytkowników, którzy nie mają write access w repo (i którzy nawet mogą nie należeć do organizacji), ponieważ mogą wysłać PR.
- 3PE Command Injection: Zwykle CI/CD pipeline'y będą ustawiać zmienne środowiskowe z informacjami o PR. Jeśli tę wartość może kontrolować atakujący (np. tytuł PR) i jest używana w niebezpiecznym miejscu (np. przy wykonywaniu sh commands), atakujący może wstrzyknąć tam polecenia.
Exploitation Benefits
Znając 3 odmiany zatrucia pipeline'a, sprawdźmy, co atakujący może uzyskać po udanej eksploatacji:
- Secrets: Jak wspomniano wcześniej, pipeline'y wymagają uprawnień do swoich jobów (pobrać kod, zbudować, zdeployować...) i te uprawnienia są zwykle przyznawane w sekretach. Te sekrety zwykle są dostępne przez zmienne środowiskowe lub pliki 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 musieć określić sekrety w konfiguracji. To oznacza, że jeśli atakujący nie może zmodyfikować konfiguracji CI (np. I-PPE), mógłby wyeksfiltrować tylko sekrety, które ma dany pipeline.
- Computation: Kod jest wykonywany gdzieś — w zależności od miejsca wykonywania atakujący może być w stanie pivotować dalej.
- On-Premises: Jeśli pipeline'y są wykonywane on-premises, atakujący może trafić do sieci wewnętrznej z dostępem do większej ilości zasobów.
- Cloud: Atakujący może uzyskać dostęp do innych maszyn w chmurze, ale także może wyeksfiltrować tokeny ról IAM/service accounts, żeby uzyskać dalej idący dostęp w chmurze.
- Platforms machine: Czasami joby będą wykonywane na maszynach platformy pipelines, które zwykle znajdują się w chmurze i mają ograniczony dostęp.
- Select it: Czasami platforma pipeline będzie miała skonfigurowane różne maszyny i jeśli możesz zmodyfikować plik konfiguracyjny CI, możesz wskazać, gdzie chcesz uruchomić złośliwy kod. W takiej sytuacji atakujący prawdopodobnie odpali reverse shell na każdej możliwej maszynie, aby spróbować dalej ją eksploatować.
- Compromise production: Jeśli jesteś wewnątrz pipeline'a i finalna wersja jest budowana i deployowana z niego, możesz skompromitować kod, który trafi do produkcji.
More relevant info
Tools & CIS Benchmark
- Chain-bench to narzędzie open-source do audytu Twojego stacku software supply chain pod kątem zgodności bezpieczeństwa, oparte na nowym CIS Software Supply Chain benchmark. Audyt koncentruje się na całym procesie SDLC, gdzie może ujawnić ryzyka od czasu tworzenia kodu po czas jego deployu.
Top 10 CI/CD Security Risk
Sprawdź ciekawy artykuł o top 10 ryzyk CI/CD według Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
Labs
- Na każdej platformie, którą możesz uruchomić lokalnie, znajdziesz instrukcję jak ją uruchomić lokalnie, abyś mógł skonfigurować ją tak, jak chcesz do testów
- Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat
Automatic Tools
- Checkov: Checkov to narzędzie do statycznej analizy kodu dla infrastructure-as-code.
References
{{#include ../banners/hacktricks-training.md}}