Check Azul en Gmail: Cómo conseguir que tus mensajes estén verificados y reducir el riesgo de ser Spam y el Phishing

Si eres un usuario de MyPublicInbox, habrás visto que las alertas y mensajes de comunicación, cuando te llegan a tu cuenta de Gmail, llegan con el un check azul verificado que identifica que el mensaje llega realmente de MyPublicInbox. Para ello, el equipo técnico ha implementado el estándar BIMI, que permite registrar la marca y garantizar que se han configurado correctamente los servidores que envían correo legítimo de de MyPublicInbox.

Figura 1: Check Azul en Gmail: Cómo conseguir que tus mensajes

estén verificados y reducir el riesgo de ser Spam y el Phishing

He hablado mucho de seguridad en el correo electrónico, ya que este caos maravilloso que es el e-mail hace que tenga muchas "goteras" por las que pasa el malware, el cibercrimen, el phishing, el spam, el spoofing, y muchas otras cosas. No es casual que por eso creáramos MyPublicInbox. Pero hoy quería contaros cómo es el proceso de poner ese Check Azul en los mensajes de correo electrónico legítimos de tu empresa cuando llegan a Gmail y servidores de correo que implementan el estándar BIMI.

Figura 2: Mensaje verificado de MyPublicInbox en Gmail

El proceso implica, primero, hacer los BASICS, y estos son los que ya conocéis de muchos artículos pasados. Hay que configurar correctamente los registros SPF, DKIM y DMARC, para conseguir pasar a la siguiente fase.

Figura 3: Configuración BASIC para BIMI

SPF o Sender Policy Framework le indica al servidor de correo electrónico del destinatario qué debe de hacer cuando reciba un mensaje que venga de una dirección IP de un servidor de correo electrónico saliente que no esté en la lista de los autorizados. Esto es, subir el SCL (Spam Confidence Level), descartarlo o darlo por bueno. Y el registro es de tipo TXT que tienes que configurar en DNS.

Figura 4: Registro SPF de MyPublicInbox.com

DKIM (Domain Key Identified Mail) es un sistema por el cual el correo electrónico, cuando sale del servidor de correo saliente, es firmado por una clave que está en el DNS de la organización del remitente. Así, cuando llega el mensaje, en el código del mensaje se puede ver qué clave de firma se utilizó.

Figura 5: Firma DKIM en código de mensaje recibido.

Se usa la calve domabs

Y por supuesto, se debe poder verificar esa clave en el registro DKIM correspondiente del servidor DNS de la organización, así que hay que configurar correctamente DKIM siguiente las especificaciones del servidor de correo saliente que estés utilizando.

Figura 6: Clave domabs de DKIM en DNS de MyPublicInbox

Por último, hay que configurar DMARC (Domain-based Message Authentication, Reporting & Conformance) que implica una coordinación de qué hacer con el mensaje en caso de diferentes situaciones con SPF y DKIM. Es decir, es un proceso de validación en cadena donde primero se obtiene el resultado de la validación SPF, luego la validación DKIM y en función de eso, se aplica la política DMARC. Lo expliqué en el artículo que le dediqué al registro DMARC.

Figura 7: Registro DMARC en DNS de MyPublicInbox

Si quieres que tu organización tenga el "Check Azul" de Gmail, tienes que configurar correctamente DMARC también en tus servicios DNS, para que se pueda comprobar correctamente. Y si es así, cuando envíes un correo electrónico a un destinatario de Gmail, en el código fuente del mensaje obtendrás un resultado similar a este.

Figura 8: SPF, DKIM y DMARC pasados. Vamos a por el BIMI

Ahora tienes que ir a la siguiente fase, que es registrar y certificar el logo de tu marca. Para ello, debes primero subir el formato gráfico del logo de tu marca que tienes registrado en el registro de marcas, así que si no has registrado tu marca, debes comenzar por ese paso. Luego, registra y sube el SVG de tu marca, como se explica en este artículo.

Figura 9: Sube el SVG del Logo de tu marca

Pero aún no has acabado, debes conseguir el certificado del registro de tu marca, que permita validar digitalmente que tu imagen está registrada a tu nombre. El VMC (Verified Mark Certificate), que puedes conseguir con el proceso que te explica este artículo.

