Las maneras en que podemos ser atacados digitalmente han incrementado y se han sofisticado, sin embargo, en Kepler hemos detectado como viejas técnicas de los años 90, algunas con toques nuevos, están siendo utilizadas hoy. Este es el caso del Spoofing, en español, cuando alguien se hace pasar por otra persona. En el caso de un correo electrónico, es cuando se envía un correo tratando de hacer creer a quien lo recibe que es otra persona el que lo envía, generalmente para cometer un ilícito aunque también es utilizado para hacer bromas (e-mail pranking).

Para detectar estos ataques no basta con revisar los remitentes, veamos unos ejemplos:

1. De: Chuck Norris – <[email protected]>
   • Basta con leer la dirección entre <> para darse cuenta que es alguien tratando de hacerse pasar por otro, en este caso, el nombre Chuck Norris no es del que envía y el correo verdadero es [email protected]
2. De: Chuck Norris <[email protected]>
   • Spoofing más sofisticado. El atacante ha cambiado todo el campo que se muestra al usuario y ha configurado para que las respuestas le lleguen a él a otro correo verdadero (desde donde sale este correo malicioso). En este caso es necesario leer los detalles del encabezado del mensaje. Revisar el “return-path” y es recomendable también revisar el X-originating-IP, este indica de donde viene. Si el «return path» no coincide con el correo que vemos en el casillero De: (From:) o la dirección IP no corresponde al dominio, debemos desconfiar del correo.
3. De: Chuck Norris <[email protected]>
   • Spoofing parecido al anterior, donde el delincuente no necesita una respuesta al correo. Puede haber mandado una instrucción a una institución bancaria, o a un empleado de una empresa haciéndose pasar por el Gerente General (Urgente acepta la cotización de la empresa 3 palitos). Sólo con una verificación de la dirección IP (X-originating-IP) podría revelar el engaño. En este caso la línea De: es idéntica al «Return Path» (X-Sender) perdiendo el atacante la capacidad de recibir un correo de respuesta.

El caso 1 es configurable en varios servidores de correo o incluso en aplicaciones de lectura de correo de escritorio o celular, donde simplemente configuramos el nombre de la cuenta con uno falso y no es necesario tener conocimientos de informática.

El caso 2 es más sofisticados y es posible engañar el SPF al servidor de GMAIL o Office365 a través de un ataque conocido como Reagan Atack.
Este caso se basa en que el campo que muestra GMAIL o Office365 a los usuarios como remitente (DE:) es diferente al campo que lee el servidor de correo como Remitente y diferente a al campo donde enviará un correo de respuesta (return path). Mientras las capas anti-phishing de estas mega compañías buscan verificar en el encabezado que el «sender» es quién dice ser, verificando la IP del servidor original, lo que nos muestra a los humanos es otro campo. Por lo tanto su verificación puede pasar si el atacante a configurado para que el receptor vea un nombre y otra el servidor de correos entrante.

El caso 3 no es capaz de engañar la verificación de SPF, siempre que el remitente lo tengo configurado. Tampoco puede recibir correos de respuesta.

Los campos que juegan un rol importante acá son:

Return-Path: Es el campo que los servidores utilizas para la revisión SPF. Revisan el dominio de este campo y lo comparan con la IP de donde viene el correo. Si está en los registros SPF, pasa.

De: O campo From en inglés, es el que se le muestra al usuario.

Para combatirlo como remitentes, es decir, que al recibir un correo que aparenta ser nuestro pero no lo es, el receptor pueda ser capaz de detectarlo debemos:

Configurar SPF (sender policy Framework) record en tu dominio.

El SPF especifica que servidores de correo tienen permiso para enviar correos de parte de tu dominio. Esto ayuda al receptor identificar el uso no autorizado de tu dominio.

Configurar DKIM DMARC

DKIM (DomainKeys Identified Mail): el servidor de correo saliente incluye una cabecera en el mensaje con una firma digital del contenido del mensaje. Cuando se manda un e-mail, el servidor de destino hace una consulta al DNS del dominio de remitente y, si en el campo de la firma DKIM está configurado, obtiene la clave pública del dominio y la utiliza para descifrar el valor de la firma del campo de la cabecera y recalcular el valor de la firma para el mensaje (cabeceras y cuerpo) que ha recibido. Esto asegura que el remitente es el que dice ser y además que el correo es fiel a lo que se envió.

DMARC: Es un registro que se configura en tu DNS, le indica al servidor de correo receptor que hacer con mensajes que fallan o pasan una revisión de SPF o DKIM .Con este registro es posible monitorear si se está utilizando de forma fraudulenta tu domino.

El caso 2 puede llegar a ser muy peligroso, dado que al engañar a los servidores de GMAIL o OFFICE365 el usuario podría creer estar seguro, pero al responder al correo estaría respondiendo al atacante. La única medida para defenderse de este ataque es ver manualmente el encabezado y revisar el X-Sender-id y el Return Path y ver que coincidan con el que vemos en De: además de revisar las IP si corresponden a los del dominio esperado. Al día de hoy, Google reporta que no ven las vulnerabilidades de SPF como críticas. Es por esto, no está priorizado para parchar. En caso de haber un cambio, lo postearemos acá.

Imágenes de apoyo

Figura 1 (caso 2 y 3)

Figura 2 (caso 3), Falla verificación SPF

Figura 3 (caso 3), Falla verificación SPF