Cuando el hacker utiliza los respaldos para vulnerar una aplicación web!

Es una técnica tradicional y hasta podría decirse que una costumbre, renombrar algunas rutinas agregándoles la extensión .bak cuando deseamos hacer nuevos ajustes para no perder el código escrito con anterioridad. Algunos de nosotros como programadores utilizamos esta y otras extensiones y simplemente las adosamos a la rutina existente de forma que por ejemplo un archivo "index.php" pasa a ser "index.php.bak" o "index.php.old". El problema reside en que dejar estas rutinas con dichas extensiones puede ser un peligro latente para la seguridad de nuestro sitio.

Los servidores web, pre-procesan los archivos del tipo php, asp, asp.net, jsp y otros, de forma que el contenido que llega al navegador cliente sea simple HTML (en nuestra jerga HTML plano). Como es conocido, dependiendo del tipo de servidor y tecnología, los archivos con estas extensiones (y algunas otras) son procesados del lado del servidor y definen lo que conocemos como rutinas "server-side", sin embargo al cambiar la extensión de los mismos a ".bak", ".old" o cualquier otro tipo de extensión no asociada a un proceso en el servidor, simplemente hacemos que el servidor entregue el archivo "como es", entregando el código "tal cual" lo hemos escrito". Para ello el atacante posee herramientas que intentan obtener nuestras rutinas con una serie de extensiones comúnmente usadas para archivos de respaldo. Inclusive apoyado en otra vulnerabilidad, podría obtener dichos listados directamente en Google (ver artículo sobre Google Hacking Database).

De esta forma puede llegar a obtener información de calidad acerca de nuestra aplicación y de nuestro servidor, como nombres de conexiones y bases de datos, directorios físicos de nuestro servidor y muchas otras cosas que pudieran abrir una brecha razonable de seguridad.

Sin embargo el anterior es el menor de los casos. Muchas veces existen respaldos completos de un sitio en formato "zip" o "rar" ubicados bajo el directorio principal, con el mismo nombre de alguna de las carpetas o directorios bajo este.

Por ejemplo, si el programador creó un sub-directorio en donde lleva todo el control administrativo llamado "admin" (por cierto admin es un mal nombre para un directorio administrativo de la aplicación) es probable que desde la interfaz de escritorio del servidor haya hecho un respaldo de dicho directorio con solo pulsar el botón derecho del ratón y ubicar la opción por defecto de enviar a carpeta comprimida en formato "zip". Por tanto todo lo que hay que hacer es intentar ubicar el archivo "admin.zip" bajo dicho directorio para obtener una copia completa y funcional de dicha aplicación.

Lo que pudiera suceder en este caso de que el atacante obtenga una copia actualizada del código completo del sitio, lo dejo a su imaginación... Este último punto pareciera un absurdo, sin embargo se sorprenderían de saber la cantidad de sitios que han sido vulnerados por esta razón.

¿Cómo protegernos?

• De ahora en adelante, si es necesario dejar archivos de respaldo de las rutinas en el servidor de producción (debiera ser un absurdo, para eso existen los entornos de desarrollo) entonces deberemos renombrar los mismos sin cambiar la extensión, ejemplo: index.old.php, index.bak.aspx. De esta forma siempre será procesado el código y al navegador cliente llegará solo HTML plano.
• Bajo ningún pretexto dejar cualquier tipo de respaldo comprimido del sitio web en el sitio web. Esto no tiene otra solución razonable. No se debe hacer y punto! Hacerlo es como dejar los planos de nuestros puestos de avance en manos del enemigo.

Hasta la próxima...