Basic Jenkins Information

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Zugriff

Benutzername + Passwort

Der häufigste Weg, sich bei Jenkins anzumelden, ist mit Benutzername und Passwort.

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 per Plugins so konfiguriert werden, dass es via third party SSO erreichbar ist.

Tokens

Benutzer können Tokens generieren, um Anwendungen Zugriff zu gewähren, damit diese sie über CLI oder REST API impersonieren können.

SSH Keys

This component provides a built-in SSH server for Jenkins. It’s an alternative interface for the Jenkins CLI, and commands can be invoked this way using any SSH client. (Aus den docs)

Autorisierung

In /configureSecurity ist es möglich, die authorization method von Jenkins zu konfigurieren. Es gibt mehrere Optionen:

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

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

Security Realm

In /configureSecurity ist es möglich, das security realm zu konfigurieren. Standardmäßig unterstützt Jenkins einige verschiedene Security Realms:

  • Delegate to servlet container: Für das Delegieren der Authentifizierung an einen Servlet-Container, der den Jenkins-Controller ausführt, z. B. 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 Security Realms bereitstellen, die nützlich sein können, um Jenkins in bestehende Identity-Systeme zu integrieren, wie z. B.:

Jenkins Nodes, Agents & Executors

Definitionen aus den docs:

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.

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 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 Secrets

Encryption of Secrets and Credentials

Definition from the docs: 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 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 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: 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; and

Credentials Access

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 the docs: 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 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.

# 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

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks