0x30 Notas preliminares

0x40 Montaje del laboratorio

0x41 Construcción

• Tener docker y docker-compose preinstalados en el host
• Clonar este repositorio: git clone https://github.com/lyy289065406/CVE-2020-13277
• Generar el par de claves de crackeo: ./keygen.sh o ./keygen.ps1
• Construir y ejecutar Gitlab (asegurándose de que el puerto 80 no esté ocupado): ./run.sh o ./run.ps1
• Tras unos 5 minutos se puede iniciar sesión en Gitlab desde el navegador: http://127.0.0.1 (en el primer inicio de sesión hay que restablecer la contraseña de la cuenta de administrador root)

0x42 Crackeo

Al generar el par de claves de crackeo anteriormente, la clave pública ya se ha escrito en el contenedor de Gitlab; todavía hay que subir la clave privada a Gitlab a través de la interfaz web para completar el crackeo:

• El par de claves se genera en el directorio ./gitlab/keys/; copia el contenido de .gitlab-license que se encuentra en él (la clave privada)
• Con el usuario root abre la página http://127.0.0.1/admin/license/new
• Selecciona Enter license key, pega la clave privada y haz clic en el botón Upload license para completar el crackeo

En este punto, la función Mirror Repository - Pull ya está activada

0x43 Configuración de salida (Outbound)

• Con el usuario root abre la página http://127.0.0.1/admin/application_settings
• Encuentra Outbound requests en la parte inferior, marca Allow requests to the local network from hooks and services y guarda

En este punto, Mirror Repository - Pull ya admite la extracción de un Repository local

0x44 Configurar Runner

• Con el usuario root abre la página http://127.0.0.1/admin/runners
• Encuentra el registration token y cópialo
• Registrar Runner: ./register.sh $TOKEN o ./register.ps1 $TOKEN

En este punto, todos los Repository pueden usar este Runner para ejecutar scripts de CI (Pipeline Jobs)

0x50 Verificación del laboratorio

El proceso de verificación puede consultarse en el Issue oficial, pero el proceso de verificación siguiente ajustará ligeramente algunos pasos según este laboratorio

0x51 Precrear cuentas para la verificación

Con el usuario root abre la página http://127.0.0.1/admin/users para crear 3 cuentas:

• victim: la cuenta de la víctima
• attacker1: la cuenta del atacante 1
• attacker2: la cuenta del atacante 2

Al crear la cuenta no se puede establecer una contraseña inicial; Gitlab envía por defecto la contraseña inicial al Email configurado. Para mayor comodidad, se puede poner cualquier Email, crear la cuenta primero y luego editarla inmediatamente; en ese momento se puede usar root para establecer la contraseña inicial de esa cuenta sin necesidad del Email

0x52 Precrear el repositorio de la víctima

• Inicia sesión en Gitlab con la cuenta victim
• Crea un repositorio en New Project:
  • Name: target
  • Visibility Level: Private
• Crea un archivo README.md en el repositorio y ponle como contenido, por ejemplo, mykey is abcxyz

Obviamente target es el repositorio privado de victim, y nuestro objetivo es obtener el contenido de este repositorio explotando la vulnerabilidad

0x53 Crear el repositorio poc del atacante

• Inicia sesión en Gitlab con la cuenta attacker1
• Crea un repositorio en New Project:
  • Name: poc
  • Visibility Level: Public
• Crea un archivo .gitlab-ci.yml en el repositorio con el siguiente contenido:

【Objetivo】En las operaciones siguientes, mediante ciertas técnicas se logrará que victim, sin saberlo, ejecute este script de CI con sus permisos.

Debido a que el laboratorio actual no tiene certificados configurados, solo se puede usar el protocolo http; además, 172.168.30.2 es la IP que docker-compose.yml asigna al contenedor de Gitlab. Como este script de CI se ejecutará finalmente a través del Runner, y el Runner y Gitlab de este laboratorio no están en el mismo contenedor, hay que usar la dirección IP asignada por Docker

0x53 Crear el repositorio espejo poc del atacante

• Inicia sesión en Gitlab con la cuenta attacker2
• Crea un grupo en New Group:
  • Name: test
  • Visibility Level: Public
• Dentro del grupo test, crea un repositorio completamente vacío en New Project:
  • Name: poc
  • Visibility Level: Public

Configura el repositorio espejo en Settings => Repository => Pull from a remote repository:

• Mirror repository: marcar
• Git repository URL: rellenar con http://GITLAB/attacker1/poc
• Password: (dejar en blanco; el nivel de confidencialidad del repositorio de Pull es Public, no requiere contraseña)
• Trigger pipelines for mirror updates: marcar (dispara la ejecución del script de CI al sincronizar el espejo)

Una vez configurado correctamente, se comprobará cada 30 minutos si el repositorio de origen ha cambiado y, si es así, se forzará la sincronización.

Git repository URL apunta al repositorio poc creado anteriormente. No se usa 127.0.0.1 porque Pull prohíbe extraer repositorios locales, pero se puede evadir mediante DNS: GITLAB es el hostname que docker-compose.yml asigna al contenedor de Gitlab y se añade por defecto a /etc/hosts. Aunque el host no puede resolver GITLAB, dentro del contenedor equivale a acceder a http://127.0.0.1/attacker1/poc

0x54 Transferir forzosamente la propiedad del repositorio espejo poc a la víctima

• Continúa usando la cuenta attacker2
• Abre la página http://127.0.0.1/groups/test/-/group_members para gestionar los usuarios del grupo test
• Añade al usuario victim al grupo:
  • Add new member to test: victim
  • Permissions: Owner
  • Expiration date: (dejar en blanco, es decir, sin límite de tiempo)
• Haz clic en el avatar de la cuenta en la esquina superior derecha => Setting => Account => Delete account para eliminar la cuenta actual (attacker2)

【Objetivo】En el grupo test solo hay dos Owner: victim y attacker2. Cuando el usuario attacker2 es eliminado, la propiedad del grupo test y de todos los repositorios que contiene se transfiere forzosamente a victim. Como actualmente el grupo test contiene un repositorio test/poc sincronizado por espejo desde attacker1/poc, esto equivale a transferir forzosamente el repositorio test/poc al usuario victim.

0x55 Lanzar el ataque

Primero repasemos la situación actual hasta ahora:

• El atacante ha creado forzosa y silenciosamente un repositorio test/poc para la víctima victim
• El contenido del repositorio test/poc se sincroniza por espejo desde el repositorio attacker1/poc (cada 30 minutos se comprueba si hay cambios que requieran sincronización)
• El contenido del repositorio attacker1/poc, incluido el script de CI .gitlab-ci.yml, está controlado por el atacante
• Como el repositorio test/poc tiene marcada la opción Trigger pipelines for mirror updates, el script de CI se ejecuta en cada sincronización
• Como el Owner del repositorio test/poc es victim, el script de CI se ejecuta con los permisos de victim

Revisando el contenido del script de CI .gitlab-ci.yml configurado anteriormente, este poc utiliza los permisos de victim en el Runner para acceder a la estructura de directorios y al README.md de su repositorio privado target:

Después, el atacante solo necesita modificar arbitrariamente algún contenido intrascendente del repositorio attacker1/poc; en el peor de los casos solo tiene que esperar 30 minutos para poder ejecutar el script de CI configurado con los permisos de victim.

Aunque el atacante no tiene permiso directo para acceder a los resultados de ejecución de los Pipeline Jobs, basta con ajustar el destino de salida del script, por ejemplo enviando el contenido del repositorio a un Email o a un servidor FTP determinados, para robar el código del repositorio.