Translated ['src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-

src/pentesting-ci-cd/gitblit-security/README.md

@@ -0,0 +1,21 @@
+# Gitblit Sicherheit
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Was ist Gitblit
+
+Gitblit ist ein selbstgehosteter Git‑Server, geschrieben in Java. Er kann als eigenständiges JAR oder in Servlet‑Containern laufen und stellt einen eingebetteten SSH‑Dienst (Apache MINA SSHD) für Git über SSH bereit.
+
+## Themen
+
+- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#ref}}
+gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
+{{#endref}}
+
+## Referenzen
+
+- [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}}
+
+## Zusammenfassung
+
+CVE-2024-28080 ist eine Authentifizierungsumgehung im embedded SSH‑Service von Gitblit aufgrund fehlerhafter Handhabung des Session‑Zustands bei der Integration mit Apache MINA SSHD. Wenn ein Benutzerkonto mindestens einen registrierten SSH‑Public‑Key hat, kann ein Angreifer, der den Benutzernamen und einen der öffentlichen Schlüssel dieses Benutzers kennt, sich ohne den privaten Schlüssel und ohne Passwort authentifizieren.
+
+- Betroffen: Gitblit < 1.10.0 (beobachtet in 1.9.3)
+- Behoben: 1.10.0
+- Voraussetzungen für die Ausnutzung:
+- Git over SSH enabled on the instance
+- Das Konto des Opfers hat mindestens einen SSH public key in Gitblit registriert
+- Der Angreifer kennt den Benutzernamen des Opfers und einen ihrer öffentlichen Schlüssel (oft auffindbar, z. B. https://github.com/<username>.keys)
+
+## Root cause (state leaks between SSH methods)
+
+In RFC 4252 verläuft die Public‑Key‑Authentifizierung in zwei Phasen: Der Server prüft zunächst, ob ein übergebener Public Key für einen Benutzernamen akzeptabel ist, und erst nach einem Challenge/Response mit einer Signatur authentifiziert er den Benutzer. In MINA SSHD wird der PublickeyAuthenticator zweimal aufgerufen: beim Key‑Acceptance (noch keine Signatur) und später, nachdem der Client eine Signatur zurückgibt.
+
+Der PublickeyAuthenticator von Gitblit veränderte den Session‑Kontext beim ersten, vor der Signatur erfolgenden Aufruf, indem er das authentifizierte UserModel an die Session band und true zurückgab ("key acceptable"). Wenn die Authentifizierung später auf Passwort zurückfiel, vertraute der PasswordAuthenticator dem veränderten Session‑Zustand und machte abkürzend true, ohne das Passwort zu prüfen. Infolgedessen wurde nach einer vorherigen Public‑Key‑"Akzeptanz" für denselben Benutzer jedes Passwort (einschließlich leerer) akzeptiert.
+
+Fehlerhafter Ablauf auf hoher Ebene:
+
+1) Client bietet Benutzernamen + öffentlichen Schlüssel an (noch keine Signatur)  
+2) Server erkennt den Schlüssel als zum Benutzer gehörig, hängt vorzeitig den User an die Session und gibt true zurück ("acceptable")  
+3) Client kann nicht signieren (kein privater Schlüssel), daher fällt die Auth auf Passwort zurück  
+4) Die Passwort‑Authentifizierung sieht bereits einen User in der Session und gibt bedingungslos Erfolg zurück
+
+## Schritt‑für‑Schritt‑Ausnutzung
+
+- Sammle den Benutzernamen des Opfers und einen ihrer öffentlichen Schlüssel:
+- GitHub stellt öffentliche Schlüssel unter https://github.com/<username>.keys bereit
+- Öffentliche Server veröffentlichen oft authorized_keys
+- Konfiguriere OpenSSH so, dass nur die öffentliche Hälfte präsentiert wird, sodass die Signaturerzeugung fehlschlägt und ein Fallback auf Passwort erzwungen wird, während auf dem Server trotzdem der public‑key‑Acceptance‑Pfad ausgelöst wird.
+
+Beispiel SSH‑Client‑Konfiguration (kein privater Schlüssel verfügbar):
+```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)
+```
+Verbinde dich und drücke bei der Passwortaufforderung Enter (oder gib irgendeinen string ein):
+```bash
+ssh gitblit-target
+# or Git over SSH
+GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
+```
+Die Authentifizierung gelingt, weil die vorherige public‑key‑Phase die Session in einen authentifizierten Benutzer verändert hat, und password auth diesem Zustand fälschlicherweise vertraut.
+
+Hinweis: Wenn ControlMaster‑Multiplexing in Ihrer SSH‑Konfiguration aktiviert ist, können nachfolgende Git‑Befehle die bereits authentifizierte Verbindung wiederverwenden, wodurch die Auswirkungen steigen.
+
+## Impact
+
+- Vollständige Identitätsübernahme (Impersonation) jedes Gitblit‑Benutzers mit mindestens einem registrierten SSH public key
+- Lese-/Schreibzugriff auf Repositories entsprechend den Rechten des Opfers (Quellcode‑Exfiltration, unautorisierte Pushes, Supply‑Chain‑Risiken)
+- Potenzieller administrativer Schaden bei Angriff auf einen Admin‑Benutzer
+- Reiner Netzwerk‑Exploit; kein Brute‑Force oder privater Schlüssel erforderlich
+
+## Detection ideas
+
+- Überprüfen Sie SSH‑Logs auf Sequenzen, in denen ein publickey‑Versuch von einer erfolgreichen password‑Authentifizierung mit einem leeren oder sehr kurzen Passwort gefolgt wird
+- Suchen Sie nach Abläufen: publickey‑Methode bietet nicht unterstütztes/fehlangepasstes Schlüsselmaterial an, gefolgt von sofortigem Passwort‑Erfolg für denselben Benutzernamen
+
+## Mitigations
+
+- Upgrade to Gitblit v1.10.0+
+- Until upgraded:
+- Disable Git over SSH on Gitblit, or
+- Restrict network access to the SSH service, and
+- Monitor for suspicious patterns described above
+- Rotate affected user credentials if compromise is suspected
+
+## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+
+Muster: Wenn der public‑key‑Authenticator eines Servers Benutzer-/Session‑Zustand während der pre‑signature "key acceptable"‑Phase mutiert und andere Authenticators (z. B. password) diesem Zustand vertrauen, kann die Authentifizierung wie folgt umgangen werden:
+
+- Vorzeigen eines legitimen public key des Zielbenutzers (kein privater Schlüssel)
+- Den Client zum Signaturfehler zwingen, sodass der Server auf password zurückfällt
+- Beliebiges Passwort eingeben, während der password‑Authenticator aufgrund des leaked state kurzschließt
+
+Praktische Tipps:
+
+- 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 @@
-# Pentesting CI/CD Methodologie
+# Pentesting CI/CD Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,99 +6,102 @@
 
 ## VCS
 
