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

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

El correo electrónico, o e-mail, es un caos maravilloso. Esa es una de las frases que solía utilizar yo cuando hablaba de cómo funcionaba y cómo había evolucionado, durante las charlas que di en el año 2009 con mi querida Informática 64 en la charla "Hay una carta para ti". Un caos maravilloso que usamos a diario, pero que tiene muchas lagunas de funcionamiento y apaños, de los que os voy a comenzar a hablar por aquí.

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

En este artículo, que he dividido en cuatro partes, voy a intentar hacer un recorrido didáctico y somero, sobre todas las vicisitudes que ha ido pasando, y las cosas que hemos ido construyendo sobre él y alrededor de él para terminar con alguna idea nueva. Espero que os guste, y sobre todo que os entretenga la lectura.

La necesidad de comunicación

Comunicarse es una necesidad humana. Lo utilizamos para todo. Para planificar la caza de un animal  que diera sustento a toda la banda de Homo Sapiens en tiempos de nuestra etapa de cazadores-recolectores, o para establecer una cita amorosa con una pareja que nos ha estimulado el sistema químico a través de una app de contactos en la que nos hemos dado de alta. Necesitamos comunicarnos para trabajar, para demostrar afecto, cariño, y hasta para estar enfadados con el mundo en Twitter.

El ser humano se comunica, y necesitamos hacerlo por cualquier nuevo medio en el que haya otros como nosotros, nos conozcamos o no. Es por eso que, en cada medio en el que nos hemos ido desenvolviendo a lo largo de nuestras vidas hemos desarrollado sistemas de comunicación en él. Desde mensajes en los árboles, señales de humo, o cartas escritas enviadas por mensajeros a caballo.

En la era moderna, ya con la tecnología de los computadores aquí, también lo hemos hecho. Cuando aparecieron los primeros sistemas de tiempo compartido, en los que muchos usuarios podían utilizar un mismo servidor para ejecutar sus algoritmos, apareció la necesidad de comunicarse entre los usuarios de ese ordenador central. El administrador del servidor debía enviar comunicaciones a los usuarios, tales como normas de comportamiento, periodos de indisponibilidad por mantenimiento, o actualizaciones de información sobre nuevas características en el servicio.

Por supuesto, entre los propios usuarios también aparecieron estas necesidades de comunicación. Estos podrían trabajar en grupos, dentro de proyectos que realizaban conjuntamente, para los que necesitaban compartir ideas, resultados o propuestas. Había que comunicarse a través del medio común, es decir, el servidor que daba vida a ese ecosistema creado alrededor de él.

Del e-mail al Webmail, pasando por SMTP, POP3, IMAP

Los primeros servicios de correo eran muy sencillos. Los requisitos eran bastante sencillos, ya que todos los usuarios estaban en el mismo servidor, así que no intervenían para nada las redes de comunicación en ese momento. Un usuario se conectaba al servidor por medio de un terminal para tener un shell, por lo que todo lo que hacía se producía directamente en el propio servidor. Al final, su terminal no era más que el equivalente a tener una pantalla y un teclado conectado al servidor desde una ubicación remota. Pero para el software del servidor, una vez el usuario iniciaba sesión, era como si el usuario estuviera sentado físicamente al lado de él.

Para crear un sistema de comunicaciones entre usuarios no había que hacer nada especial que incluyera ubicaciones remotas, múltiples servidores, o redes complejas de interconexión con federación de identidad. La autenticación y el enrutamiento de las comunicaciones se simplificaba al estar todos los usuarios en el mismo servidor. Para resolver el problema de comunicación bastaba con crear un pequeño programa que corriera en el servidor y al que decías a qué usuario querías enviarle el mensaje, por ejemplo a a p0344, cuál era el asunto por el que abrías esa comunicación, y cuál el cuerpo del mensaje.

En ese momento se generaba un fichero y el servicio de e-mail que corría en el servidor creaba un fichero con esta información en la carpeta de ese usuario p0344 - dentro del árbol de ficheros de ese usuario - destinada a recibir el correo. Es decir, el buzón de cada usuario era una carpeta con permisos de escritura para el servicio de “e-mail” donde se le depositaban ficheros de texto con los datos de qué usuario le escribía, cuándo lo hizo, cuál era el asunto y el cuerpo del mensaje. Metadatos que enriquecieran la comunicación electrónica.