Figura 10: Consigue el VMC

Perfecto, si ya tienes todo lo anterior, el siguiente paso es hacer el registro BIMI en tu DNS, que debe apuntar al SVG de tu marca certificada en el VMC, así que si intentas algún cambio, te van a denegar el proceso, porque siempre es un double-check.

Figura 11: Añadir registro BIMI al dominio

Con todo ello, y peleándote un poco con los equipos de soporte de Gmail, conseguirás el Check Azul para los correos electrónicos que envías desde tu empresa y acaban en buzones de Gmail y otros proveedores que soportan el estándar BIMI. 

Figura 12: Registro BIMI en DNS de MyPublicInbox

Si no lo tienes en tu empresa, ya tienes algo que hacer. Y si necesitas ayuda, contacta con nosotros que te podemos echar un cable, y así conseguirás el Verified Azul de Gmail para tus correos. Contacta con Leire en MyPublicInbox y te ayudamos con todo el proceso.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

WhatsApp y la desactivación de cuentas con un mensaje de e-mail

Hace un par de días publiqué en el blog el artículo de "WhatsApp: Cómo un atacante puede bloquear tu cuenta sin que la puedas desbloquear" escrito por Luis Márquez Carpintero y Ernesto Canales Pereña en el que se "weaponizan" dos características de seguridad de WhatsApp, para convertirlo en un ataque para la personas.

Figura 1: WhatsApp y la desactivación de cuentas con un mensaje de e-mail

Esto no es la primera que sucede, y es algo bastante más habitual de lo que las personas se pueden imaginar. En este tipo de escenarios, una medida de seguridad mal diseñada acaba convirtiéndose en un problema - en este caso de disponibilidad del servicio - para un usuario. Si quieres ver muchos ejemplos de esto, di una conferencia el año pasado sobre justo este tema que se llamaba "Weaponizing Features", donde explicaba muchos ejemplos de estas mismas características.

Figura 2: Conferencia de Weaponizing Features

En el caso concreto del bloqueo de la cuenta de WhatsApp, lo que hacen los investigadores es explotar o "weaponizar" de dos medidas de seguridad. Por un lado la de medida de seguridad que evita los ataques de fuerza bruta o adivinación de los códigos de activación de enviados por SMS, con una protección temporal para hacer inviable prácticamente en tiempo útil un ataque de esas características, y una segunda medida de protección - y esta es la más curiosa - por la que un usuario (cualquier) puede desactivar cualquier cuenta de WhatsApp, sea la suya o no, con un simple mensaje de correo electrónico.

Figura 3: Luis Márquez Carpintero, uno de los investigadores de este bug.

La explicación de cómo funciona este correo electrónico para desactivar una cuenta está en la web de WhtasApp, y existe para proteger la privacidad de un terminal ante robos o pérdidas de dirección de e-mail. Basta con que se envíe un mensaje de e-mail al la dirección de WhatsApp, y listo, la cuenta se desactiva.

La explicación de esta medida es fácil. Un usuario sufre el robo de su teléfono desbloqueado, y lo que debe hacer automáticamente es llamar para bloquear la SIM, urgentemente, y evitar así que se reciban llamadas o códigos de verificación por SMS, y luego pedir un cierre de sesión siguiendo el mecanismo antes explicado.

Figura 4: Cómo enviar el e-mail de desactivación de cuenta en WhatsApp

Lo que hace endiabladamente sutil y peligroso es esa regla de "usabilidad", por la que desde cualquier dirección de e-mail se pueda bloquear cualquier sesión en cualquier número de teléfono registrado en WhatsApp. Es verdad que, una dirección de e-mail solo puede usare una vez y para un solo número de teléfono, lo cual es un acierto como forma de mitigar un poco el ataque descrito en el artículo de hace dos días, con lo que una persona que quiera estar cerrando sesiones de WhatsApp debe estar creando mensajes de correo electrónico nuevos cada vez.

Figura 5: Sesión de WhatsApp cerrada por un e-mail

