Translated ['src/pentesting-ci-cd/gitblit-security/README.md', 'src/pent

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}}

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/<username>.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/<username>.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 <host-or-ip>
+User <victim-username>
+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://<victim-username>@<host>/<repo.git>
+```
+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/<username>.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}}

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}}