Prevención ante ataques phishing – Parte 2 – Evasión de protocolos SPF, DKIM y DMARC

En el anterior artículo vimos, principalmente, cómo identificar un ataque phishing analizando el propio correo y sus cabeceras. Sin embargo, dejamos una cuestión pendiente. ¿Por qué, si claramente se trataba de un ataque phishing, el servidor de correo lo dejaba pasar a la bandeja de entrada? La clave está en los protocolos SPF, DKIM Y DMARC.
En esta segunda parte procederemos a estudiar estos tres protocolos, a la misma vez que vamos a ir analizando los resultados SPF, DKIM Y DMARC del correo phishing de PayPal visto en el artículo anterior.

Protocolos de suplantación de identidad en correos electrónicos

Las herramientas SPF, DKIM y DMARC tienen la misión conjunta de comprobar la autenticidad y veracidad de los correos entrantes. De esta forma se garantiza, en la medida de lo posible, la suplantación de identidad.

A continuación, vamos a explicar detalladamente estos protocolos, a la vez que su interpretación y análisis en las cabeceras de correo. Para ello, imaginemos que hemos comprado el dominio payosrangers.es y queremos configurar los protocolos anteriores con el fin de evitar que un atacante nos suplante.

Sender Policy Framework (SPF)

La protección SPF se encarga de comprobar los servidores autorizados para enviar correos electrónicos a nombre de un dominio. Para ello, el servidor receptor comprobará en el DNS del dominio la lista de equipos permitidos para dicho fin.

Registrar SPF en el DNS

Para que pueda llevarse a cabo la comprobación SPF, se debe registrar en el DNS de tu dominio qué equipos autorizas para que envíen correos electrónicos en tu nombre.

Un ejemplo simple para la configuración SPF en el servidor DNS de payosrangers.es podría ser el siguiente, donde se indican en los parámetros ip4 los equipos autorizados.

v=spf1
ip4:194.57.88.210 ip4:194.57.88.211 ip4:194.57.88.212 ~all

A continuación, este registro se almacenaría en el DNS de tu dominio. De esta forma, cualquier servidor de correo podría consultar qué equipos están autorizados para enviar un email con origen en payosrangers.es.

Verificación SPF

Imaginemos que el servidor de correo B recibe un correo de A, donde el campo From es [email protected] . Entonces B, cuando recibe el correo, revisa en primer lugar este valor:

From: Pepito <[email protected]>

Por otro lado, B debe coger la IP del emisor (servidor A en este caso) para contrastar la información en el DNS del dominio payosrangers.com. En este ejemplo, la IP de consulta va a ser 194.57.88.211.

Por lo tanto, una vez que B tiene la lista de IPs permitidas para enviar correo en nombre de payosrangers.es, puede comprobar que la IP de A está autorizada.

Cabecera Received-SPF

Esta cabecera indica el resultado SPF determinado por el servidor destinatario. Los posibles valores son los siguientes:

• Pass
  • Se ha verificado en el DNS que la IP consultada está autorizada para enviar correos electrónicos en nombre del dominio.
• SoftFail / Fail
  • Se ha verificado en el DNS que la IP consultada no está autorizada para enviar correos electrónicos en nombre del dominio.
• Neutral
  • No se ha podido verificar en el DNS que la IP consultada esté autorizada para enviar correos electrónicos en nombre del dominio. Puede deberse a que no se haya configurado ningún registro SPF o el DNS no esté autorizado para indicar dicha información.
• None
  • Este valor indica que no se ha configurado ningún registro SPF en el servidor DNS. Se comporta igual que Neutral.

El resultado de la cabecera Received-SPF podría ser en este caso la siguiente, donde el servidor de destino (perteneciente a Gmail) indica que el dominio de la cuenta [email protected] permite a la IP 194.57.88.211 enviar correos electrónicos en su nombre.

Received-SPF: pass (google.com: domain of [email protected] designates 194.57.88.211 as permitted sender) client-ip=194.57.88.211;  

SPF en correo phishing de PayPal

En primer lugar, el servidor destino revisaría la cabecera From.

From: [email protected] <nosamdoing.whm.managescustomers-adasup80580433@numborlma.service-login-unauthorizeds.business>  

