¿Cómo es posible la falsificación de correos electrónicos?

A veces es fácil detectar correos de phishing con tan solo comprobar el remitente. No obstante, no siempre es así; ahora es posible hacer que un correo parezca totalmente auténtico y, si el atacante sabe cómo hacerlo, la organización objetivo del ataque estará en un serio problema. La mayoría de los usuarios no se lo pensarían dos veces antes de hacer clic en un enlace o archivo malicioso que han recibido en el correo supuestamente de su jefe o de un cliente importante y no podemos culparles, sobre todo si no hay forma de detectar la farsa.

Pero antes ¿cómo es posible falsificar tan bien un correo electrónico? La charla de Andrew Konstantinov en la 36ª edición del Chaos Communication Congress sobre la autentificación de correos en las pruebas de penetración responde esta pregunta e informa sobre la eficiencia de la protección de las falsificaciones de correos electrónicos.

Problema 1: Los correos electrónicos deben ser fluidos

Los correos electrónicos son el medio de comunicación principal del mundo moderno y todas las organizaciones dependen de ellos para sus operaciones cotidianas. Aunque no pensamos mucho en la tecnología cuando todo se desarrolla sin problemas, si de repente los correos comenzaran a desaparecer, puedes dar por seguro que todo el mundo se daría cuenta. Por ello la fiabilidad es la principal prioridad de cualquier administrador de servidor de correo electrónico. Da igual lo que pase, pero los e-mails tienen que seguir enviándose y recibiéndose como de costumbre.

Por tanto, los servidores de correo electrónico de todas las organizaciones deben ser lo más compatible posible con todo lo demás. Y ahí está el problema: los estándares de correo electrónico no están actualizados.

Problema 2: El protocolo de correo electrónico sin autentificación

El protocolo principal utilizado tanto para comunicaciones de correo electrónico entre cliente-servidor y servidor-servidor es el SMTP (Protocolo para Transferencia Simple de Correo, por sus siglas en inglés). Este protocolo se introdujo por primera vez en 1982 y se actualizó por última vez en el 2008; hace más de una década. Y, al igual que otros muchos estándares antiguos, el SMTP es una pesadilla para la seguridad.

En primer lugar, vamos a analizar un mensaje de correo electrónico típico:

• Sobre SMTP. Esta parte se utiliza para las comunicaciones servidor-servidor y no se muestra nunca en los clientes de correo electrónico. Especifica las direcciones del remitente y del destinatario.
• Los clientes de correo electrónico sí muestran esta parte. Ahí es donde encontrarás los famosos campos “De”, “Para”, “Fecha” y “Asunto” que ves en cualquier correo electrónico.
• Cuerpo del mensaje. El texto del e-mail y otros contenidos.

Qué hay en un mensaje de correo electrónico. Fuente de imagen

El problema principal es que el estándar no ofrece medios de autentificación. La responsabilidad del campo de dirección del remitente, tanto en el sobre SMTP como en el encabezamiento, recae directamente sobre el servidor del remitente. Y lo que es peor, la dirección del remitente que aparece en el sobre SMTP no tiene por qué coincidir con la del encabezado (y el usuario solo ve la última).

Además, aunque el estándar especifica un encabezado por correo electrónico, el SMPT no refuerza los límites. Si un mensaje contiene más de un encabezado, el cliente de correo electrónico simplemente muestra uno al usuario.

No hay que ser un profesional para ver la ocasión de hackeo.

El protocolo de correo electrónico no ofrece medios para garantizar que un correo electrónico viene realmente del remitente indicado.

Problema 3: Los remitentes falsos; podrías ser tú

Para complicar aún más las cosas, toda comunicación por correo electrónico involucra dos partes, por lo que este problema de no autentificación da lugar a dos subproblemas.

Por un lado, quieres asegurarte de que cada correo que recibas se haya enviado realmente desde la dirección indicada y, por otro, es probable que quieras evitar que otra gente envíe correos que parecen proceder de tu dirección. Por desgracia, el estándar no puede ayudarte con eso.

Dado que el protocolo SMTP se ha visto abusado con tanta frecuencia, no es de extrañar que la gente haya comenzado a divisar nuevas tecnologías para solucionar los errores que acabamos de mencionar.

Solución, intento 1: SPF (Convenio de remitentes, por sus siglas en inglés)

La idea que hay detrás del SPF es simple: el servidor receptor debería ser capaz de comprobar si la dirección del servidor que envió realmente el correo coincide con la dirección del servidor de correo genuino asociado con el dominio.

Por desgracia, es más fácil decirlo que hacerlo. El estándar SMTP no presenta medios para este tipo de comprobación, por lo que cualquier método de autentificación debería situarse por encima de lo que ya existe. Conseguir que esta tecnología se considerara como un “estándar propuesto” llevó una década. Actualmente, solo alrededor del 55 % del millón de servidores principales usan SPF, y la mayoría utiliza políticas bastante relajadas.

