Jenkins Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jenkins es una herramienta que ofrece un método sencillo para establecer un entorno de integración continua o entrega continua (CI/CD) para casi cualquier combinación de lenguajes de programación y repositorios de código fuente utilizando pipelines. Además, automatiza varias tareas rutinarias de desarrollo. Aunque Jenkins no elimina la necesidad de crear scripts para pasos individuales, proporciona una forma más rápida y robusta de integrar toda la secuencia de herramientas de construcción, prueba y despliegue que uno puede construir manualmente.
Basic Jenkins InformationPara buscar páginas interesantes de Jenkins sin autenticación como (/people o /asynchPeople, que lista los usuarios actuales) puedes usar:
Verifica si puedes ejecutar comandos sin necesidad de autenticación:
Sin credenciales, puedes mirar dentro de la ruta /asynchPeople/ o /securityRealm/user/admin/search/index?q= para nombres de usuario.
Es posible que puedas obtener la versión de Jenkins desde la ruta /oops o /error.
En la información básica puedes verificar todas las formas de iniciar sesión en Jenkins:
Basic Jenkins InformationPodrás encontrar instancias de Jenkins que te permiten crear una cuenta e iniciar sesión en ella. Tan simple como eso.
Además, si la funcionalidad/plugins de SSO están presentes, entonces deberías intentar iniciar sesión en la aplicación usando una cuenta de prueba (es decir, una cuenta de prueba de Github/Bitbucket). Truco de aquí.
Jenkins carece de política de contraseñas y mitigación de fuerza bruta de nombres de usuario. Es esencial realizar fuerza bruta a los usuarios ya que contraseñas débiles o nombres de usuario como contraseñas pueden estar en uso, incluso nombres de usuario invertidos como contraseñas.
Usa este script de python o este script de powershell.
Muchas organizaciones combinan sistemas de gestión de control de versiones (SCM) basados en SaaS como GitHub o GitLab con una solución CI interna y autohospedada como Jenkins o TeamCity. Esta configuración permite que los sistemas CI reciban eventos de webhook de los proveedores de control de versiones SaaS, principalmente para activar trabajos de pipeline.
Para lograr esto, las organizaciones agregan a la lista blanca los rangos de IP de las plataformas SCM, permitiéndoles acceder al sistema CI interno a través de webhooks. Sin embargo, es importante tener en cuenta que cualquiera puede crear una cuenta en GitHub o GitLab y configurarla para activar un webhook, enviando potencialmente solicitudes al sistema CI interno.
En estos escenarios vamos a suponer que tienes una cuenta válida para acceder a Jenkins.
Dependiendo del mecanismo de Autorización configurado en Jenkins y los permisos del usuario comprometido, podrías o no poder realizar los siguientes ataques.
Para más información, consulta la información básica:
Basic Jenkins InformationSi has accedido a Jenkins, puedes listar otros usuarios registrados en http://127.0.0.1:8080/asynchPeople/
Usa este script para volcar las salidas de consola de las construcciones y las variables de entorno de construcción para encontrar, con suerte, secretos en texto claro.
Si el usuario comprometido tiene suficientes privilegios para crear/modificar un nuevo nodo de Jenkins y las credenciales SSH ya están almacenadas para acceder a otros nodos, podría robar esas credenciales creando/modificando un nodo y configurando un host que registrará las credenciales sin verificar la clave del host:
Normalmente encontrarás las credenciales ssh de Jenkins en un proveedor global (/credentials/
), así que también puedes volcarlas como lo harías con cualquier otro secreto. Más información en la sección de volcado de secretos.
Obtener un shell en el servidor de Jenkins le da al atacante la oportunidad de filtrar todos los secretos y variables de entorno y de explotar otras máquinas ubicadas en la misma red o incluso reunir credenciales de la nube.
Por defecto, Jenkins se ejecutará como SYSTEM. Por lo tanto, comprometerlo le dará al atacante privilegios de SYSTEM.
Crear/Modificar un proyecto es una forma de obtener RCE sobre el servidor de Jenkins:
Jenkins RCE Creating/Modifying ProjectTambién puedes obtener RCE ejecutando un script Groovy, que podría ser más sigiloso que crear un nuevo proyecto:
Jenkins RCE with Groovy ScriptTambién puedes obtener RCE creando/modificando un pipeline:
Jenkins RCE Creating/Modifying PipelinePara explotar pipelines aún necesitas tener acceso a Jenkins.
Pipelines también pueden ser utilizados como mecanismo de construcción en proyectos, en ese caso se puede configurar un archivo dentro del repositorio que contendrá la sintaxis del pipeline. Por defecto se usa /Jenkinsfile
:
También es posible almacenar archivos de configuración de pipeline en otros lugares (en otros repositorios, por ejemplo) con el objetivo de separar el acceso al repositorio y el acceso al pipeline.
Si un atacante tiene acceso de escritura sobre ese archivo, podrá modificarlo y potencialmente activar el pipeline sin siquiera tener acceso a Jenkins. Es posible que el atacante necesite eludir algunas protecciones de rama (dependiendo de la plataforma y los privilegios del usuario, podrían ser eludidas o no).
Los desencadenantes más comunes para ejecutar un pipeline personalizado son:
Solicitud de extracción a la rama principal (o potencialmente a otras ramas)
Empujar a la rama principal (o potencialmente a otras ramas)
Actualizar la rama principal y esperar hasta que se ejecute de alguna manera
Si eres un usuario externo, no deberías esperar crear un PR a la rama principal del repositorio de otro usuario/organización y activar el pipeline... pero si está mal configurado, podrías comprometer completamente a las empresas solo explotando esto.
En la sección anterior de RCE ya se indicó una técnica para obtener RCE modificando un pipeline.
Es posible declarar variables de entorno en texto claro para todo el pipeline o para etapas específicas. Estas variables de entorno no deberían contener información sensible, pero un atacante siempre podría verificar todas las configuraciones del pipeline/Jenkinsfiles:
Para obtener información sobre cómo se tratan generalmente los secretos en Jenkins, consulta la información básica:
Basic Jenkins InformationLas credenciales pueden ser alcanzadas por proveedores globales (/credentials/
) o por proyectos específicos (/job/<project-name>/configure
). Por lo tanto, para exfiltrar todas ellas, necesitas comprometer al menos todos los proyectos que contienen secretos y ejecutar pipelines personalizados/contaminados.
Hay otro problema, para obtener un secreto dentro del env de un pipeline necesitas conocer el nombre y tipo del secreto. Por ejemplo, si intentas cargar un secreto de usernamePassword
como un secreto de string
, obtendrás este error:
Aquí tienes la forma de cargar algunos tipos de secretos comunes:
Al final de esta página puedes encontrar todos los tipos de credenciales: https://www.jenkins.io/doc/pipeline/steps/credentials-binding/
La mejor manera de volcar todos los secretos a la vez es comprometiendo la máquina de Jenkins (ejecutando un shell inverso en el nodo incorporado, por ejemplo) y luego filtrando las claves maestras y los secretos encriptados y desencriptándolos sin conexión. Más sobre cómo hacer esto en la sección de Nodos y Agentes y en la sección de Post Explotación.
De la documentación: La directiva triggers
define las maneras automatizadas en las que el Pipeline debe ser reactivado. Para Pipelines que están integrados con una fuente como GitHub o BitBucket, triggers
puede no ser necesario ya que la integración basada en webhooks probablemente ya esté presente. Los disparadores actualmente disponibles son cron
, pollSCM
y upstream
.
Ejemplo de Cron:
Check otros ejemplos en la documentación.
Una instancia de Jenkins puede tener diferentes agentes corriendo en diferentes máquinas. Desde la perspectiva de un atacante, el acceso a diferentes máquinas significa diferentes credenciales de nube potenciales para robar o diferente acceso a la red que podría ser abusado para explotar otras máquinas.
Para más información, consulta la información básica:
Basic Jenkins InformationPuedes enumerar los nodos configurados en /computer/
, generalmente encontrarás el Built-In Node
(que es el nodo que ejecuta Jenkins) y potencialmente más:
Es especialmente interesante comprometer el nodo Built-In porque contiene información sensible de Jenkins.
Para indicar que deseas ejecutar el pipeline en el nodo de Jenkins incorporado, puedes especificar dentro del pipeline la siguiente configuración:
Pipeline en un agente específico, con un desencadenador cron, con variables de entorno de pipeline y etapa, cargando 2 variables en un paso y enviando un reverse shell:
Puedes listar los secretos accediendo a /credentials/
si tienes suficientes permisos. Ten en cuenta que esto solo listará los secretos dentro del archivo credentials.xml
, pero los archivos de configuración de construcción también pueden tener más credenciales.
Si puedes ver la configuración de cada proyecto, también puedes ver allí los nombres de las credenciales (secretos) que se utilizan para acceder al repositorio y otras credenciales del proyecto.
Estos archivos son necesarios para desencriptar los secretos de Jenkins:
secrets/master.key
secrets/hudson.util.Secret
Tales secretos generalmente se pueden encontrar en:
credentials.xml
jobs/.../build.xml
jobs/.../config.xml
Aquí hay una regex para encontrarlos:
Si has volcado las contraseñas necesarias para descifrar los secretos, utiliza este script para descifrar esos secretos.
Accede al archivo Jenkins config.xml en /var/lib/jenkins/config.xml
o C:\Program Files (x86)\Jenkins\
Busca la palabra <useSecurity>true</useSecurity>
y cambia la palabra true
a false
.
sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml
Reinicia el servidor Jenkins: service jenkins restart
Ahora ve al portal de Jenkins nuevamente y Jenkins no pedirá ninguna credencial esta vez. Navega a "Manage Jenkins" para establecer la contraseña de administrador nuevamente.
Habilita la seguridad nuevamente cambiando la configuración a <useSecurity>true</useSecurity>
y reinicia Jenkins nuevamente.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)