Para enviar mensajes el proceso requería hacer algo similar. Había una carpeta de mensajes de salida que el programa, por medio de un “daemon” en el servidor leía periódicamente para ver si había algo nuevo. Cuando aparecía un nuevo mensaje, el servicio de “e-mail” lo borraba de esa carpeta, lo ponía en la carpeta de mensajes enviados para que quedara un copia, y el mensaje era copiado también a la carpeta de entrada del usuario destinatario en su estructura de ficheros particular. Sencillo y funcional.

La cosa se complicó cuando aparecieron más computadores. Ya no teníamos solo un mundo sino un ecosistema de servidores en red y teníamos la necesidad de comunicar usuarios de un servidor, por ejemplo llamado “Albeniz” con otro, por ejemplo llamado “Zipi”. En ese caso había que hacer un protocolo para que el servicio de e-mail de del servidor Albeniz, fuera el que fuera, supiera dónde tenía que enviar el mensaje cuando el usuario no existiera en su mundo y fuera de otro ecosistema, como por ejemplo del servidor "Zipi".

Para poder identificar a qué ecosistema pertenecía cada destinatario de las comunicaciones, inventamos las direcciones con la @servidor y creamos un protocolo que comunicaba el enrutamiento de mensajes entre servidores. El famoso y popular SMTP (Simple Mail Transfer Protocol) que habilitaba cada servicio de e-mail utilizando un puerto, ahora sí, en la red, en este caso el puerto 25. Así, un usuario “chema@albeniz.eui.upm.edu” podía enviar un mensaje a “chema@zipi.fi.upm.edu”. Los servicios de correo electrónico se enviaban los mensajes uno a otro a través de mensajes de red encapsulados en SMTP.

Pero un día los usuarios dejaron de utilizar plataformas de tiempo compartido como si estuvieran sentados en ellas, es decir, dejaron de conectarse a través de sesiones de terminal, y empezaron a usar sus propias estaciones de trabajo. Eso quería decir que el usuario chema@albeniz.eui.upm.es tenía en su despacho otro mundo, en el que había otro usuario, otro sistema operativo, y otras funcionalidades. Había una estación de trabajo y no un terminal, donde se ejecutaba un mundo tipo Solaris, o un MSDos, o un DRDOS, un OS2/Warp o lo que fuera.

Es decir, era otro sistema informático distinto, por lo que si quería enviar correo electrónico utilizando su identidad de chema@albeniz.eui.upm.edu debía actuar como un servidor remoto más y utilizar el protocolo SMTP para conectarse con el servicio de enrutamiento de correos electrónicos en su servidor, pero eso no valía para poder leer sus mensajes recibidos. Había que crear un nuevo protocolo para que pudiera conectarse a ver los mensajes que le habían entrado en su buzón. Y así nació POP3 (Post-Office Protocol v.3), corriendo en la red por el puerto 110.

Al final un puerto no es más que una zona de memoria que comunica a un programa que corre en un servidor con los mensajes que llegan por la red. Cuando arrancamos un programa que enruta mensajes con SMTP en un servidor, lo que hace este programa es hablar con servicio que recibe el tráfico de red en host y decirle:

"Oye, estoy corriendo en el servidor y esperando mensajes. Si te llega algún paquete que venga con el número 25 como destinatario me lo pones en esta zona de memoria". 

Esto mismo hace el protocolo POP3, pero diciendo algo como:

"Oye, estoy corriendo en el servidor y esperando mensajes. Si te llega algún paquete que venga con el número 100 como destinatario me lo pones en esta zona de memoria". 

Cuando los mensajes le llegan al servicio que gestiona las comunicaciones de red en el servidor, este va colocando los mensajes en diferentes direcciones de memoria para enviárselo a los servicios adecuados en función del número de puerto que venga en el destinatario. Es decir, es como el portero de un edificio en el que viven muchos vecinos y reparte los paquetes de Amazon en los distintos casilleros de los vecinos en función del puerto, que en ese caso serán 2º A, 3º C o Bajo C. Como podéis ver por los números de los puertos de los protocolos, la necesidad de conectar servidores nació tiempo antes de la necesidad de descargar el correo del buzón a la estación de trabajo.