Por supuesto, esta medida es también fácilmente saltable para un atacante con hacer un poco de spoofing de e-mail, suplantando en cada petición una dirección de correo diferente, lo que la hace un poco inútil. Y es algo curioso, pues de nuevo, el correo electrónico - ese caos maravilloso que digo yo - se ha convertido no en un sistema de comunicación sino en algo más, que como ya explicaba en el artículo de "El e-mail ha muerto. ¡Larga vida al e-mail!", le hemos ido dando atribuciones más allá de la de ser un buzón de comunicación.

Llegados a este punto, lo que pasaba por mi cabeza durante el día de ayer, era... ¿cómo puede WhatsApp mitigar este ataque de una manera más racional? Pues usando características extras de protección a la cuenta y mitigación de weaponización.

Por ejemplo, si el usuario tiene un 2FA de WhatsApp asociado a un e-mail, que solo pueda ser desactivada la cuenta de esa dirección de e-mail. Esto dificultaría al atacante la explotación porque tendría que conocer y adivinar cuál es la dirección de e-mail configurada como 2FA. Cuando se configura ese 2FA ya se asocia, implícitamente, la seguridad de la cuenta a la seguridad del e-mail, y además es una solución bastante curiosa, porque realmente no es demasiado práctica si el e-mail está protegido por un 2FA basado en SMS, como os expliqué en el artículo de "WhatsApp y la paradoja de la SIM como Verificación en 1 paso", pero al menos sirve para eso, para asociar un e-mail a un cuenta de WhatsApp, que en este caso puede tener mucho sentido.

Figura 6: Configurar correo electrónico para recuperar el PIN
del 2FA en WhatsApp

Luego, se pueden buscar otras soluciones de mitigación, como por ejemplo hacer un desafío al e-mail para garantizar que no es un correo electrónico suplantado. Para ello, el proceso de desactivación debería ser en dos pasos. Paso uno, se pide la desactivación de la cuenta. WhatsApp genera un OTP y se lo devuelve por e-mail a la dirección de correo electrónico que pide la petición de desactivación. El solicitante de la desactivación envía la confirmación de la desativación con el OTP, para así garantizar que ese correo existe y no está suplantado. Esto reduciría la facilidad de "weaponización" de este ataque.

Y por supuesto, buscar otras soluciones por las que la re-activación no se pueda ver bloqueada por un esquema similar, dando al usuario alguna otra forma de reactivar la cuenta y evitar el bloqueo de los códigos de verificación de forma tan sencilla y automatizable. 

En cualquier caso, este es un ejemplo de una medida de seguridad que se convierte en un problema para la vida del usuario, no solo para su usabilidad, sino también para la disponibilidad, por lo que debe servirnos como ejemplo y muestra del cuidado que debemos tener en cada implementación de una nueva medida de seguridad, que nuestro objetivo es hacerle la vida más segura y fácil, y no nada de lo contrario.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso) (Consigue 100 Tempos gratis con ESET)

Chema Alonso en MyPublicInbox

¿Cómo están las protecciones contra ataques de phishing en las entidades bancarias latinoamericanas?

Los cibercriminales usan las técnicas que más beneficios económicos les generen, sin importar que esta técnica sea antigua. Siempre que siga siendo efectiva será usada para obtener sus objetivos. Este es el caso de los ataques de phishing a los bancos, una técnica muy usual para engañar a los usuarios tanto en ataques de Spam Phishing (masivos y a día de hoy altamente detectados) o de Spear Phishing (dirigidos y mucho más peligrosos).

Para que sea más efectiva esta vieja técnica, los delincuentes utilizan otro mecanismo también con mucha antigüedad, que es la suplantación o "Spoofing" de direcciones de correo electrónico, con el cual los cibercriminales se hacen pasar por entidades o empresas reconocidas, principalmente del sector bancario.

Figura 1: ¿Cómo están las protecciones contra ataques de
phishing en las entidades bancarias latinoamericanas?

Para atenuar el impacto de estas técnicas, desde hace mucho tiempo se han venido desarrollando tecnologías de protección para detectar la suplantación de direcciones de e-mail, como los los mecanismos SPF (Sender Policy Framewok), SenderID, DKIM (Domain Keys Identified Mail) o DMARC (Domain-based Message Authentication, Reporting & Conformance).

