GitLab vuelve a causar confusión en los usuarios con una nueva vulnerabilidad de adquisición de canalización de CI/CD

Por segunda vez en menos de un mes, los usuarios de GitLab deben apresurarse a corregir una vulnerabilidad de seguridad crítica en las ediciones Community y Enterprise de la plataforma DevOps que podría afectar los procesos de integración/desarrollo continuo (CI/CD).

A Canalización de CI/CD de GitLab Básicamente, automatiza los pasos de construcción, prueba e implementación en un ciclo de desarrollo de software. GitLab lo describe así: «En el nivel más básico, una canalización lleva el código del punto A al punto B. Cuanto más rápida y eficiente sea la canalización, mejor hará este trabajo. Los desarrolladores pueden utilizar el flujo de trabajo automatizado mediante confirmaciones de código». , fusiones, solicitudes de activación o trabajos programados.

La vulnerabilidad identificada como CVE-2024-6385, proporciona a los atacantes la capacidad de ejecutar una canalización en el contexto de cualquier usuario dentro del sistema GitLab.

«Esto significa que un atacante puede potencialmente secuestrar la identidad de cualquier usuario y obtener acceso no autorizado a sus proyectos, repositorios de datos y códigos», dijo Howard Goodman, director técnico senior de Skybox Security. «Esto puede conducir a una variedad de actividades maliciosas, como inyectar código malicioso, acceder a información confidencial o interrumpir el funcionamiento normal de los procesos de desarrollo».

El error tiene una gravedad de 9,6 sobre un máximo de 10 en la escala CVSS y afecta a las versiones 15.8 anteriores a 16.11.6, 17.0 anteriores a 17.0.4 y 17.1 anteriores a 17.1.2 de GitLab CE/EE.

GitLab instó a los usuarios a no retrasar la implementación de la solución al error. “Este es un tema de gravedad crítica”, afirmó la empresa en su comunicado. consultivoy anima “enfáticamente” a los usuarios a actualizar a la última versión lo antes posible.

Errores de GitLab similares pero no idénticos

La novedad llega a GitLab CVE-2024-5655 lanzado el 26 de junioque tiene la misma puntuación CVSS de 9,8 y también brinda a los atacantes la capacidad de ejecutar canalizaciones como usuarios arbitrarios. Sin embargo, Goodman dice que existen diferencias sutiles entre los dos errores.

«CVE-2024-5655 se centró más en la explotación a través de llamadas API específicas, mientras que CVE-2024-6385 abarca una gama más amplia de vectores de ataque potenciales dentro del proceso de canalización CI/CD de GitLab», explica. «Esto último puede representar una superficie de ataque más amplia y potencialmente tener impactos más graves debido a la variedad de acciones que un atacante puede realizar como cualquier usuario».

David Lindner, CISO de Contrast Security, dice que la nueva vulnerabilidad sugiere que GitLab no solucionó completamente CVE-2024-5655 la primera vez o descubrió otra forma de explotar el mismo tipo de vulnerabilidad. Ambas situaciones son bastante comunes en el software, dice, señalando la Vulnerabilidad de Log4J y los numerosos problemas relacionados que los investigadores pudieron descubrir después de la revelación inicial.

Un atacante necesitaría una cuenta de usuario válida en un entorno GitLab específico para explotar las vulnerabilidades recién descubiertas, afirma Lindner. «Esto significa que un requisito previo sería una cuenta activa en esa instancia particular de GitLab, lo que en realidad reduce la probabilidad de un ataque exitoso», señala. “Eso significaría que sería más probable una amenaza interna. Pero si alguna de estas cuentas ha sido o ha sido comprometida, un atacante externo podría explotar esto”.

GitLab clasificó la vulnerabilidad como algo que podría ser explotado por un atacante sin privilegios de baja complejidad.

«Si el atacante tiene un conocimiento detallado del entorno de GitLab y de la vulnerabilidad, podría ser fácil de explotar», afirma Goodman. Sin embargo, señala que la complejidad del entorno en sí y el conocimiento requerido podrían representar una barrera para los atacantes menos experimentados. «Además, las medidas de seguridad y el monitoreo de GitLab pueden detectar y mitigar tales intentos si se configuran adecuadamente y se mantienen activamente».

Para las organizaciones que utilizan GitLab, la falla de seguridad de esta semana es el tercer error importante en la plataforma DevOps que han enfrentado en los últimos dos meses y medio. En mayo la empresa tenía expuso un error de máxima gravedad con un control de acceso inadecuado Esto brindó a los atacantes la oportunidad de apoderarse completamente de las cuentas. CISA agregó la falla a su catálogo de vulnerabilidades explotadas conocidas luego de una extensa actividad de explotación en los días posteriores a la divulgación de la falla.