Es cierto que cuando se comienza una auditoría de seguridad a una aplicación web nunca sabemos que va a terminar pasando. Bueno, es cierto salvo cuando pones una comilla en un fichero .asp y sale un error ODBC o pones un and 1=1 en un parámetro numérico PHP y sale un resultado distinto a cuando pones un and 1=0. En ese caso sí que sabes más o menos de qué sabor es el bombón. Sin embargo, en muchas otras no sabes por dónde va a cantar la rana.
De una de esas auditorías salieron las técnicas de Connection String Parameter Pollution, de otras sale la idea de meter los ficheros .DS_Store, o los ficheros .listing a las cosas que busca FOCA o el comprobar las multiple choices. Cuando empiezas una sabes el tamaño del bombón, pero no si el contenido de dentro de bombón.
En el día de hoy os voy a hablar de un ficherito que ha aparecido en dos auditorías de seguridad recientemente y que tiene mucho más jugo de lo que pensamos, por lo que ha acabado en el módulo de search for backups que tiene la FOCA PRO. Se trata del fichero .svn/entries
Este fichero almacena la información de las últimas updates que se han realizado en un proyecto de desarrollo que utiliza SVN como gestor de código, y es sólo un archivo de texto con el aspecto siguiente.
 |
| Figura 1: Fichero .svn/entries accesible desde Internet |
Como se puede ver, el fichero - que en la imagen está recortado - almacena la información de cuándo se hizo el post del código, el nombre del usuario (que en la imagen es el segundo recuadro rojo) y cual es el nombre del objeto que se subió, así como su tipo. Así, media es un directorio, y .htaccess es un fichero. Todo lleno de información más que útil que puede permitirte entrar en el sistema con la cuenta de usuario que menos protegida tenga su password.
Si desarrollas aplicaciones web, sé que es muy cómodo tener el repositorio en el mismo servidor donde estás publicándola, pero .... eso puede ser un craso error. Ten cuidado, estamos vigilando.
Saludos Malignos!
Lo interesante de este Information Disclosoure, es que permite encontrar el proveedor que desarrolla la aplicación, y donde ubica el repositorio root... Y en el caso de encontrar alguna vuln relacionada con su code, extraer de forma mas directa, sin necesidad inicial de Dorkit, el listado de posibles clientes con el mismo code afectado ;p.
ResponderEliminarBueno aporte para la foca Chema.
Si impedes el acceso a la carpeta EN PRINCIPIO no pasará nada, pero como haya un RFI o un LFI te comes una vulnerabilidad cojonuda
ResponderEliminarPensandolo bien, si eso pasa el .svn es el menor de tus problemas.
ResponderEliminarRevisando me doy cuenta que en la carpeta
ResponderEliminar.svn/text-base/ se guardan copias de mi index.php y del htaccess, ahora ha restringir, se agradece Chema :)