Cómo aprender de los mensajes de error en un pentesting

Este jueves pasé un rato entretenido con los compañeros jugando con unos nodos de un sitio web en Apple. Digamos que por casualidad topamos con un bug de IIS Short Name en uno de sus servidores - sí, Apple también utiliza Windows -, pero cuando íbamos a probar en detalle la vulnerabilidad los resultados eran inconsistentes... ¿cómo era esto posible?

Figura 1: Cómo aprender de los mensajes de error en un pentesting

Pues fácil, ese sitio web estaba siendo soportado por un cluster de servidores Microsoft Windows con Internet Information Services y el fallo no se encontraba en todos, lo que nos llevó a estrujarnos un poco más el cerebro y a que todo fuera aún más interesante.

Los mensajes de error en los servidores web

Muchas veces hemos hablado de la importancia de los mensajes de error en los servidores web. Hay que jugar mucho con querystring para sacar el máximo posible de información de un servidor web y los frameworks que tenga instalado. Cada código de respuesta HTTP puede estar configurado de forma distinta en cada framework, lo que hace que de cada uno de ellos se saquen datos.

Figura 2: Múltiples Frameworks que pueden procesar la petición

Un Error 404 dado por el servidor web no tiene por qué dar la misma información que un Error 404 del framework .NET, o del framework JSP, por lo que hay que conseguir hacer pruebas para obtener códigos de error HTTP en todos los motores del servidor web.

Múltiples nodos de un servicio

Para rizar un poco más el rizo, un sitio web puede estar soportado por un cluster de equipos publicado detrás de un balanceador - que además podría utilizar una CDN - por lo que hay que tener cuidado. Cuando un servicio utiliza más de un equipo para ofrecer su servicio, la labor del administrador debe ser configurar los dos de la misma forma, sin embargo esto no es siempre así. En el mundo de los servidores DNS esto es algo común y por eso en FOCA añadimos la opción de comprobar todo en todos los servidores DNS, pero también puede pasar en el mundo de los frontales web.

Figura 3: Un ejemplo de servidores DNS con diferentes configuraciones en Menéame en 2010

Localizar que un sitio web está detrás de un balanceador o que es parte de un cluster a veces se puede localizar directamente en las cookies. Sistemas como BigIP permiten localizar entornos con más de un sistema dando servicio a un servidor web.

Figura 4: Cookies de BigIP que dan información de los nodos

Otras veces simplemente hay que fijarse en todos los detalles para localizar la fuga de información necesario que nos haga descubrir la existencia de más de un nodo detrás de un servicio, como vamos a ver más adelante.

Dos nodos sirviendo distintos headers

En este caso, la característica que nos llevó a detectar múltiples nodos en un sitio web fue un header. Al revisar uno de los servidores web de Apple que tiene con tecnología Microsoft IIS, vimos que cuando pedíamos un documento ASPX que no existía, obteníamos una página de Error 404 aparentemente similar pero que no lo era. Esta es la respuesta del Nodo 1.

Figura 5: Mensaje de Error 404 del Framewok .NET en el Nodo 1

Si nos fiamos en los Response Headers de la siguiente imagen, podemos ver que el Nodo 2 tiene configurada la respuesta con el campo Server, donde se indica que es un Microsoft-IIS/6.0.

Figura 6: Mensaje de Error 404 del framework .NET en el Nodo 2

Por supuesto, de esto nos hubiéramos dado cuenta si nuestro sistema de pentesting persistente Faast no nos hubiera marcado que en este servidor se podía hacer un listado de directorios con el truco del IIS ShortName, así que, sabiendo que había dos nodos había que probar si este fallo estaba en uno o en los dos nodos.

Dos configuraciones distintas en los nodos

Probar un valor True con el bug del IIS Shortname exige poner el comienzo de un nombre de archivo que exista y un False el de uno que no exista. Esto nos permite hacer un proceso de booleanización para sacar los valores del nombre del archivo carácter a carácter. Con los servidores IIS 6.0 el resultado que se debe obtener, siguiendo la siguiente tabla de valor, es un Error 404 cuando existe un archivo que comienza por esa cadena y un Error 400 cuando no hay ningún archivo que comience por esa cadena.

