Guía práctica sobre abuso de la ambigüedad de RFC en los sistemas de correo

Una dirección de correo electrónico, no es un dato simple. Es una estructura regulada por múltiples estándares, interpretada por múltiples componentes, y, si no se gestiona correctamente, puede convertirse en un punto de ruptura de tu arquitectura de seguridad.

La guía Abuso de la ambigüedad de RFC en los sistemas de correo es un excelente caso de estudio para explicar este fenómeno, que demuestra un principio estructural: cuando dos capas de tu sistema interpretan el mismo dato de forma distinta, tienes una vulnerabilidad.

Vamos a analizarlo paso a paso.

Entendiendo la anatomía real de un email

local-part@domain

Hasta aquí nada nuevo.

Lo que sí suele sorprender es que:

• El local-part está regulado por varias RFC (5321, 5322, 6531).
• El dominio puede incluir IDN (Internationalized Domain Names).
• Existen mecanismos como encoded-word (RFC 2047).
• El dominio puede representarse en Unicode o en Punycode (RFC 3492).

Es decir, lo que parece una cadena sencilla admite múltiples representaciones válidas.

Y aquí empieza el problema.

Caso 1: discrepancias en la parte local

En el primer laboratorio que analiza la guía, se utiliza el mecanismo encoded-word.

Su formato es:

=?charset?encoding?encoded-text?=

Esto permite representar texto usando distintos:

• charsets (UTF-8, UTF-7, ISO-8859-1, etc.)
• encodings (Base64, Q-encoding)

Ahora piensa en el flujo típico de registro:

1. El usuario introduce un email.
2. El frontend valida formato.
3. El backend almacena el valor.
4. Se envía un correo de activación.

La clave está en esto:

• Si el frontend valida sin decodificar,
• pero el sistema de correo sí decodifica,
• y la base de datos compara con otro criterio,

puede ocurrir que lo que se validó no coincida con lo que finalmente se envía.

Eso es una discrepancia de interpretación.

En el laboratorio se demuestra que ciertas combinaciones de:

• UTF-7 + Q-encoding
• Base64 + distintos charsets
• inyección de caracteres ambiguos

permiten registrar una cuenta que aparentemente pertenece a un dominio permitido, pero cuyo correo de activación termina en un buzón controlado por el atacante.

Es una consecuencia directa de no unificar normalización.

Cuando trabajas con identificadores críticos (como el email):

• No puedes validar una representación y operar con otra.
• No puedes almacenar un valor y enviar otro.
• No puedes comparar con una collation y resolver con otra.

Si ocurre cualquiera de esas tres cosas, estás generando una brecha lógica.

caso 2: discrepancias en el dominio y homógrafos unicode

El segundo laboratorio se centra en el dominio.

Aquí entra en juego un concepto que quiero que tengas muy claro: homógrafos Unicode.

Ejemplo:

poc.com
põc.com

Visualmente pueden parecer iguales.

Pero internamente no lo son.

Cuando se usan dominios internacionales, el DNS trabaja con Punycode

põc.com → xn--pc-cka.com

Ahora imagina este flujo:

1. La aplicación recibe un email.
2. Lo compara con la base de datos usando una collation permisiva.
3. Considera equivalentes dos dominios visualmente similares.
4. Genera un token de reseteo.
5. El sistema de correo convierte el dominio a Punycode y entrega el mensaje.

Si el dominio final es distinto del almacenado, el enlace de reseteo puede terminar en un buzón controlado por el atacante.

Eso es un secuestro de cuenta basado exclusivamente en discrepancias de normalización.

La guía demuestra este escenario en un laboratorio reproducible

Ambos casos comparten el mismo patrón estructural:

• Validación lógica
• Normalización
• Comparación en base de datos
• Entrega real

Si estas cuatro fases no utilizan exactamente la misma representación canónica del email, existe riesgo.

Y este riesgo no depende del usuario.

Depende de tu arquitectura.

Implicaciones para dirección de TI

Como responsable tecnológico, debes asegurarte que:

1. Existe una normalización única y centralizada.
2. El valor que validas es el mismo que almacenas.
3. El valor que almacenas es el mismo que envías.
4. Las collations de base de datos no introducen equivalencias inesperadas.
5. No aceptas charsets o formatos que no necesitas.

La superficie innecesaria es deuda técnica.

Y la deuda técnica en identidad es deuda de seguridad.

El correo electrónico es uno de los protocolos más antiguos de internet.
Arrastra décadas de compatibilidad y flexibilidad.

Eso significa más ambigüedad.

La guía demuestra que esas ambigüedades no son teóricas C

Son explotables.

Quiero que te quedes con esta idea:

en seguridad, los problemas graves rara vez aparecen por lo que no conoces.
aparecen por lo que creías que era simple.

Y el email, aunque lo parezca, no lo es.