Y funcionó. Y se masificaron los usuarios de estos servicios. Cada vez más personas utilizaban el e-mail para todo. Ya no solo trabajo, sino también para socializar entre ellos, lo que hizo que se vieran las limitaciones de estos protocolos creados hasta el momento. SMTP y POP3 tenían que ser extendidos y su arquitectura y concepto inicial ya no eran los requisitos de hoy en día. Estos protocolos eran una evolución de la idea inicial de transferir mensajes en texto plano entre carpetas, y por eso no tenían gran funcionalidad.

Pero con la masificación de su uso se requería enviar comandos para hacer cosas en el buzón remotamente sin necesidad de descargar y enviar ficheros de texto. Si necesito crear una carpeta para organizar el correo y mover un mensaje de una carpeta a otra, descargarse mensajes de textos y volver a subirlos no tenía sentido. Por ello se creó una evolución completa para gestionar los buzones de correos, y entre las muchas propuestas, comenzó a emerger el protocolo IMAP (Internet Message Access Protocol), con una cantidad de evoluciones.

Por supuesto, desde la primera concepción del servicio e-mail en los servidores de tiempo compartido, los clientes de correo electrónico fueron evolucionando. Desde un interfaz basado en comandos, a un interfaz modo texto corriendo en sesiones de terminales, para llegar a los clientes de hoy en día. Con la creación de SMTP y POP3 aparecieron las herramientas de gestión de e-mail en estaciones de trabajo como (Microsoft Outlook – que no es de las primeras ni mucho menos) para tener clientes de correo electrónico con interfaces gráficos, y con la llegada de HTTP y las páginas web aparecieron los primeros servicios como Hotmail o Gmail. Estos, pasaron rápidamente a utilizar IMAP y hoy en día es posible gestionar tu buzón de Gmail con comandos IMAP, como hice yo hace ya muchos artículos.

Los problemas de seguridad

Como os podéis imaginar, con el aumento de la popularidad del correo electrónico, la evolución de la potencia de cómputo de los equipos en clientes y en servidores en Internet, además de la masificación del número de usuarios conectados y la velocidad de las redes de comunicación, los problemas de seguridad con el correo electrónico fueron infinitos.

SMTP y POP3 nacieron como protocolos para mover ficheros de texto plano que estaban en carpetas de un servidor. El esquema de amenazas que había cuando todos los usuarios estaban dentro del mismo servidor era mucho más pequeño que cuando tenemos dos o más servidores. Ya hay un medio por el que los mensajes deben pasar. Y deberían estar cifrados. Así que primero intentamos cifrar las conexiones entre los servidores usando un protocolo como SSL (Secure Socket Layer) para crear un túnel de cifrado servidor a servidor que impidiera que alguien pudiera interpretar el tráfico si interceptaba la señal en el medio. Así, creamos SMTP-S y POP3-S por puertos de rede distintos que la gente ya no se conoce tan de memoria.

Pero también sucedía que el esquema de identificación de remitente y de identificación del host cuando todos los servidores eran confiables y no era fácil conectarse a la red, tampoco valía. Se empezaron a suceder los ataques de suplantación de direcciones IP en los que una estación de trabajo se hacía pasar por un servidor de correo electrónico, usando técnicas de Spoofing o atacando al servidor DNS para cambiar los servidores autorizados para recibir los mensajes de correo de una organización. El esquema de cifrado era inútil frente a ellos, ya que se estaban cifrando las comunicaciones contra el propio atacante, que estaba haciendo un “man-in-the-middle”, así que pasamos a utilizar sistemas como Mutual-TLS donde tenemos no solo que cifrar las comunicaciones, sino también firmarlas por los servidores que están allí.

Figura 2: Libro de Cifrado de las Comunicaciones Digitales:
"De la cifra clásica a RSA (2ª Edición)"

Pero este proceso de enrutamiento de comunicaciones por la red solo por tramos cifrados no es obligatorio para que el e-mail funcione, y una vez que el usuario ha recibido un mensaje de correo electrónico no sabe realmente si el mensaje va a acabar cifrado en el buzón del destinatario o no, y si la comunicación por la que ha venido era un canal cifrado o no. Y por supuesto, ya que se puede suplantar a un servidor de correo electrónico con una estación de trabajo, se puede suplantar a cualquier dirección de remitente que estuviera en ese servidor. Es decir, podrían aparecer mensajes como chema@albeniz.eui.upm.edu que no hubieran sido enviados ni desde albeniz.eui.ump.edu, ni desde luego por chema.