Figura 7: Tabla de explotación del bug de IIS Shortname

Si miramos los resultados que se obtienen en el Nodo 1, se puede ver que cuando hay un archivo que comienza por esa cadena, en este caso la letra "a", se obtiene un Error 404 con un mensaje,

Figura 8: Archivo comenzando por letra "a" (sabemos que existe) da un Error 404 en Nodo 1

Por el contrario, cuando se solicita un archivo que comienza por la letra "X" y esta petición llega al Nodo 2, el resultado que se obtiene es un Error 404 con el mismo mensaje, lo que deja claro que NO se puede hacer un listado de directorios en formato 8:3 en este nodo del sitio web usando estas técnicas.

Figura 9: Archivo comenzando por letra "X" (sabemos que NO existe) da un Error 404 en Nodo 1

Por el contrario, si miramos los resultados que se obtienen con el Nodo 2 notamos diferencias. Cuando el archivo existe vemos un Error 404 con un mensaje de una única línea, tal y como indica la tabla de comprobación.

Figura 10: El archivo existe, así que se obtiene un Error 404 en Nodo 2

Pero cuando ponemos la cadena de un archivo que no existe, obtenemos otro Error 400 de Bad Request debido a que el archivo NO existe. Tal y como dice la tabla que se explotan estos fallos en la versión de IIS 6.0.

Figura 11: El archivo NO existe. Se obtiene un Error 400 en Nodo 2

Esto quiere decir que el Nodo 2  adolece de esta debilidad, mientras que el Nodo 1 está configurado de una forma que no permite esta manera de explotarlo.

Dos nodos con dos configuraciones distintas también en ASP

Esta configuración distinta de los tratamientos de errores se pude encontrar en muchos otros sitios, por ejemplo, en el código de Error 404 de ASP se puede ver que en el Nodo 1 sale un mensaje no controlado. 

Figura 12: Error 404 de framework ASP en el Nodo 1

Ese mensaje de arriba deja a las claras que es un IIS 6, ya que si no probablemente nos hubiéramos encontrado un mensaje de Error ASP de un servidor IIS migrado, mucho más verbose que éste. 

Figura 13: Error 404 ASP controlado en el Nodo 2

En el caso del Nodo 2, el mensaje de Error 404 de ASP está controlado y sale una página de Apple totalmente maquetada para evitar cualquier fuga de información. 

Más errores: ASP.NET, ColdFusion y JSP

Ya para terminar, volviendo al principio, no tiene porque pasar lo mismo en todos los frameworks, y si probamos con un archivo que no existe en el framework de ColdFusion, lo que obtendremos en todos los nodos es el mismo mensaje de error. Un Error 400 en este caso.

Figura 14: Error 400 con un not found en ColdFusion

Aún así, como veis, jugando con los mensajes de error de los distintos frameworks se puede sacar mucha información. Ya para terminar, me faltaba comprobar el Framework JSP, ya que si hay ColdFusion hay soporte para JSP y dependiendo de la licencia se puede obtener un Error 500 o un Error 404.

Figura 15: Errores por el framework JSP

Ya por último, igual que en el caso de Microsoft.com podemos intentar poner algún carácter o cadena de caracteres no válida para generar algún otro error del framework .NET (que sabemos que está). Simplemente, con dejar la tilde sin poner un número, se obtiene el Runtime Error de .NET.

Figura 16: Runtime Error en el framework .NET. Error 500

Al final, como se puede ver, jugando con los errores de una web, en todos sus frameworks y en todos los nodos de un sitio se puede llegar a obtener una gran cantidad de información. Hay que revisar todo que puede que, como en este caso, el administrador se deje muchos mensajes de error sin maquetar y controlar.

Saludos Malignos!