CVE-2024-23897: Jenkins

Resumen

• CVE-2024-23897, anunciado el 24 de enero de 2024, es una vulnerabilidad en Jenkins CI/CD, que puede resultar en la lectura de archivos arbitrarios.
• A 30 de enero de 2024, Censys ha observado 83.509 servidores Jenkins en Internet, de los cuales 79.952 (~96%) son potencialmente vulnerables.
• Se insta a los usuarios a actualizar a Jenkins 2.442 para la versión estándar de Jenkins y a 2.426.3 para las ediciones Long-Term Support (LTS).
• Siempre que sea posible, los servidores Jenkins no deben estar conectados directamente a Internet.

Introducción

Servidores Jenkins en Internet.

El 24 de enero de 2024, se anunció una vulnerabilidad de nivel crítico para el sistema de Integración Continua y Despliegue Continuo (CI/CD) Jenkins, que actualmente está siendo rastreada como CVE-2024-23897(vendor advisory 3314). Cuando se tiene éxito, un atacante no autenticado podría utilizar una Ejecución Remota de Código (RCE) para facilitar el trabajo de lectura de archivos arbitrarios (con algunas salvedades).

Con la configuración por defecto, un atacante no autenticado no tiene permisos por defecto y sólo puede leer las dos o tres primeras líneas de un archivo de texto plano arbitrario. Cuando está autenticado, un atacante puede ver la totalidad de cualquier archivo de texto plano .

Por otro lado, si el servidor Jenkins se ha configurado con una de las dos opciones "peligrosas" que se indican a continuación:

• "Permitir a los usuarios registrarse"
• "Permitir acceso anónimo de lectura"

Los usuarios con los permisos anteriores activados pueden leer la totalidad de los archivos tanto de texto plano como binarios (aunque los archivos binarios se convierten a texto plano).

El problema proviene de una de las bibliotecas de programación que Jenkins utiliza para analizar los argumentos que se envían a una utilidad de línea de comandos. La API en cuestión, args4j, tiene una función que sustituye los caracteres "@" seguidos de una ruta de archivo por el contenido real del archivo. Las versiones de Jenkins LTS anteriores a la 2.426.2 inclusive y Jenkins release 2.441 y anteriores no deshabilitan esta característica específica, cuyo resultado permite a un atacante leer archivos arbitrarios en el sistema de archivos de Jenkins.

Los pocos exploits de prueba de concepto que se han publicado hasta ahora sólo han sido capaces de leer archivos arbitrarios; no ejecutan comandos arbitrarios. Esto significa que un atacante puede potencialmente leer archivos sensibles como /etc/passwd (que, en realidad, no es tan sensible dado que las contraseñas reales están en /etc/shadow). El uso de este exploit por sí solo no proporcionará al atacante una shell remota. Sin embargo, un atacante podría tener suerte y encontrar una contraseña almacenada en algún archivo específico, que podría, a su vez, ser utilizado para obtener más acceso.

En resumen, si bien este exploit ejecuta un comando, se limita sólo a las utilidades a las que el servidor Jenkins tiene acceso (como el Jenkins-CLI a través de un WebSocket), cuyos resultados pueden ser potencialmente utilizados para obtener acceso elevado.

Esto no quiere decir que esto no sea un problema; es técnicamente un "RCE" en el que se ejecuta un comando (específico), y no estamos de ninguna manera restando importancia a esto. Tampoco estamos diciendo que un atacante no podría encontrar un archivo que podría ser utilizado para obtener acceso adicional (como una clave SSH privada); es sólo que hasta ahora, la gravedad es muy limitada basada en la configuración del servidor Jenkins.

Para conocer los detalles de las diferentes severidades de configuración y una gran descripción de los tipos exactos de datos que pueden ser filtrados, recomendamos encarecidamente la descripción de Horizon3.ai de CVE-2024-23897 y el post de Sonar sobre el mismo tema.

Para entender por qué esto podría ser un problema en las condiciones adecuadas, primero tenemos que entender qué es Jenkins, lo que hace, por qué la gente lo usa, y las posibles ramificaciones de seguridad de uno de estos servicios que se adueñan.

Qué es es Jenkins?

