Carta kobold: los riesgos del correo electrónico HTML

 (lutrasecurity.com)
2 puntos por GN⁺ 2024-04-05 | 1 comentarios | Compartir por WhatsApp

Carta kobold

  • Quienes tienen que lidiar técnicamente con correos HTML probablemente ya hayan llegado a momentos en los que quieren renunciar a su trabajo o prender fuego a todos los clientes de correo por sus implementaciones inconsistentes.
  • El correo HTML no es solo una fuente de frustración, también puede convertirse en un grave riesgo de seguridad.
  • Imagina que tu jefe reenvía un correo en el que pide transferir una gran cantidad de dinero; como ya has oído hablar del fraude del CEO, verificas si el correo realmente vino de tu jefe.
  • El correo efectivamente viene de tu jefe y, si en tu empresa trabajan así, incluso podría estar firmado con cifrado.
  • Pero aun así no estás del todo seguro, así que llamas a tu jefe para confirmar la autenticidad del correo.
  • Si tu jefe lo confirma, haces la transferencia.
  • Pero si esto no fuera una estafa, este artículo terminaría aquí.

Thunderbird

  • Este problema fue reportado a Mozilla el 5 de marzo de 2024, y la fecha de publicación prevista junto con un borrador de la siguiente sección fueron enviados a Mozilla el 20 de marzo de 2024.
  • Se discutieron posibles medidas de mitigación, pero su implementación quedó para más adelante.
  • Explotarlo en Thunderbird es sencillo. Thunderbird envuelve el correo en `

` y por lo demás no lo modifica.

  • Al reenviar el correo, el mensaje citado se envuelve en otro `

`, bajándolo un nivel en el DOM.

  • Teniendo esto en cuenta, se obtiene la siguiente prueba de concepto:

      .kobold-letter {
        display: none;
      }
      .moz-text-html>div>.kobold-letter {
        display: block !important;
      }

    This text is always visible.

    This text will only appear after forwarding.
  • El correo contiene texto siempre visible y texto oculto con display: none;.
  • Al reenviar el correo, el texto oculto aparece de repente, pero solo para el nuevo destinatario.

Outlook web

  • Este problema fue reportado a Microsoft el 5 de marzo de 2024, y la fecha de publicación prevista junto con un borrador de la siguiente sección fueron enviados a Microsoft el 20 de marzo de 2024.
  • Microsoft decidió el 26 de marzo de 2024 no tomar medidas inmediatas y cerró el reporte.
  • En Outlook web (OWA), la situación es un poco más compleja. El correo se envuelve en `

`, aunque el nombre exacto de la clase puede cambiar.

  • Para evitar que el CSS del correo afecte los estilos del webmail, Outlook antepone x_ a todos los id y clases del correo y ajusta el CSS.
  • Teniendo esto en cuenta, se obtiene la siguiente prueba de concepto:

      .kobold-letter {
        display: none;
      }
      body>div>.kobold-letter {
        display: block !important;
      }

    This text is always visible.

    This text will only appear after forwarding.
  • Al mostrar el correo en OWA, el CSS se ve así:
  • Después de reenviar el correo, la carta kobold queda envuelta en otro `` y el CSS se actualiza de nuevo.

Gmail

  • Este problema fue reportado a Google el 5 de marzo de 2024, y la fecha de publicación prevista junto con un borrador de la siguiente sección fueron enviados a Google el 20 de marzo de 2024.
  • Gmail técnicamente no es vulnerable a la carta kobold, porque elimina todos los estilos al reenviar un correo.
  • Al reenviar el correo, antes de que se elimine el CSS, la carta kobold oculta con CSS aparece automáticamente.

Investigación previa

  • La existencia de esta posibilidad no es algo sorprendente ni nuevo.
  • En el pasado ya se habían reportado problemas similares.

Perspectivas

  • Los usuarios pueden mitigar la carta kobold desactivando por completo el correo HTML o viéndolo en un modo restringido.
  • Para los clientes de correo, implementar mitigaciones es difícil. Impedir el uso de `` podría resolver el problema, pero también podría romper muchas soluciones ya existentes dentro del ecosistema del correo.
  • Lamentablemente, no es realista esperar que los clientes de correo implementen mitigaciones sólidas en el futuro cercano.

Opinión de GN⁺

  • Este artículo muestra las vulnerabilidades del correo HTML y explica en particular el ataque de la “carta kobold”, en el que el contenido puede cambiar cuando el correo es reenviado. Es información importante que ayuda a generar conciencia de seguridad entre los usuarios del correo.
  • También muestra que la forma en que los clientes de correo manejan CSS puede generar vulnerabilidades de seguridad, y exhorta tanto a usuarios como a desarrolladores a prestar atención a la seguridad.
  • Este tipo de ataque es especialmente peligroso porque parece provenir de una fuente en la que el usuario confía. Esto subraya la necesidad de mantenerse siempre alerta en la comunicación por correo.
  • Desde una perspectiva técnica, los desarrolladores de clientes de correo necesitan mejorar la manera en que procesan CSS para evitar estos ataques. Sin embargo, esto puede causar problemas de compatibilidad con diseños de correo ya existentes, por lo que es importante encontrar un equilibrio adecuado.
  • Aunque este artículo no trata sobre una nueva tecnología ni sobre open source, sí plantea consideraciones que deben tenerse en cuenta al adoptar tecnologías relacionadas con la seguridad del correo. Los desarrolladores de clientes de correo deben buscar formas de reforzar la seguridad del usuario sin sacrificar la usabilidad.

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-04-05
Comentarios en Hacker News

  • “However, you are still not convinced, so you call your manager to ensure that the email is legit. He confirms, so you transfer the money.”

    • Este comentario enfatiza que, cuando surge una sospecha sobre una solicitud de transferencia de dinero por correo electrónico, no basta con preguntar simplemente “¿enviaste este correo?”, sino que hay que preguntar algo más específico, como “¿de verdad quieres que transfiera este dinero así?”. Señala que una conversación de ese tipo haría mucho más probable que el ataque fracasara. También indica que, para que el escenario de ataque descrito en el artículo tenga éxito, se necesita una situación muy específica y limitada, y expresa dudas sobre la probabilidad real de que un ataque tan complejo funcione.

  • The other day I was discussing the design for an "update" email that our designer was putting together...

    • Este comentario comparte una experiencia sobre diseño de correos. Señala el problema de que, por culpa del encabezado gráfico creado por el diseñador, había que hacer scroll para poder ver el asunto, y expresa sorpresa por cómo un correo se convierte de versión móvil a versión de escritorio al ser reenviado. Critica que se use CSS en correos electrónicos por considerarlo innecesario y se queja de que aún no se haya adoptado un marcado de texto simple como Markdown.

  • I long argued that we should use markdown (without the inline HTML) or a similar simple text markup...

    • Este comentario sostiene que en el correo electrónico debería usarse Markdown, o un marcado de texto simple parecido, en lugar de HTML. Explica que así sería más fácil para el cliente de correo decidir si mostrarlo como texto enriquecido o como texto plano, y que aun así podría cubrir la mayor parte del formato que la gente necesita. También opina que el HTML avanzado usado en correos de marketing no es importante.

  • The real risk to your organisation is that the developer you assign to generate HTML emails will go mad...

    • Este comentario bromea con que el verdadero riesgo para la organización es que el desarrollador encargado de generar correos HTML termine volviéndose loco por las diferencias de renderizado en Outlook, y añade que los ataques por correo le parecen interesantes.

  • Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags?

    • Este comentario propone si el problema podría resolverse no permitiendo Stylesheets y dejando solo atributos de estilo inline en las etiquetas. Sostiene que la usabilidad podría mejorar si el cliente de correo incluyera un paso para convertir automáticamente las hojas de estilo en estilos inline.

  • HTML in email shouldn't be as big of a nightmare as it is.

    • Este comentario dice que el HTML en correo no debería ser una pesadilla tan grande. Sostiene que el problema podría resolverse fácilmente si todos los clientes de correo distinguieran entre texto y HTML, y en caso de ser HTML cambiaran el motor de renderizado a WebKit. También se pregunta si alguna vez se propuso un estándar para eso.

  • Some possible mitigations from the top of my head (maybe ineffective):

    • Este comentario plantea algunas posibles formas de mitigar ataques por correo. Por ejemplo, advertencias sobre elementos ocultos o pedir confirmación si, al reenviar un mensaje, la apariencia calculada del contenido cambia de manera importante.

  • When efail came out, I wrote a blogpost about the security risks of HTML mail.

    • Este comentario menciona que escribió una entrada de blog sobre los riesgos de seguridad del correo HTML. Señala que la especificación del correo HTML es antigua y casi no contempla aspectos de seguridad, y que un correo HTML seguro debería limitarse a un subconjunto de HTML; sin embargo, como nadie parece haber definido cuál sería ese subconjunto, siguen apareciendo fallas de seguridad sin parar.

  • This is really clever!

    • Este comentario elogia como muy ingenioso el uso de CSS en correos HTML para hacer que cierto texto solo sea visible después de que el mensaje sea reenviado. Señala que esto podría convertirse en una gran amenaza para la confiabilidad de correos verificados. También se pregunta por qué los clientes de correo envuelven el contenido del mensaje con etiquetas HTML adicionales y modifican el CSS y los nombres de clase, y cuestiona por qué no usan un iframe en sandbox para renderizar correos HTML.