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

En la primera parte de esta serie me detuve en explicar someramente cómo el correo electrónico fue creciendo desde ser un servicio para copiar ficheros de texto en sistemas de tiempo compartido a ser el elemento de comunicación por excelencia. Ese crecimiento acompañó problemas de seguridad asociados a la privacidad y la integridad de los mensajes. Había que asegurarse de que el tráfico sobre el que se envía el mensaje está cifrado y garantizar la autenticidad del remitente, y como hemos visto, no es trivial.

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

Aunque el uso de certificados digitales para firmar y cifrar los mensajes y una política de seguridad que ignorara el resto de los mensajes solucionaría el problema, lo cierto es que tanto PGP como S/MIME tienen un uso residual, así que el cifrado se ha dejado en manos de los protocolos de intercambio de mensajes que se producen entre el cliente y el servidor de correo saliente, y entre los servidores de e-mail en cada salto que dan los mensajes.

Hemos hecho despliegues de protocolos con capas SSL/TLS para las conexiones, y hemos encapsulado el tráfico de e-mail en protocolos como HTTPS o RPC/HTTPs para subsanar el hecho de que el usuario no utiliza los certificados digitales. Y no los utiliza por un problema de usabilidad.

Pero si para arreglar el problema de cifrado hemos tenido que solventar el problema a tramos, mitigar el impacto de no utilizar firma digital para garantizar el origen del remitente ha sido un proceso mucho más tedioso. Como hemos visto en la parte anterior hemos utilizado filtros como Reverse MX Lookup, como Sender Policy Framewok, como SenderID, Domain Key Indetified Mail y Domain-Based Message Authentication, Reporting & Conformance, además de generar índices de confianza en si el mensaje es un ataque de phishing o no, como es el Phishing Confidence Level (PCL).

Correos no deseados: SPAM y Correos no solicitados

Pero, también tenemos que lidiar con otro gran problema más, el famoso SPAM, que no hay que confundir con el “Correo no solicitado”. Ambos pueden ser considerados “Correos no deseados” según las circunstancias, pero tienen una sutil diferencia.

Mientras que el primero, el SPAM, es un correo masivo que puede utilizarse para múltiples objetivos como puede ser la publicidad, la distribución de malware, los ataques masivos de phishing, o las famosas estafas (scams), el segundo, los correos no solicitados, pueden ser mensajes de correo electrónicos enviados individualizados y enviados solo a un destinatario que, aún así, sean correos no deseados.

Figura 12: Un SPAM phishing alertándote de los ataques de phsihing

Para evitar este tipo de mensajes también hemos tenido que ir desarrollando diferentes tecnologías, herramientas de configuración e incluso algunas regulaciones para controlar la ambición publicitaria de las organizaciones.

En algunos países hemos obligado a las empresas a que marquen sus correos publicitarios con textos que puedan ser detectados fácilmente y ayuden a su filtrado, y hemos desarrollado legislaciones que prohíben a las compañías enviar mensajes de e-mail si no disponen de un consentimiento explícito de los usuarios para hacerlo. Legislaciones como LSSI, LOPD, LOPDv2 o el último GDPR tienen en cuenta este tipo de actividades, directa o indirectamente.

Esto ha funcionado con las empresas legítimas con vocación de operar dentro del marco regulatorio legal y que se ven afectadas por esas normas, pero no ha reducido para nada el tráfico generado por el cibercrimen y sus campañas de distribución de malware, ransomware, troyanos bancarios, intentos de phishing, o grupos dedicados a estafas y fraudes en Internet con sus mensajes de “scams”, etc… Ni, por supuesto, para controlar la agresividad de las compañías no afectadas por esas legislaciones que tienen listas de distribución o mecanismos de anuncios basados en SPAM.

DNSBL (Domain Name System-Based BlackHole List) o RBL (Real-Time BlackHole List)