Para ello, sería necesario que el cifrado y la firma de los correos electrónicos fuera extremo a extremos y robusta. Necesitamos no solo garantizar la comunicación de los servidores, sin la comunicación entre remitente y destinatario, para lo que utilizamos sistemas de firma digital como PGP o los certificados digitales de e-mail S/MIME.

Por desgracia, estos sistemas de certificados digitales son bastante poco usados, ya que tienes que  generar certificados en entidades confiables, configurarlos en los diferentes clientes de e-mail que uses (computadoras, ordenadores portátiles, tabletas, diferentes navegadores de Internet) , hay que renovarlos, hay que intercambiarlos antes de establecer una comunicación segura, etc... Demasiadas barreras de usabilidad para la gran mayoría de las personas que utilizan mensajería e-mail por Internet,  por lo que la mayoría de la comunicación por medio de correos electrónicos ni se cifra ni se firma.

Google intentó avisar a los usuarios cuando los correos venían cifrados en tránsito o no, con un candadito rojo como respuesta a las filtraciones de Edward Snowden en las que descubrió que la NSA estaba capturando el tráfico sin cifrar. Y, además, todos los clientes de correo electrónico marcan con un icono especial si el mensaje viene cifrado y/o firmado desde el emisor.

Figura 3: El intento del candado rojo de Gmail. Mucho candado rojo, mejor quitarlo.

Al final, como la realidad es que casi ningún mensaje llega firmado y cifrado extremo a extremo, los usuarios ven normal que un banco o su jefe les envíen un mensaje sin cifrar o firmar. Con lo que se abre el campo para los ataques de suplantación del remitente y de Phishing o los más peligrosos Spear-Phishing que se utilizan en los ataques dirigidos a personas concretas.

A todo esto hay que sumar problemas inherentes al sistema de correo electrónico más, y es que, al ser un sistema de comunicación de coste cero, se ha aprovechado para hacer captura masiva de clientes por medio de mensajes publicitarios, para hacer campañas de estafas masivas engañando a víctimas (Scam), para dar de alta sin autorización en listas de correos, o para simplemente molestar.

Necesitamos más seguridad pero... ¿Será suficiente?

Tras la creación del servicio de e-mail, vimos que la necesidad de usabilidad nos llevó a crear SMTP, POP3 e IMAP, y que las primeras amenazas nos llevaron a aplicar capas de seguridad como SSL, y mecanismos de firma digital y cifrado extremo a extremo sobre sobre el servicio de e-mail, como PGP o S/MIME, pero aún estamos lejos de que poder proteger al servicio de correo electrónico de todos los problemas que se fueron creando, así que hay que hacer más.

En la siguiente parte de este artículo veremos cómo se empezaron a intentar soluciones como Sender Policy Framework, Sender ID, DKIM, o los Filtros Anti-Spam basados en todo tipo de algoritmos, desde listas blancas y listas negras, hasta Inteligencia Artificial pasando por los Filtros Bayesianos o la colaboración de usuarios para detectar Scams, Spam, Spear Phishing, y otros ataques a las personas. Pero aún así... no será bastante, así que habrá que ver qué alternativas han aplicado personas y empresas para lidiar con el e-mail.

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

Efail: O cómo descifrar e-mails cifrados con S/MIME y OpenPGP usando técnicas de exfiltración

La verdad es que hoy, día de San Isidro, tenía cualquier plan menos ponerme a leer un paper técnico, pero encontrarme esta mañana información del trabajo de Efail merece la pena el cambio de planificación. Se trata de un trabajo que explica cómo se pueden descifrar correos electrónicos que hayan sido cifrados mediante S/MIME u OpenPGP, incluso si los correos tienen mucha antigüedad.

Figura 1: Efail: O cómo descifrar e-mails cifrados
con S/MIME y OpenPGP usando técnicas de exfiltración

