Como ya vimos en nuestro blog, una capa de protección muy importante contra la suplantación de identidad viene dada por los protocolos SPF, DKIM y DMARC.
Entonces, cuando recibimos un correo electrónico, el resultado de la evaluación de estos protocolos va a determinar en gran medida si nuestro cliente de correo mostrará el correo recibido en nuestra bandeja de entrada, en SPAM o directamente será rechazado.
Todo esto en la teoría. En la práctica ya sabemos que las cosas no son tan sencillas.
En este post vamos a ver una manera (de varias) para que estos protocolos sean bypasseados.
Escenario inicial
Este problema ocurre puntualmente cuando hay algún reenvío de por medio. Reenvío que para el usuario final de nuestra organización seguramente es transparente, no sabe que existe.
Veamos un caso muy común para entenderlo mejor: si usamos Google Workspace (Gmail corporativo) es posible que tengamos una dirección de correo como ventas@dominio.com configurada para reenviar todos los correos entrantes a la cuenta corporativa de cada empleado del área de ventas:
En este caso, Juan y María reciben los correos enviados al email de ventas en su casilla corporativa personal.
Envío de un correo de suplantación de identidad
Dentro de este escenario, supongamos ahora el envío de un correo de suplantación de identidad a ventas@dominio.com. Una vez realizado el envío, podemos evaluar si el correo es recibido exitosamente en esta casilla. En nuestra prueba, el correo va directo a la carpeta de SPAM.
A continuación podemos ver el header correspondiente a la validación SPF resultante de este envío:
Received-SPF: fail (google.com: domain of [dominio-suplantado] does not designate [IP del remitente] as permitted sender) client-ip=[IP del remitente];
Como podemos ver, el resultado es el esperado. La IP del remitente no está autorizada a enviar correos utilizando el dominio suplantado.
Algo similar ocurre con DKIM y con DMARC.
En casos como este, si alguien ingresa a la bandeja de entrada de ventas@dominio.com seguramente encuentre el correo enviado en SPAM, o bien puede que directamente no esté.
Esto depende en gran medida de la política de DMARC que tenga el dominio suplantado: quarantine o reject.
Bandeja de entrada de los usuarios: Resultado esperado
Ahora bien, ¿qué sucede si los empleados del área de Ventas ingresan a su bandeja de entrada? Aquí es donde ocurre la magia.
Supongamos la casilla de correos de maria.ventas@dominio.com. Como dijimos, María recibe los correos que son enviados a ventas@dominio.com.
Por lo general, uno supone lo siguiente: María va a recibir el correo en su bandeja de SPAM, o bien no lo va a recibir. Esto es así ya que las validaciones de SPF, DKIM y DMARC no son satisfactorias.
Bandeja de entrada de los usuarios: Resultado real
En la práctica, sucede lo siguiente: María recibe el correo electrónico en su bandeja de entrada con las validaciones de SPF, DKIM y DMARC satisfactorias.
¿Qué pasó aquí? Analicemos el header correspondiente a la validación SPF en el correo que recibe María.
Received-SPF: pass (google.com: domain of ventas+bncbaabbleyu2pamgqet6ctaaa@dominio.com designates 209.85.220.69 as permitted sender) client-ip=209.85.220.69;
Como podemos ver, el cliente de correo de María recibe el correo desde ventas@dominio.com, correo enviado desde una IP de Google (209.85.220.69). Como dominio.com utiliza Gmail como servidor corporativo, autoriza a las IP de Google a hacer envíos con ese dominio.
Algo similar ocurre con DKIM y con DMARC.
Un detalle a tener en cuenta: En el correo recibido por María, podemos ver el header donde la validación de SPF falla:
Received-SPF: fail (google.com: domain of [dominio-suplantado] does not designate [IP del remitente] as permitted sender) client-ip=[IP del remitente];
Pero más arriba, encontramos el nuevo, donde la validación es correcta. Y el cliente de correo parece estar mirando únicamente la última validación SPF sin tener en cuenta la primera.
Por eso, en el reenvío, se termina pisando la validación de SPF, DKIM y DMARC original, quedando en primer lugar y con más relevancia el resultado del último reenvío.
Otros escenarios reales
Además del escenario descrito, donde tenemos una cuenta genérica que reenvía a cuentas particulares, este problema puede ocurrir también con:
- Alias de correos electrónicos: Se hace un reenvío del correo enviado al alias hacia la dirección de correo electrónico principal del usuario.
- Grupos de Google: En este caso los usuarios del grupo pueden recibir los correos enviados a éste, ocurriendo nuevamente el problema descrito en este post.
- Redirecciones configuradas en nuestras cuentas: Por ejemplo, cuando configuramos una cuenta personal que ya no queremos utilizar para que reenvíe los correos recibidos hacia una nueva cuenta.
Controles técnicos para prevenir este problema
Luego de realizar varias pruebas, obtuvimos un resultado relativamente satisfactorio cuando el dominio suplantado tiene un registro DMARC válido con política reject.
En este caso parece que el reenvío a los usuarios particulares no ocurre, ya que el correo nunca llega a la bandeja de entrada del primer destinatario.
De todas formas, la presencia de este registro y su configuración únicamente está bajo nuestro control en los dominios de nuestra organización. Esto significa que estaríamos protegidos de este proceso únicamente si intentan suplantar a nuestra propia organización. O bien, si intentan suplantar un dominio que no cuente con el DMARC configurado de esta manera.
Además, en reiteradas ocasiones hemos visto diferencias en la interpretación de estos registros entre distintos proveedores de servicios de correo electrónico, e incluso dentro del mismo proveedor.
Como si esto fuera poco, muchas organizaciones (entre las cuales nos incluimos) tenemos problemas para utilizar una política reject, ya que muchos clientes de correo de nuestros clientes o partners realizan interpretaciones particulares de este registro y dejan de recibir nuestros correos.
Para casos más particulares, como por ejemplo el de los grupos de Google, pueden existir configuraciones concretas que puedan ayudar. Por ejemplo en Google existe una configuración para que los mensajes catalogados como SPAM de un grupo no se reenvíen a sus miembros.
Este control no viene activado por defecto y en la práctica puede resultar inapropiado, ya que por ejemplo en un grupo de ventas o recursos humanos pueden llegar frecuentemente correos legítimos que por alguna “inteligencia artificial“ se termine marcando como no deseado.
Todos estos correos nunca verían la bandeja de entrada ni la de correo no deseado de los miembros del grupo y directamente se perderían.
Caso real en SMARTFENSE
En nuestra organización nos ocurrió este caso con un grupo de Google. Por los motivos mencionados arriba, no nos resultan prácticos los controles técnicos que podrían disminuir este riesgo.
Lo que sucedió fue que suplantaron la identidad de nuestra propia organización y enviaron un correo a uno de nuestros grupos, el cual fue recibido en regla por todos los miembros del mismo.
Uno de ellos reportó el correo al área correspondiente y el ciberataque finalmente no tuvo consecuencias.
A partir del análisis realizado, en SMARTFENSE determinamos que la medida más recomendada para disminuir el riesgo de un ataque de ingeniería social que siga el proceso descripto en este post es concientizar a los usuarios de nuestra organización que reciben correos reenviados desde otra cuenta para que conozcan y reporten casos similares al analizado.
Deja un comentario