viernes, diciembre 07, 2012

RoundCube II: Nuevos vectores para ataques XSS (1 de 2)

Ya hace tiempo publiqué usa serie sobre cómo jugar con un XSS en RoundCube, y como desde entonces he seguido jugando con él, en este artículo os voy a contar alguna cosa más. Hará unas semanas que reporté a los desarrolladores de RoundCube una vulnerabilidad de tipo XSS explotable mediante ficheros SWF. A estas alturas ya cerraron el ticket pero, mientras ellos se entretenían en buscar la solución al problema, yo seguí enredando y probando cosas de las mías.

El resultado es que me encontré con otro par de vulnerabilidades más, también de tipo XSS. Y es que los problemas de seguridad se parecen a las cabezas de la legendaria Hidra: cortas una y le surgen dos nuevas. De modo que hubo que abrir otro ticket

Menos de un día han tardado en dar el tema por cerrado y, la verdad, no dan demasiados detalles al respecto, pero supongo que las próximas versiones de RoundCube ya no presentarán estas vulnerabilidades. Mientras tanto, y por si alguien quisiera comprobar la seguridad de sus sistemas de webmail, ahí va la historia.

La teoría

Antes de mostrar un mensaje o un fichero adjunto, RoundCube se toma el trabajo de analizarlo y eliminar los elementos que pudieran ser utilizados para realizar ataques de XSS. O al menos de aquellos que detecta como tales. Aunque esta medida de seguridad altera el contenido de los mensajes, es imprescindible para intentar mantener un nivel de seguridad adecuado.

Otra modificación que introduce RoundCube es introducir un “target=’_blank’” en los enlaces que aparecen en los mensajes con formato HTML, de modo que sus destinos se abran en una nueva ventana o pestaña.

Ambas cosas pueden dificultar la realización de ataques mediante XSS. Pero no hacerla imposible. Una de las cosas que descubrí hace tiempo es que este sistema de webmail detecta los enlaces cuyo HREF comenzara por “javascript:” y los anula.

Pero Internet Explorer permite realizar scripts no sólo en JavaScript, sino además en Visual Basic Script, y las URLs de tipo “vbscript:” sí estaban permitidas, lo que hace posible la ejecución de código de forma sencilla.

Pero las URLs que comienzan con “javascript:” - y “vbscript” en IE - no son las únicas que pueden causar la ejecución de scripts en el navegador. Unas de las que no se habla tanto y que, al menos en Firefox, pueden servir para este propósitio son las “data:”. Las URLs “data:” se pueden utilizan para insertar directamente, dentro de una página, contenidos que de otro modo habría que obtener de fuentes externas. Por ejemplo, una imagen podría venir dada por:
<IMG SRC="data:image/jpeg;base64, /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEPERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/ … … (aquí va un montón de líneas de datos que no se copian por motivos de espacio) … wDfqMVEbscZNR1CaJEKHGd6zalfzRKhQ4z/AModMy1cdLKPNtpkQv8AvG1z+f54zCxsZgRdXTzyF250Hurt5ZCzV//Z ">

La clave está al principio. Con “data:” se indica que no es necesario acceder a otro documento para obtener a la información. Después aparece el tipo MIME para los datos, en este caso “image/jpeg”. Con “;base64” se indica que los datos están codificados en BASE64. Finalmente, una coma (“,”) marca el punto de inicio de los datos. Para más información se puede leer el correspondiente RFC 2397.

Algunos navegadores, como Firefox o Chrome soportan el uso de URLs “data:” en la barra de direcciones y como destino de enlaces. Eso hace posible cosas como:

Figura 1: Mostrando una imagen de Fear the FOCA con una URL data:

O también generar páginas HTML de forma dinámica y sobre la marcha. Por ejemplo, con una URL como:
 data:text/html, <h1> Hola</h1> <script>alert('HOLA')</script> 
Con lo que se obtendría el siguiente resultado:

Figura 2: Un script en una URL data:

Existe una diferencia importante en la forma en que Chrome y Firefox manejan los enlaces a URLs “data:” que crean una nueva página de forma dinámica. Mientras que Chrome no asigna un dominio a la nueva página, Firefox la considera como perteneciente al dominio de la página desde la que fue abierta. Y esto puede significar problemas, como veremos en la segunda parte...

Enrique Rando

************************************************************************************************
- RoundCube II: Nuevos vectores para ataques XSS (1 de 2)
- RoundCube II: Nuevos vectores para ataques XSS (2 de 2)
************************************************************************************************

1 comentario:

AnilloRbl dijo...

Incluso se puede afinar más el código html embebido poniéndolo también en base64 para bypassear filtros XSS:

data:text/html;base64, PGgxPiBIb2xhPC9oMT4gPHNjcmlwdD5hbGVydCgnSE9MQScpPC9zY3JpcHQ+

Saludos!

Eleven Paths Blog

Seguridad Apple

Entradas populares