Dejé mi directorio .git legible por el servidor web, ¿qué riesgos tengo?


7

En una de mis aplicaciones web, accidentalmente dejé el directorio .git legible por el servidor web durante las últimas semanas. El listado de índice fue deshabilitado. Visitar la URL del sitio web.com/.git daría lugar a un error 404 que no se puede distinguir de ningún otro error 404, pero navegar a sitio web.com/.git/config, por ejemplo, descargaría el archivo.

¿Qué tipo de riesgos existen con mis aplicaciones? ¿Es posible que exista suficiente información de que alguien podría haber descargado el código fuente de la aplicación completa?


¿Intentaste un git clone http://website.com/.git? Ese es el mayor riesgo (poder clonar el repositorio completo).
VonC

Tendré que probarlo en mi servidor de desarrollo ... Me di cuenta de la vulnerabilidad mientras soñaba despierto y solucioné el error lo antes posible.
Thomas Hunter

Respuestas:


4

Sí, es posible descargar todo el contenido del repositorio (incluido el historial); una simple acción git clonesería suficiente. Sin embargo, esto supone que alguien sabía sobre la existencia de ese .gitdirectorio ... es más probable que nadie lo haya notado. Siempre puede verificar los registros de su servidor web para estar seguro.


1
excepto si tienes gente de "auto-prueba" por ahí que durante curl $URL/.git/configtodo el día por cada url que ven ... :)
akira

Con la carpeta .git en la raíz, ¿alguien solo habría necesitado ejecutar git clone domainname.com ? ¿Y habría funcionado con el listado de directorio deshabilitado?
Thomas Hunter

@Thomas: Git no utiliza listados de directorio, ya que su formato varía mucho entre servidores web. Toda la información requerida está en refsy packed-refs.
Grawity

Gracias por el consejo. Revisé mis registros de acceso lighttpd y no vi ninguna solicitud al directorio git (aparte de mi propia verificación de pánico hoy).
Thomas Hunter

1
@Willem: Tengo curiosidad por saber en qué parte del código fuente realiza el análisis de la lista de directorios y cómo maneja la docena de formatos diferentes.
Grawity

2

Un simple git cloneen la raíz del documento no es del todo exacto. La clonación de un repositorio GIT expuesto no es posible con servidores " tontos ", como una exposición accidental de .git a través de HTTP, a menos que git update-server-infose ejecute en el servidor. Si bien algunos de los metadatos están disponibles, .git/objectsno siempre es posible obtener el contenido del directorio (también conocido como material jugoso). Es posible recuperar objetos que no están empaquetados . No debería ser el caso con una copia de trabajo / repositorio en un servidor de producción.

Es una historia diferente para una máquina de desarrollo con cambios comprometidos que no se envían a un control remoto. En este caso, generalmente no se llama al recolector de basura, a menos que invoque git gc, por lo tanto, los archivos aún no forman parte de los archivos de paquete. Puede recuperar a través de HTTP los archivos comprometidos desde el último envío.

update-server-info básicamente crea un mapa de las referencias (.git / info / refs) y de los paquetes (.git / objects / info / packs). Si bien se pueden usar .git / package -refs para sustituir el primero, no es posible obtener los archivos de paquete sin tener habilitado el índice de directorio o SHA-1 de fuerza bruta (que es una mala idea desde el principio).


1
Consulte también los scripts de PoC para obtener las referencias .git / index: github.com/evilpacket/DVCS-Pillage y k0st.wordpress.com/2012/10/23/… y github.com/kost/dvcs-ripper
Willem
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.