Dicho esto, dejadme que os explique un poco el escenario para que sea más fácil de entender por todos, pues si no puede llevar a confusión. Supongamos que Eduardo (Emisor) envía un mensaje cifrado con OpenPGP o S/MIME a Ricardo (Receptor). Para eso, quiere decir que Ricardo tiene la clave privada de descifrado del Mensaje, ya que hemos cifrado el contenido del Mensaje con la Clave Pública de Ricardo.

Figura 2: Efail: Breaking S/MIME and OpenPGP Email Encryption

Supongamos ahora que Ricardo, años después sigue teniendo disponible esa Clave Privada (no ha caducado, y la sigue teniendo en uso). Bien, en ese escenario, un atacante, podría enviar un e-mail, al que llamaremos Mensaje Malicioso que iría cifrado con la Clave Pública de Ricardo, y que podría ser utilizado por el Atacante para descifrar los Mensajes enviados años atrás por Eduardo. ¿Cómo?

Figura 3: Si la Víctima abre un e-mail Mailicioso puede descifrar mensajes antiguos

Pues tan sencillo como metiendo en el Mensaje Malicioso "trozos" del Mensaje de Eduardo a Ricardo que van cifrados para que los descifre y Exfiltrando el contenido descifrado utilizando diferentes técnicas que dependen de:

A) El tipo de cifrado que se utiliza 

B) El cliente de correo electrónico que usa Ricardo.

Si queréis los detalles completos, podéis leeros el paper, pero básicamente utiliza tres tipos de exfiltración basados en el uso de la interpretación del HTML y las Primitivas de los sistemas de cifrado:

- BackChanels: Si el cliente interpreta el código HTML de un e-mail se puede crear un mensaje HTML con una etiqueta IMG que se cargue de un servidor controlado. Este canal que siempre ha sido visto como un riesgo de privacidad - ya os conté alguna aventura mía con esto por culpa de Gmail - también se puede usar para exfiltrar datos usando parámetros en las URLs o dejando las etiquetas sin cerrar. 

- Direct Exfiltration: Se dejan las etiquetas IMG sin cerrar y algunos clientes envían parte del mensaje descifrado al servidor. Esto permite que el Atacante acceda a datos descifrados que le permiten tener duplas de datos cifrados y descifrados. 

- Malleability Gadget: Aquí el paper se centra en cómo utilizar los datos exiltrados para, utilizando las primitivas de OpenPGP y S/MIME que permiten reordenar o inyectar pedazos de mensajes cifrados en el sistema para obtener su descifrado. Es decir, dinámicamente se puede solicitar el motor que descifre cadenas de texto cifrado.

Con estás técnicas, dependiendo de la configuración del cliente de correo electrónico y las versiones de OpenPGP o S/MIME una víctima podría estar descifrando correos electrónicos antiguos con solo abrir un mensaje malicioso hoy en día.  Las versiones afectadas por esta técnica las tenéis en la tabla de la figura siguiente.

Figura 4: Tabla de sistemas afectados

¿Cómo evitar esto?

La forma más sencilla es actualizar el software de S/MIME y de OpenPGP para evitar el uso de las primitivas para modificación y quitar el uso de HTML en la interpretación de mensajes de e-mail. HTML en el e-mail ha sido siempre un leak de privacidad debido a la existencia de Side-Channels para saber si un mensaje ha sido leído o no y desde qué equipo, así que si lo tienes deshabilitado, mejor que mejor.

Si quieres saber más sobre este tema, te recomiendo el libro de Cifrado de las Comunicaciones Digitales que explica todos estos conceptos con extrema facilidad y te permitirá entender mejor este tipo de situaciones.

Saludos Malignos!

SMTP STS: SMTP Strict Transport Security

El correo electrónico es uno de los servicios más antiguos y arraigados en Internet. De hecho, el protocolo SMTP disfruta de tener como Well-Known Port el número 25, dejando claro que cuando nació este servicio no había muchos otros alrededor de él. Está muy arraigado, pero su larga historia ha hecho que casi se convierta en un collage de cabeceras que se adjuntan en cada mensaje a modo de remiendo para lograr hacer de él un servicio seguro, ya que no se pensó en la seguridad cuando se concibió. 

Figura 1: SMTP STS (SMTP Strict Transport Security)

