Sí, un Task Manager en tu sitio web... sin darte ni cuenta!!

Hacía tiempo que no tenía tiempo de investigar algunos de los leaks que mi amigo rootkit me envía, pero aprovechando que en las siestas de verano he sacado algo de tiempo, he mirado este de WestWind Technologies que me ha resultado peculiar.

Figura 1: Un Task Manager en tu servidor web... Sin darte ni cuenta!!

A simple vista, cuando lo ves, es la típica página de administración de servicios Microsoft Internet Information Services que la propia Microsoft ofrecía desde las primeras versiones de su servidor web & FTP. En ella, se pueden ver un montón de opciones, que van desde subir ficheros, hasta tocar configuraciones del servidor, lo que puede resultar muy peligroso. No debería estar expuesta a Internet.

Figura 2: Panel de control de WestWind Technologies

Por supuesto, cuando haces clic en los enlaces, todos llevan a ficheros que están protegidos, ya que de no estarlo los servidores durarían unos segundos en la vorágine de la red, pero sin embargo, se pueden hacer cosas muy curiosas con este página web de administración que no es de Microsoft, sino de Westwind Technologies.

Figura 3: Firma que aparece en el panel del fabricante

Haciendo un poco de Hacking con buscadores con la firma que la compañía pone a sus paneles de administración web se pueden encontrar un buen número de otras herramientas de ayuda, y ejemplos de la compañía, pero yo me voy a centrar en la original.

Figura 4: Buscando paneles de Westwind indexados en Google. Bing y Shodan dan aún más.

Aquí tenéis otro de los paneles de Westwind Technologies con muchas Demos "peligrosas" que recuerdan a los ejemplos que instalaba Microsoft FrontPage en Server-Side.

Figura 5: Otro panel de Westwind Technologies con "Demos" jugosas

En la página original, lo primero que llama la atención es que se puede acceder a la ruta de instalación del software, lo que ya es un leak en sí mismo que puede ser de utilidad en ataques LFI o RFI, como hemos visto en tantas ocasiones (véase Hacking Web Technologies).

Figura 6: Ruta de instalación del sitio web

La segunda cosa que llama poderosamente la atención es que hay un buscador de procesos... What?. Sí en la parte inferior del panel puedes poner una letra por la que quieres filtrar, y accedes a la lista completa de los procesos del sistema - más los del servicio web - que están corriendo, con su PID incluido si pasas el ratón por encima de la opción de matar el proceso, ya que lo usa como parámetro POST.

Figura 7: Lista de procesos que comienzan por s

Con ello, puedes averiguar todo el software de seguridad que está en ejecución, pero también si tiene DNS, servicios extras, etcétera. En este ejemplo se puede ver que este servidor utiliza un antivirus avp.exe que apunta directamente a Kaspersky.

Figura 8: Procesos del antivirus avp.exe

Pero también se puede saber si el administrador de este sitio navega, como en este caso, donde se puede ver cómo se está utilizando el web browser de Moxilla Firefox. Todo esto es debido a que el formulario que refresca la lista de procesos no está llamando a ningún otro fichero del servidor web, sino que es una petición directa sobre la página web que estamos visitando. Es decir, es el propio panel el que gestiona las llamadas al sistema para acceder a la lista de procesos. Y además hay opción de parar procesos, o actualizar constantemente para ver si hay cambios.

Figura 9: Procesos de Firefox

En la imagen superior se puede ver cómo el administrador ha dejado de utilizar Firefox, o bien alguien ha matado los procesos, o simplemente ha cambiado de navegador de Internet. Si alguien pudiera matar desde un sitio web un proceso - incluso los de los vhosts - corriendo en escritorio daría medida de cuáles son los privilegios con los que corre el sitio web (probablemente sin Application Pool), el servicio web, y la falta de uso de niveles de integridad - luego apuntaría a versiones de Windows concretas -.

Figura 10: Procesos de Firefox cerrados

Lo cierto es que estos paneles de Westwind Technologies son de gran utilidad para muchos administradores web, pero nunca, nunca, nunca, deberían estar expuestos a Internet sin estar protegidos por credenciales.

Saludos Malignos!

Pon un "Referrer Policy" y mejora la seguridad de tu web

