Se solucionó una vulnerabilidad en GitLab que permite el acceso a los tokens de Runner
Hace ya varios dias en GitLab se dio a conocer mediante una publicación de blog que investigadores dieron a conocer los detalles de una vulnerabilidad de seguridad ahora ya parcheada en GitLab, un software DevOps de código abierto, que podría permitir que un atacante remoto no autenticado recupere información relacionada con el usuario.
La principal vulnerabilidad, la cual ya está registrada como CVE-2021-4191, se le atribuye a la falla de gravedad media que afecta a todas las versiones de GitLab Community Edition y Enterprise Edition desde la 13.0 y todas las versiones desde la 14.4 y anteriores a la 14.8.
Fue Jake Baines, un investigador sénior de seguridad de Rapid7, a quien se le atribuye el descubrimiento y la notificación de la falla, quien después de la divulgación responsable del 18 de noviembre de 2021, se publicaron correcciones como parte de las versiones de seguridad críticas de GitLab 14.8.2, 14.7.4 y 14.6.5 que podría permitir que un usuario no autorizado extraiga tokens de registro en GitLab Runner, que se utiliza para organice los controladores de llamadas al crear el código del proyecto en un sistema de integración continua.
“La vulnerabilidad es el resultado de una verificación de autenticación faltante al ejecutar ciertas solicitudes de API de GitLab GraphQL”, dijo Baines. mencionado en un informe publicado el jueves. “Un atacante remoto no autenticado puede usar esta vulnerabilidad para recolectar nombres de usuario, nombres y direcciones de correo electrónico registrados en GitLab”.
Adicionalmente, se menciona que si se está utilizando ejecutores de Kubernetes, se deberá actualizar manualmente los valores del gráfico de Helm con el nuevo token de registro.
Y que para las instancias autoadministradas que no están en las versiones 14.6 o posteriores, GitLab ha publicado parches que se pueden aplicar para mitigar la divulgación del token de registro de Runner a través de la vulnerabilidad de acciones rápidas Estos parches deben considerarse temporales. Cualquier instancia de GitLab debe actualizarse a una versión parcheada de 14.8.2, 14.7.4 o 14.6.5 lo antes posible.
La explotación exitosa de la fuga de información de la API podría permitir a los actores maliciosos enumerar y compilar listas de nombres de usuario legítimos que pertenecen a un objetivo que luego se pueden usar como trampolín para llevar a cabo ataques por fuerza bruta, incluida la adivinación de contraseñas, el rociado de contraseñas y el relleno de credenciales.
“La fuga de información también permite potencialmente que un atacante cree una nueva lista de palabras de usuario basada en las instalaciones de GitLab, no solo desde gitlab.com sino también desde las otras 50,000 instancias de GitLab accesibles desde Internet”
Se recomienda a los usuarios que mantienen sus propias instalaciones de GitLab que instalen una actualización o apliquen un parche lo antes posible. Este problema se solucionó dejando el acceso a los comandos de acciones rápidas solo a los usuarios con permiso de escritura.
Después de instalar una actualización o parches de «token-prefix» individuales, los tokens de registro creados previamente para grupos y proyectos en Runner se restablecerán y regenerarán.
Además de la vulnerabilidad crítica, las nuevas versiones que fueron liberadas también incluyen las correcciones a 6 vulnerabilidades menos peligrosas:
- Un ataque DoS a través del sistema de envío de comentarios: un problema en GitLab CE/EE que afecta a todas las versiones a partir de la 8.15. Era posible activar un DOS mediante el uso de la función matemática con una fórmula específica en los comentarios de problemas.
- Adición de otros usuarios a grupos por parte de un usuario sin privilegios: que afecta a todas las versiones anteriores a la 14.3.6, todas las versiones a partir de la 14.4 anterior a la 14.4.4, todas las versiones a partir de la 14.5 anterior a la 14.5.2. Bajo ciertas condiciones, la API REST de GitLab puede permitir que los usuarios sin privilegios agreguen otros usuarios a los grupos, incluso si eso no es posible hacerlo a través de la interfaz de usuario web.
- Información errónea de los usuarios a través de la manipulación del contenido de Snippets: permite que un actor no autorizado cree Snippets con contenido engañoso, lo que podría engañar a los usuarios desprevenidos para que ejecuten comandos arbitrarios
- Fuga de variables de entorno a través del método de entrega «sendmail»: en la validación de entrada incorrecta en todas las versiones de GitLab CE/EE usando sendmail para enviar correos electrónicos permitió a un actor no autorizado robar variables de entorno a través de direcciones de correo electrónico especialmente diseñadas.
- Determinación de la presencia de usuarios a través de la API GraphQL: as instancias privadas de GitLab con registros restringidos pueden ser vulnerables a la enumeración de usuarios por parte de usuarios no autenticados a través de la API de GraphQL
- fugas de contraseña al duplicar repositorios a través de SSH en modo pull
Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.