El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)

Como hemos visto en la parte anterior de este artículo, ya habíamos solucionado los problemas de usabilidad e interconexión entre los diferentes ecosistemas de usuarios, para que todos ellos pudieran enviar y recibir correos utilizando todo tipo de clientes de escritorio, web, móviles, etcétera a usuarios que se encontraran en cualquier otro destino. Se había conseguido una infraestructura global e interconectada, algo que desde luego no han fomentado las redes sociales en versiones posteriores y de lo que hablaremos un poco más adelante.

Figura 4: El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)a

Con la construcción de esta infraestructura global interoperable y compatible para la comunicación, aparecieron los primeros problemas de seguridad, que tenían que ver más con las comunicaciones sobre Internet, un medio que se definió de forma insegura sin un modelo de amenazas claro desde el principio, lo que nos llevó a aplicar las primeras soluciones de cifrado y firma digital para garantizar la integridad y confiabilidad de la información que sobre el e-mail se envía.

Para el cifrado y la firma digital de los correos electrónicos aplicamos túneles SSL a los protocolos de red, y para el cifrado y la firma digital de los mensajes se puede utilizar a día de hoy S/MIME (certificados digitales para e-mail) o PGP (Pretty Good Privacy), que permiten firmar y cifrar extremo a extremo - sin contar con que los servidores de correo electrónico aplican una capa de seguridad o no -. Los clientes de correo electrónico, por su parte, avisan a los usuarios del nivel de cifrado y privacidad utilizado en cada uno de los mensajes. Pero no es suficiente ni mucho menos para todas las amenazas que fueron apareciendo.

Más soluciones de seguridad para saber de dónde viene un correo:
Reverse MX Lookup, SPF, SenderID, DKIM & DMARC

Con el escenario de envío masivo de mensajes no solicitados a direcciones de correo electrónico comenzamos a poner un montón de soluciones para ir tapando la sangría de problemas que supone para una persona y una organización – no olvidemos que el 90% de los APTs de seguridad han provenido por un correo electrónico en un ataque de spear phihing enviado a una persona de la empresa - que su buzón de correo electrónico esté abierto y disponible para cualquiera que conozca la dirección.

En esta primera remesa de soluciones vamos a intentar centrarnos en el problema de la suplantación del remitente o e-mail Spoofing, que da lugar a los ataques de Phishing y Spear Phishing. Por supuesto, la firma digital S/MIME y PGP son lo ideal, pero como hemos dicho repetidas veces, no es muy popular en el mundo global.

Reverse MX Lookup

Para evitar que suplantaran las direcciones de correo electrónico de nuestra organización, es decir, que nadie pudiera enviar mensajes de correo en nuestro nombre como se hace en los ataques de phishing, comenzamos a indicar cuáles eran los servidores de correo electrónico que pueden enviar mensajes con un remitente de nuestro dominio. La primera solución fue sencilla, pero inútil. Como al principio el servidor de correo entrante - donde están los buzones y se implementan POP3 - era el mismo que por el que salían los correos electrónicos - donde se implementa SMTP - algunos servidores de correo comenzaron a aplicar el filtro de Reverse MX Lookup.

Para saber dónde está el servidor de correo entrante de una organización, en el servidor DNS de esa organización se crea un registro especial llamado MX (Mail eXchanger) que apunta a la dirección IP o hostname del servicio que recibe el correo electrónico de ese dominio. Lo que hacían algunos servicios de correo electrónico entrante es rechazar cualquier correo electrónico que viniera de @otrodominio.com si el servidor que entregaba ese mensaje no tenía la dirección que tenía alguno de los registros MX del dominio otrodominio.com.

Como os podéis imaginar, cuando los servidores de correo saliente se separaron físicamente de los servidores de correo electrónico entrante, este filtro dejó de ser útil, ya que nunca coincidían las direcciones IP de los servidores que entregaban los mensajes con los registros MX. Por eso, hubo que crear otro registro. El registro SPF, donde se da la lista de cuáles son los servidores autorizados desde nuestra organización para entregar correos electrónicos que tengan como remitente uno de nuestros usuarios.

SPF (Sender Policy Framerwork)

Creando los famosos registros SPF (Sender Policy Framework) - también conocido como SPFv1 - se identifican los servidores de correo saliente que usa esa organización y qué debería hacer el servidor de correo entrante de un tercero si recibe un mensaje de este dominio que no viene de esos servidores identificados en SPF. A priori, suena como una medida útil, pero tiene muchos "peros" a la hora de su implementación y uso.

Figura 5: Registro SPF de Gmail.com.