-VCS steht für **Version Control System**, dieses System ermöglicht Entwicklern, ihren **Quellcode zu verwalten**. Das gebräuchlichste ist **git** und Sie werden normalerweise Unternehmen finden, die es auf einer der folgenden **Plattformen** verwenden:
+VCS stands for **Version Control System**, dieses System ermöglicht Entwicklern, ihren **Source Code zu verwalten**. Das gebräuchlichste ist **git** und man findet es in der Regel bei Unternehmen auf einer der folgenden **Plattformen**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
-- Cloud-Anbieter (sie bieten ihre eigenen VCS-Plattformen an)
+- Gitblit
+- Cloud providers (they offer their own VCS platforms)
+
 
 ## CI/CD Pipelines
 
-CI/CD-Pipelines ermöglichen es Entwicklern, die **Ausführung von Code** für verschiedene Zwecke zu **automatisieren**, einschließlich des Erstellens, Testens und Bereitstellens von Anwendungen. Diese automatisierten Workflows werden durch **spezifische Aktionen** ausgelöst, wie z.B. Code-Pushes, Pull-Requests oder geplante Aufgaben. Sie sind nützlich, um den Prozess von der Entwicklung bis zur Produktion zu optimieren.
+CI/CD pipelines ermöglichen Entwicklern, die **Ausführung von Code zu automatisieren** für verschiedene Zwecke, einschließlich Build, Tests und Deployment von Anwendungen. Diese automatisierten Workflows werden durch **bestimmte Aktionen ausgelöst**, wie z. B. code pushes, pull requests oder geplante Tasks. Sie sind nützlich, um den Prozess von der Entwicklung zur Produktion zu straffen.
 
-Diese Systeme müssen jedoch **irgendwo ausgeführt werden** und normalerweise mit **privilegierten Anmeldeinformationen, um Code bereitzustellen oder auf sensible Informationen zuzugreifen**.
+Allerdings müssen diese Systeme **irgendwo ausgeführt** werden und oft mit **privilegierten Credentials, um Code zu deployen oder auf sensitive Informationen zuzugreifen**.
 
-## VCS Pentesting Methodologie
+## VCS Pentesting Methodology
 
 > [!NOTE]
-> Auch wenn einige VCS-Plattformen das Erstellen von Pipelines erlauben, werden wir in diesem Abschnitt nur potenzielle Angriffe auf die Kontrolle des Quellcodes analysieren.
+> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
 
-Plattformen, die den Quellcode Ihres Projekts enthalten, enthalten sensible Informationen, und die Menschen müssen sehr vorsichtig mit den innerhalb dieser Plattform gewährten Berechtigungen sein. Dies sind einige häufige Probleme auf VCS-Plattformen, die Angreifer ausnutzen könnten:
+Plattformen, die den Source Code deines Projekts enthalten, bergen sensitive Informationen und es ist wichtig, sehr sorgfältig mit den vergebenen Berechtigungen innerhalb dieser Plattform umzugehen. Dies sind einige häufige Probleme in VCS Plattformen, die ein Angreifer ausnutzen könnte:
 
