topsearches-hijacker o “inyectando XSS como búsqueda más común”

A la hora de realizar una auditoría web siempre tenemos que andar buscando si cada parámetro que podemos modificar en las peticiones provoca cualquier cambio en el resultado devuelto por el servidor, por poco perceptible que sea.

Es muy común que las páginas web hoy día muestren las búsquedas más realizadas por sus usuarios con la finalidad de proporcionar información que, estadísticamente, será de utilidad para gran parte de los visitantes. Lo que conviene tener en cuenta es que, si nosotros conseguimos alterar las búsquedas más realizadas para incluir la nuestra propia, podremos hacer que se muestre el texto que nosotros queramos en la página principal (siempre teniendo en cuenta posibles filtrados que realicen a los parámetros recibidos).

Para ello, la forma más sencilla de llevarlo a cabo es realizar búsquedas con la inyección XSS que queramos para que se realicen por parte de la aplicación web los correspondientes INSERT en la base de datos para guardar registro de todas las búsquedas realizadas hasta que detectemos que ya aparece nuestro XSS en la página principal.

He realizado un pequeño script en python que realiza justo lo comentado, le indicamos la url que muestra las búsquedas mas realizadas y la expresión regular para parsearlas, le indicamos la url utilizada para realizar las búsquedas “legítimas” y le decimos el “tag” que queremos inyectar.

Por ejemplo:

• URL del buscador: http://localhost/search.php?q=BÚSQUEDA
• URL que muestra las búsquedas más repetidas: http://localhost/show_searches.php
• Expresión regular para detectar dichas búsquedas más repetidas: tags = re.findall("<div class=\"mostsearched\"> (.+) <\/div>", html_response)

Para probarlo he “programado” dos sencillos php, por un lado el php que muestra los resultados más comunes:

Script en php que muestra las búsquedas más típicas

Lo sé, no tengo desperdicio como diseñador web... :p

Por otro lado, está el php que se encarga de guardar la “búsqueda” realizada (no muestra ningún resultado, sólo hace el correspondiente INSERT en la base de datos y lo muestra por pantalla).

Script en php para "buscar" y guardar registro de las búsquedas

Eso sería la parte que correspondería a la página web, algo austera pero funcional ;) .

Ahora bien, para inyectar búsquedas con nuestro XSS he creado un script muy sencillo en python que se encarga de realizar “búsquedas” hasta que detecta que el XSS ha sido inyectado correctamente (por supuesto, hay que recordar que si realizan algún tipo de filtrado el resultado no será el esperado...).

topshearches-hijacker.py en acción

En este caso vemos cómo han sido necesarias 12 peticiones para colocar el tag con el XSS entre los resultados más buscados y que, por tanto, sea mostrado en la principal, logrando un XSS almacenado que podría afectar a un gran número de visitantes.

Para todos aquellos que os apetezca trastear con el script tenéis todo para descargar en https://sites.google.com/site/navegandoentrecolisiones/home/scripts-python.
El script no es nada del otro mundo y necesitará cambios para que funcione en otro entorno, pero lo dejo a modo de PoC y por si le puede servir a alguien...

Nos vemos!

 

Análisis estático de código con RATS

Durante el proceso de desarrollo, o mantenimiento, de software es necesario prestar atención a todos los aspectos relacionados con la seguridad del mismo y no únicamente al aspecto y/o funcionalidades del mismo.

Entre las acciones que se han de llevar a cabo para vigilar el nivel de calidad en cuanto a términos de seguridad se refiere, nos encontramos con la auditoría de seguridad de caja blanca de todo el código fuente. A pesar de que dicho proceso pueda realizarse manualmente revisando miles y miles de líneas de código es una tarea repetitiva y tediosa que puede automatizarse en gran medida.

Existe gran diversidad de software destinado a ayudar a la auditoría de código (semi)automatizada y, dependiendo del lenguaje auditado, de las necesidades de creación automatizada de informes, etc, necesitaremos usar uno u otro.

En este caso vamos a utilizar RATS (Rough Auditing Tool for Security), de la empresa Fortify y disponible como herramienta Open Source, para analizar de forma estática un programa en C y buscar de forma fácil vulnerabilidades en el mismo.

Para ello, vamos a utilizar el siguiente código:

int main(int argc, char *argv[]){

char buffer[10];

strcpy(buffer, argv[1]);

}

Es un código muy simple que, lo único que hace, es copiar el primer parámetro que se le proporcione en el array de char llamado buffer, sin realizar ningún tipo de comprobación previa. Ello, dependiendo de dicho parámetro, puede conducir a un stack buffer overflow, lo que podría provocar la ejecución de código arbitrario mediante la explotación de dicha vulnerabilidad. Es un ejemplo simple, pero nos servirá para la prueba de RATS.

Primero será necesario instalar RATS, o bien con un conocido ./configure, make, make install o bien directamente del repositorio según la distribución.

La forma más sencilla de ejecución de RATS es indicando únicamente el fichero, o directorio, que contiene el código fuente a auditar.

Como podemos ver en la imagen, RATS ha encontrado que se utiliza un buffer de tamaño fijo, así como la función strcpy, y nos avisa de que ambas acciones son peligrosas y pueden conllevar un desbordamiento de memoria.

Entre las distintas opciones disponibles, existe una que considero que puede resultar de gran utilidad, la opción --xml. Con ella, la salida de RATS se nos mostrará formateada en XML, por lo que podremos volcarlo a un fichero para su posterior tratamiento.

Un ejemplo de dicho tratamiento podría ser un script de entrada en un repositorio SVN para comprobar el número y gravedad de vulnerabilidades y, según los resultados, permitir o no hacer el commit (gracias Leo por la idea).

Esto es sólo un ejemplo muy sencillo pero que vale para demostrar la utilidad de herramientas como RATS que pueden ayudar en gran medida en los tediosos procesos de revisión de código, siempre sin olvidar que se realiza un contenido estático basado en las funciones utilizadas (en RATS dichas funciones peligrosas se declaran en ficheros XML, lo que permite una rápida modificación o expansión de las mismas) y que siempre será necesaria la revisión manual debido a posibles falsos positivos y/o falsos negativos.

Espero que a alguno de vosotros os sea de utilidad en algún momento, saludos.