CVE-2020-13277

Laboratorio CVE-2020-13277: Vulnerabilidad lógica de Gitlab: acceso no autorizado de cualquier usuario a repositorios privados

---

0x10 Entorno del laboratorio

0x20 Estructura de directorios

CVE-2020-13277
├── README.md ............... [此 README 说明]
├── imgs .................... [辅助 README 说明的图片]
├── gitlab .................. [Gitlab 容器的挂载目录]
│   ├── Dockerfile .......... [Gitlab 的 Docker 构建文件]
│   ├── config .............. [Gitlab 配置挂载目录]
│   ├── data ................ [Gitlab 数据挂载目录]
│   ├── logs ................ [Gitlab 日志挂载目录]
│   ├── keys ................ [Gitlab 破解 License 存储目录]
│   └── runner .............. [Runner 容器的挂载目录]
├── license ................. [破解 License 的容器构建目录]
│   ├── Dockerfile .......... [License 的 Docker 构建文件]
│   └── license.rb .......... [生成破解 License 的 Ruby 脚本]
├── docker-compose.yml ...... [Docker 的构建配置]
├── keygen.ps1 .............. [Windows: 一键生成破解 License]
├── keygen.sh ............... [Linux:   一键生成破解 License]
├── run.ps1 ................. [Windows: 一键运行 Gitlab 靶场]
├── run.sh .................. [Linux:   一键运行 Gitlab 靶场]
├── register.ps1 ............ [Windows: 一键注册 Runner]
├── register.sh ............. [Linux:   一键注册 Runner]
├── stop.ps1 ................ [Windows: 一键停止 Gitlab 靶场]
└── stop.sh ................. [Linux:   一键停止 Gitlab 靶场]

0x30 Notas preliminares

Sobre el criterio para elegir la versión de la imagen Docker del laboratorio

El núcleo de esta vulnerabilidad consiste principalmente en explotar Mirror Repository, la función de sincronización y respaldo por espejo de los repositorios.

La dirección de sincronización de Mirror se divide a su vez en dos tipos:

• Pull: trae el contenido de un Repository especificado al Repository actual
• Push: envía el contenido del Repository actual a un Repository especificado

Esta vulnerabilidad explota el Mirror Repository en dirección Pull

Cabe señalar que Gitlab se divide en dos versiones: CE (Community Edition, gratuita) y EE (Enterprise Edition, de pago), y Gitlab declara oficialmente que esta vulnerabilidad afecta tanto a CE como a EE en las siguientes versiones:

• >=10.6, <12.9.10
• >=12.10, <12.10.11
• >=13.0, <13.0.6

Pero esto no significa que las imágenes Docker de Gitlab de esas versiones puedan utilizarse para montar el laboratorio, porque:

• La Mirror Repository de la versión CE solo tiene dirección Push
• La versión EE se subdivide a su vez en cuatro ediciones: Core, Starter, Premium y Ultimate. Según la tabla comparativa de funciones oficial, solo la edición Core carece de la dirección Pull, y las imágenes Docker de Gitlab-EE solo ofrecen la edición Core

En otras palabras, para montar el laboratorio con Docker solo se puede elegir la versión Gitlab-EE y crackearla (quien tenga dinero también puede optar por comprar una License) para activar la función Mirror Repository - Pull.

Pero incluso con Gitlab-EE crackeado, ya sea 10.x, 12.x o 13.x, cuando la URL de Mirror Repository - Pull contiene una ruta local, se muestra el error Import url is blocked: Requests to localhost are not allowed.

Aunque tras configurar Allow requests to the local network from hooks and services mediante Admin area => Settings => Network => Outbound requests se puede configurar una URL local, al sincronizar el espejo aparece el error 2:Fetching remote upstream failed: fatal: unable to access http://127.0.0.1/xxxx/: The requested URL returned error: 301. En otras palabras, solo es utilizable el Pull de un Remote Repository.

Por suerte, aunque 12.x y 13.x son muy estrictos a la hora de detectar URL locales, en la versión 10.x hay una forma de sortearlo: al configurar la URL de Pull basta con utilizar el nombre del servicio DNS configurado localmente para evadir la restricción.

En resumen, solo se puede utilizar la imagen Docker de la versión gitlab-ee:10.6.0-ee.0 para construir este laboratorio.

De hecho, por lo descrito anteriormente se puede saber que las condiciones para explotar esta vulnerabilidad son bastante exigentes; básicamente es difícil que los menos pudientes se vean afectados por esta vulnerabilidad

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