Siguiendo el formato Nombre del remitente <dirección de correo>, podemos ver que el dominio de la cuenta emisora es numborlma.service-login-unauthorizeds.business y no ics.paypal.com.

Al hacer la consulta SPF al DNS de este dominio, el resultado ha indicado que no hay configurado ningún registro SPF para el mismo. Por lo tanto, no va a poder comprobar si la IP del servidor que le ha pasado el mensaje está autorizada o no para ello.

Received-SPF: None (google.com:   
numborlma.service-login-unauthorizeds.business does not designate permitted sender hosts)   

Esto puede deberse, entre otros casos, a que este dominio se encuentre en un hosting gratuito, donde no se permite configurar estos valores.

DomainKeys Identified Mail (DKIM)

La protección DKIM se encarga de firmar el mensaje para autenticar el emisor, haciendo uso de un par de claves pública-privada. A parte de ello, pretende garantizar la integridad del mensaje, es decir, que no sea modificado por ninguna entidad intermedia.

Registrar DKIM en el DNS

Para que pueda llevarse a cabo la comprobación DKIM, la persona encargada de gestionar el dominio debe generar un par de claves pública-privada. Una vez creadas, se procede a insertar la clave pública en el DNS del dominio.

Por su parte, la clave privada será utilizada para firmar el correo que se envíe. Para ello el remitente, antes de enviar el mensaje, elige las cabeceras del email que quiere incluir en la firma DKIM. De esta forma, en caso de que estos parámetros sean modificados durante el trayecto, la integridad del mensaje no será válida.

Una vez elegidas las cabeceras, el remitente configurará su plataforma de correo electrónico para crear automáticamente un hash de las mismas, convirtiendo el texto legible en una cadena de texto única, conformada por caracteres alfanuméricos.

Para este ejemplo, vamos a suponer que elegimos los siguientes campos para que sean cifrados.

To: [email protected]   
From: Pepito <[email protected]>   
Reply-to: Pepito <[email protected]>   
Subject: Entradas de cine 

Una vez elegidos los campos, se procederá a realizar el cifrado mediante un algoritmo hash como, por ejemplo, SHA-256.

54afea8b3e0736faec084a1618a42e829b2dcc8e19c93c6f7916a16771e3f13a

Antes de enviar el correo electrónico, esa cadena de hash es codificada utilizando la clave privada que generamos con anterioridad.

De esta forma, cuando se realice la consulta DKIM con la clave privada, se podrá verificar la autenticación.

Cabecera DKIM-Signature

Esta cabecera de correo indica la firma proporcionada por el emisor del mensaje para comprobar las propiedades de autenticación e integridad de este. Vamos a explicarla mejor con un ejemplo.

Imaginemos que al servidor B le va a llegar un correo, en el cuál se encuentra esta cabecera. Para no extendernos, vamos a ir directos a los campos más interesantes.

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=payosrangers.es; s=miclave; h=To:From:Reply-To:Subject; bh=h1DshjZZJftaE89yWs5wQMVlOZ3yKYTEdHukeqKOvT+w=; b=54afea8b3e0736faec084a1618a42e829b2dcc8e19c93c6f7916a16771e3f13a

• El campo a indica el esquema de criptografía y la firma criptográfica. En este caso son rsa y sha256, respectivamente.
• El campo s indica el nombre del registro donde está almacenada la clave pública en el DNS. En este caso el registro se llama miclave.
• El campo h indica las cabeceras encriptadas. En este caso son To, From, Reply-To y Subject.
• El campo bcontiene el hash realizado a las cabeceras definidas en el campo h. Esto se define como la firma DKIM.

Al existir esta cabecera, generada por el servidor A que es el emisor, el servidor B tendrá que comprobar la firma DKIM. Para ello, en primer lugar el servidor B revisará el campo From con el fin de conocer el dominio de origen.

From: Pepito <[email protected]>

Una vez lo tenga, realizará una consulta al DNS del dominio para desencriptar el hash con la clave pública alojada en el mismo. De esta forma estamos asegurando la autenticación del mensaje.

Una vez el servidor de correo B tiene el hash, comprueba si coincide con el hash contenido en el parámetro b de la cabecera DKIM-Signature. Si es así, significa que el contenido no ha sido alterado por el camino, por lo que se garantiza la integridad del mensaje. A continuación, podemos ver que ambos coinciden.

