💣GitLab - Ataques
Como vimos en la sección anterior, incluso el acceso no autenticado a una instancia de GitLab podría provocar la vulneración de datos confidenciales. Si pudiéramos obtener acceso como usuario válido de la empresa o administrador, podríamos descubrir datos suficientes para comprometer por completo la organización de alguna manera. GitLab tiene 553 CVE reportados a septiembre de 2021. Si bien no todos son explotables, ha habido varios graves a lo largo de los años que podrían provocar la ejecución remota de código.
Enumeración de nombres de usuario
Aunque GitLab no lo considera una vulnerabilidad, como se ve en su página de Hackerone ("Enumeración de usuarios y proyectos/divulgación de rutas a menos que se pueda demostrar un impacto adicional"), sigue siendo algo que vale la pena verificar, ya que podría resultar en acceso si los usuarios seleccionan contraseñas débiles. Podemos hacer esto manualmente, por supuesto, pero los scripts hacen que nuestro trabajo sea mucho más rápido. Podemos escribir uno nosotros mismos en Bash o Python o usar este para enumerar una lista de usuarios válidos. La versión Python3 de esta misma herramienta se puede encontrar aquí .
Al igual que con cualquier tipo de ataque de rociado de contraseñas, debemos tener en cuenta el bloqueo de cuentas y otros tipos de interrupciones. Los valores predeterminados de GitLab están configurados en 10 intentos fallidos que resultan en un desbloqueo automático después de 10 minutos. Esto se puede ver aquí . Esto se puede cambiar, pero GitLab tendría que compilarse por fuente. En este momento, no hay forma de cambiar esta configuración desde la interfaz de usuario de administrador, pero un administrador puede modificar la longitud mínima de la contraseña, lo que podría ayudar a los usuarios a elegir contraseñas cortas y comunes, pero no mitigará por completo el riesgo de ataques de contraseña.
Al descargar el script y ejecutarlo en la instancia de GitLab de destino, vemos que hay dos nombres de usuario válidos root
(la cuenta de administrador integrada) y bob
. Si logramos extraer una lista grande de usuarios, podríamos intentar un ataque de rociado de contraseñas controlado con contraseñas débiles y comunes como Welcome1
o Password123
, etc., o intentar reutilizar las credenciales obtenidas de otras fuentes, como volcados de contraseñas de violaciones de datos públicos.
Ejecución remota de código autenticado
Las vulnerabilidades de ejecución remota de código suelen considerarse las "mejores", ya que el acceso al servidor subyacente probablemente nos otorgará acceso a todos los datos que residen en él (aunque es posible que primero debamos aumentar los privilegios) y puede servir como punto de apoyo en la red para que lancemos más ataques contra otros sistemas y potencialmente resulte en un compromiso total de la red. GitLab Community Edition versión 13.10.2 y anteriores sufrieron una vulnerabilidad de ejecución remota de código autenticada debido a un problema con ExifTool al manejar metadatos en archivos de imagen cargados. GitLab solucionó este problema con bastante rapidez, pero es probable que algunas empresas sigan usando una versión vulnerable. Podemos usar este exploit para lograr la ejecución remota de código.
Como se trata de una ejecución remota de código autenticada, primero necesitamos un nombre de usuario y una contraseña válidos. En algunos casos, esto solo funcionaría si pudiéramos obtener credenciales válidas a través de OSINT o un ataque de adivinación de credenciales. Sin embargo, si encontramos una versión vulnerable de GitLab que permita el autorregistro, podemos registrarnos rápidamente para obtener una cuenta y llevar a cabo el ataque.
Y obtenemos un shell casi instantáneamente.
Caso práctico
Busca otro usuario válido en la instancia de GitLab de destino.
Obtén ejecución remota de código en la instancia de GitLab. Envía la flag al directorio en el que se encuentra.
Última actualización