-- **Leaks**: Wenn Ihr Code Leaks in den Commits enthält und der Angreifer auf das Repo zugreifen kann (weil es öffentlich ist oder weil er Zugriff hat), könnte er die Leaks entdecken.
-- **Zugriff**: Wenn ein Angreifer **Zugriff auf ein Konto innerhalb der VCS-Plattform** hat, könnte er **mehr Sichtbarkeit und Berechtigungen** erlangen.
-- **Registrierung**: Einige Plattformen erlauben externen Benutzern nur, ein Konto zu erstellen.
-- **SSO**: Einige Plattformen erlauben es Benutzern nicht, sich zu registrieren, erlauben jedoch jedem, mit einem gültigen SSO zuzugreifen (ein Angreifer könnte beispielsweise sein Github-Konto verwenden, um einzutreten).
-- **Anmeldeinformationen**: Benutzername+Pwd, persönliche Tokens, ssh-Schlüssel, Oauth-Tokens, Cookies... es gibt verschiedene Arten von Tokens, die ein Benutzer stehlen könnte, um auf irgendeine Weise auf ein Repo zuzugreifen.
-- **Webhooks**: VCS-Plattformen erlauben das Generieren von Webhooks. Wenn sie **nicht geschützt** sind mit nicht sichtbaren Geheimnissen, könnte ein **Angreifer sie ausnutzen**.
-- Wenn kein Geheimnis vorhanden ist, könnte der Angreifer den Webhook der Drittanbieterplattform ausnutzen.
-- Wenn das Geheimnis in der URL ist, passiert dasselbe und der Angreifer hat auch das Geheimnis.
-- **Code-Kompromittierung:** Wenn ein böswilliger Akteur eine Art von **Schreibzugriff** auf die Repos hat, könnte er versuchen, **bösartigen Code einzuschleusen**. Um erfolgreich zu sein, muss er möglicherweise **Branch-Schutzmaßnahmen umgehen**. Diese Aktionen können mit verschiedenen Zielen im Hinterkopf durchgeführt werden:
-- Kompromittierung des Hauptzweigs, um **die Produktion zu gefährden**.
-- Kompromittierung des Hauptzweigs (oder anderer Zweige), um **Entwicklermaschinen zu gefährden** (da sie normalerweise Tests, Terraform oder andere Dinge auf ihren Maschinen im Repo ausführen).
-- **Kompromittierung der Pipeline** (siehe nächsten Abschnitt).
+- **Leaks**: Wenn dein Code Leaks in den Commits enthält und der Angreifer auf das Repo zugreifen kann (weil es public ist oder weil er Zugriff hat), könnte er diese Leaks entdecken.
+- **Access**: Wenn ein Angreifer **Zugriff auf ein Konto innerhalb der VCS platform** erhält, könnte er **mehr Sichtbarkeit und Berechtigungen** erlangen.
+- **Register**: Manche Plattformen erlauben es externen Benutzern einfach, ein Konto zu erstellen.
+- **SSO**: Manche Plattformen erlauben keine Registrierung, aber jeder mit einem gültigen SSO kann zugreifen (z. B. könnte ein Angreifer sein Github-Konto verwenden, um zuzugreifen).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... es gibt mehrere Arten von Tokens, die ein Benutzer stehlen könnte, um auf irgendeine Weise auf ein Repo zuzugreifen.
+- **Webhooks**: VCS platforms erlauben das Erstellen von webhooks. Wenn diese **nicht mit nicht sichtbaren Secrets geschützt** sind, könnte ein **Angreifer sie missbrauchen**.
+  - Wenn kein Secret vorhanden ist, könnte der Angreifer den Webhook der Drittanbieter-Plattform missbrauchen.
+  - Wenn das Secret in der URL steckt, gilt das Gleiche und der Angreifer hat das Secret ebenfalls.
+- **Code compromise:** Wenn ein böswilliger Akteur irgendeine Art von **write**-Zugriff auf die Repos hat, könnte er versuchen, **malicious code zu injecten**. Um erfolgreich zu sein, muss er möglicherweise Branch-Protections **bypassen**. Diese Aktionen können mit unterschiedlichen Zielen ausgeführt werden:
+  - Kompromittiere den main branch, um die **Production zu kompromittieren**.
+  - Kompromittiere den main (oder andere Branches), um **Entwickler-Maschinen zu kompromittieren** (da diese normalerweise Tests, terraform oder andere Dinge im Repo auf ihren Maschinen ausführen).
+  - **Compromise the pipeline** (siehe nächsten Abschnitt)
 
-## Pipelines Pentesting Methodologie
+## Pipelines Pentesting Methodology
 
-Der gebräuchlichste Weg, eine Pipeline zu definieren, besteht darin, eine **CI-Konfigurationsdatei, die im Repository gehostet wird**, zu verwenden, das die Pipeline erstellt. Diese Datei beschreibt die Reihenfolge der ausgeführten Jobs, Bedingungen, die den Ablauf beeinflussen, und Einstellungen der Build-Umgebung.\
-Diese Dateien haben typischerweise einen konsistenten Namen und ein konsistentes Format, zum Beispiel — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) und die GitHub Actions YAML-Dateien, die sich unter .github/workflows befinden. Wenn sie ausgelöst werden, **zieht der Pipeline-Job den Code** aus der ausgewählten Quelle (z.B. Commit / Branch) und **führt die im CI-Konfigurationsdatei angegebenen Befehle** gegen diesen Code aus.
+Die gebräuchlichste Art, eine Pipeline zu definieren, ist die Verwendung einer **CI configuration file, die im Repository gehostet** wird, das die Pipeline baut. Diese Datei beschreibt die Reihenfolge der ausgeführten Jobs, Bedingungen, die den Ablauf beeinflussen, und Einstellungen der Build-Umgebung.\
+Diese Dateien haben typischerweise einen konsistenten Namen und ein Format, z. B. — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), und die GitHub Actions YAML Dateien unter .github/workflows. Wenn die Pipeline ausgelöst wird, **holt der Pipeline-Job den Code** aus der gewählten Quelle (z. B. Commit / Branch) und **führt die in der CI configuration file angegebenen Befehle** gegen diesen Code aus.
 
