Los atacantes pueden ejecutar comandos del sistema operativo de forma remota aprovechando esta vulnerabilidad de GitLab

Parece que no importa a qué extremos estén dispuestas las empresas a proteger sus productos, los atacantes siempre van un paso por delante y encuentran formas ingeniosas de eludir toda protección.

En este mundo en línea en constante cambio, mantener sus datos confidenciales seguros es cada vez más difícil y estamos aquí para informarle sobre otra vulnerabilidad que se está explotando activamente en lo salvaje.

Otra vulnerabilidad de GitLab explotada activamente en la naturaleza

Según HN Security, se encontraron dos cuentas de usuario sospechosas con derechos de administrador en el servidor GitLab CE expuesto a Internet.

Aparentemente, estos dos usuarios se registraron entre junio y julio de 2021, con nombres de usuario de apariencia aleatoria. Esto fue posible porque esta versión de GitLab CE permite el registro de usuarios de forma predeterminada.

Además, la dirección de correo electrónico proporcionada durante el registro no se verifica de forma predeterminada. Esto significa que el usuario recién creado inicia sesión automáticamente sin más pasos.

Para complicar las cosas, no se envía absolutamente ninguna notificación a los administradores.

Uno de los archivos adjuntos cargados llamó la atención de los expertos, por lo que configuraron su propio servidor GitLab e intentaron replicar lo que observaron en la naturaleza.

Un exploit lanzado recientemente para CVE-2021-22205 abusa de la funcionalidad de carga para ejecutar de forma remota comandos arbitrarios del sistema operativo.

La vulnerabilidad mencionada anteriormente reside en ExifTool, una herramienta de código abierto utilizada para eliminar metadatos de imágenes, que falla al analizar ciertos metadatos incrustados en la imagen cargada.

GitLab está compuesto por múltiples elementos, como Redis y Nginx. El que maneja las cargas se llama gitlab-workhorse, que a su vez llama a ExifTool antes de pasar el archivo adjunto final a Rails.

Profundizando en los registros, se descubrió una pequeña evidencia de dos cargas fallidas dentro de los registros de Workhorse.

Esta carga útil utilizada por el exploit público puede ejecutar un shell inverso, mientras que el utilizado contra nuestro cliente simplemente aumentó los derechos de los dos usuarios registrados previamente a la administración.

echo 'usuario = User.find_by (nombre de usuario: "czxvcxbxcvbnvcxvbxv"); user.admin = "true"; user.save!' | consola gitlab-rails / usr / bin / echo dXNlciA9IFVzZXIuZmluZF9ieSh1c2VybmFtZTogImN6eHZjeGJ4Y3ZibnZjeHZieHYiKTt1c2VyLmFkbWluPSJ0cnVlIjt1c2VyLnNhdmU base64 -d | / usr / bin / gitlab-rails consola

Entonces, básicamente, lo que parecía ser una vulnerabilidad de escalada de privilegios en realidad resultó ser una vulnerabilidad RCE.

Como explicaron los expertos en seguridad, todo el proceso de explotación se reduce a solo dos solicitudes.

En una instalación predeterminada de GitLab (hasta la versión 13.10.2) no es necesario abusar de la API para encontrar un proyecto válido, no es necesario abrir un problema y, lo más importante, no es necesario autenticarse.

Todas las vulnerabilidades descritas en el artículo (ExifTool, abuso de API, registro de usuario, etc.) no están presentes en la última versión de GitLab CE en el momento de escribir este artículo.

Sin embargo, le recomendamos encarecidamente que tenga cuidado al tratar cualquier tema que implique que esté en línea para que no tenga ninguna experiencia desafortunada.

¿Cuál es su opinión sobre esta situación? Comparta su opinión con nosotros en la sección de comentarios a continuación.