Home Uncategorized Mail PHISHING: saber algo más de SPF, DKIM y DMARC…

Mail PHISHING: saber algo más de SPF, DKIM y DMARC…

by José Luis Sánchez Borque

El presente Post no pretende ser un Master en técnicas suplantación de correo. Más bien es un Post simple, que pretende a alertar a los administradores de sistemas de la importancia de configurar correctamente sus servidores DNS, para evitar en la medida de lo posible la suplantación de identidad en el caso de correos electrónicos, y aprender mecanismos básicos de consulta de dichos registros.

La película tiene varios capítulos….

  1. Como se sabe que servidor gestiona un determinado dominio de correo (Registro MX)
  2. Cómo sabemos que el que lo envía (remitente), lo hace desde un servidor autorizado (Registro SPF)
  3. Qué más podemos hacer para mejorar la suplantación de identidad (Registro DKIM)
  4. Como actuar cuando se sospecha que el correo puede estar falsificado  (Registro DMARC)

Los proveedores de servicio y en última instancia los administradores de sistemas son los responsables de aplicar una correcta configuración en sus servidores DNS, en lo que respecta a la configuración de los servidores de correo.

La culpa siempre es del DNS, no os olvidéis

Para entender todo esto lo primordial es entender como se produce la entrega de un correo entre un determinado remitente y un destinatario. Lo que se conoce como Mail Delivery.

Mail DELIVERY (Registro MX)


Una vez hemos enviado el correo a nuestro servidor de correo, este debe entregarlo en el destinatario.

La pregunta es muy sencilla, ¿Cómo sabe nuestro servidor de correo a quien enviar dicho mensaje, en otras palabras que servidor de correo se encarga de gestionar la cuenta destina?

Imaginemos en nuestro caso que queremos enviar un correo a una cuenta de GMAIL, desde una cuenta de HOTMAIL.

El servidor de correo de HOTMAIL realizará una consultar DNS preguntando por el registro MX -Mail Exchange- del dominio destino, en nuestro caso GMAIL. Dicho registro apunta a o los servidor(es) destino encargado(s) de gestionar las cuentas de GMAL, y por lo tanto a quien se debe entregar el mensaje.

Podemos realizar una simple consulta con nslookup:

C:\Users>nslookup -type=mx gmail.com


Respuesta no autoritativa:
gmail.com MX preference = 30, mail exchanger = alt3.gmail-smtp-in.l.google.com
gmail.com MX preference = 20, mail exchanger = alt2.gmail-smtp-in.l.google.com
gmail.com MX preference = 5, mail exchanger = gmail-smtp-in.l.google.com
gmail.com MX preference = 10, mail exchanger = alt1.gmail-smtp-in.l.google.com
gmail.com MX preference = 40, mail exchanger = alt4.gmail-smtp-in.l.google.com

alt1.gmail-smtp-in.l.google.com internet address = 209.85.233.27
alt4.gmail-smtp-in.l.google.com internet address = 74.125.28.27
gmail-smtp-in.l.google.com internet address = 173.194.76.27

Como vemos la respuesta no es un único servidor, sino varios. GMAIL dispone de una granja de servidores que trabajan en paralelo para proporcionar redundancia si alguno de ellos cae. Los números 5, 10, 20, … indican la prioridad de dichos servidores a nivel de carga.

Como os he dicho, el objetivo de este post no es explicar el funcionamiento de DNS, sino aprender a comprobar que todo es ok.

Si por ejemplo hago la misma consulta sobre mi dominio mytcpip.com vemos el resultado:

C:\Users>nslookup -type=mx mytcpip.com


Respuesta no autoritativa:
mytcpip.com MX preference = 0, mail exchanger = mytcpip-com.mail.protection.outlook.com

En este caso podemos ver que el correo lo gestiono desde una plataforma de Microsoft.

Podemos hacer las mismas consultas desde plataformas Online como:

MXTOOLBOX

Caja de herramientas G Suite Dig

Vemos aquí un ejemplo con MXTOOLBOX:

mxtoolbox

Alguno podría pensar en el caso de  mytcpip.com que solo hay un servidor detras… al responder con una única línea. Eso no es cierto, si consultamos que IP’s hay detrás del servidor mytcpip-com.mail.protection.outlook.com veremos que aparecen al menos dos.

C:\Users>nslookup -type=a mytcpip-com.mail.protection.outlook.com


Respuesta no autoritativa:
Nombre: mytcpip-com.mail.protection.outlook.com
Addresses: 104.47.2.36
           104.47.0.36