Para ello primero utilizamos las listas de reputación de servidores de correo electrónico, para marcar las direcciones IP utilizadas por los spammers de manera clara. Esto llevó crear las DNSBL o RBL  que son listas de direcciones IP donde se introducen aquellos servidores que hacen o han hecho campañas de SPAM y que se mantiene por la comunidad de administradores de servidores de correo electrónico u organizaciones dedicadas a esto exclusivamente. Esto hace que haya personas manteniendo esas listas, a veces manualmente, y que se generen un montón de conflictos.

Puede ser que una RBL introduzca tu servidor de correo saliente por error, o porque alguien quiere hacer un ataque de Denegación de Servicio (DoS) a tu organización, y los mensajes que envían tus buzones jamás llegarán al destino. O unos sí y otros no, dependiendo de si el servidor de correo del destinatario consulta esa RBL o no.

Salir de esas listas puede ser un infierno, ya que hay que demostrar que no estas enviando SPAM. Además puede ser que tu servidor sí lo haya hecho porque uno de tus usuarios ha decidido hacer una campaña publicitaria por e-mail o ha sido infectado por un malware que se ha puesto a enviar mensajes masivamente para infectar a otras víctimas.

Una vez que ese servidor consigue salir de la RBL que le dio de alta, hay que espera que se propague correctamente, y puede ser, como es habitual, que otras listas hayan copiado los registros de esta RBL y aún el servidor aparezca listado en muchas otras, con lo que se van a seguir perdiendo mensajes de correo electrónico de forma aleatoria.

Black Lists/While Lists

Si has tenido problemas con RBLs, probablemente entenderás porque muchas personas acaban por dejar de utilizarlas y pasan a configurarse ellos manualmente sus propias listas blancas y listas negras. No solo para direcciones de servidores de correo que entregan mensajes, sino también para dominios de e-mail o direcciones alias concretas de listas de distribución que no tienen un sistema de “unsuscribe” que de verdad funcione.

En estos casos, el trabajo del administrador es alto, pero también se traslada a los usuarios, por lo que los clientes de correo electrónico tienen herramientas de reporte de mensajes como SPAM o para configurar bloqueos de remitentes por dominio o por dirección de alias.

SCL (Spam Confidence Level)

De nuevo, toda la información de la reputación de la dirección IP de los servidores, toda la información asociada al dominio, los datos reportados por los usuarios en el historial de los mensajes y modelos estadísticos basados en Filltros Bayesianos además de modernas técnicas de Machine Learning, se utilizan para generar un índice de confianza sobre si un mensaje es SPAM o no lo es. Este número se conoce como SCL (Spam Confidence Level) y se usa para establecer parámetros similares a los de PCL.

Es decir, en función del SCL se decide si el mensaje entra en la bandeja de entrada, si entra en la bandeja de entrada con alertas y funciones deshabilitadas, si va a la bandeja de “Correo No deseado” o si directamente no se entrega al usuario.

Figura: 13: Configuración de Exchange y acciones en función de SCL

Pocos son los servidores que eliminan grandes cantidades de mensajes, y esto lleva a que entren muchos en la bandeja de “Correo No deseado”, lo que hace que muchos usuarios pierdan tiempo semanalmente rebuscando en la basura a ver si algo se ha escapado.

Buzones de reporte / Buzones Sonda

Por supuesto, poder detectar las campañas de SPAM (Publicidad, Phishing, Malware, etc...) es importante para alimentar la detección temprana de campañas y poder enriquecer los algoritmos con las últimas técnicas utilizadas por los spammers.

Para eso, se utilizan buzones de decepción, es decir, buzones especialmente creados para estar en las listas de todas las direcciones machacadas por spammers que todo el tráfico que reciben es reportado automáticamente como SPAM - como si lo hubiera hecho manualmente un usuario - y enriquecer el conocimiento para establecer RBLs y SCLs al minuto.

Gamificación

Otra de las opciones en la que estamos trabajando nosotros desde haya ya bastante tiempo en ElevenPaths, es en un sistema de gamificación para premiar a los usuarios por el reporte positivo de ataques de phishing, malware y spear attacks. Es decir, cuando un usuario recibe un mensaje sospechoso, lo reporta con un plugin con la información de qué le hace sospechar que es un SPAM, phishing, o spear attack.

