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.
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!
********************************************************************************************************
********************************************************************************************************
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso 3DAIS
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
