From f48c99ba086da220b6e089eddbc99af72ded79f7 Mon Sep 17 00:00:00 2001 From: Translator Date: Sun, 31 Aug 2025 08:23:11 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/gitblit-security/README.md', 'src/pent --- .../gitblit-security/README.md | 21 ++++ ...embedded-ssh-auth-bypass-cve-2024-28080.md | 107 ++++++++++++++++ .../pentesting-ci-cd-methodology.md | 119 +++++++++--------- 3 files changed, 189 insertions(+), 58 deletions(-) create mode 100644 src/pentesting-ci-cd/gitblit-security/README.md create mode 100644 src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md diff --git a/src/pentesting-ci-cd/gitblit-security/README.md b/src/pentesting-ci-cd/gitblit-security/README.md new file mode 100644 index 000000000..756da855d --- /dev/null +++ b/src/pentesting-ci-cd/gitblit-security/README.md @@ -0,0 +1,21 @@ +# Gitblit Bezpieczeństwo + +{{#include ../../banners/hacktricks-training.md}} + +## Co to jest Gitblit + +Gitblit to samodzielnie hostowany serwer Git napisany w Javie. Może działać jako samodzielny plik JAR lub w kontenerach servletów i jest dostarczany z wbudowaną usługą SSH (Apache MINA SSHD) dla Git over SSH. + +## Tematy + +- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080) + +{{#ref}} +gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md +{{#endref}} + +## Referencje + +- [Gitblit project](https://gitblit.com/) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md new file mode 100644 index 000000000..8ad5b0176 --- /dev/null +++ b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md @@ -0,0 +1,107 @@ +# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080) + +{{#include ../../banners/hacktricks-training.md}} + +## Podsumowanie + +CVE-2024-28080 to obejście uwierzytelniania w wbudowanym serwisie SSH Gitblit spowodowane niepoprawnym zarządzaniem stanem sesji podczas integracji z Apache MINA SSHD. Jeśli konto użytkownika ma zarejestrowany co najmniej jeden klucz SSH publiczny, atakujący znający nazwę użytkownika i dowolny z jego kluczy publicznych może się uwierzytelnić bez private key i bez hasła. + +- Dotknięte: Gitblit < 1.10.0 (observed on 1.9.3) +- Naprawione: 1.10.0 +- Wymagania do exploitacji: +- Git over SSH włączony na instancji +- Konto ofiary ma zarejestrowany co najmniej jeden klucz SSH publiczny w Gitblit +- Atakujący zna nazwę użytkownika ofiary i jeden z jego kluczy publicznych (często do znalezienia, np. https://github.com/.keys) + +## Root cause (state leaks between SSH methods) + +W RFC 4252 uwierzytelnianie public‑key przebiega w dwóch fazach: serwer najpierw sprawdza, czy podany klucz publiczny jest akceptowalny dla nazwy użytkownika, a dopiero po challenge/response z podpisem uwierzytelnia użytkownika. W MINA SSHD PublickeyAuthenticator jest wywoływany dwukrotnie: przy akceptacji klucza (jeszcze bez podpisu) i później, po tym jak klient zwróci podpis. + +PublickeyAuthenticator Gitblita modyfikował kontekst sesji przy pierwszym, przed‑podpisem wywołaniu, wiążąc uwierzytelniony UserModel z sesją i zwracając true ("key acceptable"). Gdy uwierzytelnianie później przechodziło do hasła, PasswordAuthenticator ufał temu zmodyfikowanemu stanowi sesji i skracał ścieżkę, zwracając true bez weryfikacji hasła. W efekcie każde hasło (włącznie z pustym) było akceptowane po wcześniejszej public‑key "acceptance" dla tego samego użytkownika. + +Ogólny, wadliwy przebieg: + +1) Klient oferuje nazwę użytkownika + public key (jeszcze bez podpisu) +2) Serwer rozpoznaje, że klucz należy do użytkownika i przedwcześnie przypisuje użytkownika do sesji, zwracając true ("acceptable") +3) Klient nie może podpisać (brak private key), więc uwierzytelnianie przechodzi na hasło +4) Uwierzytelnianie hasłem widzi, że użytkownik jest już przypisany do sesji i bezwarunkowo zwraca powodzenie + +## Krok‑po‑kroku eksploatacja + +- Zbierz nazwę użytkownika ofiary i jeden z jej kluczy publicznych: +- GitHub udostępnia klucze publiczne pod adresem https://github.com/.keys +- Publiczne serwery często ujawniają authorized_keys +- Skonfiguruj OpenSSH tak, by prezentował tylko część publiczną, tak że generowanie podpisu się nie powiedzie, wymuszając fallback do hasła, jednocześnie wywołując ścieżkę akceptacji public‑key po stronie serwera. + +Przykładowa konfiguracja klienta SSH (no private key available): +```sshconfig +# ~/.ssh/config +Host gitblit-target +HostName +User +PubkeyAuthentication yes +PreferredAuthentications publickey,password +IdentitiesOnly yes +IdentityFile ~/.ssh/victim.pub # public half only (no private key present) +``` +Połącz się i naciśnij Enter przy monicie o hasło (lub wpisz dowolny ciąg): +```bash +ssh gitblit-target +# or Git over SSH +GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://@/ +``` +Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state. + +Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact. + +## Impact + +- Pełne podszycie się pod dowolnego użytkownika Gitblit, który ma co najmniej jeden zarejestrowany SSH public key +- Dostęp do odczytu/zapisu do repozytoriów zgodnie z uprawnieniami ofiary (eksfiltracja kodu źródłowego, nieautoryzowane pushes, ryzyko supply‑chain) +- Potencjalny wpływ administracyjny w przypadku skompromitowania użytkownika z uprawnieniami admina +- Czysty exploit sieciowy; nie wymaga brute force ani private key + +## Detection ideas + +- Przejrzyj logi SSH pod kątem sekwencji, w których próba publickey jest następnie zakończona udanym password authentication z pustym lub bardzo krótkim password +- Szukaj przepływów: metoda publickey oferująca nieobsługiwany/niezgodny materiał klucza, a następnie natychmiastowy sukces password dla tej samej nazwy użytkownika + +## Mitigations + +- Upgrade to Gitblit v1.10.0+ +- Until upgraded: +- Wyłącz Git over SSH w Gitblit, lub +- Ogranicz dostęp sieciowy do usługi SSH, oraz +- Monitoruj wzorce opisane powyżej pod kątem podejrzanej aktywności +- Obetnij/odśwież poświadczenia dotkniętych użytkowników, jeśli podejrzewasz kompromitację + +## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services) + +Pattern: If a server’s public‑key authenticator mutates user/session state during the pre‑signature "key acceptable" phase and other authenticators (e.g., password) trust that state, you can bypass authentication by: + +- Presenting a legitimate public key for the target user (no private key) +- Forcing the client to fail signing so the server falls back to password +- Supplying any password while the password authenticator short‑circuits on leaked state + +Practical tips: + +- Public key harvesting at scale: pull public keys from common sources such as https://github.com/.keys, organizational directories, team pages, leaked authorized_keys +- Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password +- MINA SSHD integration pitfalls: +- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature +- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method + +Related protocol/design notes and literature: +- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process) +- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior + +## References + +- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/) +- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0) +- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/) +- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html) +- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252) + + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index fd2e1be85..6f8475b7a 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -1,4 +1,4 @@ -# Metodologia Pentestingu CI/CD +# Pentesting CI/CD Metodologia {{#include ../banners/hacktricks-training.md}} @@ -6,99 +6,102 @@ ## 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 można znaleźć firmy korzystające z niego na jednej z następujących **platform**: +VCS oznacza **System kontroli wersji**, ten system pozwala deweloperom **zarządzać swoim source code**. Najpopularniejszym z nich jest **git** i zwykle firmy używają go na jednej z następujących **platform**: - Github - Gitlab - Bitbucket - Gitea -- Dostawcy chmury (oferują swoje własne platformy VCS) +- Gitblit +- Cloud providers (oferują własne platformy VCS) -## Pipelines CI/CD -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. +## CI/CD Pipelines -Jednak te systemy muszą być **wykonywane gdzieś** i zazwyczaj z **uprawnieniami uprzywilejowanymi do wdrażania kodu lub dostępu do wrażliwych informacji**. +CI/CD pipelines pozwalają deweloperom **automatyzować wykonywanie code** w różnych celach, włączając budowanie, testowanie i wdrażanie aplikacji. Te zautomatyzowane workflowy są **wyzwalane przez konkretne akcje**, takie jak pushy kodu, pull requests lub zadania zaplanowane. Są przydatne do usprawnienia procesu od developmentu do produkcji. -## Metodologia Pentestingu VCS +Jednakże te systemy muszą być **wykonywane 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ą na tworzenie pipelines, w tej sekcji będziemy analizować tylko potencjalne ataki na kontrolę kodu źródłowego. +> Nawet jeśli niektóre platformy VCS pozwalają na tworzenie pipelines, w tej sekcji przeanalizujemy tylko potencjalne ataki prowadzące do przejęcia kontroli nad source code. -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 mogą być wykorzystywane przez atakujących: +Platformy zawierające source code twojego projektu zawierają wrażliwe informacje i trzeba bardzo uważać na uprawnienia przyznawane w tej platformie. Oto kilka typowych problemów w platformach VCS, które atakujący mógłby 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 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 wiele 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, 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ę). +- **Leaks**: Jeśli twój code zawiera leaki w commitach, a atakujący może uzyskać dostęp do repo (bo jest publiczne lub ma dostęp), może odkryć te leaki. +- **Access**: Jeśli atakujący potrafi **uzyskać dostęp do konta na platformie VCS**, może zyskać **większą widoczność i uprawnienia**. +- **Register**: Niektóre platformy po prostu pozwalają zewnętrznym użytkownikom na stworzenie konta. +- **SSO**: Niektóre platformy nie pozwalają na rejestrację, ale umożliwiają dostęp każdemu z ważnym SSO (więc atakujący mógłby użyć np. swojego github account, 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 pozwalają generować webhooks. Jeśli nie są **chronione** niewidocznymi secretami, **atakujący może je wykorzystać**. +- Jeśli nie ma żadnego secreta, atakujący może wykorzystać webhook z platformy trzeciej +- Jeśli secret znajduje się w URL, dzieje się to samo i atakujący również ma secret +- **Code compromise:** Jeśli złośliwy aktor ma jakikolwiek **write** access do repo, może spróbować **wstrzyknąć złośliwy code**. Aby odnieść sukces może być wymagane **obejście branch protections**. Te działania mogą być wykonane z różnymi celami: +- Skompromitować main branch w celu **skompromitowania produkcji**. +- Skompromitować main (lub inne branche) aby **skompromitować maszyny deweloperów** (ponieważ zwykle wykonują testy, terraform lub inne rzeczy z repo na swoich maszynach). +- **Skompromitować pipeline** (sprawdź następną sekcję) -## Metodologia Pentestingu Pipelines +## 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 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. +Najczęstszy sposób definiowania pipeline to użycie **CI configuration file hostowanego w repository**, które pipeline buduje. Ten plik opisuje kolejność wykonywanych jobów, warunki wpływające na flow i ustawienia środowiska builda.\ +Te pliki zwykle mają spójne nazwy i formaty, 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 job pipeline **pulls the code** z wybranego źródła (np. commit / branch) i **uruchamia polecenia określone w CI configuration file** względem tego code. -Dlatego ostatecznym celem atakującego jest w jakiś sposób **kompromitacja tych plików konfiguracyjnych** lub **poleceń, które wykonują**. +Dlatego ostatecznym celem atakującego jest w jakiś sposób **skompromitować te pliki konfiguracyjne** lub **polecenia, które one wykonują**. -### PPE - Wykonanie Zatrutego Pipeline +### PPE - Poisoned Pipeline Execution -Ś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ń. +Ścieżka Poisoned Pipeline Execution (PPE) wykorzystuje uprawnienia w repo SCM do manipulowania CI pipeline i wykonywania szkodliwych poleceń. Użytkownicy z niezbędnymi uprawnieniami mogą modyfikować CI configuration files lub inne pliki używane przez job pipeline, aby dołączyć złośliwe polecenia. To „zatrucie” CI pipeline prowadzi do wykonania tych złośliwych poleceń. -Aby złośliwy aktor odniósł sukces w przeprowadzeniu ataku PPE, musi być w stanie: +Aby złośliwy aktor odniósł sukces wykonując atak PPE, musi: -- 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**. +- Mieć **write access do platformy VCS**, ponieważ zwykle pipeline są wyzwalane gdy następuje push lub pull request. (Sprawdź VCS pentesting methodology dla podsumowania sposobów zdobycia dostępu). +- Zauważ, że czasami **zewnętrzne PR liczy się jako "write access"**. +- Nawet mając uprawnienia do zapisu, musi mieć pewność, że może **modyfikować CI config file lub inne pliki, na które config polega**. +- W tym celu może być konieczne **obejście branch protections**. -Istnieją 3 smaki PPE: +Istnieją 3 odmiany 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**. +- **D-PPE**: **Direct PPE** występuje, gdy aktor **modyfikuje CI config** file, który będzie wykonywany. +- **I-DDE**: **Indirect PPE** występuje, gdy aktor **modyfikuje** jakiś **file**, na którym polega CI config (np. make file lub terraform config). +- **Public PPE or 3PE**: W niektórych przypadkach pipeliny mogą być **wyzwalane przez użytkowników, którzy nie mają write access do repo** (a którzy mogą nawet nie być częścią organizacji), ponieważ mogą wysłać PR. +- **3PE Command Injection**: Zwykle, CI/CD pipelines 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. przy wykonywaniu poleceń sh), atakujący może **wstrzyknąć tam polecenia**. -### Korzyści z Eksploatacji +### Exploitation Benefits -Znając 3 smaki, aby zatruć pipeline, sprawdźmy, co atakujący mógłby uzyskać po udanej eksploatacji: +Znając 3 odmiany zatrucia pipeline, sprawdźmy co atakujący może uzyskać po pomyślnym exploitowaniu: -- **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 się przemieszczać. -- **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 liczby 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ć uruchamiany w produkcji**. +- **Secrets**: Jak wspomniano wcześniej, pipeline wymagają **uprawnień** dla swoich jobów (pobranie code, build, deploy...) i te uprawnienia są zwykle **przechowywane w secrets**. Te secrets są zwykle dostępne przez **env variables lub pliki w systemie**. Dlatego atakujący zawsze będzie próbował wyeksfiltrować jak najwięcej secrets. +- W zależności od platformy pipeline atakujący **może potrzebować zadeklarować secrets w konfiguracji**. To oznacza, że jeśli atakujący nie może zmodyfikować CI configuration pipeline (**I-PPE** na przykład), mógłby **tylko wyeksfiltrować te secrets, które pipeline posiada**. +- **Computation**: Code jest wykonywany gdzieś — w zależności od miejsca wykonania atakujący może być w stanie pivotować dalej. +- **On-Premises**: Jeśli pipeline wykonują się 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ć** IAM roles/service accounts **tokens**, aby uzyskać **dalszy dostęp w cloud**. +- **Platforms machine**: Czasami joby będą wykonywane na **maszynach platformy pipelines**, które zwykle znajdują się w chmurze bez dodatkowego dostępu. +- **Select it:** Czasami **platforma pipelines będzie miała skonfigurowane kilka maszyn** i jeśli możesz **zmodyfikować CI configuration file**, możesz **wskazać, gdzie chcesz uruchomić złośliwy code**. W takiej sytuacji atakujący prawdopodobnie uruchomi reverse shell na każdej możliwej maszynie, aby spróbować dalej ją eksploatować. +- **Compromise production**: Jeśli znajdujesz się wewnątrz pipeline i finalna wersja jest budowana oraz wdrażana z niego, możesz **skompromitować code, który trafi do środowiska produkcyjnego**. -## Więcej istotnych informacji +## More relevant info -### Narzędzia i Benchmarki CIS +### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/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**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Audyt koncentruje się na całym procesie SDLC, gdzie może ujawnić ryzyka od momentu kodowania do momentu wdrożenia. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) to open-source tool do audytu twojego software supply chain stack pod kątem compliance bezpieczeństwa, oparty na nowym [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Audyt koncentruje się na całym procesie SDLC, gdzie może ujawnić ryzyka od czasu tworzenia code do momentu deployu. -### Top 10 ryzyk bezpieczeństwa CI/CD +### Top 10 CI/CD Security Risk -Sprawdź ten interesujący artykuł na temat 10 największych ryzyk CI/CD według Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Sprawdź interesujący artykuł o top 10 CI/CD risk według Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) -### Laboratoria +### Labs -- 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](https://github.com/cider-security-research/cicd-goat) +- Na każdej platformie, którą możesz uruchomić lokalnie, znajdziesz instrukcję jak ją uruchomić lokalnie, abyś mógł skonfigurować ją według własnych potrzeb i testować. +- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) -### Narzędzia automatyczne +### Automatic Tools -- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** to narzędzie do analizy statycznej kodu dla infrastruktury jako kodu. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** to static code analysis tool dla infrastructure-as-code. -## Referencje +## References - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422) + {{#include ../banners/hacktricks-training.md}}