En el mundo del pentesting, cualquier fuga de información o "leak" se puede convertir en crucial. Puede ser el que te de el nombre de usuario, la ruta o la variable de entorno adecuada o la que simplemente te oriente hacia dónde dar el siguiente paso. Entre la multitud de sitios en los que se buscan estos repositorios de datos se encuentran los logs de las aplicaciones, los sistemas de estadísticas, las herramientas de monitorización y, por supuesto, los sistemas de debugging que usan los desarrolladores de aplicaciones.

En el mundo .NET son famosas las herramientas de debugging Trace Viewer y Elmah.axd, pero puede ser que el entorno tenga una herramienta de compilación y gestión de código mucho más importante. Ya en Apple.com nosotros localizamos las herramientas de gestión de proyectos de desarrollo de software publicadas en Internet, con una de ellas que podía gestionar hasta los archivos del servidor. (Y que nos han agradecido por avisarles de ello)

Dependiendo de la tecnología que utilice el sitio podrá tener un "leak" de una de estas herramientas, así que a la hora de buscar los sistemas de debugging es importante tener localizados todos (y nosotros procuramos tener la lista bien actualizada para que no se nos escape ningún panel que pueda tener algo de información). Uno de ellos que mi amigo rootkit busca mediante un poco de hacking con buscadores con el dork que tenéis aquí es JBoss Seam Debug Page, una herramienta conocida por los desarrolladores en JBoss que no debería estar nunca publicada.

Sin embargo, está en la zona pública muchas veces y, como se puede ver en el dork, hasta indexada en los buscadores. De ella se puede sacar información del servidor a cinco niveles. A nivel de componente, a nivel de conversación, de negocio, de sesión y de aplicación. De cada uno de estos niveles se puede ver cómo están configurados los parámetros y/o variables de todos los componentes.

Si se encuentra publicado uno de estos paneles de debug basta con ir a la página principal y navegar por los componentes. Se puede ver cómo están configuradas las variables de usuario, las cookies de sesión o el entorno de ejecución con las variables de entorno del sistema, como ClassPath.

Al final, de estos componentes sale una buena lista de directorios locales, de software instalado en el servidor con sus versiones correspondientes, de nombres de usuarios, recursos internos y hasta secciones del código que se está ejecutando.

Por supuesto, estas herramientas no deben estar nunca publicadas en Internet, pero se si estás haciendo una auditoría a un servidor web, debes tenerlas presentes porque nunca sabes con qué te vas a encontrar ni dónde. 

Saludos Malignos!