Un HTTP Redirect no te libra de securizar un servidor web

Una de las formas sencillas para "quitar" un servidor web de Internet es la de la redirección del tráfico hacia otro servidor web. Este sistema te permite seguir aprovechándote de todo el tráfico que estuvieras recibiendo en el servidor y usarlo para promocionar los servicios en el nuevo. Sin embargo no sale gratis esta forma de conservar el tráfico, ya que debes seguir gestionando la seguridad del activo que dejas expuesto sólo para hacer la redirección y, si no lo haces, se puede convertir en un punto de inseguridad para la red.

Figura 1: Un HTTP Redirect no te libra de securizar un servidor web

Para que veáis un ejemplo, os voy a poner el caso de un servidor de Apple que hace una redirección a un dominio nuevo. El dominio se llamaba "ShopNow.Apple.com", pero si te conectas a él te redirige a "iContact.Apple.com", un servicio de e-mail marketing. Si hacemos una prueba muy sencilla con un Error 404 veremos que iContact está corriendo sobre un servidor Apache montando en Ubuntu.

Figura 2: Error 404 en iContact con info de Apache/2.4.7 sobre Ubuntu

Sin embargo, si miramos las cabeceras del servidor ShopNow veremos que se trata de un IIS 7.5 que está haciendo la redirección. Basta con forzar un error de Request Filtering o cualquiera no controlado para que obtengamos una respuesta del servidor IIS.

Figura 3: Error 404 controlado por Request Filtering en IIS

La redireción se está haciendo a nivel de servidor web, pero si con forzar cualquier error se rompe dicho proceso de reencaminamiento hacia el nuevo dominio y se puede jugar con este servidor. En este caso, como es un servidor que parece abandonado para ser solo una redirección, podemos encontrar con facilidad que tiene el bug de IIS Short Name sin parchear.

Figura 4: El fichero robots.txt aún está en el servidor web

Para hacer la prueba, podemos comprobarlo haciendo peticiones con mensajes de errores con un fichero que sepamos que sí que existe, por ejemplo robots.txt. Cuando pedimos un fichero en formato 8:3 que cumpla con el patrón de robots.txt recibimos un 404.

Figura 5: Respuesta TRUE con el bug de IIS Short Name

Cuando pedimos un fichero que no existe, obtenemos un mensaje distinto, un HTTP 200 con una página de respuesta en blanco. Este no es el primer servidor IIS de Apple con este bug.

Figura 6: Respuesta FALSE con el bug de IIS Short Name

Este servidor no sería ningún problema si estuviera limpio y se hubiera hecho un borrado de todos los programas que tuviera originalmente el sitio de ShopNow, pero como podemos ver usando el bug de IIS Short Name, no es así y hay más ficheros en el servidor. Aquí vemos que obtenemos un HTTP 404 cuando pedimos un archivo que comienza por "callb".

Figura 7: Existe algún fichero/directorio que cumple con el patrón "callb*"

Mientras que si pedimos uno que comience por "calla" obtenemos un HTTP 200, indicando que no hay ningún fichero en el servidor web que comience por esa cadena.

Figura 8: No existe ningún fichero/directorio que cumpla con el patrón "calla*"

Al final, poner una redirección para reutilizar el tráfico que te llegue está bien, pero eso no te evita tener que hacer el trabajo de seguridad con el activo que dejes. Si eliminas un sitio, debes eliminar todo su contenido pues el redirect no te va a salvar de todo. Siguen expuestos a Internet y hay formas de meterles mano.

Saludos Malignos!