Por desgracia, como las empresas tienen cedidos "alias" de correo de sus dominios a campañas de de marketing que se envían desde servidores externos a la organización o que no son controlados por ellos, la política de seguridad suele ser “Softfail” que se identifica con un "~". Para que os hagáis una idea, cuando usamos SPF lo que hacemos es irnos al DNS de nuestra empresa y decir algo como:

"Estos son los servidores que pueden enviar correo de @miempresa.com o @mibanco.com. Si te llega un correo de alguien que dice que es de @mibanco.com debes aplicar esta política."

La política más férrea debería ser “Hardfail” (-), o lo que es lo mismo, “tíralo y no lo entregues al destinatario, que es falso”, pero por desgracia sucede lo que he comentado antes, y las políticas son “Softfail” o lo que es lo mismo:

 “Míralo bien y ponlo un poco en alerta, pero no estoy seguro de que no sea mío”.

La cosa se complica a la hora de detectar si un registro realmente viene de una organización o no, yo que hay muchas variantes. Muchas personas tienen delegada la gestión de su buzón de correos a terceros, por lo que hay casuísticas en las que una persona manda un mensaje en nombre de otra.

SenderID o SPFv2 (antes conocido como CallerID)

Así, en un e-mail tenemos los campos from, pero también sender y también resent-from y resent-sender. y es ahí donde apareció el estándar SenderID, empujado por Microsoft, y conocido como SPFv2. Su idea es garantizar que el remitente de un correo viene realmente de la organización que tiene el servidor de correo electrónico que lo entrega.

Así que, determinar si un correo electrónico viene o no de una organización realmente es complejo. SenderID intentó centrarse en identificar esa casuística del emisor, pero no consiguió ser un estándar de facto, y su aplicación fue residual en el mundo de Internet, así que encontrar registros SPFv2 con políticas Hardfail fue como localizar un unicornio o un mirlo blanco.

De hecho, al final, se utilizan otras cabeceras como Return-Path y X-Return-Path (las cabeceras X- no son parte del estándar oficial y son introducidas por servidores de correo electrónico para dejar información extra que consideran útil hasta que son estandarizadas... o no.)

DKIM (Domain Keys Identified Mail)

Intentar determinar que un mensaje no es legítimo cuando la situación es tan completo hizo que SPF no fuera el único estándar que salió para evitar la suplantación de los remitentes en los mensajes de correo. Y así nació DKIM, con una aproximación distinta, tratando de decir algo como:

"No sé si este correo electrónico que viene de un servidor que no conozco y un resent-from o resent-sender extraño es un correo electrónico legítimo de esta organización o no, pero este otro que viene firmado por uno de mis servidores de correo saliente sí que es mío y puedes estar más que seguro de que su contenido es legítimo."

Como veis, la idea de DKIM (Domain Key Indentified Mail) es que cada correo electrónico que ha salido de un servidor autorizado de la organización, va firmado por una clave privada que tiene configurado el servidor de correo saliente y cuyo par de clave pública está accesible para todo el mundo en el servidor DNS de la organización y se puede consultar.

Figura 6: Clave DKIM usada por un servidor de yahoo.com

Es decir, recibo un correo de paco@yahoo.com y en el texto del mensaje aparece una cabecera DKIM con un HASH, que se supone que ha generado el servidor de correo saliente de Yahoo.com que ha entregado el correo. Así que se mira qué servidor ha entregado el correo, nos vamos al servidor DNS de Yahoo.com, pedimos la clave pública DKIM de ese servidor y comprobamos que el hash que nos han entregado es correcto.

Figura 7: Correo de Ebay firmado correctamente por DKIM

Como veis, la aproximación es diferente, mientras que con Reverse MX Lookup, SPF o SenderID se trata de eliminar lo que no venga entregado desde el dominio correcto, con DKIM se trata de indicar que, si el correo ha llegado desde la IP correcta, el usuario lo sepa con un icono especial, tal y como podéis ver en esta captura con correos de Ebay tiempo atrás. Pero como la mayoría no lo usa, pues otro intento fallido para diferenciar los correos legítimos de los no legítimos.

Como veis, el uso de Reverse MX Lookup, SPF, SenderID y DKIM hace que haya mucha información en el cuerpo de un mensaje para analizar un correo electrónico. Esta información no es concluyente ninguna por sí misma, ya que los casos son muchísimos, y es lo que hizo que los clientes de correo electrónico no se atrevieran a marcar definitivamente un mensaje como malo o como bueno.

El Proyecto "Apolo"

