¿Y tú cómo juegas con el QueryString en un pentesting?

Los pocos ratos libres que saco en cafeterías, aeropuertos, viajes en tren o noches de desvelo los dedico a seguir jugando con lo que más me apasiona. Dedico ratos a revisar artículos que he guardado para leer después, a revisar alguna herramienta o a probar alguna nueva idea. Lo bueno de la seguridad informática y el hacking es que siempre hay posibilidad de dar una nueva vuelta de tuerca a cualquier parte. Siempre se puede probar algo nuevo y siempre puedes probar una nueva aproximación. En el mundo de la seguridad de las aplicaciones web, una de mis grandes pasiones, siempre puedes sacar un rato, abrir el navegador y enredar por ahí a ver qué sale.

Figura 1: ¿Y tú cómo juegas con el QueryString?

A lo largo de todos estos años, mi visión era que para hacer una auditoría web completa había que probar todo. Al igual que los investigadores que van en busca de bugs en binarios utilizan técnicas de fuzzing para localizar cualquier anomalía que pueda llevar a descubrir un fallo de seguridad, en las aplicaciones web mi idea es que hay que conseguir hacer lo mismo. Por supuesto, éste no es exactamente el mismo entorno, ya que con un binario puedes trabajar en tu equipo y aprovechar al máximo la potencia de computo de tu máquina, mientras que en un servidor web tienes que contar con la línea de comunicaciones en medio y las medidas de seguridad que protejan el sitio.

Aún así, es fundamental probar todo lo probable, todo lo improbable y parte de lo imposible si quieres conseguir encontrar los secretos que detrás de una URL esconde un servidor web. Hay que jugar con el QueryStging a ver quién hay detrás y cómo se comporta, que muchas veces te sorprende. Yo me dedico a jugar mucho con él, y si sale alguna nueva pieza de información útil, a la mañana siguiente que pase por la oficina de Eleven Paths me siento un rato con los compañeros que llevan los plugins de nuestro sistema de Pentesting Persistente para que metan en la knowledge base de Faast las pruebas pertinentes para detectar en los servidores de nuestros clientes ese defecto, bug, leak o trick.

Figura 2: Un sencillo fuzzing con parámetros puede generar un error no esperado

El QueryString, tomado como una cadena de caracteres que pueda ser procesada como un string puede dar mucho juego. Por ejemplo, cuando haces una llamada a un determinado servidor web con un QuerySgtring cualquiera, eso antes puede pasar por los elementos de seguridad de red. Sabiendo eso puedes intentar hacer saltar el WAF y sacar información de él. Esto ya os lo conté en el artículo que explicaba lo fácil que es simular un ataque de LFI para hacer cantar al WAF. Esta misma idea se puede aplicar de igual forma con los ataques de inyección de código Server-Side y Client-Side.

Figura 3: Errores por protecciones contra ataques de HTML Injection

En muchos servidores IIS, por ejemplo, es suficiente con simular un ataque de Inyección de comandos HTML para obtener un Error 400 o un Error 500 que lo identifique, o, como se ve aquí, hacer saltar por los aires una aplicación .NET como en el caso de la propia Microsoft.com.

Figura 4: Error forzado en Microsoft.com simulando un ataque de HTML Injection

Dedicarse a hacer fuzzing del QueryString añadiendo caracteres a un determinado nombre de dominio o directorio puede dar muchas sorpresas. Hay que tener en cuenta que muchas veces, puede que ese QueryString esté siendo parseado por algún módulo del servidor que esté haciendo URL Rewrite o que directamente esté siendo entregado a una aplicación que va a procesar el QueryString completamente. Una cosa que hacen muchos sitios es, cuando se solicita por URL una dirección que una aplicación que no existe, el módulo de tratamiento de errores, en lugar de enviar un Error 404 directamente lanza una consulta a ver si puede extraer alguna otra página y devuelven documentos.

Figura 5: El QueryString sirve para buscar páginas con el título que tengan en Rolling Stones

En el momento en del QueryString se saque una cadena de caracteres y se trate como un parámetro, esto podría desembocar en un ataque de inyección de código tanto del lado del cliente como del lado del servidor. Podría acabar en una consulta a una base de datos o en un parámetro que se imprimiese en la página del cliente. En muchos casos, simplemente porque el QueryString se ha copiado íntegramente en la página de respuesta.

Figura 6: En esta página el QueryString puede convertirse en una cadena de búsqueda.
Además sufre una sanitización peculiar.

Por supuesto, hacer fuzzing en el QueryString puede desembocar en la generación de mensajes de error en todos los niveles que pueden interpretarlo, lo que ayudaría a poder sacar mucha información del sitio objetivo. Pensad que solo el QueryString puede ser procesado por el WAF, por el WebServer, por el motor del Engine que ejecute la aplicación, por el programa en concreto que se ejecute, por el sistema de ficheros y por los programas que se lanzan en el tratamiento de errores. Así aparecen cosas como el bug de IIS, los leaks del módulo de Mod_Negotiation, los mensajes de errores con tanta información de PHP, de TomCat, ColdFussion y demás.

Figura 7: Elementos que pueden acabar procesando el QueryString según el flujo

La gracia está en que, depende de cómo esté construido ese QueryString, vas a poder comunicarte con uno u otro de los elementos de toda la cadena y, tal vez, sacar información diferente de cada uno de ellos para encontrar, quién sabe, un nuevo camino. ¿Qué pruebas haces tú cuando te enfrentas un www.server.com para jugar con el QueryString?

Saludos Malignos!