Para ir solucionando problemas de seguridad hemos visto como se han añadido cabeceras "X-" fuera de estándar para atacar un determinado problema, o como se expandía el uso de soluciones como SPF, Sender ID, Identified Mail, DKIM, etcétera, para evitar problemas de suplantación, manipulación del mensaje, reducir el Spam mediante cabeceras calificaciones SCL (Spam Confidence Level). Hemos añadido RBLs, filtros bayesianos, búsquedas inversas de PTR, etcétera. Todo para intentar hacer que el correo electrónico pudiera ir superando los ataques a los que se iba enfrentando.

Desde el punto de vista de privacidad, uno de los problemas  que tiene el correo electrónico es el del reenvío de mensajes entre servidores SMTP para conseguir que ningún hombre en medio pueda acceder al contenido de los mensajes. Este problema no existiría si en la industria hubiéramos conseguido que el cifrado end-to-end entre destinatarios utilizando PGP o S/MIME se hubiera hecho lo suficientemente usable como para que todos los usuarios del mundo lo usasen por defecto, pero por desgracia no ha sido así.

Figura : WebPG, un intento de hacer PGP más usable en Gmail

Asumiendo que no hay cifrado end-to-end, lo que se busca es conseguir al menos que, la parte que no depende del usuario vaya cifrada. Es decir, que la conexión entre el cliente de correo electrónico y servidor de correo saliente vaya con SMTP-s o IMAP y que la conexión de SMTP Relay que va entre el servidor de correo saliente del emisor y el servidor de correo entrante del destinatario - o cualquier otro salto de enrutamiento que pudiera estar configurado - vaya cifrada con un túnel TLS. 

Para conseguir este cifrado hemos visto diferentes soluciones que van desde poner rutas de reenvío fijadas con TLS para que no sea opcional o el uso de Mutual TLS en los servidores de las organizaciones. Pero hay que conseguir que esto se utilice. Hay que conseguir que el cliente configure su cuenta como SMTP-s o IMAP, hay que configurar el Mutual TLS en las organizaciones o hay que hacer que los SMTP Relays vayan con TLS siempre y no es fácil conseguir vencer una tendencia.

Figura: El candado rojo de Gmail para avisar del NO uso de cifrado

Una iniciativa para apoyar esto ha sido el uso del candadito rojo en los mensajes de Gmail, donde se informa al usuario de si el correo electrónico que se recibe ha llegado vía túnel TLS cifrado o en claro en algún tramo, lo que haría que pudiera haber sido interceptado por cualquiera. 

Figura: Draft que describe SMTP STS

Ahora, un grupo de ingenieros ha propuesto migrar el uso de las cabeceras STS (Strict Transport Security) que se utilizan en HTTP bajo el protocolo HSTS (HTTP Strict Transport Security) al entorno SMTP. Para ello han publicado en Internet un documento de 19 páginas en el que abogan por la implantación de un sistema de Certificate Pinning similar al que se utiliza en la web, reduciendo las posibilidades de los ataques de downgrade que se pueden hacer al protocolo SMTP con las cabeceras STARTTLS.

Figura: Cabeceras STS para SMTP descritas en el draft

La idea es conseguir desplegar SMTP STS y lograr que las conexiones a un servidor SMTP se hagan utilizando un certificado digital validado para ese servidor y que esa validación se pueda hacer vía DANE (DNS-Based Authentication of Name Entities) y como complemento utilizando STS con una confianza en el primer intercambio o en el primer uso. Al final, lo que propone el draft es incrementar el uso de los túneles TLS mediante la automatización de un sistema de confianza en los certificados digitales usando STS, que en HTTP hay que reconocer que ha funcionado razonablemente bien y, a pesar de tener aún limitaciones, ha reducido sustancialmente los ataques de Hijacking y Tampering en las webs en las que se hace uso de HSTS.

Saludos Malignos!

Un errónea recomendación de seguridad de Twitter

A mi regreso de vacaciones tocó volver a revisar las opciones de seguridad con las identidades. De todas las que tengo protegidas con Latch es bastante sencillo, pues solo debo revisar el log de intentos de acceso y sesiones abiertas que se añadió en la última revisión de la app, pero las de que tengo protegidas con segundos factores de autenticación como Google Authenticator hay que revisar el log y cambiar passwords, ya que incluso aunque te hayan robado la password y tengas Google Authenticator no recibes alerta alguna. Además, no viene mal revisar los tokens de acceso que puedan tener concedidos en las identidades principales. Tarea habitual en el regreso al trabajo.