Para poder dar más información al usuario, nosotros creamos en Informática 64, un plugin para el navegador que se leía el cuerpo de los mensajes en el cliente web de Gmail y Hotmail, buscaba la información SPF, DKIM, SenderID, las direcciones IP en los registros MX y hacía las comprobaciones desde el propio navegador, y luego mostraba información de ayuda al usuario sobre los mensajes de correo electrónico que estaban en su bandeja de entrada. Fue un proyecto de investigación más que una verdadera herramienta, pero lo llamamos el Proyecto Apolo.

Figura 8: Información del proyecto Apolo

Si el registro SPF era correcto en el mensaje, mostramos un icono verde. Si no cumple DKIM, ni Sender ID, ni SPF, ni MX Reverse Lookup, lo poníamos en alerta roja. Una prueba para dar más información a los usuarios avanzados.

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

Al final, lo que nosotros hicimos en el Proyecto Apolo tenía todo el sentido. Había que hacer algo que mezclara todo, y así, tiempo después, nació DMARC. El funcionamiento de este protocolo es el que se ve en la figura siguiente. En él se puede ver en la fila del medio del gráfico que, cuando llega el mensaje al destinatario, el servidor valida la información DKIM, valida la información SPF y después, con estas dos comprobaciones previas, valida la información DMARC para aplicar una de las políticas que se pueden ver en la fila inferior.

Figura 9: Flujo de funcionamiento de DMARC

Por último, si un mensaje de correo electrónico cumple todas las validaciones correctamente, es decir, viene firmado por DKIM correctamente con una clave de firma que está en el DNS de la organización y pasa la comprobación SPF al ser enviado desde una de las direcciones IP marcadas en el registro SPF como una de las autorizadas, entonces el proveedor podrá tener las máximas garantías de legitimidad del mensaje posibles - que aún así siempre inferiores a que el mensaje venga firmado digitalmente con una clave de remitente -, para lo que vamos a necesitar alguna tecnología extra.

PCL (Phishing Confidence Level)

Al final, ni con DMARC se garantiza que un mensaje no sea malicioso. Existen casos concretos en los que es posible pasar DMARC o no hay información suficiente para tomar una decisión firme. En algunos mensajes habrá información de Return-Path o X-Return-Path útil. En otros habrá información de direcciones IP que podremos consultar en bases de datos de salud que nos dirán si son de hosters que nunca hacen ataques o de otros con "mala reputación". Además, si miramos el cuerpo del mensaje podremos ver si tienen textos utilizados normalmente en ataques de phishing o no, etcétera.

Figura 10: Configuración de umbrales PCL en Microsoft Outlook

Es decir, que si independientemente de los estándares que intentan garantizar que un mensaje viene o no viene de un determinado dominio, podemos aplicar técnicas avanzada de Machine Learning a los mensajes que utilicen toda la información en el mensaje disposnible, y todo el conocimiento histórico que tengamos de nuestro correo electrónico para generar un índice, que llamamos PCL (Phishing Confidence Level) y que generar mi servidor de correo para clasificar el mensaje en función del número que salga.

Así, creamos unos umbrales para decidir qué mensajes entran en la carpeta de entrada, cuáles entran en ella pero con funcionalidad limitada - carga de imágenes, alertas mostradas y deshabilitación de funciones -, cuáles van a la carpeta de Spam y cuáles no se entregan al buzón.

Es un trabajo avanzado e ímprobo, y muchas veces tiene errores, pero es la solución que aglutina todos los intentos anteriores existentes para sacar el máximo de la información disponible. Además, para poder tener la información actualizada y el PCL vaya ajustándose, es necesario contar con la colaboración de los usuarios, que deberán ir reportando aquellos mensajes sospechosos. Pero esto es solo para los ataques de Phishing.

Y aún así no son suficientes y se intentan cosas nuevas.

Aún nos queda el SPAM por donde vienen la mayoría de los problemas de malware, robo de tiempo de las personas para convertir el e-mail en improductivo y molesto para las personas. Y mucho peor, los problemas de identidad asociados a las direcciones de correo electrónico, así que nos queda mucho por hablar todavía de la muerte y resurrección del e-mail.

Como os podéis imaginar, a pesar de todas estas tecnologías, el correo electrónico sigue siendo un caos. Al final un mensaje puede entrar en el buzón de entrada de un destinatario o no dependiendo de la configuración de estas tecnologías en su servidor de correo, lo que permite que un mensaje de Spam o un Phishing puedan entrar o no dependiendo de la configuración que tengas.

Nos quedan muchas cosas, y lo iremos viendo en las partes siguientes de este artículo. Espero que estéis disfrutando la lectura tanto como yo la escritura.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

********************************************************************************************************
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 1 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 3 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 4 de 4)
********************************************************************************************************