-Daher ist das ultimative Ziel des Angreifers, auf irgendeine Weise **diese Konfigurationsdateien** oder die **Befehle, die sie ausführen**, zu **kompromittieren**.
+Das ultimative Ziel des Angreifers ist daher, diese Konfigurationsdateien oder die Befehle, die sie ausführen, auf irgendeine Weise zu **compromisen**.
 
-### PPE - Vergiftete Pipeline-Ausführung
+### PPE - Poisoned Pipeline Execution
 
-Der Vergiftete Pipeline-Ausführungs (PPE) Pfad nutzt Berechtigungen in einem SCM-Repository aus, um eine CI-Pipeline zu manipulieren und schädliche Befehle auszuführen. Benutzer mit den erforderlichen Berechtigungen können CI-Konfigurationsdateien oder andere Dateien, die vom Pipeline-Job verwendet werden, ändern, um bösartige Befehle einzuschließen. Dies "vergiftet" die CI-Pipeline und führt zur Ausführung dieser bösartigen Befehle.
+Der Poisoned Pipeline Execution (PPE) Pfad nutzt Berechtigungen in einem SCM Repository aus, um eine CI Pipeline zu manipulieren und schädliche Befehle auszuführen. Benutzer mit den nötigen Berechtigungen können CI config Dateien oder andere Dateien, die vom Pipeline-Job verwendet werden, modifizieren, um bösartige Befehle einzufügen. Dadurch wird die CI Pipeline "poisoned" und diese bösartigen Befehle ausgeführt.
 
-Damit ein böswilliger Akteur bei einem PPE-Angriff erfolgreich ist, muss er in der Lage sein:
+Damit ein böswilliger Akteur einen PPE-Angriff erfolgreich durchführen kann, muss er:
 
-- **Schreibzugriff auf die VCS-Plattform** zu haben, da Pipelines normalerweise ausgelöst werden, wenn ein Push oder ein Pull-Request durchgeführt wird. (Überprüfen Sie die VCS-Pentesting-Methodologie für eine Zusammenfassung der Möglichkeiten, Zugriff zu erhalten).
-- Beachten Sie, dass manchmal ein **externer PR als "Schreibzugriff" zählt**.
-- Selbst wenn er Schreibberechtigungen hat, muss er sicherstellen, dass er die **CI-Konfigurationsdatei oder andere Dateien, auf die die Konfiguration angewiesen ist**, **ändern** kann.
-- Dazu muss er möglicherweise in der Lage sein, **Branch-Schutzmaßnahmen zu umgehen**.
+- **Write access to the VCS platform** haben, da Pipelines in der Regel ausgelöst werden, wenn ein Push oder ein Pull Request erfolgt. (Siehe die VCS pentesting methodology für eine Zusammenfassung der Wege, um Zugriff zu erhalten).
+- Beachte, dass manchmal ein **external PR als "write access"** gilt.
+- Selbst wenn er write permissions hat, muss er sicherstellen können, dass er die **CI config file oder andere Dateien, auf die die Config angewiesen ist, modifizieren** kann.
+- Dafür muss er möglicherweise Branch-Protections **bypassen**.
 
 Es gibt 3 PPE-Varianten:
 
