A finales de la semana pasada Marina Brocca (ES) me compartía por Twitter el artículo de presentación de ROPEMAKER (EN/Remotely Originated Post-delivery Email Manipulation Attacks Keeping Email Risky), un nuevo «exploit» que al parecer afecta a prácticamente cualquier gestor de correo en local.
La idea, según comenta Matthew Gardiner en el blog de Mimecast, pasa porque al enviar un email desde un ordenador comprometido por ROPEMAKER, o mediante un MITM, se podría tergiversar información crítica del email con el fin de que los receptores fueran redirigidos a URLs maliciosas y/o obtuvieran información distinta a la que el emisor había escrito.
¿Nada nuevo bajo el sol, verdad? Sí y no.
Lo cierto es que la parte chula del asunto está en que el ataque puede realizarse a posteriori, incluso después de que la víctima haya recibido el email en su bandeja, y pese a que realmente no se necesita comprometer el dispositivo de la víctima, solo el del emisor.
¿Cómo es esto posible?
Mediante el uso de hojas de estilo CSS en línea, que no vienen incluidas en el código HTML del email, y que por supuesto estarán bajo el control de los atacantes.
De esta manera, en teoría, la víctima podría recibir un email que pasaría todos los controles de seguridad de un gestor tradicional de correo (ya que a todos los efectos el email es legítimo), y más adelante, cuando los cibercriminales quisieran, podrían modificar esos CSS para mostrar, ocultar o añadir partes del email maliciosas.
Puesto que la mayoría de gestores de correo locales solo hacen comprobaciones en tiempo de entrada de correos, y no a la hora de abrirlos, en teoría (nuevamente), estaríamos ante un nuevo vector de ataque bastante más sofisticado que eludiría los sistemas anti-phishing.
Y hablo de gestores de correo local, ya que la mayoría de webmails (GMail, Outlook…), puesto que lo normal es que operen siempre en conectividad (hay maneras de abrir GMail sin Internet, alojando el contenido en local, pero no suele ser lo habitual), son más estrictos a la hora de controlar qué abrimos y qué dejamos de abrir.
Según su descubridor, Francisco Ribeiro, aplicaciones como Apple Mail, Outlook de Microsoft Office y Mozilla Thunderbird son vulnerables a este ataque.
Más que un fallo de seguridad, un error de diseño
Es aquí a donde quería llegar.
Le he estado dando vueltas estos días a las posibilidades que tendría jugar con estilos de cascada para inyectar código o enlaces que en primera instancia no estuvieran, y lo único que se me ocurre es que o bien ese código ya está dentro del HTML, o bien debe cargarse de otro documento externo.
- Código insertado y oculto en el HTML del email: En este caso, bastaría con utilizar los atributos position y/o display para ofuscar o mostrar la pieza de código en el momento adecuado. Pero lo verdaderamente importante es que ese código ya estaba en el HTML (aunque no se mostrase y el gestor lo obviara), por lo que debería haber pasado los controles de seguridad del gestor en el momento de recibir el email en la bandeja.
- Código inyectado desde un archivo externo: En CSS veo complicado inyectar código (quizás se podría buscar alguna manera sutil de hacerlo mediante la carga externa de imágenes en background, pero vaya, que presuponiendo que los atributos están correctamente formateados, lo más probable es que cualquier código inyectado de esta manera no llegue tan siquiera a ejecutarse), así que la única opción que le veo es realizar llamadas a archivos .html o .js externos. Ficheros que deberían levantar las alarmas del gestor… siempre y cuando el visualizador HTML fuera capaz de leerlos (cualquiera que haya lanzado campañas de email marketing sabrá que todo lo que esté fuera del propio email corre peligro de no cargarse, ergo, no funcionar).
La cuestión es que en ambos casos, o es un fallo del gestor de correos por no comprobar TODO el código del email aunque no se esté mostrando (el código está ahí, otra cosa que se use o no), o bien es un fallo del gestor de correos por permitir ejecutar contenido externo que podría ser peligroso y sin embargo no revisarlo en tiempo de apertura.
Que un gestor en local no realice comprobaciones en tiempo de apertura podría llegar a ser hasta entendible, habida cuenta de que la gracia que tienen estos gestores es que trabajan con caché local, y por tanto, pueden ser utilizados sin conexión, aprovechando cuando estén online para sincronizarse y enviar los emails o cambios que el usuario haya efectuado con anterioridad. Pero lo suyo es que la comprobación se haga siempre, siendo conscientes de que en caso de que el usuario no tenga conexión, en efecto no podría realizarse, y ya de paso tampoco sería capaz de mostrar los nuevos cambios que presumiblemente el cibercriminal haya incluido a posteriori.
El único escenario plausible es aquel en el que un código, esté dentro o fuera del HTML, se está ejecutando y no se ha comprobado. Y eso es un fallo de diseño de la herramienta.
Por tanto, veo complicado, sinceramente, materializar una campaña típica de phishing mediante este método. Seguro que habrá maneras muy creativas de cambiar una URL por otra, pero me da que la mayoría se van a encontrar con las limitaciones propias de cada uno de los gestores, que como herramientas de su padre y de su madre, controlan a su manera la visualización de HTML en emails.
No obstante, y por aquí si podrían ir los tiros, me parece una manera muy brillante de realizar campañas de ingeniería social muy dirigidas. Comprometemos el dispositivo del emisor (un conocido de la víctima que cuenta, por tanto, con la confianza de ésta), esperamos a que éste envíe algún email a la víctima, y ese email se cambia, ofuscando la parte que no nos interesa e incluyéndole información (e incluso un enlace acortado que no cargue como URL, sino simplemente como texto) que lo dirija hacia donde queremos que la víctima acabe.
Eso sí lo veo más «sencillo» de elaborar, y en efecto podría bypasear los controles de seguridad que tenga el sistema de la víctima implementados.
Eso sí, habría que ser rápido o conocer muy bien los movimientos de la víctima, ya que el email inicial que recibiría sería el correcto, y si lo ha abierto ya para cuando nosotros realizamos el cambio, pues como que no ha servido para nada toda esta operación.
Aunque bien pensado, ya que tenemos control sobre el dispositivo del conocido, bien podríamos escribir nosotros el email y dejarnos de tanta tontería. Los controles anti-phishing tienden a dar más prioridad a la relación con el remitente que al riesgo que tenga el HTML enviado, así que presumiblemente ese email llegaría a la bandeja de correo sin alerta ninguna, y el mal ya está hecho :).
Hi Pablo, thank you for your article and your critical analysis.
You make some valid points. When it comes to offline view, I encourage to read more about the ways I devised for «safe» fallback involving HTML tags holding safe text which will be hidden once the remote CSS is loaded or – even better – the Content-property technique which I elaborate in more detail in my technical whitepaper (EN). This could also be used for attacks with plausible deniability.
Perhaps the main risk in here, is not even the phishing attacks you talk about, but the non repudiation aspect of it. To break past commitments and to remove textual evidence from emails in which humans rely on.
Have a look at my paper and please let me know if you have any questions.
Thank you for your article.
Thanks for the comment Francisco. It’s a interesting aproximation. Change past evidence, maybe to obfuscate sensible information or any do you like.
Good report!