Una de las opciones que se puede configurar a nivel de hipervínculo, de documento o de servidor web en los navegadores es el funcionamiento de la política para el HTTP Header "Referrer", para mejorar la seguridad de una aplicación web. Para entender en qué consiste esta política, primero hay que hacer un pequeño resumen de cómo funciona el campo HTTP Referrer que se envía desde los navegadores que cada vez que se hace clic en un hipervínculo de un documento HTML.

Figura 1: Pon una "Referrer Policy" y mejora la seguridad de tu aplicación web

La idea es que cuando se llega a un sitio al que llamaremos URI_destino, a través de hacer un clic en un enlace en un sitio al que llamaremos URI_origen, el navegador envía una cabecera HTTP al servidor URI_destino que se identifica como "Referrer" y donde se encuentra la dirección absoluta o relativa del URI_origen donde estaba el enlace que le llevó al lugar en que el navegador está ahora.

Figura 2: IETF RFC 7231 sección Referrer Header

Esto puede ser muy útil o muy peligroso si no se controla, ya que se podrían enviar direcciones internas de sistemas privados, o direcciones URL de aplicaciones privilegiadas que necesitan de unas credenciales para entrar a sitios no deseados. El uso de esta cabecera no se creo pensando en los posibles riesgos de seguridad, sino como se recoge en el RFC del IETF, para que los administradores de los sitios pudieran hacer estadísticas, crear backlinks, etc...

Figura 3: Campo Referrer enviado desde el cliente con una URL completa

Sin embargo, tiene una fuerte implicación en la seguridad, y alguien podría plantear un ataque de CSRF (Cross-Site Request Forgery), XSPA (Cross-Site Port Attack), o simplemente de phishing, a través de las direcciones URL que quedaran filtradas en las cabeceras HTTP Referrer que envían los navegadores de Internet. Para mitigar esta problemática existen varias configuraciones distintas.

Políticas Referrer: Configuraciones

Como se puede ver a continuación, se pueden establecer diferentes políticas de seguridad para evitar que la URL con los parámetros y sus valores - donde pueden filtrarse nombres de usuarios, directorios privados, cookies de sesión o información sensible de una organización - acaben en las estadísticas de un sitio remoto o en las manos de un tercero. Los valores que pueden configurarse en las políticas Referrer son los siguientes, y cada uno forzará un comportamiento diferente en el navegador.

- no-referrer: En este caso, no se enviará nunca el HTTP Header Referrer desde el cliente. 

- no-referrer-when-downgrade: Este es el valor por defecto en muchos navegadores y consiste en que se envía Referrer con la URL de la web si el destino es igual o más seguro. Es decir,  se envía cuando el hipervínculo va de una página HTTP a una página HTTP, cuando va de una página HTTP  a una página HTTPs y cuando va de una página HTTPs a una página HTTPs, pero no cuando va de una página HTTPs a una página HTTP.

Figura 4: Ejemplos no-referrer-when-downgrade en Mozilla

- origin: Con este modificador, el valor Referrer que se envía no especificará la dirección URL completa, y solo llevará en nombre del dominio y el protocolo. Es decir, se elimina el Path de la dirección URL de origen del hipervínculo. 

Figura 5: Ejemplo con valor origin

- origin-when-cross-origin: En este caso, cuando el hipervínculo es dentro del mismo dominio, se envía la URL completa, y cuando el hipervínculo es a otro origen, se envía entonces solo el dominio y el protocolo de la URL, sin el Path.

Figura 6: Ejemplos de origin-when-cross-origin

- same-origin: Con este valor, el HTTP header Referrer se enviará cuando el hipervínculo sea dentro del mismo dominio y no se enviará cuando sea entre distintos dominios.

Figura 7: Ejemplos con same-origin

- strict-origin: Solo se envía en el Referrer el origen del hipervínculo (solo el dominio y el protocolo de la URL sin el path) a un destino más seguro. Nunca en un hipervínculo HTTPs-HTTP.

Figura 8: Ejemplos con strict-origin

- strict-origin-when-cross-origin: Se envía en Referrer la URL completa a un destino dentro del mismo dominio más seguro, y solo el dominio y el puerto a un destino igual o más seguro, pero nada a un destino menos seguro.

Figura 9: Ejemplos con strict-origin-when-cross-origin

- unsafe-URL: En este caso, se envía la URL completa a cualquier destino pero sin valores en los parámetros de la URL (para evitar el envío de nombres de usuarios, cookies de sesión o información sensible).