b: 54afea8b3e0736faec084a1618a42e829b2dcc8e19c93c6f7916a16771e3f13a
hash desencriptado: 54afea8b3e0736faec084a1618a42e829b2dcc8e19c93c6f7916a16771e3f13a 

Cabecera Authentication-Results

Esta cabecera indica un resumen de las valoraciones dadas por el servidor final tras realizar las comprobaciones SPF, DKIM y DMARC. Será en la misma donde nosotros, como analistas, podremos ver la valoración del protocolo DKIM. Los valores posibles de éste son los mismos que en el caso de SPF: pass, neutral, fail, softfail o none.

La cabecera Autentication-Results para el protocolo DKIM del ejemplo anterior sería la siguiente, donde podemos ver que el receptor ha determinado que el mensaje es auténtico e íntegro debido a que el parámetro dkim es igual a pass.

Authentication-Results: mx.google.com; 
spf=pass (google.com: domain of [email protected] designates 194.57.88.211 as permitted sender) [email protected];  
dkim=pass [email protected] header.s=miclave header.b=54afea8b; 
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=payosrangers.es  

En caso de que la cabecera DKIM-Signature no existiera, no se realizarían los pasos anteriores, sino que el resultado del parámetro dkim sería none o, incluso, no aparecería dkim contenido en la cabecera Authentication-Results (depende del servidor).

DKIM en correo phishing de PayPal

En primer lugar, el servidor comprueba que exista la cabecera DKIM-Signature. De lo contrario, no habría ninguna firma DKIM que validar y, por lo tanto, no se realizarían los siguientes pasos.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=numborlma-service-login-unauthorizeds-business.20150623.gappssmtp.com; s=20150623; h=date:to:from:subject:message-id:mime-version:content-transfer-encoding; bh=za5Oe+uCpTqKfD2r98o+MqHSUQJYbsNZQoTpWh/3qwk=; b=gnSTKkU6jhrda3Xh4qmCPqAIBiGDn05g+BR+/QijWUDL/V2Zrf7y0On3l7k8vbzfJjocIHch6YEMQuox247lpQK0GIg1z7CrYePz+GTmHXRv9gMdsgtpbWl+VYh0M3FWOHycbjBdH1UOXomFXKgtgXf8eEwhXct9ZAwtj7aR5xjdHa/mUPZGVqeGUgTyUgdAFPWipKJ1+BTFmJ+Ifp9k1L8jkjh3FYmFlI+jqRMXl+uBlySG+sd56f39tFoOC9AC8nSHaG3qAxwSaUGQEBXSt2ao1uwZA09tw5eduEHFBYzraGwxaOa3leTglVO30vcbj/Zdgs0AqEvciHWdOUytFg==      

A continuación, el servidor obtiene el campo From:

From: [email protected] <nosamdoing.whm.managescustomers-adasup80580433@numborlma.service-login-unauthorizeds.business>  

Con estos datos, realiza la petición de la clave pública al servidor DNS del dominio numborlma.service-login-unauthorizeds.business, en concreto del registro 20150623 (que es donde se encuentra la clave según indica el parámetro s).

Cuando obtiene el hash, comprueba si coincide con el parámetro b de la cabecera DKIM-Signature, e indica los resultados en el parámetro dkim del campo Authentication-Results.

Authentication-Results:  
spf=none (sender IP is 209.85.221.68) smtp.mailfrom=numborlma.service-login-unauthorizeds.business; hotmail.com; 
dkim=pass (signature was verified) [email protected]; hotmail.com; header.s=20150623 header.b=gnSTKkU6;  
dmarc=none action=none  header.from=numborlma.service-login-unauthorizeds.business;   

El resultado de la firma DKIM para el correo phishing de PayPal es pass, es decir, se ha autenticado al emisor. Sin embargo, se ha autenticado para el dominio numborlma.service-login-unauthorizeds.busines. Por lo tanto, es normal que sea pass si el atacante ha configurado la firma DKIM para su dominio. En caso de que se estuviese comprobando la firma para paypal.com, el resultado no hubiera sido precisamente pass.

Domain-based Message Authentication, Reporting & Conformance (DMARC)

La protección DMARC se encarga de indicar al servidor destinatario qué hacer con el correo si las valoraciones dadas por SPF y DKIM han determinado que el mensaje es una suplantación de identidad. Por lo tanto, para que un mensaje sea validado por DMARC, debe pasar la autenticación SPF y/o la autenticación DKIM. En cambio, si ambas fallan, el mensaje será rechazado.

Al contrario que podríamos pensar, esta decisión no la toma exclusivamente el servidor destino. Si yo soy el propietario del dominio payosrangers.es, configuro un registro dmarc en el DNS indicando qué acción quiero que tome un servidor que reciba un correo suplantando mi identidad. Por lo tanto, al igual que los protocolos anteriores, se debe registrar primero en el DNS la configuración DMARC. Para entenderlo mejor, vamos a seguir con nuestro ejemplo anterior.

Imaginemos que somos los encargados de gestionar el dominio payosrangers.es. Para la configuración DMARC, debemos registrar primero en el DNS de dicho dominio el registro correspondiente. Un ejemplo sería el siguiente:

_dmarc.payosrangers.es IN TXT "v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r;"

El parámetro clave es p. Este define cómo quieres que el servidor receptor gestione los mensajes sospechosos que le llegan haciéndose pasar por tu dominio. Este campo puede estar compuesto por uno de los siguientes valores:

• NONE
  • Le indica al servidor que no haga nada con el mensaje y siga sus propias políticas para determinar el destino del mismo. Le va a indicar una cuenta de correo a la que quiere que se le notifique con un informe del mensaje sospechoso, indicada en el parámetro rua. Este es el valor por defecto.
• QUARANTINE
  • Le indica al servidor que marque los mensajes como spam y que los mantenga en cuarentena a la espera de seguir tratándolos. También se enviaría notificación a la entidad suplantada.
• REJECT
  • Le indica al servidor que rechace el correo, evitando que llegue al destinatario. Al igual que los anteriores, se enviaría notificación a la entidad suplantada.

Por otro lado, se encuentran los parámetros adkim y aspf. A modo resumen, estos campos tienen dos posibles valores: relaxed (r) o strict (s). Según la combinación de estos parámetros, se determinará si el correo es o no una suplantación de identidad.

ADKIM	ASPF	Veredicto
Relaxed	Relaxed	Con que uno de los protocolos SPF o DKIM sea pass, neutral o none el correo es verídico.
Relaxed	Strict	Para determinar que el correo es verídico, por lo menos SPF debe ser distinto de fail/softfail.
Strict	Relaxed	Para determinar que el correo es verídico, por lo menos DKIM debe ser distinto de fail/softfail.
Strict	Strict	Ambos protocolos, SPF y DKIM, deben ser distintos de fail/softfail para determinar el correo como verídico.

Para entender mejor su funcionamiento, imaginemos que llega un correo al servidor B. Una vez comprueba SPF y DKIM, le toca el turno a DMARC. En el siguiente esquema podemos ver la lógica que sigue este protocolo.

Cabecera Authentication-Results

Para no alargarnos con este protocolo, vamos a ir directos al análisis de sus resultados. Como analistas, podremos ver la valoración DMARC descrita en la cabecera Authentication-Results exclusivamente. Los valores posibles del parámetro dmarc son los mismos que en el caso de SPF y DKIM: pass, neutral, fail, softfail o none.

Un ejemplo de esta cabecera podría ser la siguiente:

Authentication-Results: mx.google.com;
spf=pass (google.com: domain of [email protected] designates 194.57.88.211 as permitted sender) [email protected]; 
dkim=pass [email protected] header.s=miclave header.b=54afea8b;  
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=payosrangers.es  

Tal y como podemos observar, el resultado del protocolo DMARC sería pass debido a que tanto SPF como DKIM han dado como resultado que el correo es verídico (son distintos de fail/softfail). En caso de que el correo hubiese sido catalogado como phishing, se hubiera movido a la bandeja de spam, debido a que el parámetro p indica el valor QUARANTINE.

DMARC en correo phishing de PayPal

En el caso del correo phishing de PayPal, los protocolos SPF y DKIM han determinado que no se trata de una suplantación de identidad. Por lo tanto, DMARC no sospecha que el correo sea falso y lo categoriza como legítimo.