Jenkins es, en esencia, un sistema de compilación y entrega de software. Cualquiera que haya trabajado en una organización o campo que requiera programadores y desarrolladores probablemente ha tenido que utilizar un sistema de construcción de software en un momento u otro. Jenkins es una de las plataformas de integración continua más conocidas (a veces infame). Es de código abierto y está disponible para cualquiera que desee utilizarla. Además de tareas "sencillas" como compilar uno o varios proyectos y crear paquetes, Jenkins también puede desplegar automáticamente estas aplicaciones en las redes de los clientes.

Este servicio es a menudo un catalizador para todo el ciclo de despliegue de código de una organización, y es por ello que podemos entender mejor por qué se considera un objetivo muy valioso para los atacantes.

Jenkins es la Cadena de Suministro...

...o, al menos, una parte muy crítica.

En términos generales, si hubiera que considerar un solo producto como el verdadero punto débil de la cadena de suministro de una empresa de software (o de cualquier equipo de desarrollo), ese sería su servidor de compilación. Este servidor no sólo contiene (múltiples) copias del código fuente de una organización, sino que a menudo contiene todos los bits y bobs que componen una sola construcción, que puede incluir claves, configuraciones y contraseñas necesarias para que una aplicación sea ensamblada y desplegada (aunque esto será específico del proyecto de construcción). A menudo, Jenkins se utiliza como un determinante final en cuanto a si una pieza de software está listo para la producción.

En el peor de los casos, un atacante que pueda modificar una compilación en un servidor Jenkins podría teóricamente envenenar tanto el proceso de compilación como el de despliegue inyectando código o comandos maliciosos como parte del trabajo. Y ya ha sucedido antes con el incidente de SolarWinds en 2020, en el que actores malintencionados pudieron instalar puertas traseras en el software de monitorización de red Orion de la compañía utilizando su canal CI/CD. A continuación, se desplegó automáticamente a miles de clientes, enmascarado como una actualización normal.

"Para establecer un punto de apoyo en la organización, el actor de la amenaza comprometió el "corazón" de la tubería CI/CD, donde el código es probado, envuelto, en contenedores y firmado, luego cambió con éxito el código fuente de SolarWinds." - CyberArk

Incidentes como el de SolarWinds2k convierten el acceso a un sistema de Integración Continua (IC) o de Despliegue Continuo (DC) en una mina de oro para un posible atacante. O, al menos, un punto de entrada muy codiciado.

Esto no quiere decir que esta vulnerabilidad de Jenkins sea la misma que la vulnerabilidad utilizada en el ataque de SolarWinds, sólo como ejemplo de lo que podría conseguirse con acceso administrativo a los sistemas de construcción y despliegue de una empresa.

La perspectiva Censys

Nota para los lectores.

En las siguientes secciones, tratamos cualquier versión de Jenkins LTS menor o igual a la versión 2.426.2 y versiones de Jenkins menores o iguales a la 2.441 como vulnerables a esta CVE, según el aviso del proveedor. Esto no tiene en cuenta si se dan las condiciones adecuadas para leer la totalidad de los archivos de texto y binarios (acceso de lectura anónimo o usuarios autenticados), ya que nuestro escáner no informa directamente de este nivel de detalle, y no se pretende decir que el mundo está en llamas; sólo estamos informando del número bruto de servidores Jenkins en Internet para dar una idea del alcance potencial de este problema.

Jenkins en Internet

En total, Censys observa 83.509 servidores Jenkins en Internet. De ellos, 79.952 hosts están ejecutando una versión vulnerable, mientras que sólo 3.557 hosts han sido parcheados con una de las versiones corregidas. Esto significa que sólo el 4,2% de los hosts que ejecutan Jenkins en Internet están a salvo de esta CVE, y el 95,7% son potencialmente vulnerables.

La captura de pantalla anterior muestra los últimos ocho días de servidores Jenkins vulnerables frente a los no vulnerables que pudimos encontrar en la Internet pública. Vemos que el 25 de enero de 2024, un día después de que se anunciara la vulnerabilidad, poco más de 300 servidores ejecutaban las últimas versiones no vulnerables. En los próximos días, veremos un número consistente de servidores Jenkins siendo desconectados y/o actualizados a la última versión.

* 2024-01-24 es la fecha de publicación del aviso. Tenga en cuenta que nuestras estadísticas se extrajeron a las 11 AM ET.

