Mecanismos de protección ante las principales amenazas en el correo electrónico (II)

Según mencionábamos en el anterior artículo de esta serie, actualmente una de las grandes amenazas en el correo electrónico son el phishing y el spoofing (suplantación de identidad), cuya identificación puede llegar a ser especialmente problemática.

Para mitigar este problema existen principalmente tres mecanismos:

• SPF, el convenio de remitentes. Permitirá a una organización definir desde qué servidores o IPs se puede mandar correo en su nombre.
• DKIM, que hace uso de una firma para garantizar la autenticidad del correo.
• DMARC, la combinación de SPF y DKIM, que permitirá realizar valoraciones cruzadas y, en base a sus resultados, determinar qué se hace con un correo (eliminarlo, dejarlo en cuarentena o entregarlo con normalidad).

SPF (Sender Policy Framework)

SPF es una técnica de autenticación de correo electrónico que sirve para validar si un correo recibido fue enviado desde un lugar autorizado y, de esta forma, dificultar que los ciberdelincuentes o spammers puedan enviar emails en nombre de un dominio manipulado.

En el artículo anterior veíamos un ejemplo real de un caso de “fraude del CEO”, en él un ciberdelincuente intenta hacerse pasar por otra persona modificando el campo “From” de la cabecera del correo, para que el receptor vea en su bandeja de entrada que el email viene de alguien conocido o confiable.

Sin embargo, el ciberdelincuente puede necesitar que el empleado responda a su email engañoso y le mande alguna información, por este motivo, el campo “Return-Path” de las cabeceras (que no es visible cuando simplemente leemos un correo) contendrá una dirección email al que el ciberdelincuente sí tiene acceso.

La buena noticia es que SPF puede identificar este correo engañoso desde el primer momento y de forma automática. SPF no consulta la dirección que aparece en el campo “From” de la cabecera del correo, pues es el dato que precisamente suele manipularse para hacer la suplantación de identidad; lo que SPF valida es la dirección que aparece en el campo “Return-Path”.

Veamos ahora un ejemplo genérico donde aplicar SPF:

Supongamos que Bob, trabajador en ACME, recibe un correo electrónico de su jefa, Alice, en su bandeja de entrada. En este email Alice aparece como remitente y su correo aparece perfectamente escrito: alice@acme.com. Bob no tiene motivos para sospechar de la autenticidad del mismo.

• v=spf1 indica la versión a utilizar.
• Con ip4 o ip6 indicamos las IPs (en IPv4 o IPv6, respectivamente) de los servidores autorizados para mandar correo en nombre de nuestra organización.
• Con la etiqueta include añadimos las organizaciones o terceros que pueden mandar emails en nombre de nuestra empresa.
• Finalmente, con -all, ~all o +all podemos indicar al ISP qué debería hacer si hay un correo electrónico que aparentemente vienen de nuestro dominio pero que no ha sido originado en uno de los servidores autorizados:
• -all, se cataloga “fail SPF”.
• ~all, equivaldría a un “soft fail”, es decir, si el correo proviene de un servidor no autorizado se marcaría para ser aceptado con una advertencia.
• +all, no realizaría ningún etiquetado en los correos aunque provengan de servidores no autorizados, es decir, a efectos prácticos sería como deshabilitar el control SPF.

Además de estos, existen otros parámetros adicionales (mx, exists, a) con utilidades muy diversas, de modo que es posible adaptar bastante bien el control a nuestras necesidades.


Ahora, con SPF implantado, cuando Bob recibe un correo que aparentemente es de Alice, se hará una comprobación. La validación SPF cogerá el dominio del Reply-To, que no es acme.com sino umbrellacorp.com y consultará su registro SPF, si es que tiene. En cualquier caso, allí no aparecerá la IP del servidor de ACME, ya que es una dirección privada.

Por tanto, la validación SPF no ha sido superada y el correo podría gestionarse como malicioso.
 

 
Y si Alice manda un correo a Bob, SPF extrae el dominio que aparece en el campo “Return-Path”: acme.com y consulta el registro SPF asociado a dicho dominio. Se comprueba que el email fue enviado desde la IP 1.2.3.4 y que esta IP aparece en el registro SPF de acme.com, así que el mecanismo considerará que se ha superado la validación y que se trata de un correo seguro:

Este ejemplo era relativamente evidente porque tanto remitente como destinatario pertenecían a la misma organización, pero SPF también tiene sus limitaciones: por ejemplo, el hecho de reenviar un correo añade una nueva capa de cabeceras que provoca que SPF falle en su verificación.