Authentication-Results: 
spf=none (sender IP is 209.85.221.68) smtp.mailfrom=numborlma.service-login-unauthorizeds.business; hotmail.com;   
dkim=pass (signature was verified) [email protected]; hotmail.com; header.s=20150623 header.b=gnSTKkU6;    
dmarc=none header.from=numborlma.service-login-unauthorizeds.business;   

Si nos fijamos, el resultado en este caso es none. Esto indica que no hay configurado ningún registro DMARC en el DNS del dominio numborlma.service-login-unauthorizeds.business. En este caso, se sigue la siguiente lógica:

Es decir, el servidor destinatario aplicaría sus propias reglas para decidir qué hacer con el correo. Debido a que SPF y DKIM han determinado que el correo no es sospechoso, se fía y lo envía a la bandeja de entrada.

Ejemplo de un correo phishing detectado por SPF, DKIM y DMARC

En caso de que el campo From del correo de PayPal hubiese sido [email protected], seguramente el servidor de correo lo hubiese bloqueado o enviado a spam. Los protocolos SPF, DKIM y DMARC serían parecidos a los siguientes:

SPF
Se habría comprobado en el DNS de paypal.com (dominio suplantado en el campo From) que el host 209.85.221.68 (servidor de correo del atacante) no está autorizado para enviar correos a nombre de dicho dominio. Por lo tanto, el resultado sería softfail ó fail.

DKIM
Sería absurdo establecer una firma DKIM en estos casos debido a que la comprobación en el DNS de paypal.com daría como resultado fail o softfail. Además, en hostings gratuitos no es posible configurar los registros SPF, DKIM y DMARC. Por lo tanto, lo normal en este caso es que dkim sea none.

DMARC
Hay herramientas online bastante interesantes donde buscar el valor de los registros spf, dkim y dmarc de un dominio concreto. Una de ellas es mxtoolbox.com, donde podemos buscar cuál es el registro dmarc configurado para el dominio paypal.com.

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]

Tal y como podemos observar, PayPal quiere que cualquier servidor de correo que detecte una suplantación en su nombre rechace de inmediato el email y le avise a la cuenta [email protected].

Por otro lado, mientras no se indique lo contrario, los valores por defecto de aspf y adkim son relaxed. Es por ello que, con que spf ó dkim sea fallido, el servidor va a determinar el correo como phishing. Como en este caso SPF ha dado como resultado softfail, este correo va a ser catalogado como suplantación de identidad y, directamente, va a ir a la basura.

La cabecera Authentication-Results en este caso sería la siguiente:

Authentication-Results: mx.google.com; 
spf=softfail (google.com: domain of transitioning [email protected] does not designate 209.85.221.68 as permitted sender) smtp.mailfrom= [email protected]  
dkim=none; 
dmarc=fail (p=reject sp=reject dis=reject) header.from=paypal.com

Conclusiones

Un buen ejemplo de ataque phishing actual es el que hemos visto de PayPal. Para evitar ser descubiertos, los atacantes hacen uso de dominios propios, ya sean comprados o proporcionados en hostings gratuitos. De esta forma, en lugar de suplantar el campo From, arriesgándose así de que su correo no llegue a la bandeja de entrada de la víctima, hacen uso de un dominio propio sin ocultarse.

A veces es bastante evidente que el correo no es verídico (solo hace falta ver el dominio numborlma.service-login-unauthorizeds.business). Sin embargo, con esta táctica se aseguran de evadir los protocolos de seguridad implementados en los servidores de correo, tales como SPF, DKIM y DMARC, siendo el usuario final el encargado de evaluar si el correo es o no legítimo. En caso de que el usuario no esté bien formado, puede caer en la trampa sin percatarse de tal ataque.

Tal y como hemos visto, no siempre los parámetros SPF, DKIM y DMARC son fiables para determinar si un correo es o no un ataque phishing. Es por ello que no se debe dejar en manos de herramientas automatizadas la decisión final, sino ayudarse de analistas que revisen todas las evidencias que dejan este tipo de ataques.

Por último, si eres administrador de dominio aconsejarte configurar SPF y DKIM por lo menos (y si haces uso de DMARC mejor que mejor). Aunque se haya mostrado que a veces no es posible parar estos correos, cuantas más trabas y obstáculos le pongas al enemigo, mejor que mejor 😉

¡¡Saludos!! 👋👋

👉 @verbergar
👉 LinkedIn