Jugando con RoundCube (5 de 5)

************************************************************************************************
- Jugando con RoundCube (1 de 5)
- Jugando con RoundCube (2 de 5)
- Jugando con RoundCube (3 de 5)
- Jugando con RoundCube (4 de 5)
- Jugando con RoundCube (5 de 5)
Autor: Enrique Rando
************************************************************************************************

Episodio 7. Revisando lo del XSS

El ataque anterior tiene sus problemillas. Por un lado, el atacante ha enviado un correo mediante el webmail y, si la cosa se investiga, lo pillarían. Por otro, ha necesitado encontrarse con un problema de configuración que permitiera listar y acceder a los contenidos de la carpeta temporal.

¿Podría haberse hecho mejor? Seguro que sí. Para empezar, remitiendo el correo de una forma más conveniente. Desde un equipo que sea difícil de controlar, se lanza un telnet, netcat o similar al servidor de correos y, si el SMTP no pide contraseñas, … En este caso, el atacante sólo tenía a mano el programa putty para Windows, de manera que se puso manos a la obra. Primero, usó el Bloc de Notas para crear un fichero con el siguiente contenido:

Figura 30: El mensaje en el bloc de notas

Después, arrancó putty con: putty.exe -raw -P 25 webmail.example.com y copió todo el contenido del bloc de notas y lo peguó en el putty (botón secundario del ratón). La ventana del putty se cerró. El correo había sido enviado con lo que el jefe recibió entonces un correo que parecía provenir de un superior:

Figura 31: El mensaje recibido

Se supone que el texto (“bla,bla,bla”) es suficientemente largo como para que no se vea en pantalla el código HTML/JavaScript del final, el cual sirve para explotar una vulnerabilidad que presenta RoundCube cuando es utilizado con Internet Explorer 8 o anterior. Vayan ahora el código de “evil.php”, que se encarga de redirigir al usuario a una URL que explota la vulnerabilidad (también se podría haber usado de un IFRAME en lugar de la redirección):

Figura 32: evil.php

El fichero “evil.js” debe resultar familiar a estas alturas. Era aquel que robaba los correos y los mandaba a un servidor controlado por el atacante. “Más me vale hacer caso a mi superior” – pensó el jefe. Así que hizo clic en el enlace y:

Figura 33: Esto está haciendo algo

El resto de la historia es conocido. El atacante obtuvo los correos de su víctima:

Figura 34: Hay un correo nuevo

Figura 35: Su contenido

En fin… del resto, quizá nos enteremos algún día.

Epílogo

Esta vulnerabilidad fue reportada al equipo de RoundCube, que la cerró al considerarla un duplicado de otra anterior que decía:

Contents of attachments (such as pictures) which are embedded in HTML (multipart/related) messages should be checked before sending them to the client.
Internet Explorer executes javascript code within images (!) if <script> ... exists in content. It entirely ignores mimetype headers but does content sniffing. This is a XSS vulnerability which exists when using Internet Explorer and is an attack that takes advantage of a bug which exists in the web browser.
Reproduction Procedure: Disguise HTML which contains a SCRIPT tag as a picture file (.jpg, .gif, etc.) or create a picture file that contains a SCRIPT tag and attach it. Send this email and when this attachment is opened/viewed, the javascript is executed.

Y modificaron ésta para que hiciera referencia a los ejemplos que yo les mandaba (que eran distintos de los de este artículo). Pensándolo bien, creo que la mía está bien cerrada, ya que los dos problemas tienen un mismo origen. De hecho, realizando unas (muy) ligeras modificaciones al código usado anteriormente, también se pueden incrustar los scripts en ficheros adjuntos, en lugar de colocarlos en el cuerpo del mensaje. Si es posible encontrar una solución común que acabe con ambos... ¿Para qué tener dos incidencias abiertas relativas a una misma actuación?

Lo que me preocupa es que la otra incidencia era de hace 5 meses. Esperemos que se arregle pronto.

EPILOGO:

Esta vulnerabilidad fue notificada a los desarrolladores de RoundCube, quienes determinaron que la solución pasaba por detectar los adjuntos con contenido Flash que tuvieran una extensión "falsa". De este modo se trataría de evitar que se engañe al usuario para que haga clic donde no debiera.

Yo les pregunté sobre qué pasaba con los ficheros SWF sin renombrar. Si tras su solución seguía siendo posible que el usuario los abriera y que se ejecutara el código JavaScript en el contexto de la sesión del correo. Y me respondieron que sí, que RoundCube no bloqueaba ese tipo de adjuntos. Que eso ya sería algo similar a que un usuario recibiera un adjunto de Word con VB malicioso dentro.

A mí, eso de que la decisión final la tome el usuario... También indicaban que era posible deshabilitar manualmente la visualización en el navegador de los documentos SWF, anulándola en la opción de configuración 'client_mimetypes' de RoundCube. Y yo les pedí que ésta sea la configuación por defecto.

Ya veremos si lo hacen o no. Y, aunque se haga, siempre habrá quien tenga sistemas RoundCube que, por una u otra razón, no pueda (o no se atreva a) actualizar. De modo que si administras un servicio de webmail basado en RoundCube ahí va mi consejo: asegúrate de que está deshabilitada la visualización en el navegador de los documentos SWF. Que nunca se sabe.

************************************************************************************************
- Jugando con RoundCube (1 de 5)
- Jugando con RoundCube (2 de 5)
- Jugando con RoundCube (3 de 5)
- Jugando con RoundCube (4 de 5)
- Jugando con RoundCube (5 de 5)
************************************************************************************************