Estas medidas de atenuación deben ser configuradas por todas las empresas, pero especialmente por las entidades bancarias, quienes son las principales víctimas de la suplantación de sus direcciones de correo electrónico.

Un estudio con la banca en Latinoamérica

Como estos ataques siguen generando impactos económicos y reputacionales muy grandes uno espera que todos estos controles estén correcta y estrictamente configurados. Para comprobar si esto era así, me decidí a hacer un análisis de estas medidas en las 25 principales entidades financieras de Latinoamérica, que por nacionalidad son:

Figura: Distribución por países de las organizaciones en el estudio

El análisis no es muy complicado ya que basta con mirar la configuración de los registros adecuados en el DNS, y para automatizarlo utilicé la herramienta de SpoofCheck, que permite validar la posibilidad de suplantar estos dominios de correo. Los resultados no fueron buenos, ya que como se puede ver desafortunadamente estas medidas no están implementadas de forma adecuada en la mayoría de los casos, pues solo 2 entidades tienen correctamente implementadas las medidas de SPF y DMARC.

Figura: Resutado de las pruebas con SpoofCheck en las 25 entidades

Al entrar al detalle de las configuraciones, es posible darse cuenta que la mayoría de las entidades sí configuran las medidas de mitigación que técnicamente se pueden implementar, pero no realizan un proceso de fortificación para hacer que estás sean robustas y que garanticen un control efectivo.

Como se puede ver en la gráfica solo existen 2 entidades que tienen ambos controles configurados de forma robusta, pero es más crítico que existen 3 entidades que no tienen implementado ninguno de los controles. Esto lo que evidencia que la implementación de los controles en el DNS no son correctamente configurados, exponiendo a los usuarios a ser víctimas de una suplantación.

Figura: Nivel de seguridad brindado por las medidas SPF y DMARC

En la Figura 4 se puede apreciar que los controles se marcan con una implementación débil, por lo que se revisan las sentencias en el DNS de cada uno de los dominios para sacar la característica que genera esta calificación en cada una de las herramientas.

En el caso de SPF, que es la medida de seguridad más veces configurada, se permite registrar dominios y direcciones IP autorizados para ser emitir correos electrónicos a nombre del dominio de la entidad y al final de la sentencia se indica la severidad con la que se debe tratar a los correos que no cumplan las anteriores características de origen descritas para ser rechazados.

Figura: Ejemplo de configuración de un registro SPF

Este mensaje final tiene cuatro niveles de calificación, desde que cualquiera pueda enviar hasta totalmente restrictiva, por lo que al analizar las sentencias de DNS configuradas por las entidades financieras se detecta que la mayoría tienen la configuración en lo que se denomina “softfail” que se interpreta usualmente como que es posible que ese origen sea un remitente válido.

La configuración de DMARC es mucho menos usada y solo 2 entidades la configuraron de forma que garantiza que la política aplicada por los receptores cuando un mensaje no contenga los datos de autenticación, reporte y conformidad, sea rechazada o puesta en cuarentena. Esta política es la que se configura en la sentencia de DNS donde se configura el DMARC.

Figura: Flujo de funcionamiento de DMARC

Al revisar la configuración en los dominios de las entidades financieras, se encuentra que solo dos entidades tienen configurada la política que implica rechazo o cuarentena y en 10 entidades la política esta marcada como “none” lo que permite que el correo fraudulento pase sin que se le aplique una restricción.

Reflexiones finales

En conclusión, las principales entidades financieras de Latinoamérica tienen controles implementados para evitar que sus clientes sean víctimas de ciberdelincuentes que usando el correo electrónico, sin embargo, la efectividad de estos controles no es todo lo robusta que podría ser debido a que usan configuraciones que no garantizan la implementación de políticas de restricción para los servidores que reciben correos fraudulentos. Cuanto mejor estén las medidas de seguridad, más alto será el PCL (Phishing Confidence Level) de los mensajes de correo y más fácil será detectarlos en los sistemas de seguridad de los servidores de correo electrónico.

