Información básica de Jenkins

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Acceso

Username + Password

La forma más común de iniciar sesión en Jenkins es con un nombre de usuario o una contraseña.

Si una cookie autorizada es robada, puede usarse para acceder a la sesión del usuario. La cookie suele llamarse JSESSIONID.*. (Un usuario puede terminar todas sus sesiones, pero primero tendría que descubrir que una cookie fue robada).

SSO/Plugins

Jenkins puede configurarse mediante plugins para ser accesible vía SSO de terceros.

Tokens

Los usuarios pueden generar tokens para dar acceso a aplicaciones y que las mismas los suplanten vía CLI o REST API.

SSH Keys

Este componente proporciona un servidor SSH integrado para Jenkins. Es una interfaz alternativa para el Jenkins CLI, y los comandos pueden invocarse de esta manera usando cualquier cliente SSH. (From the docs)

Autorización

En /configureSecurity es posible configurar el método de autorización de Jenkins. Hay varias opciones:

  • Anyone can do anything: Incluso el acceso anónimo puede administrar el servidor.
  • Legacy mode: Igual que Jenkins <1.164. Si tienes el rol “admin”, se te concederá control total sobre el sistema, y de lo contrario (incluyendo usuarios anonymous) tendrás acceso de solo lectura.
  • Logged-in users can do anything: En este modo, cada usuario autenticado obtiene control total de Jenkins. El único usuario que no tendrá control total es el usuario anonymous, que solo obtiene acceso de lectura.
  • Matrix-based security: Puedes configurar quién puede hacer qué en una tabla. Cada columna representa un permiso. Cada fila representa un usuario o un grupo/rol. Esto incluye un usuario especial ‘anonymous’, que representa a usuarios no autenticados, así como ‘authenticated’, que representa a todos los usuarios autenticados.

  • Project-based Matrix Authorization Strategy: Este modo es una extensión a “Matrix-based security” que permite que matrices ACL adicionales sean definidas para cada proyecto por separado.
  • Role-Based Strategy: Permite definir autorizaciones usando una estrategia basada en roles. Gestiona los roles en /role-strategy.

Security Realm

En /configureSecurity es posible configurar el Security Realm. Por defecto Jenkins incluye soporte para varios Security Realms:

  • Delegate to servlet container: Para delegar la autenticación a un servlet container que ejecute el Jenkins controller, como Jetty.
  • Jenkins’ own user database: Usar el almacenamiento de usuarios incorporado de Jenkins para la autenticación en lugar de delegar a un sistema externo. Esto está habilitado por defecto.
  • LDAP: Delegar toda la autenticación a un servidor LDAP configurado, incluyendo usuarios y grupos.
  • Unix user/group database: Delegar la autenticación al sistema Unix de nivel OS subyacente en el Jenkins controller. Este modo también permitirá reutilizar los grupos Unix para autorización.

Los plugins pueden proporcionar Security Realms adicionales que pueden ser útiles para incorporar Jenkins en sistemas de identidad existentes, como:

Jenkins Nodes, Agents & Executors

Definiciones de los docs:

Nodes son las máquinas en las que se ejecutan los agents de build. Jenkins monitoriza cada node conectado en cuanto a espacio en disco, espacio temporal libre, swap libre, hora/sincronización de reloj y tiempo de respuesta. Un node se toma offline si cualquiera de estos valores sale de los umbrales configurados.

Agents gestionan la ejecución de tareas en nombre del Jenkins controller mediante el uso de executors. Un agent puede usar cualquier sistema operativo que soporte Java. Las herramientas necesarias para builds y tests se instalan en el node donde corre el agent; pueden instalarse directamente o en un contenedor (Docker o Kubernetes). Cada agent es efectivamente un proceso con su propio PID en la máquina host.

Un executor es un slot para la ejecución de tareas; efectivamente, es un hilo en el agent. El número de executors en un node define el número de tareas concurrentes que pueden ejecutarse en ese node a la vez. En otras palabras, esto determina el número de concurrent Pipeline stages que pueden ejecutarse en ese node al mismo tiempo.

Jenkins Secrets

Encryption of Secrets and Credentials

Definición de los docs: Jenkins usa AES para cifrar y proteger secrets, credentials y sus respectivas claves de cifrado. Estas claves de cifrado se almacenan en $JENKINS_HOME/secrets/ junto con la master key usada para proteger dichas claves. Este directorio debe configurarse de modo que solo el usuario del sistema operativo con el que corre el Jenkins controller tenga permisos de lectura y escritura en este directorio (p. ej., un valor de chmod de 0700 o usando atributos de archivo apropiados). La master key (a veces referida como “key encryption key” en jerga cripto) está stored _unencrypted_ en el sistema de ficheros del Jenkins controller en $JENKINS_HOME/secrets/master.key, lo cual no protege frente a atacantes con acceso directo a ese fichero. La mayoría de usuarios y desarrolladores usarán estas claves de cifrado indirectamente vía la API Secret para cifrar datos confidenciales genéricos o mediante la credentials API. Para los criptocuriosos, Jenkins usa AES en modo cipher block chaining (CBC) con padding PKCS#5 e IVs aleatorios para cifrar instancias de CryptoConfidentialKey que se almacenan en $JENKINS_HOME/secrets/ con un nombre de fichero correspondiente a su id de CryptoConfidentialKey. IDs de clave comunes incluyen:

  • hudson.util.Secret: usado para secretos genéricos;
  • com.cloudbees.plugins.credentials.SecretBytes.KEY: usado para algunos tipos de credentials;
  • jenkins.model.Jenkins.crumbSalt: usado por el CSRF protection mechanism; y

Credentials Access

Las credentials pueden estar en el scope de proveedores globales (/credentials/) que pueden ser accedidas por cualquier proyecto configurado, o pueden estar en el scope de proyectos específicos (/job/<project-name>/configure) y por tanto solo accesibles desde el proyecto específico.

Según the docs: Las credentials que están en scope se ponen a disposición del pipeline sin limitación. Para prevenir la exposición accidental en el build log, las credentials son enmascaradas en la salida normal, por lo que una invocación de env (Linux) o set (Windows), o programas que imprimen su entorno o parámetros no las revelarán en el build log a usuarios que de otro modo no tendrían acceso a las credentials.

Por eso, para exfiltrar las credenciales, un atacante necesita, por ejemplo, codificarlas en base64.

Secrets in plugin/job configs on disk

No asumas que los secrets están solo en credentials.xml. Muchos plugins persisten secrets en su propio XML global bajo $JENKINS_HOME/*.xml o en el $JENKINS_HOME/jobs/<JOB>/config.xml por trabajo, a veces incluso en texto plano (el enmascaramiento de la UI no garantiza almacenamiento cifrado). Si obtienes acceso de lectura al filesystem, enumera esos XML y busca etiquetas de secret evidentes.

# 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" {} \\;

Referencias

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks