Cartas Kobold: los riesgos del correo electrónico HTML
(lutrasecurity.com)- Kobold letters es una técnica de ataque que hace que un correo HTML que al principio parece inofensivo cambie, después de ser reenviado, a contenido de phishing para otro destinatario
- La clave está en aprovechar el CSS permitido por los clientes de correo y la posición del DOM que cambia durante el reenvío para ocultar o volver a mostrar frases específicas
- Thunderbird y Outlook on the web pueden mostrar frases ocultas después del reenvío debido a su estructura DOM y a la forma en que reescriben el CSS; Gmail permite una exposición más simple al eliminar estilos al reenviar
- El problema fue reportado a Mozilla, Microsoft y Google el 5 de marzo de 2024; Microsoft lo cerró el 26 de marzo sin tomar medidas inmediatas, y Google confirmó el 9 de abril que estaba trabajando en una corrección
- Los usuarios pueden desactivar el correo HTML o verlo en modo restringido, pero bloquear `` puede romper muchos casos de uso del ecosistema actual de correo, por lo que la mitigación a nivel de cliente no es sencilla
Escenario de ataque e idea principal
- Un correo reenviado por un administrador puede parecer al principio un mensaje de consulta inofensivo, pero después de ser reenviado puede convertirse en una solicitud de phishing para el nuevo destinatario
- El destinatario conoce al remitente y, en algunos casos, el mensaje incluso puede incluir una firma criptográfica; aun si confirma por teléfono que el correo fue reenviado, puede caer en el engaño
- Como el administrador, que es el destinatario original, no vio ninguna frase de phishing en el correo que reenvió, le resulta difícil detectar el ataque incluso si confirma que hizo el reenvío
Cómo funcionan las Kobold letters
- La mayoría de los clientes de correo permiten estilos CSS en correos HTML
- Cuando se reenvía un correo, la posición DOM del correo original suele cambiar, y el atacante aplica selectores CSS tomando ese cambio como referencia
- El atacante puede insertar en el correo elementos que aparecen o desaparecen según el contexto
- Normalmente se ocultan con
display: none; - Si la estructura DOM cambia después del reenvío, se muestran con reglas como
display: block !important;
- Normalmente se ocultan con
- Estos elementos normalmente no se ven y aparecen solo en situaciones específicas; como pueden abusarse para phishing y otros fines, se llaman kobold letters
- En general, pueden verse afectados los clientes de correo y webmail que soportan correo HTML
Funcionamiento en Thunderbird
- El problema relacionado con Thunderbird fue reportado a Mozilla el 5 de marzo de 2024, y el 20 de marzo de 2024 se enviaron la fecha prevista de divulgación pública y un borrador
- Se discutieron posibles mitigaciones, pero la implementación quedará para más adelante
- Thunderbird envuelve el correo con `
` y casi no realiza otros cambios
- Al reenviar un correo, el correo original citado vuelve a quedar dentro de `
` y se desplaza un nivel hacia abajo en el DOM
- El CSS de ejemplo oculta
.kobold-letterde forma predeterminada y solo lo muestra bajo la condición.moz-text-html>div>.kobold-letter - Quien ve el correo original solo ve los párrafos que siempre son visibles, pero quien recibe el correo reenviado ve aparecer de repente el párrafo que estaba oculto
- Como el atacante conoce la posición relativa dentro del DOM y puede controlar el CSS, puede ocultar o mostrar partes del correo para cambiar todo el contenido
- Si se le da estilo a la kobold letter como una superposición, incluso puede reemplazar los comentarios que el remitente añadió al correo original, aumentando las oportunidades de phishing
Funcionamiento en Outlook on the web
- El problema de Outlook on the web fue reportado a Microsoft el 5 de marzo de 2024, y el 20 de marzo de 2024 se enviaron la fecha prevista de divulgación pública y un borrador
- Microsoft decidió el 26 de marzo de 2024 no tomar medidas inmediatas y cerró el reporte
- Como OWA es webmail, la situación es más compleja; el correo se coloca en un contenedor como `
`, pero los nombres exactos de las clases cambian
- Outlook antepone
x_a los id y class, y ajusta también el CSS, para que el CSS del correo no afecte los estilos de la interfaz del webmail - En el ejemplo, el CSS del correo original se transforma así al mostrarse en OWA
.rps_78fa .x_kobold-letter {display:none}.rps_78fa > div > div > .x_kobold-letter {display:block!important}
- Después del reenvío, la clase vuelve a cambiar, por ejemplo a
x_x_kobold-letter, y el CSS también se actualiza de nuevo - En la segunda regla desaparece el
>entre.rps_78faydiv, por lo que hay que tenerlo en cuenta al crear selectores complejos - Los ajustes de OWA no bloquean el ataque en sí, pero se vuelven una restricción incómoda al crear una kobold letter que funcione simultáneamente en varios clientes
Funcionamiento en Gmail
- El problema de Gmail fue reportado a Google el 5 de marzo de 2024, y el 20 de marzo de 2024 se enviaron la fecha prevista de divulgación pública y un borrador
- Google confirmó el 9 de abril de 2024 que estaba trabajando en una corrección
- Como Gmail elimina todos los estilos al reenviar un correo, técnicamente no es vulnerable a las kobold letters en su definición estricta, donde los selectores CSS cambian la visibilidad según el contexto
- Pero sí es posible un ataque más simple
- Ocultar la kobold letter con CSS en el correo original
- Al reenviarlo, los estilos se eliminan y el elemento oculto se muestra automáticamente
- Este método es limitado y no permite la operación inversa: que algo se vea en el original y desaparezca después del reenvío
- Como Gmail todavía no elimina el CSS en el editor antes de enviar el correo, el párrafo oculto tampoco se ve mientras quien reenvía escribe sus comentarios
- En el correo resultante, los estilos se eliminan y aparece el segundo párrafo
- Si Gmail eliminara el CSS en la etapa del editor, quien reenvía podría detectar el ataque antes de enviar, lo que mitigaría el problema
Casos similares anteriores y diferencias
- No es nuevo que el contenido de una respuesta o reenvío pueda cambiarse con CSS en correos HTML
- En el pasado se reportaron problemas similares
- La diferencia de las Kobold letters es que se enfocan en un escenario de ataque específico y analizan varios clientes de correo en conjunto
- Es necesario discutir los riesgos del correo HTML y los trade-offs para mitigarlos
Mitigaciones y límites
- Los usuarios pueden desactivar por completo el correo HTML o verlo en un modo restringido como “plain HTML” de Thunderbird
- Si los clientes de correo impidieran el uso de ``, el problema podría resolverse, pero eso podría romper muchos casos de uso existentes del ecosistema de correo
- Una implementación como la de Gmail, que elimina estilos al reenviar, puede ser un punto intermedio para limitar los riesgos del correo HTML sin dejar de permitir newsletters corporativos con estilo
- No es realista esperar que los clientes de correo implementen mitigaciones fuertes en el futuro cercano
- Los usuarios deben ser conscientes de los riesgos del correo HTML y tomar por su cuenta las precauciones necesarias
1 comentarios
Comentarios de Hacker News
La parte de “aun así no está seguro, así que llama a su gerente para confirmar si el correo es real. El gerente dice que sí, entonces transfiere el dinero” se siente como una suposición demasiado grande
Normalmente, en vez de preguntar algo vago como “¿usted envió este correo?”, uno preguntaría de forma más específica “¿de verdad me está diciendo que transfiera dinero de esta manera?”, y entonces el gerente naturalmente se alarmaría y es muy probable que el ataque se frene en esa conversación
Es una vía de ataque interesante, pero tengo dudas sobre qué tan probable sea que realmente funcione. El artículo plantea que, para que este ataque salga, tiene que darse una secuencia de eventos bastante específica y estrecha, y en lo personal no me termina de convencer
Sé que el phishing sí funciona en la práctica. Pero la gente que cae en phishing normalmente ni siquiera requiere un ataque tan elaborado, y de hecho, si el atacante invierte tanto esfuerzo en algo tan específico, hasta podría reducir sus probabilidades de éxito. Con un correo de phishing común probablemente ya tendría buenas posibilidades de lograrlo
La información de esos ejecutivos se podía encontrar fácilmente en LinkedIn o en el sitio de la empresa, y aun así pasaba, incluso cuando ese caso era exactamente el ejemplo que se usaba en la capacitación contra phishing, así que no debería sorprender
https://www.microsoft.com/en-us/research/publication/why-do-...
El atacante podría poner algo como “Estoy de viaje en este momento. Si no está seguro, llame a mi celular personal...” y luego responder con una voz falsa
Una buena forma de llegar al objetivo podría ser el “reenvío doble”. El remitente finge ser un empleado que reenvía el correo del gerente a alguien cercano al personal administrativo, y si esa persona lo vuelve a reenviar por algo aparentemente inocuo como felicitaciones de cumpleaños o aviso de licencia por enfermedad, al objetivo real le resulta difícil identificar el origen original del correo
Además, es fácil imaginar otras formas más creativas de abusar de esta “función”. Por ejemplo, hacer que alguien que no sabe nada reenvíe contenido problemático y luego extorsionarlo
Los encargados no van a llamar a su gerente de línea cada vez que llega una solicitud de pago por correo, especialmente si la cantidad es pequeña y no requiere aprobación previa
Recuerdo que Google también cayó en una estafa en la que terminó pagando a alguien por trabajo que nunca se hizo. En ese caso había facturas falsas, pero el principio es el mismo
Hace unos días estaba viendo el diseño de un correo de “actualización” hecho por un diseñador, y por culpa de un encabezado gráfico absurdamente grande puesto arriba de todo, si no hacías scroll ni siquiera podías ver el texto principal del mensaje
Luego reenvié otra versión para pedir comentarios, y de repente se sorprendió diciendo que la fuente parecía un poco más pequeña, y después dijo “Ah, al reenviarlo se convierte en la versión de escritorio en vez de la versión móvil”
Me quedé mirándolo sin poder creerlo. Esto es un correo electrónico; ¿qué significa “versión de escritorio” y “versión móvil” aquí? ¿Cómo se supone que eso tiene sentido? ¿Qué significa que se “convierte”? Si solo se está copiando. El simple hecho de que se “rompa” al reenviarlo ya demuestra lo absurda que es esta forma de hacer las cosas. ¿Por qué demonios mi correo tendría que llevar CSS?
Si lo que querían era expresar cosas como cursivas, debieron haber adoptado hace tiempo una forma mucho más simple, como Markdown, y es absurdo que todavía no lo hayan hecho. Eso muestra el poco interés real que hay por mejorar esta situación. Todo existe solo para satisfacer requisitos corporativos extraños de poner logos y banners por todas partes. El correo HTML es realmente ridículo
[1] https://www.rfc-editor.org/rfc/rfc1896.txt
Llevo mucho tiempo defendiendo que, para el texto con formato en correo, debería usarse algo como Markdown sin HTML en línea, o algún marcado de texto simple parecido, en lugar de HTML
Así el cliente de correo podría decidir fácilmente si mostrarlo como texto con formato o simplemente como texto plano, y además permitiría cubrir la mayoría del formato que necesita un usuario común: negritas, cursivas, citas, imágenes en línea, bloques de código, encabezados, etc.
Quizá no serviría para correos de marketing que usan HTML muy avanzado, pero no creo que haya que preocuparse por ese caso de uso
https://en.wikipedia.org/wiki/Enriched_text
https://www.rfc-editor.org/rfc/rfc1896.html
De hecho, ni siquiera sigue habiendo soporte para poner hipervínculos en el correo, y recientemente alguien trató de arreglar eso
https://pastebin.com/kHQs50xm
El verdadero riesgo para una organización es que el desarrollador al que le asignaron generar correos HTML se vuelva loco, se encierre en la sala de servidores y, gritando «¿por qué Outlook renderiza distinto?», destruya todo el hardware.
Hablando en serio, claro, esta es una vulnerabilidad muy interesante.
¿No se podría arreglar si no se permiten hojas de estilo y solo se permite el atributo
styleinline en las etiquetas?Por usabilidad, el cliente de correo incluso podría incluir un paso automático que “compile” todas las hojas de estilo en estilos inline.
Así solo se romperían selectores CSS avanzados, como
hover, pero no estoy seguro de que esas cosas sean realmente necesarias.Las pseudoclases y las media queries no funcionarían, pero podrían ser un riesgo de seguridad y además no están soportadas por los principales clientes de correo: https://www.caniemail.com/features/css-at-media/
Además, si matas todos los atributos
style, también matas la optimización móvil y el modo oscuro, porque las media queries no se pueden inlinear.Normalmente los estilos base/de escritorio ya vienen compilados e inlineados, y para que se lea bien en dispositivos móviles se ponen selectores con media queries en la etiqueta
styledentro dehead.Muy ingenioso.
La premisa es que, por el CSS de los correos HTML, puede haber texto que solo se vea después de que el mensaje haya sido reenviado. Eso es una gran amenaza para la confiabilidad de los emails verificados.
Se presentan ejemplos de Thunderbird, Outlook y Gmail, y es un excelente trabajo.
Yo leo todos mis correos en mutt, así que oficialmente es “problema de otros”.
Así que, para quejarme de otra cosa, la fecha del reporte a Mozilla aparece como 05.03.2024. Estoy de acuerdo en que la fecha little-endian tiene más sentido que la fecha middle-endian al estilo estadounidense.
Pero si eres técnico, me parece mal no usar el formato de fecha ISO 8601, 2024-03-05, con o sin guiones :)
Little-endian al menos tiene la ventaja de ser lo opuesto a cómo se escriben todos los demás números, pero middle-endian es simplemente una locura. Claro, por eso mismo es el formato que usan los estadounidenses.
Se nota que algunos de los clientes de correo mencionados envuelven el contenido del mensaje con etiquetas HTML adicionales y cambian el CSS y los nombres de clase.
Me pregunto por qué los clientes de correo no usan un iframe sandboxeado al renderizar correos HTML. ¿Sigue habiendo riesgos de seguridad aun así?
Es un comportamiento esperable, porque quien reenvía podría querer añadir más texto al correo.
El asunto era que, si el correo tenía un enlace a un sitio web y el iframe sandboxeado no permitía JavaScript, ese contexto de seguridad se extendía hasta la página que se abría al hacer clic en el enlace dentro del iframe, y el sitio web no podía usar JS.
La solución fue
allow-popups-to-escape-sandbox, así que ahora no parece haber motivo para que no funcione.Esta es la típica solución de amputar brazos y piernas para curar una herida. El problema es la mala estandarización del correo electrónico que ha permitido que este tipo de hacks dominen.
Todo HTML en general es vulnerable a este tipo de preocupaciones. Aun así, hay muchos correos que usan HTML sin problemas. Este texto se lee como una frustración personal con algo que encontró en la naturaleza, disfrazada de problema de seguridad.
Se me ocurren posibles mitigaciones, aunque quizá no sirvan: advertir de forma visible sobre los elementos ocultos, aleatorizar la cantidad de
divenvolventes tanto al recibir como al enviar, y al reenviar calcular cómo se verá realmente y pedir confirmación si hay una diferencia grande.O quizá sea más efectivo abordarlo al revés, porque así no requiere ayuda de otros clientes.
Se puede corregir a «por qué el correo electrónico es un riesgo para las organizaciones».
Este artículo presenta un vector de ataque específico de los correos HTML, pero la mayoría de los ataques por correo podrían trasladarse fácilmente a WhatsApp, Slack, Jira, Zoom o cualquier herramienta que la gente use para comunicarse con el exterior.