-- **D-PPE**: Ein **Direkter PPE**-Angriff tritt auf, wenn der Akteur die **CI-Konfigurationsdatei** ändert, die ausgeführt werden soll.
-- **I-DDE**: Ein **Indirekter PPE**-Angriff tritt auf, wenn der Akteur eine **Datei** ändert, auf die die CI-Konfigurationsdatei, die ausgeführt werden soll, **angewiesen ist** (wie eine Make-Datei oder eine Terraform-Konfiguration).
-- **Öffentlicher PPE oder 3PE**: In einigen Fällen können die Pipelines von Benutzern **ausgelöst werden, die keinen Schreibzugriff im Repo haben** (und die möglicherweise nicht einmal Teil der Organisation sind), weil sie einen PR senden können.
-- **3PE-Befehlsinjektion**: Normalerweise setzen CI/CD-Pipelines **Umgebungsvariablen** mit **Informationen über den PR**. Wenn dieser Wert von einem Angreifer kontrolliert werden kann (wie der Titel des PR) und in einem **gefährlichen Ort** (wie der Ausführung von **sh-Befehlen**) **verwendet** wird, könnte ein Angreifer **Befehle dort injizieren**.
+- **D-PPE**: Ein **Direct PPE** Angriff tritt auf, wenn der Akteur die **CI config** Datei direkt **modifiziert**, die ausgeführt werden soll.
+- **I-DDE**: Ein **Indirect PPE** Angriff tritt auf, wenn der Akteur eine **Datei modifiziert**, auf die die CI config angewiesen ist (z. B. ein Makefile oder eine terraform config).
+- **Public PPE or 3PE**: In einigen Fällen können Pipelines von Benutzern ausgelöst werden, die **kein write access im Repo** haben (und vielleicht nicht einmal Teil der Org sind), weil sie ein PR senden können.
+- **3PE Command Injection**: Üblicherweise setzen CI/CD pipelines **environment variables** mit **Informationen über den PR**. Wenn dieser Wert vom Angreifer kontrolliert werden kann (z. B. der Titel des PR) und an einer **gefährlichen Stelle** verwendet wird (z. B. beim Ausführen von **sh commands**), könnte ein Angreifer **Befehle injizieren**.
 
-### Ausbeutungsnutzen
+### Exploitation Benefits
 
-Wenn man die 3 Varianten kennt, um eine Pipeline zu vergiften, lassen Sie uns überprüfen, was ein Angreifer nach einer erfolgreichen Ausbeutung erhalten könnte:
+Wenn man die 3 Varianten kennt, schauen wir uns an, was ein Angreifer nach erfolgreicher Exploitation erreichen könnte:
 
