Exposed .git Repository

1. Descripción técnica del ataque

Muchas aplicaciones se despliegan copiando directamente el repositorio Git al servidor web, dejando el directorio .git/ accesible desde el navegador. Ese directorio contiene toda la historia del proyecto: código fuente, ramas, commits antiguos y, con frecuencia, secretos (credenciales, claves privadas, tokens) que se introdujeron y luego se "borraron" pero siguen en el historial.

Si .git/ es accesible (aunque el listado de directorios esté deshabilitado), un atacante puede reconstruir el repositorio completo descargando los objetos de Git (.git/HEAD, .git/index, .git/objects/...) con herramientas automatizadas, y luego inspeccionar el código y el historial en busca de información sensible o vulnerabilidades.

2. Impacto de la vulnerabilidad

Divulgación del código fuente completo de la aplicación (facilita encontrar otras vulnerabilidades: LFI, SQLi, RCE...).
Fuga de secretos presentes en el historial (claves SSH/API, contraseñas de BD, .env).
Conocimiento de rutas internas, endpoints ocultos y lógica de autenticación.

3. Historia y evolución

Es uno de los hallazgos de information disclosure más habituales en pentesting web desde la popularización de Git como sistema de despliegue.
Nmap lo detecta automáticamente (http-git), y existen herramientas dedicadas (git-dumper, GitTools) que automatizan la descarga y reconstrucción.

4. Factores que la hacen posible

Desplegar la aplicación incluyendo el directorio .git/ en la raíz web.
Configuración del servidor que sirve el contenido de .git/ (no bloquea rutas ocultas).
Historial con secretos no purgados.

5. Detección

Nmap:

nmap -sV --script http-git -p80 target

Comprobación manual:

curl http://target/.git/HEAD        # ref: refs/heads/master  → existe

Reconstrucción del repositorio:

git-dumper http://target/.git/ ./loot
# o GitTools (gitdumper.sh + extractor.sh)

Revisar el historial una vez descargado:

git log --all
git log -p          # ver diffs (secretos borrados aparecen aquí)

6. Mitigación

No desplegar el directorio .git/ en producción (usar git archive, CI/CD que excluya .git, o exportar sin él).
Bloquear el acceso a rutas ocultas en el servidor web (location ~ /\.git { deny all; } en nginx; RedirectMatch 404 /\.git en Apache).
Purgar secretos del historial si se filtraron (git filter-repo) y rotarlos.

7. Ejemplo de explotación real

Nmap detecta el repositorio y revela incluso el remoto de GitHub:

| http-git:
|   192.168.1.28:80/.git/
|     Git repository found!
|     Remotes:
|_      https://github.com/rskoolrash/Online-Admission-System

Descargando el código (o consultando el repo público), se analiza el fuente y se descubren vulnerabilidades (p. ej. endpoints de subida de archivos sin control de sesión) o secretos en el historial:

git log -p | grep -iE 'password|secret|api[_-]?key|BEGIN .* PRIVATE KEY'

8. Clasificación

Tipo: Information Disclosure / Sensitive Data Exposure
CWE:
- CWE-527 – Exposure of Version-Control Repository to an Unauthorized Control Sphere
- CWE-200 – Exposure of Sensitive Information

9. Resumen

Un directorio .git/ accesible por web permite reconstruir el repositorio completo (con git-dumper/GitTools) y obtener el código fuente y secretos del historial, que sirven para encontrar otras vulnerabilidades o acceder directamente. La defensa es no desplegar .git/ y bloquear el acceso a rutas ocultas. Es un paso de reconocimiento frecuente que habilita ataques posteriores (LFI (Local File Inclusion), SQL Injection, etc.).