Políticas Referrer: Establecimiento de política

La primera forma de configurar el comportamiento del navegador con los campos Referrer es a nivel de documento HTML con el uso de una META Tag llamada Referrer donde se establece una política para todos los hipervínculos que se generen - tanto de forma estática como de forma dinámica - desde esa URL.

Figura 10: Algunos valores de la Meta Tag "referrer" en HTML

Añadir un código Javascript que configure la política de tu aplicación web que tú quieras sería algo como lo que tienes en la imagen siguiente, y te permitiría automatizarlo en todas las webs si lo introduces en alguna de las librerías que uses siempre.

Figura 11: Configuración de Meta Tag Referrer desde Javascript

Si no se ha establecido la política a nivel de META Tag, ésta se puede cambiar a nivel de hipervínculo en la etiqueta "A" con el atributo rel="noreferrer", que permitiría evitar en un enlace filtrar la URL de la ubicación del enlace actual.

Figura 12: atributo "noreferrer" en hipervínculos

Éste, como se puede ver en la imagen siguiente suele ir acompañado del modificador noopener que evita ataques de phishing en enlaces con target=_blank, como ya os conté hace tiempo, y que pueden ser muy peligrosos para la seguridad de tu sitio web.

Figura 13: HTTP Header Server-Side "Referrer-Policy"

Por último, y esto es algo que es bastante novedoso, se puede utilizar un HTTP Header llamado Referrer-Policy a nivel de servidor web, para que el propio servidor, sin necesidad de que una aplicación web manualmente lo configure, pueda establecer la política que considere adecuada.

Figura 14: HTTP Header Server-Side "Referrer Policy"

En la Figura 14 se puede ver cómo el servidor envía este Header para establecer cuál es la política que se quiere configurar en el navegador. Y utilizando el servicio de Security Headers puedes comprobar si un determinado sitio la está utilizando o no.

Figura 15: Referrer-Policy en Security Headers

Reflexiones finales

Lo importante de esto es que entiendas que cualquier enlace - ya sea dinámico o estático - que no tenga una política Referrer controlada puede ser un leak de información. Si tienes una aplicación web que permite a usuarios inyectar código HTML y generar hipervínculos, o tu aplicación genera enlaces a partir de información dinámica, y no tienes controlada la política Referrer a nivel de enlaces, documentos o servidor web, puedes estar abriendo la puerta a ataques que no te esperas.

Dentro del proceso de fortificación de una aplicación web debes tener en cuenta estas opciones, y por supuesto, si lo que estás haciendo es una auditoría de seguridad o un pentesting, deberías informar al cliente de cuál es el nivel de la política que tiene establecida. Nosotros en nuestro sistema de pentesting persistente Faast miramos con cariño la políticas políticas de fortificación, que van desde los Referrers, la configuración SRI, los filtros AntiXSS y Anti-ClickJacking, las fugas por Metadatos, etcétera,  para reportar una alerta si no están controladas las opciones de fortificación.

Saludos Malignos!

Análisis de un HPP (HTTP Parameter Pollution) en Apple @Owasp #Apple #HPP #pentesting

Las técnicas de HPP (HTTP Parameter Pollution) llevan ya un tiempo entre nosotros. Fueron publicadas por Stefano Di Paola y Luca Carretano en la conferencia OWASP 2009, y desde entonces han sido utilizadas en muchos ataques distintos. Se basan en conseguir un comportamiento anómalo en las aplicaciones web duplicando (polucionando) los valores de los parámetros de entrada. Es decir, vamos a suponer que una aplicación recibe el parámetro1 con valor 23. Lo que se preguntan las técnicas de HPP es... ¿Qué pasa si le enviamos a la aplicación web el parámetro1 dos veces con valores 23 en el primero y 24 en el segundo? ¿Usará el primero? ¿El segundo? ¿Todos?

Figura 1: Análisis de un HPP (HTTP Parameter Polluiton) en Apple.com

Con esa idea de polucionar los parámetros, en este caso los parámetros de las cadenas de conexión a bases de datos, construimos las técnicas de Connection String Parameter Pollution [PDF] que me tocó explicar en detalle en el libro de Hacking Web Technologies. Todo partió de la idea de polucionar todo lo que teníamos por delante, gracias a la aparición del HPP, y de eso hablamos Stefano y yo cuando nos conocimos. 