-- **Geheimnisse**: Wie bereits erwähnt, erfordern Pipelines **Berechtigungen** für ihre Jobs (den Code abrufen, ihn erstellen, bereitstellen...) und diese Berechtigungen werden normalerweise **in Geheimnissen gewährt**. Diese Geheimnisse sind normalerweise über **Umgebungsvariablen oder Dateien im System** zugänglich. Daher wird ein Angreifer immer versuchen, so viele Geheimnisse wie möglich zu exfiltrieren.
-- Abhängig von der Pipeline-Plattform muss der Angreifer möglicherweise **die Geheimnisse in der Konfiguration angeben**. Das bedeutet, dass, wenn der Angreifer die CI-Konfigurationspipeline nicht ändern kann (**I-PPE** zum Beispiel), er **nur die Geheimnisse exfiltrieren könnte, die diese Pipeline hat**.
-- **Berechnung**: Der Code wird irgendwo ausgeführt, abhängig davon, wo er ausgeführt wird, könnte ein Angreifer in der Lage sein, weiter zu pivotieren.
-- **Vor Ort**: Wenn die Pipelines vor Ort ausgeführt werden, könnte ein Angreifer in einem **internen Netzwerk mit Zugang zu mehr Ressourcen** enden.
-- **Cloud**: Der Angreifer könnte auf **andere Maschinen in der Cloud** zugreifen, könnte aber auch **IAM-Rollen/Dienstkonten-Tokens** von dort **exfiltrieren**, um **weiteren Zugang innerhalb der Cloud** zu erhalten.
-- **Plattformmaschine**: Manchmal werden die Jobs innerhalb der **Pipelines-Plattformmaschinen** ausgeführt, die sich normalerweise in einer Cloud mit **keinem weiteren Zugang** befinden.
-- **Wählen Sie es aus:** Manchmal hat die **Pipelines-Plattform mehrere Maschinen konfiguriert**, und wenn Sie die **CI-Konfigurationsdatei ändern können**, können Sie **angeben, wo Sie den bösartigen Code ausführen möchten**. In dieser Situation wird ein Angreifer wahrscheinlich auf jeder möglichen Maschine eine Reverse-Shell ausführen, um zu versuchen, sie weiter auszunutzen.
-- **Kompromittierung der Produktion**: Wenn Sie sich innerhalb der Pipeline befinden und die endgültige Version von dort erstellt und bereitgestellt wird, könnten Sie **den Code kompromittieren, der letztendlich in der Produktion ausgeführt wird**.
+- **Secrets**: Wie bereits erwähnt, benötigen Pipelines **Privilegien** für ihre Jobs (Code abrufen, bauen, deployen ...) und diese Privilegien werden üblicherweise in **Secrets** hinterlegt. Diese Secrets sind oft über **env variables oder Dateien im System** zugänglich. Daher wird ein Angreifer immer versuchen, so viele Secrets wie möglich zu exfiltrieren.
+- Abhängig von der Pipeline-Plattform **muss der Angreifer die Secrets vielleicht in der Config angeben**. Das bedeutet, wenn der Angreifer die CI configuration pipeline nicht ändern kann (z. B. bei I-PPE), könnte er **nur die Secrets exfiltrieren, die diese Pipeline bereits hat**.
+- **Computation**: Der Code wird irgendwo ausgeführt; abhängig davon, wo, könnte ein Angreifer weiter pivotieren.
+- **On-Premises**: Wenn die Pipelines on-premises ausgeführt werden, könnte ein Angreifer in einem **internen Netzwerk** landen mit Zugriff auf weitere Ressourcen.
+- **Cloud**: Der Angreifer könnte **andere Maschinen in der Cloud** erreichen, aber auch IAM roles/service accounts **tokens** exfiltrieren, um **weiteren Zugang in der Cloud** zu erhalten.
+- **Platforms machine**: Manchmal werden Jobs innerhalb der **Pipelines platform machines** ausgeführt, die normalerweise in einer Cloud laufen und **keinen weiteren Zugang** haben.
+- **Select it:** Manchmal hat die **Pipelines platform mehrere Maschinen konfiguriert** und wenn du die CI config ändern kannst, kannst du **angeben, wo der malicious code laufen soll**. In diesem Fall wird ein Angreifer wahrscheinlich auf jeder möglichen Maschine eine Reverse Shell starten, um weiter zu versuchen, sie auszunutzen.
+- **Compromise production**: Wenn du in der Pipeline bist und die finale Version von dort gebaut und deployed wird, könntest du den Code kompromittieren, der letztlich in Production läuft.
 
-## Weitere relevante Informationen
+## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ist ein Open-Source-Tool zur Überprüfung Ihres Software-Lieferketten-Stacks auf Sicherheitskonformität basierend auf einem neuen [**CIS Software Supply Chain Benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Die Überprüfung konzentriert sich auf den gesamten SDLC-Prozess, in dem Risiken von der Codezeit bis zur Bereitstellungszeit aufgedeckt werden können.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ist ein Open-Source-Tool zur Auditierung deiner Software Supply Chain für Security Compliance, basierend auf einem neuen [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Das Audit konzentriert sich auf den gesamten SDLC-Prozess und kann Risiken von Code bis Deploy aufdecken.
 
-### Top 10 CI/CD Sicherheitsrisiken
+### Top 10 CI/CD Security Risk
 
-Überprüfen Sie diesen interessanten Artikel über die Top 10 CI/CD-Risiken laut Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Siehe diesen interessanten Artikel über die Top 10 CI/CD Risiken laut Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Auf jeder Plattform, die Sie lokal ausführen können, finden Sie, wie Sie sie lokal starten können, damit Sie sie nach Ihren Wünschen konfigurieren können, um sie zu testen.
-- Gitea + Jenkins Lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
+- Für jede Plattform, die du lokal ausführen kannst, findest du Anleitungen, wie du sie lokal startest, damit du sie nach Belieben konfigurieren und testen kannst.
+- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
-### Automatische Tools
+### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ist ein statisches Code-Analyse-Tool für Infrastruktur als Code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ist ein statisches Code-Analyse-Tool für infrastructure-as-code.
 
-## Referenzen
+## 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}}