Ya tenemos el primer paso, es decir, el servidor origen (HOTMAIL) ya sabe a quien debe entregar el mensaje (registro MX)

Sender Policy Framework (Registro SPF)


Ahora surge otra pregunta. ¿Cómo puede estar seguro el servidor destino (registro MX) que el correo origen (HOTMAIL) proviene de un servidor autorizado?

Está claro que montarse un servidor de correo en casa es algo sencillo. Cualquiera podría hacerlo y suplantar la identidad de Microsoft, enviado correos en su nombre, pero desde IP’s diferentes a la de sus servidores.

Aquí es donde entra el registro SPF. Dicho registro se encarga de definir los remitentes (servidores) autorizados a enviar correo en nombre de Microsoft en este caso, o del dominio que sea.

En este caso el servidor destino realizará una consulta DNS preguntando por el registro SPF del dominio origen (recordemos Microsoft).  Si las IP’s que obtenga no le cuadran con la IP desde donde le ha llegado el correo origen, hay bastantes posiblidades que este sea SPAM o suplantación de identidad…

Veamos con una simple consulta como podemos saber el registro SPF de HOTMAIL. SPF es un registro que guardamos dentro de un registro tipo TXT.

C:\Users>nslookup -type=txt hotmail.com


Respuesta no autoritativa:
hotmail.com text =

"google-site-verification=gqFmgDKSUd3XGU_AzWWdojRHtW3_66W_PC3oFvQVZEw"
hotmail.com text =

"v=spf1 ip4:157.55.9.128/25 include:spf.protection.outlook.com include:spf-a.outlook.com include:spf-b.outlook.com include:spf-a.hotmail.com include:_spf-ssg-b.microsoft.com include:_spf-ssg-c.microsoft.com ~all"

Todo lo que vemos en la línea «v=spf1 ip4:……..» marca las IP’s autorizadas para el envío de correo en nombre @hotmail.com

Podemos hacer la misma consulta desde entorno Web vía el enlace https://mxtoolbox.com/spf.aspx

spf_mxtoolbox

Curiosamente nos encontramos al final un  ~all.

~all sugiere desautorización a las máquinas que no encajen en lo autorizado explícitamente. Curioso!!!!!! Lo suyo a mi entender en poner un -all. Alguien de #microsoft puede contestar. Sugerencia no es prohibición….

Podemos consultar el de @hotmail.com por curiosidad:

C:\Users>nslookup -type=txt gmail.com


Respuesta no autoritativa:
gmail.com text =

"globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8="
gmail.com text =

"v=spf1 redirect=_spf.google.com"

C:\Users>nslookup -type=txt _spf.google.com


Respuesta no autoritativa:
_spf.google.com text =

"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

Curioso….. Queremos ser estrictos, e incluso Microsoft y Gmail recomiendan poner siempre -all y resulta que ellos ponen ~all

Os enseño un correo enviado a una cuenta mía de GMAIL desde HOTMAIL, donde mostrando el mensaje original podemos ver que el registro SPF está validado.

spfvalidado

Domain Keys Identified Mail (Registro DKIM)


DKIM es una técnica de autenticación de correo electrónico que le permite al receptor verificar que un correo electrónico fue enviado y autorizado por el propietario de ese dominio. Esto se hace dando al correo electrónico una firma digital. Esta firma DKIM es un encabezado que se agrega al mensaje y se asegura con cifrado.

Una vez que el receptor (o el sistema receptor) determina que un correo electrónico está firmado con una firma DKIM válida, es seguro que partes del correo electrónico entre las cuales el cuerpo del mensaje y los archivos adjuntos no se han modificado. Por lo general, las firmas DKIM no son visibles para los usuarios finales, la validación se realiza a nivel de servidor.

La implementación del estándar DKIM mejorará la capacidad de entrega del correo electrónico. Si usa el registro DKIM junto con DMARC (e incluso SPF), también puede proteger su dominio contra correos electrónicos maliciosos enviados en nombre de sus dominios. Sin embargo, en la práctica, estos objetivos se logran de manera más efectiva si usa el registro DKIM junto con DMARC.  Juntos proporcionan sinergia y el mejor resultado para la seguridad y la capacidad de entrega del correo electrónico.

Vemos aquí parte del mensaje donde podemos observar dkim=pass, dmarc=pass y la parte cifrada.

firmadkim

En el siguiente enlace encontrarás ayuda si tienes el correo en Office 365:

Usar DKIM para validar el correo electrónico saliente enviado desde su dominio personalizado en Office 365

Sin entrar en grandes alardes tecnológicos, os muestro a continuación el registro DKIM asociado al dominio @hotmail.com: . Todos tienen el formado selector1._domainkey.tudominio… En este caso selector1._domainkey.hotmail.com ( o selector 2 )

C:\Users>nslookup -type=txt selector1._domainkey.hotmail.com

Respuesta no autoritativa:
selector1._domainkey.hotmail.com canonical name = selector1._domainkey.outbound.protection.outlook.com
selector1._domainkey.outbound.protection.outlook.com text =

"v=DKIM1;k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvWyktrIL8DO/+UGvMbv7cPd/Xogpbs7pgVw8y9ldO6AAMmg8+ijENl/c7Fb1MfKM7uG3LMwAr0dVVKyM+mbkoX2k5L7lsROQr0Z9gGSpu7xrnZOa58+/pIhd2Xk/DFPpa5+TKbWodbsSZPRN8z0RY5x59jdzSclXlEyN9mEZdmOiKTsOP6A7vQxfSya9jg5"
"N81dfNNvP7HnWejMMsKyIMrXptxOhIBuEYH67JDe98QgX14oHvGM2Uz53if/SW8MF09rYh9sp4ZsaWLIg6T343JzlbtrsGRGCDJ9JPpxRWZimtz+Up/BlKzT6sCCrBihb/Bi3pZiEBB4Ui/vruL5RCQIDAQAB;n=2048,1452627113,1468351913"

En la respuesta podemos ver la clave pública en rsa que utilizará el destinatario para cotejar el mensaje original y asegurarse que es original y que no ha sido modificado.

Podemos validarlo también Online a través de DKim Record Check:

mytcpip_dkim_validator

 

Domain-based Message Authentification, Reporting and Conformance (Registro DMARC)


DMARC es un sistema de validación de correo electrónico diseñado para proteger el dominio de correo electrónico de su empresa para que no se utilice para suplantación de identidad, estafas de phishing y otros delitos cibernéticos. DMARC aprovecha las técnicas de autenticación de correo electrónico existentes SPF (Sender Policy Framework) DKIM (Domain Keys Identified Mail). DMARC agrega una función importante, informar. Cuando el propietario de un dominio publica un registro DMARC en su registro DNS, obtendrá información sobre quién envía el correo electrónico en nombre de su dominio. Esta información se puede utilizar para obtener información detallada sobre el canal de correo electrónico. Con esta información, el propietario de un dominio puede tener control sobre el correo electrónico enviado en su nombre. Puede usar DMARC para proteger sus dominios contra el abuso en phishing o ataques de suplantación de identidad.

Bien, estamos a punto de terminar nuestro particular ciclo de vida vital de la entrega de un correo electrónico. Tal  como os he puesto en el párrafo anterior, DMARC nos permitirá estar informados de quien envía correo en nuestro nombre (OJo puede generar mucho correo), o cómo debe actual el servidor remoto con nuestro correo de no cumplirse alguna de las validaciones SPF o DKIM. Con este registro le indicaremos que hacer y como reportar.

Os enseño a continuación la configuración de los registros DMARC de @hotmail.com y de @gmail.com:

C:\Users>nslookup -type=txt _dmarc.hotmail.com

Respuesta no autoritativa:
_dmarc.hotmail.com text =

"v=DMARC1; p=none; rua=mailto:d@rua.agari.com;ruf=mailto:d@ruf.agari.com;fo=1:s:d"

C:\Users>nslookup -type=txt _dmarc.gmail.com

Respuesta no autoritativa:
_dmarc.gmail.com text =

"v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"

Podéis consular vosotros mismos la sintaxis por Internet. Como curiosidad @hotmail.com reporta a la empresa AGARI , dedicada al tema de la protección de PHISHING.

Os dejo también algunos enlaces de utilidad para la gestión de todo esto.

  1. Analizador de DMARC
  2. DMARC Deployment tools ( muy útil )
  3. Comprobar el grado de SPAM de tus correos (https://www.mail-tester.com/)

Como os he comentado al inicio, esto es una pequeña guía para entender un poco más este tema. Si alguno necesita soporte y ayuda con el tema, recordar que me dedico a la consultoría. Puedo ayudaros con el tema y configurar adecuadamente vuestros dominios. Podéis poneros en contacto conmigo vía correo electrónico:

Nos vemos en el siguiente POST.

#yomequedoencasa

 

You may also like

Leave a Comment