Hemos visto este mismo patrón antes con productos como Confluence, donde se anuncia una vulnerabilidad, y en lugar de ver un número consistente de servidores en línea en total, vemos disminuciones en el número de servidores en línea en general. Esto indica que cuando se anuncia una vulnerabilidad, los administradores los retiran de Internet en lugar de actualizar sus servidores, ya sea poniéndolos detrás de un cortafuegos o desconectándolos por completo. Esto también podría indicar que muchos de estos servidores no estaban siendo utilizados en primer lugar (es decir, eran instancias de prueba o algo similar).

Los gráficos y tablas siguientes representan el número de versiones vulnerables frente a las no vulnerables de Jenkins en todos los sistemas autónomos y países en los que residen a 30 de enero de 2024.

Sistemas autónomos (30 de enero de 2024)

Países (30 de enero de 2024)

Servidores Jenkins vulnerables en Quantum Space

Censys sugiere que los administradores tomen nota cuidadosamente de todos los servicios Jenkins que se ejecutan en sus hosts, ya que hemos encontrado algo menos de 600 hosts en Internet que están ejecutando múltiples versiones del software Jenkins en varios puertos y un poco más de 60 hosts que tienen tanto una versión vulnerable como no vulnerable de Jenkins.

Por ejemplo, en la siguiente captura de pantalla, vemos un único host ejecutando una versión parcheada de Jenkins LTS en el puerto TCP 80, pero una versión vulnerable ejecutándose en el puerto TCP 9001.

Identificación de los servicios Jenkins

Con Censys, está a una consulta de búsqueda de descubrir todos los servidores Jenkins en funcionamiento en Internet:

• servicios: (software.vendor: jenkins y software.product: jenkins)

Una de las formas más sencillas de identificar no sólo si un host está ejecutando un servidor Jenkins, sino también de obtener la versión exacta del servicio en ejecución, es analizar las cabeceras de respuesta HTTP y buscar la existencia de la clave X-Jenkins, cuyo valor será a menudo la versión real del servidor.

Un host ejecutando Jenkins.

En la mayoría de los casos, al realizar una petición HTTP al servidor Jenkins se obtiene un código de estado 403, que nos informa como cliente de que el servidor requiere autenticación; en otras palabras, si vas a esa URL en tu navegador, verás un formulario de inicio de sesión.

El mismo host pero en un navegador.

Pero la captura de pantalla anterior no es la única vista que se puede ver con Censys y Jenkins; un servidor Jenkins se puede configurar para que se pueda dar acceso anónimo/de invitado a Internet en general, lo que da a cualquier usuario la capacidad (como mínimo) de ver los diversos trabajos y construcciones que están configurados actualmente.

Si se modifica la consulta de búsqueda de Censys para incluir una búsqueda de títulos HTML, se pueden encontrar muchos ejemplos de servidores Jenkins con acceso de lectura global al sistema:

• services: (software.vendor: jenkins and software.product: jenkins and http.response.html_title: "Panel de control [Jenkins]")

Cabe señalar que muchos de los servidores Jenkins encontrados con acceso de lectura al panel de control no están necesariamente mal configurados, ya que muchos proyectos de código abierto utilizan Jenkins como un medio para construir y probar su software. Pero es algo a tener en cuenta.

Diferenciando Jenkins LTS de Jenkins Release

En el aviso, vemos que las versiones de Jenkins inferiores o iguales a la versión 2.441 son vulnerables a esta CVE. Por otro lado, las versiones de Jenkins LTS inferiores o iguales a la 2.426.2 también son vulnerables. Dado que hay un pequeño solapamiento entre estos dos árboles de código, necesitamos una forma de diferenciar un servidor Jenkins LTS (Long Term Support) de un servidor Jenkins normal.

Afortunadamente, el valor de la versión en la cabecera de respuesta HTTP de X-Jenkins incluirá tres dígitos (mayor, menor, parche, separados por un punto) para las versiones LTS y sólo dos dígitos (mayor, menor, separados por un punto) para las versiones estándar. Por una vez, tenemos un proveedor que hace el versionado semántico correctamente.

¿Qué se puede hacer?

• Consulte el aviso del proveedorque indica que los usuarios deben actualizar a Jenkins 2.442 o a la versión LTS 2.426.3.
• Utilice esta Censys consulta de búsqueda para encontrar servidores Jenkins expuestos a Internet.
• Censys Los clientes de ASM tendrán acceso a un nuevo riesgo que identificará los servidores Jenkins potencialmente vulnerables (busque "CVE-2024-23897").