Figura 1: Un errónea recomendación de seguridad de Twitter

Realizando los cambios de configuraciones, asocié un nuevo número de teléfono a mi cuenta de Twitter, y recibí un aviso de seguridad por correo electrónico. Algo bastante habitual a día de hoy en la mayoría de los servicios online en los que la cuenta, inicialmente, se crea utilizando una identidad basada en una dirección de correo - éste es el caso de Twitter -. El mensaje es el que podéis ver ahí, pero os pido que os fijéis principalmente en la recomendación de seguridad que se puede leer para reconocer si el correo es original de Twitter o no.

Figura 2: Recomendación de Twitter para reconocer un correo electrónico de Twitter

La verdad es que es bastante pobre que una empresa como Twitter añada esa recomendación de seguridad para educar a sus usuarios en reconocer un correo electrónico auténtico de un correo de spoofing que intente hacer un ataque de phishing y robarle las contraseñas. Algo, que además hemos visto que es la principal forma de robar identidades en Twitter.

Poner como recomendación que la dirección URL debe comenzar por twitter.com deja abiertas tantas posibilidades para un atacante que si un usuario de Twitter se ha aprendido esta regla, y asume que una dirección que comienza por twitter.com es segura, entonces se estaría provocando a los usuarios de la red de los - por ahora - 140 caracteres a caer en la trampa. Por supuesto, lo más fácil sería para un atacante crear un sitio falso con una dirección del tipo twitter.com.chema/login que cumple a la perfección la recomendación de seguridad. 

Figura 3: Un phising al login de Twitter que cumple la regla de seguridad

Para poner a los usuarios más nerviosos, da una regla (que los enlaces siempre comiencen por twitter.com) que luego no cumple, ya que en el correo electrónico mismo en el que viene la recomendación hay tres enlaces que comienzan por support.twitter.com lo que ya, para un usuario que solo siga esa regla sería contradictorio. 

No solo eso, sino que además no se hace hincapié en que se utilice protocolo HTTPs - algo que podría dificultar un poco más la construcción del sitio de phishing -, ni se habla de comprobación de certificados digitales, ni nada similar y deja tomar la decisión de si el correo viene de Twitter o no en mirar los enlaces que trae. Es más, en español nos encontramos ante una traducción de un mensaje que en la web en inglés pone de otra forma.

Figura 4: Recomendación en inglés para evitar el phishing y fake emails

En inglés pone al menos que debe estar en el "websiste" de http://twitter.com, algo que deja en el cliente la necesidad de entender si está en el website de http://twitter.com o no, o lo que es lo mismo, que sepa ya que es un phishing o no, con lo que no aporta nada. Pero para arreglarlo,  en lugar de poner un dominio - que sería solo twitter.com -, ponen una URL - http://twitter.com -, donde de nuevo se usa HTTP en lugar de HTTPs cuando la web de login la sirven vía HTTPs únicamente. Y no le piden al usuario que verifique ningún certificado digital, que es justo para lo que se crearon: para identificar que estas en el sitio que dices que estás.

Figura 5: El certificado de Twitter.com correctamente emitido

Dejando estos "cabos sueltos", los que se dedican al fraude online, al robo de identidad a la carta, o a los ataques dirigidos a personas concretas, tienen pequeñas ayudas en la educación de las víctimas, que son enseñadas a confiar en enlaces siguiendo malas reglas de seguridad. Entre otras cosas, me gustaría resalta que aunque el enlace sea del dominio Twitter, y esté en la web oficial de Twitter, podría tratarse de un robo de tokens OAuth de la cuenta, tal y como hemos visto que se ha hecho ya en Gmail o Hotmail en muchas campañas de robo de dinero.

Figura 6: Las llamadas a la API de Twitter pueden ser maliciosas para el usuario

Lo suyo, si vas a utilizar el correo electrónico para enviar notificaciones de seguridad y quieres dotar al mismo de alguna medida de identificación que ayude a evitar el spoofing de la dirección de correo electrónico y dificultar el phishing, es que utilices algo que no se pueda suplantar.

Figura 7: Paypal firma sus comunicaciones con DKIM

