Exposed .git directory

Cuando un sitio web se despliega copiando un repositorio Git "tal cual", el directorio oculto .git/ queda servido bajo la raíz web. Ese directorio contiene todo el historial del proyecto: el árbol de objetos comprimidos, los commits, las ramas y, sobre todo, ficheros que la navegación normal nunca enseña (configuración, credenciales, rutas internas, código no publicado). Que exista .git/ accesible por HTTP equivale a filtrar el código fuente completo.

Cómo confirmarlo (atacante). Basta pedir un fichero conocido del directorio. Si responde 200, el .git está expuesto:

curl -s http://shop.ejemplo.com/.git/HEAD      # ref: refs/heads/master  -> existe
curl -s http://shop.ejemplo.com/.git/config    # remotos, rutas...

A veces el servidor permite listar el índice (Index of /.git), lo que confirma de un vistazo que están HEAD, config, objects/, refs/, logs/, etc.

Cómo se explota. No hace falta clonar a mano objeto a objeto: herramientas como git-dumper reconstruyen el repositorio local descargando el índice y todos los blobs alcanzables:

git-dumper http://shop.ejemplo.com/.git/ ./loot
cd loot && git log --all --oneline        # historial completo

Una vez reconstruido, se revisa el historial (git log, git show) y los ficheros que el servidor no servía: el servidor web aplica reglas que ocultan o deniegan ciertos directorios, pero esos ficheros sí viven dentro de los blobs del .git, así que git-dumper los recupera igual. Es la diferencia entre lo que el navegador puede ver y lo que el repositorio contiene. Los git log también filtran el autor (nombre y correo), útil como nombre de usuario para un acceso posterior, una reutilización de credenciales o un spray.

Cómo detectarlo. La firma en el log de acceso es una avalancha de peticiones a rutas /.git/... (/.git/HEAD, /.git/index, /.git/objects/xx/...), que ningún navegador solicita, desde una sola IP y en poco tiempo, a menudo con el User-Agent de git-dumper/wget. Un 200 en /.git/HEAD seguido de cientos de descargas de objects/ es el patrón inequívoco; un WAF que bloquee el acceso a /.git/ lo corta y a la vez lo registra.

Defensa. No desplegar con .git dentro de la raíz web; si se hace, denegar el acceso a .git en la configuración del servidor (Require all denied / location ~ /\.git). Mejor aún, publicar solo el build, no el repositorio. Relacionado con la ejecución de comandos que suele seguir cuando el código filtrado revela una versión vulnerable o una credencial.