SPF también se enfrenta a otros problemas, como una arquitectura desordenada que facilita la desconfiguración, métodos para sortearla utilizando otros servidores almacenados en la misma dirección y demás. Pero el peor error del SPF es que comprueba solo la dirección indicada en el sobre SMTP e ignora por completo el campo “De” en el encabezado, que es el que ve el usuario.

Resultado:

• El SPF ayuda a comprobar si un correo electrónico viene de un servidor genuino.
• La dirección visible a los usuarios puede falsificarse igualmente.

Solución, intento 2: DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail afronta el problema de una forma diferente: firma de forma cifrada el encabezado del mensaje y parte del cuerpo del mensaje con una clave privada, dicha firma puede verificarse con una clave pública emitida en el sistema de nombre de dominio.

No obstante, cabe destacar que el DKIM no tiene por qué cifrar el mensaje completo. Sino que más bien adjunta un apéndice firmado de forma cifrada y esto es un problema. Es complicado modificar la parte cifrada, pero eliminar la firma por completo y crear un mensaje falso es fácil y los resultados son indetectables.

Resulta complicado implementar el DKIM porque involucra expedir y gestionar claves cifradas. Además, un DKIM desconfigurado puede habilitar a un atacante para que preserve la firma DKIM genuina en un mensaje mientras cambia por completo el encabezado y el cuerpo.

Resultado:

• DKIM te permite firmar mensajes de forma digital, ayudando a garantizar al servidor receptor que un mensaje procede realmente de ti.
• Resulta complicado implementarlo porque supone la gestión de las claves cifradas.
• El falsificador puede eliminar la firma mientras falsifica una dirección de correo electrónico en tu nombre.
• Los errores de configuración pueden tener como resultado mensajes falsos que contienen firmas DKIM genuinas.

Solución, intento 3: DMARC (Autentificacion de mensajes, informes y conformidad basada en dominios, por sus siglas en inglés)

A pesar de tener un nombre tan largo, el protocolo DMARC resulta más sencillo que el SPF o el DKIM. Es una extensión de los dos que pone solución a sus omisiones más evidentes.

En primer lugar, DMARC ayuda al administrador del dominio a especificar qué mecanismo de protección (SPF, DKIM o ambos) utiliza el servidor, lo que soluciona el mecanismo DKIM. En segundo lugar, también soluciona el SPF, ya que ofrece una comprobación de la dirección especificada en el campo “De” del encabezado (el que queda visible al usuario), además de la comprobación de la dirección del remitente en el sobre SMTP.

El lado negativo es que el protocolo DMARC es relativamente nuevo, todavía no es un estándar propiamente dicho (RFC 7489 no lo define como un estándar o incluso un estándar propuesto, pero solo como “informacional”) y no se utiliza tanto como se debería. Según este estudio de 20000 dominios, solo el 20 % había adoptado DMARC en el 2019, y solo el 8,4 % había optado por políticas estrictas.

Por desgracia, la adopción de DMARC todavía no está generalizada y en muchos casos se utiliza sin “ninguna” política. Fuente de imagen

Resultado:

• Soluciona los problemas más importantes de SPF y DKIM.
• No está muy generalizado y, por tanto, no es tan eficaz como debería.

Cómo protegerte de la suplantación de correo electrónico

En resumen: la falsificación de correo electrónico sigue siendo posible porque el protocolo de SMTP no se ha diseñado pensando en la seguridad, por lo que permite que el atacante añada la dirección de cualquier remitente en un correo falsificado. En las últimas décadas han emergido ciertos mecanismos de protección: SPF, DKIM y DMARC. No obstante, para que estos mecanismos sean más eficaces, tienen que utilizarse (e implementarse de forma correcta) en la mayor cantidad de servidores de correo posibles, pero todavía no es el caso.

Además, es importante tener en cuenta que, debido a errores de configuración, un servidor de correo podría empezar a añadir algo a los mensajes y esto arruinaría directamente la comprobación DKIM. Tampoco podemos olvidarnos de que estas tecnologías te ayudarán a enfrentarte a las amenazas masivas, pero para proteger tu negocio de los ataques de correo sofisticados deberías utilizar soluciones de protección adicionales tanto en las estaciones de trabajo como en los servidores de correo.

He aquí algunas recomendaciones para la protección del correo electrónico:

• Al menos adopta el SPF y asegúrate de que esté bien configurado. Pero ten en cuenta que los atacantes más ingeniosos pueden esquivar este protocolo (más información en la charla).
• Implemente el DKIM para una protección más eficaz. Puede resultar más complicado, pero merece la pena considerarlo. Y, de nuevo, asegúrate de que esté bien configurado (algunos consejos sobre lo que buscan los atacantes).
• Siempre que sea posible adopta el DMARC, ya que soluciona algunos de los errores más aprovechables de SPF y DKIM.
• Comprueba la configuración de los correos entrantes.
• Utiliza soluciones de seguridad compatibles con los mecanimos de autentificación actuales. Por ejemplo, utiliza Kaspersky Security for Mail Server o Kaspersky Security for Microsoft Office 365.