Una firma digital en PGP o S/MIME que le permita al receptor del correo comprobar la misma, o algo como DKIM, que es lo que ha pasado a utilizar Paypal en sus notificaciones, que ayuda a saber si el correo electrónico ha salido o no de los servidores de Paypal y en clientes como Gmail ya se verifica directamente. A día de hoy, Twitter solo utiliza SPFv1 para identificar sus direcciones de correo. Eso sí, con política hardfail (-all) para que los clientes estrictos eliminen todo correo que no venga de sus servidores que, por desgracia, son pocos.

Saludos Malignos!

Dile cositas bonitas al oído a los chicos de Apple

Desde hace unas semanas tengo un iPhone 5 que ha pasado a engrosar mi colección de smartphones y tablets que uso para aprender cositas. Una de las primeras cosas que quisimos probar en iPhone 5, además de cómo trabaja Oxigen Forensics con iOS 6, fueron las funciones nuevas que vienen con iOS6 y no están disponibles en los iPhone 4 e iPhone 4S, así que había que jugar mucho con Siri.

Siri es el asistente personal de iOS que te ayuda, entre otras cosas, a que otros usen tu dispositivo aunque lo tengas bloqueado, también ha obligado a Apple a parchear iOS 6 porque permitía acceder a las contraseñas de Passbook aún con el dispositivo bloqueado, o a tener que reprogramar la propia "inteligencia" de Siri porque les salió respondón y cuando preguntaban qué smartphone era el mejor contestaba que un Nokia Lumia con Windows Phone.

Figura 1: Enviando correos electrónicos con Siri en un iPhone bloqueado

Además de esos "detalles" insignificantes en seguridad, Siri tuvo que ser bloqueado en muchas redes de empresas, porque tiene la peculiaridad de que el reconocimiento de voz no se hace en el terminal sino en los servidores de Apple. Es decir, cuando tu hablas a Siri lo que estás haciendo es generar un fichero de audio que es enviado a los servidores de Apple que devuelven su interpretación en modo texto.

A muchas personas de empresas preocupadas por la seguridad - de esas que son capaces de poner los smartphones en cajas faraday en las reuniones - eso de que Siri se active solo cuando va el terminal en el bolsillo no les gusta nada, y por supuesto, que se almacenen todos los mensajes de voz, a las empresas que venden sistemas de seguridad biométrica basados en voz no les parece nada inteligente que se vayan dejando grabaciones de voz en servidores ajenos.

El caso es que en el teclado de iOS6 también está escondido Siri, y yo pensaba que no era así. Entre las teclas aparece un botón con un micrófono que reconoce tu voz para escribir el mensaje sin teclearlo, y la verdad es que funciona muy bien. El problema es que, aunque no lo creas, es Siri, y todo lo que estés escribiendo en un mensaje de correo está siendo grabado en los servidores de Apple. Para probadlo, activa el modo avión de tu iOS6 y verás como el micrófono desaparece.

Figura 2: Siri escondido en el teclado desconectado porque no hay Internet

Es decir, si Apple ya se llevó los SMS con el iMessage, y tiene asociado tu Apple ID con tu UDID del terminal - ese que se puede utilizar para hacer un ataque dirigido con un troyano para iOS - y vas tú y ahora le lees los correos electrónicos confidenciales que vas a escribir, olvídate de PGP, S/MIME o lo que quieras.

Como se puede ver en las imágenes, el teclado con Siri sale en todas las aplicaciones, como las notas, el despertador, las búsquedas en Internet, e incluso las que hagas en tu teléfono, así que utiliza sólo este sistema para decirle cosas al oído y no para escribir correos confidenciales o para pedir "servicios especiales" en países donde estén prohibidos }:O

Figura 3: Escribiendo una nota con voz para dejar un mensaje bonito en Apple

Para eso, que Apple siga teniendo que reconstruir los mensajes de Carrier IQ, el "troyano" ese que se instala en los smartphones para reconstruir lo que haces en paso a paso en cada equipo y hacer un debugging "como debe hacerse". Por cierto, un amigo me dijo hace poco que si en el anuncio de Apple pone que tu dedo pulgar va de aquí a aquí, porque el teclado en horizontal no aprovecha toda la pantalla en iPhone 5... y tiene toda la razón como podéis ver en la Figura 3.

Saludos Malignos!