Figura 2: Comportamiento con parámetros polucionados según las tecnologáis

En el caso de las aplicaciones web, el comportamiento que se va a obtener en cada caso depende de la tecnología de backend que tengamos. Según el estudio inicial realizado, esta tabla sería la lista de casos que se esperan cuando se poluciona un parámetro en el QueryString de una aplicación web.

Un bug de HPP en los foros de Apple

Nosotros tenemos un plugin en nuestro sistema de Pentesting Persistente Faast creado exclusivamente para descubrir este tipo de bugs, y a veces te lo encuentras de forma muy sencilla en sitios como los Foros de Apple, como es el caso de hoy.

Figura 3: El buscador de temas por etiquetas en los foros de Apple

Vamos a ver este ejemplo en detalle. En esta imagen tenemos la lista de etiquetas con las que han sido marcados los diferentes temas del foro. Con el interfaz, basta con seleccionar una de las etiquetas para ver que queda añadida el QueryString con el parámetro tags que coge como valor el de la etiqueta pulsada. Esta etiqueta es pintada en el buscador y recibimos la lista de temas que la tienen asignada.

Figura 4: Se elige la etiqueta, se envía en el Querystring, se imprime y salen los artículos

Esto es un funcionamiento normal y habitual, pero quería remarcarlo para explicar que hay una aplicación en el backend que está recibiendo el QueryString, extrayendo el valor de tags, buscando los temas y pintando la página de respuesta en función del valor de tags.

Si seleccionamos dos etiquetas, vemos que la aplicación está preparada para ello, añadiendo las dos etiquetas en el mismo parámetro tags separándolas por el operador de suma. Algo bastante habitual. Esto significa que la aplicación en el backend está preparada para procesar el string que le llega en el parámetro tags y sacar la lista de etiquetas.

Figura 5: Comportamiento con selección múltiple de etiquetas

Pero ¿qué pasaría si polucionamos el parámetro tags? Pues bien, en este caso la tecnología del backend ha generado una lista con todos los valores separados por commas. Esto es interesante, porque cuando el QueryString ha procesado la lista CSV (Comma Separated Values) generada en el parámetro tags, ha sido capaz de descubrir las dos tags, pero luego no ha sido capaz de imprimirlas correctamente.

Figura 6: Comportamiento con polución del parámetro tags

Esto quiere decir que la tecnología en el backend está generando una lista CSV con los valores de los parámetros polucionados, que la aplicación en el backend está preparada parcialmente para procesarlos, y parcialmente no está preparada. 

¿Es esto un bug? 

Visto el entorno, no parece que sea un "security bug" de ninguna manera, pero sí que existen casos sin controlar, por lo que podría darse una situación no deseada más allá del fallo de impresión de las etiquetas en el campo de texto en otros entornos, como ya se ha visto con estos bugs de HPP en el pasado.

Corolario tecnológico

Para terminar, tras ver que se generaba una lista de valores separada por comas, siguiendo la tabla de casos publicada en HPP, decidí comprobar si había algún cambio, así que pasé por BuiltWith el sitio web para ver qué tecnologías son las que hay detrás y que han generado este comportamiento.

Figura 7: Tecnologías detrás de Forum.Apple.com

Como podéis ver, sale que es un Apache con J2EE, que no estaba contemplada en la tabla, pero que si nos basamos en este comportamiento funciona igual que un servidor IIS o un servidor Apache con Python.

Saludos Malignos!

Paint.NET en metadatos de Internet Information Services #Microsoft #metadata #IIS

Hoy domingo os voy a traer un post con sólo una curiosidad - que hoy ya habrá mucho denso que leer con eso de ser día de elecciones generales - sobre el mundo de los metadatos que descubrimos revisando en Eleven Paths los resultados de un escaneo hecho con Faast, nuestro sistema de Pentesting Persistente. Se trata en este caso de un metadato que aparece en la imagen que se utiliza por defecto en los servidores Microsoft Internet Information Services 8.5 y que apuntan a que ha sido creada con el software Paint.NET, tal y como se dio cuenta nuestro compañero Ioseba Palop que siempre anda con el ojo abierto.

Figura 1: Paint.NET en metadatos de IIS 8.5