Figura: Valores PCL utilizados en Outllook para detectar Spam/Spear Phishing

En muchos clientes, con nuestro sistema de pentesting persistente, detectamos la misma situación, y esto suele ser debido a una mala gestión de los canales de comunicación vía e-mail de la empresa. Es decir, se suelen dar casos en los que las newsletters, las listas de distribución de e-mails o campañas concretas de comunicación vía correo electrónico, se delegan en terceras empresas, que envían mensajes desde servidores no corporativos, que adolecen de medidas de seguridad similares, lo que hace al final que haya que rebajar la configuración global de seguridad.

Y esto genera muchos problemas en las empresas que se preguntan después ¿por qué mi correo llega como spam? Una configuración robusta y segura de las medidas de seguridad no solo ayuda a mitigar el Spam Phishing, el Spear Phishing y el Spoofing, sino que además reduce los SCL (Spam Confidence Level) de los mensajes que son enviados desde la compañía lo que ayuda a tener un mejor negocio electrónico.

Por último, hay que recalcar que estos mecanismos de seguridad no son nada más que una pequeña pieza dentro de la estrategia de seguridad contra el fraude y los ataques de phishing dentro de una organización financiera, ya que se utilizan muchos otros sistemas de vigilancia digital, alerta y detección temprana desde los SOCs y controles en el uso de credenciales robadas, así que no se puede tomar estas configuraciones como una medida final de seguridad global de la entidad, aunque su configuración robusta ayuda, como ya se ha dicho, a mejorar las protecciones globales.

Autor: Diego Samuel Espitia Montenegro
Chief Security Ambassador – CSA (Colombia) @ElevenPaths

Los registros DNS que delatan a Office365 y Gmail

Una de las partes que se revisa en detalle cuando se hace un pentesting a una compañía es el servidor DNS. Los registros que allí se encuentran pueden dar mucha información. Desde conocer la infraestructura del Active Directory - buscando los registros que genera este servicio - o la infraestructura de la red - buscando los registros PTR, SRV, WPAD o el Primary Name Server -, hasta llegar a conocer información sobre la versión del DNS, el software sobre el que está construido el servicio, dónde navegan sus usuarios, el software de los clientes - inluidos los antivirus -,  etcétera. Y entre otras, las opciones de seguridad en los servicios de correo electrónico.

Figura 1: Los registros DNS que delatan a Office365 & Gmail

Es en este último servicio de correo electrónico, donde más información se puede obtener sobre la seguridad del mismo. Desde información de la infraestructura con los servicios MX y SPF, hasta las políticas antispoofing y antispam con la información de las políticas en las configuraciones DKIM, SPF o SenderID o DMARC (y en el futuro con los registros de SMTP STS). Todos ellos permiten saber a un atacante si va a poder realizar con facilidad o dificultad un ataque de Spear Phishing a la organización.

Los registros que delatan a Microsoft Office 365

A todos ellos, hay que añadir un par de registros DNS que pueden ayudar a un atacante a reconcoer que la empresa está utilizando Microsoft Office365 o Windows Live Mail. Los registros son de tipo TXT y son necesarios para validar el dominio de la organización.

Figura 2: Registro de validación de Office365

Esta validación es obligada por Microsoft cuando contratas un dominio nuevo personalizado para Office365, para evitar que nadie suplante el dominio y basta con hacer una búsqueda de registros TXT en el dominio objetivo para ver si están allí. Son los que comienzan por "MS=XXXXXXXX"

Figura 3: Registro de validación de microsoft

Esta es la forma en la que Microsoft valida el dominio. En el caso de que sea un dominio del antiguo Windows Live Mail, el registro tiene un aspecto como "v=msv1 t=XXXXXXXXX", pero también indica la existencia del backend de Microsoft. 

Los registros que delatan a Gmail

Para detectar Gmail, basta con mirar el DNS y fijarse en dos registros TXT. El primero el de "Google-Site-Verification", que indica que se ha validado el dominio con Google - pero no es concluyente porque se puede validar el domino sin tene el correo en Gmail - y el registro SPF, donde debe aparecer incluido el valor _spf.google.com como uno de los enviadores de correo autorizados, ya que ese registro de Google es el que incluye las direcciones IP utilizadas por Gmail para enviar los mensajes de e-mail.

