Seguridad en correo electrónico. Lucha contra phishing y spam

Hoy en día es pues, una cuestión de gran importancia detectar correos electrónicos falsificados y/o fraudulentos y evitar, en la medida de lo posible, que estas amenazas logren entrar en nuestra bandeja de entrada. En este artículo se describen las soluciones de validación de correo más utilizadas en la actualidad, entre ellas, SPF, SenderID, DomainKeys, DKIM y la más reciente y emergente, DMARC. Estos métodos están orientados a aportar seguridad a las transacciones de correo electrónico pero desde diferentes puntos de vista. En general, se apoyan en registros DNS y en firmas electrónicas que proporcionarán la información necesaria para realizar verificaciones.

SENDER POLICY FRAMEWORK (SPF)

SPF consiste en proporcionar un registro de nombre de dominio (DNS) que identifica los servidores de correo que pueden enviar mensajes en nombre de ese dominio. Este registro DNS aporta información al cliente de correo para que pueda comprobar si el servidor de correo que le ha hecho llegar el mensaje está autorizado para el dominio en cuestión. Un registro SPF se compone de unos mecanismos para especificar qué hosts están autorizados como emisores de correo para el dominio. Estos mecanismos se complementan con unos prefijos (calificadores) que proporcionan el criterio a aplicar en caso de no cumplirse la condición sobre el mecanismo. Los mecanismos posibles son:

all | ip4 | ip6 | a | mx | ptr | exists | include

que se complementan con los calificadores:

"+" Pass: Los hosts especificados en el registro están permitidos (aceptado)

"-" Fail: Los hosts especificados en el registro se deniegan (denegado)

"~" SoftFail: Los hosts no están autorizados pero no hay criterios suficientes para rechazar el correo. Usualmente el cliente de correo indica al usuario alguna alerta de posible suplantación pero se acepta. (aceptado)

"?" Neutral: No se puede determinar la autorización (aceptado)

None: No hay un registro SPF para el dominio especificado (aceptado)

Los mecanismos del registro SPF se evalúan en orden, así por ejemplo:

"v=spf1 +mx +a:spf.example.es +ip4:213.143.52.0/24 -all"

Indicaría que los registros MX (+mx), los registros A con nombre de dominio especificado (+a: ) y el rango de IPv4 que se indica (+ip4: )estarían permitidos como emisores, denegando (-all) todo lo demás. La sintaxis y especificación detallada puede consultarse en :

http://www.openspf.org/SPF_Record_Syntax (Enlace no disponible actualmente)

Dependiendo del resultado de la verificación (pass, fail, softfail, neutral, none) el correo electrónico será clasificado y se tomará la medida definida para el caso. Por ejemplo un correo cuyo resultado de verificación es "softfail" se acepta, pero se muestra un mensaje advirtiendo la posibilidad de que pueda ser una suplantación:

Ilustración 1. Alerta mostrada en un correo con SPF=softfail

Ilustración 2. Verificación SPF. Softfail

Ilustración 3. Cabecera de un correo electrónico. Verificación correcta SPF del dominio icloud.com

Ilustración 4. Registro SPF del dominio icloud.com

SENDERID.

SenderID, fue desarrollado por Microsoft y es similar a SPF pero extiende el alcance de los identificadores del correo. Así, SPF se basa en la verificación de la identidad reflejada cabecera "Mail From:", mientras que SenderID verifica otras, aplicando heurística para extraer el dominio real a partir de las cabeceras Resent-Sender:, Resent-From:, Sender:, y From. Su uso no está tan extendido como SPF.

DOMAIN KEYS IDENTIFIED MAIL (DKIM)

DKIM viene a completar un borrador inicial desarrollado por Yahoo! denominado DomainKeys, y da un paso más en el objetivo de validar la autenticidad de un correo electrónico.

DKIM se apoya en el uso de criptografía de clave pública y aporta una firma digital en la cabecera de los mensajes de correo enviados desde su dominio. Mediante la verificación de la firma con la clave pública, el cliente puede comprobar que el mensaje realmente procede de ese dominio y que no ha sufrido modificaciones durante la transmisión. En la firma, bajo etiqueta "h=" se indican qué campos de la cabecera del mensaje han sido firmados. Los resultados de la verificación de la firma se clasifican según lo reflejado en el estándar RFC 7001 Message Header Field for Indicating Message Authentication Status, que en caso de DKIM son: none, pass, fail, policy, temperror y permerror. En función de la verificación, el receptor decide como tratar el correo.

En la siguiente imagen se observa un fragmento de la cabecera de un correo electrónico, firmado con DKIM y enviado desde una cuenta de gmail con un resultado "pass":

Ilustración 5. Cabecera del correo electrónico recibido. Firma DKIM

Clave pública DKIM y comprobación de la firma.

En destino se comprueba la firma, recuperando la clave pública del dominio que se almacena en un registro TXT con el formato especificado en el estándar: s._domainkey.d , donde s es la etiqueta que identifica la firma, y d es la etiqueta que identifica el dominio que viene reflejado en la cabecera. De este modo, para obtener la clave pública del ejemplo se consultará al servidor DNS para obtener el registro 20120113._domainkey.gmail.com:

Ilustración 6. Clave pública DKIM en registro DNS

Dificultades en la validación con SPF y DKIM

El empleo de esto métodos no asegura en todos los casos una identificación de un correo fraudulento por una serie de motivos y complicaciones como:

• Complejidad de los entornos de algunos emisores. Grandes compañías utilizan frecuentemente complejos sistemas con multitud de servidores para el envío de correo, incluyendo terceras partes. La variabilidad de estos entornos dificulta la tarea de asegurar el tratamiento de los mensajes.
• Flexibilidad de políticas. Cuando un dominio envía correos tanto si están firmados como si no lo están, el receptor debe discernir si el mensaje entrante es legítimo, y contemplar cierta flexibilidad cuando un correo no puede ser autenticado. Para ello puede apoyarse en filtros anti-spam y otras tecnologías, pero no se garantiza que todo correo no autenticado pueda ser fraudulento.
• Falta de feedback. Los emisores de correo por lo general no disponen de sistemas de retroalimentación que les permitan averiguar las causas por las que un receptor no ha conseguido verificar un mensaje de correo. Ello dificulta el proceso de resolución de problemas, sobre todo en entornos de alta complejidad.

Hemos visto como el empleo de las soluciones SPF y DKIM proporcionan facilidades para detectar correos fraudulentos que proceden de emisores no autorizados o que han sido manipulados. No obstante, no siempre es posible verificar la validez del emisor y en esos casos no existe una retroalimentación al emisor que le permita conocer las causas del problema y tomar las medidas correctoras oportunas. En un próximo artículo describiremos la solución DMARC, que intenta poner solución a las dificultades que encontramos con SPF y DKIM.