Request Filtering en Internet Information Services y sus errores

Hace un par de días os conté como se podía jugar con los mensajes de error en un servidor Microsoft Internet Information Services en un dominio de Apple para localizar un nodo de una arquitectura en cluster que era vulnerable. Bajo esa misma premisa quise hacer algo similar con los servidores que dan soporte al sitio web www.microsoft.com que por supuesto también es publicado bajo una buena cantidad de máquinas.

Figura 1: Request Filtering en IIS y sus errores

Al final, tras horas de juegos, pruebas y darle la vuelta a Internet buscando información, acabe dando con un pequeño detalle de la configuración por defecto de IIS y Request Filtering. No es que sea de enorme importancia, pero espero que os entretenga la historia para este domingo. Os la narro según yo la fui pensando.

Los servidores en la web de www.microsoft.com

Como os he dicho, todo comenzó con la búsqueda de los servidores detrás de www.microsoft.com. Mirando en los Response Headers, se puede ver que ahora hay servidores con versiones de Microsoft IIS 8.0 y Microsoft IIS 8.5. No hay más que hacer varias peticiones y comprobar como varía el campo.

Figura 2: Servidor IIS 8.0 en www.microsoft.com

Figura 3: Servidor IIS 8.5 en www.microsoft.com

Jugando con los mensajes de error en ellos, se puede ver que están configurados de la misma forma, así que no sucede lo mismo que sucedía en el caso del otro día. Todos parecen correr sobre Windows Server 2012 y con las mismas configuraciones. Salían cosas curiosas, no obstante, así que decidía jugar un poco con ellos. El Error 404 genérico controlado es el que se puede ver a continuación.

Figura 4: Error 404 controlado en www.microsoft.com

Como curiosidad, pensé que tendría gracia ver el Error 404 del framework PHP, y la verdad es que no me equivoqué y salía algo bastante peculiar, que puedes ver aquí, ya que contesta con un Error 304.

Figura 5: Error 304 cuando se pide un fichero PHP (debería ser un 404 normal)

También volví a probar el Error 500 del RunTime del framewok .NET para hacer saltar las protecciones contra ataques de XSS y HTML Injection que incorpora esta tecnología, tal y como ya había visto atrás.

Figura 6: Error 500 en www.microsoft.com

En este punto, me acorde de algo que tal vez sí pudiera ayudarme en las pruebas. El módulo de seguridad para filtrar el QueryString que lleva Microsoft Internet Information Services. Este módulo se llama Request Filtering - antes conocido como URLScan -.

Request Filtering en Microsoft Internet Information Services

El módulo que acompaña a los servidores Microsoft IIS desde la versión 7.0 hasta la versión 8.5, pasando por IIS 7.5 e IIS 8.0 lleva por nombre Request Filtering y es una evolución del anterior URLScan que se utilizaba en los servidores Microsoft IIS hasta la versión 7.0. Este módulo puede filtrar por muchas característica, y una de ellas es la extensión del fichero solicitada, como se ve en la imagen siguiente.

Figura 7: Request Filtering

Como ya os conté en el artículo de "¿Y tú cómo juegas con el QueryString en un pentesting?", todos los módulos que van recibiendo las peticiones pueden tratarlas o no, y generar códigos de respuesta con páginas por defecto para atender la petición. Así, una URL puede ser procesada y respondida por el core del servidor web, pero también por los motores de cada uno de los lenguajes que soporte una determinada instalación, o, si hay un WAF, por el módulo de seguridad - algo que hemos visto en el artículo de Cómo hacer cantar al WAF.

Figura 8: Reglas de bloqueo de ataques de SQL Injection en Request Filtering

Con Request Filtering se pueden configurar reglas para bloquear tipos de ficheros, extensiones, o expresiones regulares en la URL, bloqueando ataques de SQL Injection, de MongoDB Injection, o lo que quieras. De hecho, como es programable en tiempo real se pueden montar escenarios de virtual patching modificando las reglas de Request Filtering en tiempo real.

En este caso, Request Filtering también procesa las peticiones y genera un mensaje de error con páginas de respuesta que podrán estar controladas por el administrador del sitio para que el usuario tenga un mensaje friendly o dejadas por defecto. Como se puede ver, en el caso de www.microsoft.com al solicitar una URL con un fichero de extensión filtrada la respuesta no está modificada.

Figura 9: Una extensión filtrada por Request Filtering en www.microsoft.com

La lista de extensiones de ficheros que se bloquean por defecto en Request Filtering es de más de 40, y están entre ellos algunos como .dd, .ldf, .java, .mdb, etcétera. Y en ese punto llegó mi pregunta. ¿Habrá algún fichero que esté bloqueado en algunas versiones? Si fueran varios y disjuntos, tal vez se  podría llegar a realizar una detección de la versión de IIS simplemente por el tratamiento que hace Request Filtering a cada una de las peticiones. Y continué probando cosas.

Extensiones de Fichero bloqueadas por Request Filtering

No fue trivial localizar las extensiones de ficheros que vienen bloqueadas por defecto en todas las versiones de Request Filtering que acompañan a cada versión de IIS. Además, algunas extensiones no están filtradas en Request Filtering por defecto, pero software de SharePoint u Office Web Server - por poner dos ejemplos - pueden modificar esa lista, además del propio administrador del sitio. 

Figura 10: Extensiones filtradas por Request Filtering por defecto en algunos IIS

Ésta es la lista de configuraciones por defecto que fui capaz de localizar sin tener que instalarme todas las versiones de IIS. Como veis falta la de IIS 8.5, así que si lo instalas y me confirmas la lista de extensiones te lo agradeceré.

Al hacer la comparación entre las extensiones que están bloqueadas en uno y otro, se puede ver que hay pocas diferencias. La principal diferencia es que en IIS 7 no se filtraba la extensión .rules. Esto hace que si el servidor es un IIS con version IIS 7.5 o superior vaya a generar un mensaje de error igual para las peticiones foca.rules que para foca.dd o foca.mdb.

Figura 11: Error 404 al pedir una extensión filtrada por Request Filtering en IIS 7.0

Sin embargo, si es una versión de IIS 7.0, puede que nos encontremos con que foca.rules y foca.dd tienen tratamientos de error distintos. En .NET los ficheros .rules tienen un funcionalidad muy específica y por eso da un Error 403 en este caso.

Figura 12: En este caso es el framework .NET el que prohibe la extensión .rules

Esto puede ayudar a primero, localizar un nuevo mensaje de error, y dos conocer mejor el servidor web con el que estamos trabajando.

La extensión rules en IIS 6.0

Cuando estamos con un servidor IIS 6.0, aprovechando que .rules está prohibido por el framework, siempre podremos forzar un error para sacar información de la versión .NET que está instalada.

Figura 13: Error 403 en un IIS 6.0 al pedir la extensión .rules

Al final son pequeños detalles, pero como sabéis, la suma de todos acaba ayudando a hacer un pentesting completo. Ojo, depende de la personalización de cada sitio puede ser que no siempre se consiga el resultado esperado, pero por lo menos tienes un punto más por el que tirar. Espero que la lectura os haya entretenido, que yo pasé todo un sábado dándole vueltas a esto, que no tenía otra cosa mejor que hacer.

Saludos Malignos!