Figura 4: Ejemplo con BBVA, cliente reconocido de Gmail

Por supuesto, que estén los registros DNS ahí puede no significar nada si el administrador del servidor DNS los dejó allí olvidados después de validar los dominios o configurar el servicio, pero es un indicio más que útil en la mayoría de los casos. ¿Conoces algún otro registro DNS de validación que obligue a crear algún sistema en los DNS de las organizaciones?

Conocer que una organización tiene como plataforma Office365 o Gmail es útil para aquellos ataques de Spear Apps que se quieran realizar contra una organización, como ya os contamos en la serie de artículos de SAPPO: Spear Apps to stealth OAuths Tokens. Es necesario, ya que dependiendo de cuál sea el ID Provider, la app maliciosa y la API que habrá que utilizar será distinta y, con solo mirar estos registros se puede saber qué utiliza la organización.

Saludos Malignos!

Hacer e-mail spoofing con SMTP sobre SSL/TLS en Gmail

Hace unos días os hablé del candado rojo que Gmail añade ahora a los mensajes de correo electrónico que han sido recibidos sin utilizar cifrado. Por supuesto, esto no tiene absolutamente nada que ver con la suplantación de identidad, donde ya sabéis que existen otras soluciones para detectar los mensajes con e-mail spoofing. Algunas de ellas son tecnologías de las que ya he hablado mucho en el pasado como los filtros SPF, Sender ID, o el uso de DKIM para garantizar el servidor de origen del mensaje.

Figura 1: Hacer e-mail spoofing con SMTP sobre SSL/TLS en Gmail

Google tiene ya en producción el uso de DKIM para algunos servicios como EBay o Paypal que hacen uso de ellos y que cuando el mensaje viene correctamente firmado desde uno de los servidores autorizados, entonces se muestra la famosa llavecita de DKIM.

Figura 2: Correo de Ebay firmado por DKIM

En el caso del candado rojo, tiene como significado únicamente que es un mensaje que simplemente se ha enviado sin cifrar, pero que se envíe por un canal seguro SSL o TLS no garantiza para nada que el mensaje sea original, por lo que si se hace un e-mail spoofing con comandos SMTP que salte los filtros SPF, o las tecnologías de scoring antispam, entonces el mensaje aparecerá sin el candado rojo como siempre ha sido.

Figura 3: Un mensaje no cifrado que aparece con el candado rojo

Para hacerlo, basta con elegir un servidor de correo entrante de Gmail para enviar el mensaje falso. En este caso he elegido gmail.smtp-in.l.google.com.

Figura 4: Servidores para intercambio de correo en Gmail

Después se tira con OpenSSL una conexión cifrada, en este caso por el puerto 25. Puede que suene raro que se use una conexión cifrada SSL por el mismo puerto que se usa para el tráfico no cifrado, pero como ya os puse en el otro artículo, Gmail reconoce en la pasarela de entrada la conexión y la dirige hacia el servicio adecuado.

Figura 5: Estableciendo la conexión SSL con OpenSSL por el puerto 25

Para tirar la conexión, utilizamos el cliente de OpenSSL con los parámetros que aparecen en la captura superior, y se establece el túnel cifrado por el puerto especificado.

Figura 6: Conexión SMTP sobre SSL establecida

Una vez creada la conexión, el resto es como siempre, escribir el mensaje con el protocolo SMTP como si fuéramos un servidor de correo saliente que envía mensajes a un destinatario de Gmail.

Figura 7: Correo enviado desde una cuenta inexistente

Y si todo ha ido bien, entonces el mensaje de correo llegará a la cuenta de Gmail del destinatario sin que aparezca el candado rojo. 

Figura 8: Mensaje recibido con e-mail spoofing sin candado rojo

No es nada rocket-science, simplemente quería dejaros una nota de cómo se puede seguir haciendo e-mail spoofing usando los túneles SSL/TLS y así evitar el candado rojo que pueda hacer sospechar más al destinatario.

Saludos Malignos!