Figura 14: Plugin para reportar un e-mail como malicioso y ganar puntos

Esta información llega a la consola central del administrador, donde se revisan todos los parámetros que hemos visto hasta ahora. Datos de SPF, SenderID, DKIM, la dirección IP del servidor que lo entregó, información de los remitentes, el SCL, el PCL, el contenido del mensajes, los enlaces que van dentro del e-mail para saber si son maliciosos o no, etcétera.

Figura 15: Desde la consola de análisis, los administradores premian los usuarios con puntos.

Con el resultado del análisis, se premia al usuario con una serie de puntos que podrán utilizar para obtener premios, nuevos niveles dentro de la organización de seguridad - como embajador -, o ciber cooperante. Se trata de fomentar comportamientos positivos - como reportar correos maliciosos - en los usuarios de la organización.

Aún hay más: Identidad en Internet

La cosa aún se complicó más con el correo electrónico. Lo que funcionaba para enviar mensajes entre amigos, compañeros de trabajo y familiares, se complicó y funciona a medias para interactuar abiertamente en Internet - lo que ha obligado a desarrollar todas las tecnologías de protección de las que heos hablado en estas dos partes de la serie -, pero es que funciona relativamente mal para lo que lo estamos utilizando: Identidad en los servicios de Internet.

Hoy en día, la dirección de correo electrónico que utilizan tus contactos, y probablemente tú también, se ha convertido en el "Username" de los servicios de Internet, lo que ha llevado a que si alguien conoce tú e-mail, sabe dónde tienes servicios en la red. No os sorprenderá nada de esto, ya que os he estado hablando muchas veces de nuestro Dirty Business Card Reader, que a partir de tu dirección de correo electrónico y número de teléfono, buscamos en que sitios se puede saber si hay una cuenta, gracias a los info-leaks del login, de creación de cuentas o de recuperación de contraseñas.


Figura 16: Demo de Dirty Business Card Reader
Esas tres opciones en la página de login, es decir, intentar iniciar sesión, intentar recuperar una contraseña olvidad, o intentar crear una nueva cuenta, da información de si una determinada dirección de e-mail ha sido usada como nombre de usuario para tener una cuenta en ese servicio.

Second Factor Authentication

El que sea la identidad de los servicios en Internet, hace que, para robar identidades de servicios, enviar mensajes maliciosos a los buzones de las personas sea el paso más lógico. Luego hacer que la dirección de correo electrónico se haya convertido en el login, hace que se genere más correo malicioso contra los buzones de las personas para robarle todo tipo de identidades.

Por ello, hay que utilizar sistemas de segundo factor de autenticación como TOTP, OTP-SMS, Latch, etc... para proteger estas cuentas, y especialmente la cuenta que hace de piedra de clave. Es decir, la dirección de correo electrónico que está al final de la cadena para recuperar todas las contraseñas - o el número de teléfono que esté en esa posición -.

¿Y qué hacemos ahora, visto esto?

Todo esto ha llevado a un caos de comunicación brutal. En el que la gente utilizar hasta más de una decena de sitios de comunicación distintos a lo largo de su día, dependiendo de si es un amigo, un conocido, un compañero de trabajo, una persona que te contacta por Internet para trabajo o para una cosa particular.

Es decir, el número de canales de comunicación digital similares al e-mail se han multiplicado, especialmente la mensajería instantánea, y la comunicación empresarial. Pero sin ofrecer una solución que haga que desaparezca el e-mail.

Eso sí, lo que ha conseguido esta masificación del miedo al robo de la identidad en servicios de Internet - nadie quiere perder su Facebook, Twitter o Instagram -, esa masificación de los ataques de SPAM, Phishing, Malware y Scams por medio del correo electrónico, y la suplantación de identidades, ha hecho que las personas intentemos ocultar nuestro correo personal, lo que trae otras consecuencias. Pero eso ya lo veremos en la siguiente parte de esta serie.

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)
********************************************************************************************************