Para ayudar a superar estos problemas, lo ideal es combinarlo con DKIM y DMARC.

DKIM (Domain Keys Identified Email)

El estándar DKIM consiste en “firmar” las cabeceras de los correos electrónicos, para garantizar que su origen es auténtico y que el mensaje no ha sido alterado por el camino. Está implementado de tal forma que es compatible incluso con servidores de correo que no lo soportan, de modo que estos no tienen problemas con la recepción. Es decir, es una capa de seguridad adicional y opcional.

DKIM se basa en un sistema de criptografía asimétrica o criptografía de clave pública, que consisten en tener dos claves: una privada, que sólo conoce la parte emisora, y una pública que, como su nombre indica, puede distribuirse públicamente.
 

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Aunque a menudo se cataloga a DMARC como un tercer mecanismo de protección ante phishing y spoofing, se trata en realidad de una unificación o combinación de SPF y DKIM, que da la posibilidad de definir un comportamiento más fino según los resultados obtenidos:

• SPF verifica que cada correo recibido procede de un host autorizado por el administrador del dominio correspondiente.
• DKIM verifica que cada correo recibido no ha sido cambiado de camino al destinatario y que fue originado por el remitente especificado.
• Los sistemas que reciben los correos evalúan los resultados de estas dos verificaciones (pass/fail) y actúan según se haya preestablecido (se entrega el correo, se rechaza, se pone en cuarentena).

Esta política de comportamiento se define en los registros TXT de DNS de la compañía (como SPF) siguiendo la siguiente estructura:

_dmarc.domain  TTL  IN  TXT  "v=DMARC1; p=[none|quarantine|reject]; pct=[0-100]"

donde:

• domain es el dominio a proteger.
• TTL debe equivaler a una hora (dependiendo del registrador de dominio varía la unidad que se toma -segundos, minutos-, pero siempre debe equivaler a una hora).
• p es la política que se usa en caso de no pasar la validación:
• none: el email se entrega
• quarantine: el email se entrega en la carpeta de spam
• reject: el email no se entrega
• pct representa el porcentaje de correo sobre el que queremos aplicar esta directiva. Por ejemplo, si se acaba de implantar DMARC y desconocemos el efecto que puede tener, puede ser interesante empezar a analizar un porcentaje bajo, pct=10, ir evaluando que el comportamiento es el deseado y, si es así, ir aumentándolo progresivamente hasta analizar llegar a pct=100 y analizar el 100%.

Un ejemplo de registro DMARC ya parametrizado sería:

_dmarc.acme.com    3600 IN TXT "v=DMARC1; p=reject; pct=100"

Además de estos que son los fundamentales, existen otros parámetros adicionales, como aquellos que permiten incluir una dirección de correo electrónico donde recibir informes de actividad (rua) o los informes forenses (ruf, disponible sólo en algunas plataformas de correo).

En resumen, con esta configuración, podría empezar a definirse un comportamiento a la hora de gestionar correos que no cumplen todos los controles de seguridad: si un correo pasa todas las validaciones, se entregará al destinatario; si no cumple ninguna, se bloqueará; y se definirá qué hacer si sólo cumple una parte de las validaciones.

Conclusiones

Como hemos visto, el correo electrónico es una puerta de entrada para muy distintos tipos de ataques externos. Para hacer frente, en concreto, a la suplantación de identidad y al phishing, existen mecanismos de protección específicos: SPF para establecer una asociación entre dominios y servidores seguros, DKIM para garantizar que un correo procede realmente del remitente que indica y, finalmente, DMARC para combinar los resultados de estas validaciones y establecer una política de actuación.

Si bien es un sistema que dista mucho de ser perfecto y que en el caso de DKIM puede entrañar un esfuerzo adicional (por la gestión de claves), en el campo de la ciberseguridad es importante desplegar distintas capas de protección que se complementen (lo que se conoce como “defense in depth”). En este sentido, no sólo se recomienda a las organizaciones la activación de estos mecanismos, sino también complementarlos con otras medidas como puedan ser la protección activa de los sistemas a través de actualizaciones de seguridad y búsqueda de vulnerabilidades o la formación y concienciación de los empleados.

Referencias

• Tripwire: “6 Common Phishing Attacks and How to Protect Against Them”
• Kaspersky: “The Human Factor in IT Security: How Employees are Making Businesses Vulnerable from Within”
• Outlook: SPF
• Outlook: DKIM
• Outlook: DMARC