Como podéis ver, la imagen es un fichero en formato PNG que, a pesar de lo que muchos puedan pensar, también tiene sus propios metadatos. De hecho, en MetaShield Protector es una de las cosas que miramos en todas las imágenes para poder evitar que se filtre información como los programas que se están utilizando.

Figura 2: Imagen de Microsoft para los servicios IIS 8.5

El que se conozca el software en uso puede abrir un problema de seguridad, al poderse descubrir alguna vez algún fallo relativo a él. No hay que irse muy lejos en el tiempo para ver cómo un software de tratamiento de imágenes se convirtió en la peor pesadilla para la seguridad de las empresas con el 0day de ImageMagick que afectó a tantos servidores GNU/Linux.

En otras ocasiones, el problema de que se conozca el software que está en uso es más reputacional que otra cosa, ya que puede dejar mal a la compañía por su posicionamiento público o peor, que se descubra que se está utilizando una copia pirata del software para la que la compañía no tiene licencia.

El caso de la imagen de IIS 8.5

Si analizamos esta imagen con un editor hexadecimal podemos ver que en la cabecera del fichero ya aparece el nombre del software Paint.Net dentro del mismo.

Figura 3: Head del fichero PNG

Si queremos hacer un análisis más detallado, podemos usar cualquier software de análisis de ficheros PNG, en este caso Inspect PNG de Simon Strandgaard para OS X y está disponible dentro de Mac App Store.

Figura 4: Inspect PNG para OS X

Como se puede ver, dentro de los metadatos es posible acceder al nombre del software que ya habíamos visto. El software en concreto es Paint.Net, una popular herramienta gratuita que es freeware y vive de donaciones.

Figura 5: El software utilizado es Paint.NET v3.5.10 (no es la última versión)

Así que esperamos que los ingenieros de Microsoft que la hayan utilizado, hayan puesto algo de los fondos que normalmente estas compañías destinan para donar a los creadores de software independientes, dentro de las arcas de los creadores de Paint.Net. O mejor, ¿y si se cambiara Paint por Paint.Net en futuras versiones de Windows?

Saludos Malignos!

Security Headers & SRI Test: Para los bookmarks

Cuando estas revisando la seguridad de la infraestructura expuesta en Internet de una organización, como hacemos nosotros con Faast, se deben revisar todos los detalles. Fugas de información, configuraciones inseguras, vulnerabilidades o cualquier otra debilidad que pueda ser utilizada por un atacante para afectar la seguridad de la organización, ya sea de forma directa o encadenando varios fallos. Como sabéis, miramos cosas como los leaks de información por culpa de los metadatos, los fallos OWASP, la calidad de los certificados digitales, las versiones de software, etc...

Figura 1: Security Headers & SRI Test. Para los favoritos

Para hacer tests puntuales de seguridad en la web, existen muchas utilidades que puntualmente puedes utilizar para ello. Desde revisar los archivos que tiene una web enviándolos a Virus Total, revisar la configuración de los certificados digitales con SSL Server Test de Qualys o usar nuestro MetaShield Analyzer para revisar los metadatos de los documentos públicos de una web. Son útiles para pruebas puntuales porque se ofrecen desde la nube y te permiten ver rápidamente la información relevante de un determinado aspecto.

Security Headers para comprobar tus HTTP Headers

Hoy os traigo un par de webs que sirven para revisar algo de forma rápida. La primera de ellas es Security Headers, que revisa algo que es muy útil en la configuración de un sitio web que quiere ser robusto frente a todo tipo de ataques. Son los HTTP Headers que un servidor envía a un navegador para fortificar la plataforma. 

Figura 2: Revisión de Security HTTP Headers en Google.com

Basta con poner el nombre del sitio y obtener información de cómo están configurados los HTTP Headers relativos a la seguridad del sitio. Algunos de los más importantes ya los hemos tratado en multitud de artículos, por lo que os dejo algunas referencias:

- Server: Este header puede ser muy "verbose" y llegar a dar la información de la versión exacta del servidor, así que su revisión es más para evitar fugas de información que para configurar algo robusto en el cliente. 

- X-Powered-By: Normalmente este campo también puede ser una fuente de información de leaks que informe al visitante del framework con que se construye una web.  

- X-Frame-Options: Este header es para fortificar el navegador frente a ataques de ClickJacking. 

- X-XSS-Protection: Esta cabecera sirve para que el servidor fuerce el uso del filtro AntiXSS en el navegador. También, por supuesto, para deshabilitarlo. 

