Pentesting CI/CD Methodology
VCS
VCS oznacza System Kontroli Wersji, ten system pozwala programistom zarządzać swoim kodem źródłowym. Najczęściej używanym jest git, a firmy zazwyczaj korzystają z jednej z następujących platform:
Github
Gitlab
Bitbucket
Gitea
Dostawcy chmury (oferują własne platformy VCS)
Pipeliny
Pipeliny pozwalają programistom na automatyzację wykonania kodu (np. w celu budowania, testowania, wdrażania...) po wystąpieniu określonych akcji: push, PR, cron... Są one 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.
Metodologia testowania penetracyjnego VCS
Nawet jeśli niektóre platformy VCS pozwalają tworzyć pipeliny, w tej sekcji analizujemy tylko potencjalne ataki na kontrolę kodu źródłowego.
Platformy zawierające kod źródłowy projektu zawierają wrażliwe informacje, dlatego ludzie muszą być bardzo ostrożni z przyznanymi uprawnieniami w tej platformie. Oto kilka powszechnych problemów występujących na 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 do niego dostęp), może odkryć wycieki.
Dostęp: Jeśli atakujący ma dostęp do konta w platformie VCS, może uzyskać większą widoczność i uprawnienia.
Rejestracja: Niektóre platformy pozwolą tylko zewnętrznym użytkownikom na utworzenie konta.
SSO: Niektóre platformy nie pozwolą użytkownikom na rejestrację, ale pozwolą każdemu na dostęp za pomocą ważnego SSO (więc atakujący może na przykład użyć swojego konta github).
Poświadczenia: Nazwa użytkownika + hasło, tokeny osobiste, klucze ssh, tokeny OAuth, pliki cookie... istnieje kilka rodzajów tokenów, które użytkownik może ukraść, aby w jakiś sposób uzyskać dostęp do repozytorium.
Webhooki: Platformy VCS pozwalają na generowanie webhooków. Jeśli nie są chronione za pomocą niewidocznych sekretów, atakujący może je wykorzystać.
Jeśli nie ma ustawionego sekretu, atakujący może wykorzystać webhook z platformy osób trzecich.
Jeśli sekret znajduje się w adresie URL, dzieje się to samo, a atakujący ma również dostęp do sekretu.
Kompromitacja kodu: Jeśli złośliwy aktor ma pewien rodzaj dostępu do zapisu w repozytoriach, może próbować wstrzyknąć złośliwy kod. Aby odnieść sukces, może być konieczne ominięcie zabezpieczeń gałęzi. Te działania mogą być wykonywane z różnymi celami:
Skompromituj główną gałąź, aby skompromitować produkcję.
Skompromituj główną (lub inne gałęzie), aby skompromitować maszyny programistów (ponieważ zazwyczaj wykonują testy, terraform lub inne rzeczy w repozytorium na swoich maszynach).
Skompromituj pipeline (sprawdź następną sekcję)
Metodologia testowania penetracyjnego Pipelinów
Najczęstszy sposób definiowania pipeliny polega na użyciu pliku konfiguracyjnego CI hostowanego w repozytorium, dla którego pipeline jest budowany. Ten plik opisuje kolejność wykonywanych zadań, warunki wpływające na przepływ i ustawienia środowiska budowy. Te pliki zwykle mają spójną nazwę i format, na przykład — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) i pliki YAML GitHub Actions znajdujące się w .github/workflows. Po wywołaniu zadania pipeline pobiera kod z wybranego źródła (np. commit / gałąź) i uruchamia polecenia określone w pliku konfiguracji CI na tym kodzie.
Dlatego ostatecznym celem atakującego jest w jakiś sposób skompromitowanie tych plików konfiguracyjnych lub wykonywanych przez nie poleceń.
PPE - Zatrute Wykonanie Pipeliny
Ścieżka Zatrutego Wykonania Pipeliny (PPE) wykorzystuje uprawnienia w repozytorium SCM do manipulowania pipeliną CI i wykonywania szkodliwych poleceń. Użytkownicy posiadający odpowiednie uprawnienia mogą modyfikować pliki konfiguracji CI lub inne pliki używane przez zadanie pipeliny, aby zawierały złośliwe polecenia. To "zatruwa" pipelinę CI, co prowadzi 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ż pipeliny zazwyczaj są uruchamiane, gdy następuje push lub pull request. (Sprawdź metodologię testowania penetracyjnego VCS, aby uzyskać podsumowanie sposobów uzyskania dostępu
Więcej istotnych informacji
Narzędzia i standard CIS
Chain-bench to narzędzie open-source do audytu stosu łańcucha dostaw oprogramowania pod kątem zgodności z bezpieczeństwem, oparte na nowym standardzie CIS Software Supply Chain. Audyt skupia się na całym procesie SDLC, gdzie może ujawnić ryzyka od czasu pisania kodu do czasu wdrożenia.
Top 10 ryzyk związanych z CI/CD
Sprawdź ten interesujący artykuł na temat top 10 ryzyk związanych z CI/CD według Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
Laboratoria
Na każdej platformie, którą można uruchomić lokalnie, znajdziesz informacje o tym, jak ją uruchomić lokalnie, aby można ją było skonfigurować według własnych preferencji i przetestować.
Laboratorium Gitea + Jenkins: https://github.com/cider-security-research/cicd-goat
Automatyczne narzędzia
Checkov: Checkov to narzędzie do statycznej analizy kodu dla infrastruktury jako kodu.
Odwołania
Last updated