- X-Content-Type-Options: Los navegadores, sobre todo al principio, intentaban averiguar el tipo del documento que estaban cargando independientemente de su extensión. Esto era un problema con sistemas de correo electrónico donde archivos HTML enviados como TXT se acababan ejecuntando en el navegador. Con este header el servidor le puede decir al navegador que no intente averiguar el MIME Type del documento. 

- Strict-Transport-Policy: Es la cabecera que se utiliza para configurar las funcionalidades de Certificate Pinning disponibles en el protocolo HSTS. 

- Access-Control-Allow-Origin: Es el header que configurar la política CORS (Cross-Origin Resource Sharing) que indica de qué puntos se puede cargar o no cierto contenido. 

- CSP (Content Security Policies): Son los headers que se usan para configurar de forma completa cómo debe ser la ejecución de los contenidos de una web. Desde carga de contenido script, plugins o servidores a utilizar.

SRI Test para comprobar SubResource Integrity

La segunda de las webs que os dejo, de diseño similar, se encarga de revisar la política SRI (SubResource Integrity) de la que os hablé hace no mucho. En esta web - SRI Test - se comprueba si hay algún archivo de un servidor tercero que tenga o no configurada los hashes de integridad para evitar cargar contenido manipulado por un atacante.

Figura 3: SRI Test en Apple.com. Ninguna protección SRI pero ninguna
carga de contenido de fuera del dominio apple.com

Al final, son dos pequeñas utilidades que te pueden ayudar a revisar la configuración de tus sitios web expuestos a Internet y recibir algunas recomendaciones de fortificación que son útiles y que si no las conoces te pueden ayudar.

Saludos Malignos!

Proyecto No Encontrado: Dona tu mensaje de Error HTTP

Quienes hemos participado activamente en distintas ONG sabemos el esfuerzo personal y económico que eso implica para tratar de brindar algo a la comunidad o a la sociedad en general. Muchas veces las personas que trabajamos en el mundo de la tecnología, somos absorbidos por el famoso y tan odiado “día a día” que nos quita tiempo para los proyectos que realmente nos gustan, para las investigaciones que queremos hacer, para desarrollar ideas y avanzar con nuevas tecnologías, y mucha veces se apodera de ese tiempo que podríamos dedicar a ayudar o a colaborar con otros…

Figura 1: Dona tu mensaje de Error HTTP 404 al Proyecto No Encontrado

Es por todo lo mencionado antes que esta idea me ha parecido simplemente genial. “No Encontrado” (@NoencontradoORG ) es un proyecto impulsado en Argentina por el abogado Daniel Monastersky en conjunto con Missing Children Argentina, basados en propuestas similares lanzadas en 2012 en Europa como www.notfound.org, para que los mensajes de error por páginas no encontradas (el famoso Error HTTP 404 Not Found), muestren, además de la notificación, una fotografía de un niño desaparecido con sus respectivos datos de búsqueda.

Figura 2: Un Error 404 conectado con el proyecto No Encontrado

Sin duda el sufrimiento y desesperación de no saber acerca del paradero de una persona es alto terrible, que encima se agrava con la sensación de que nadie lo está buscando… proyectos como “No Encontrado” son una forma distinta de mezclar la tecnología con la ayuda social.

Figura 3: Otro ejemplo de Error 404 del Proyecto No Encontrado

En la web de “No Encontrado” podremos encontrar información sobre cómo adherirse a esta iniciativa y colaborar donando tus mensajes de error para que cuando alguien no encuentre lo que busque en tu sitio, quizás pueda ayudar a encontrar a una persona desaparecida. La forma de interconexión es muy simple, a través de una API que fue desarrollada en un hackathon por varios voluntarios.

Figura 4: Información de los niños desaparecidos en el Error HTTP 404

Imagínense si los medios de comunicación con mayor cantidad de lectores o suscriptores se adhiriese a este ejercicio, cuanto podríamos ayudar a difundir las búsquedas de estos pequeños?? Si estás en Argentina, puedes donar tu error, si estas en otro país, puedes contactarte con la gente de “No Encontrado” para ver la posibilidad de ayudar a que ese proyecto se haga también en tu país.

Autor: Claudio Caracciolo (@holesec)
CSA Eleven Paths

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!