Enviar a un "amigo" [I de III]

***************************************************************************************************
- Enviar a un "amigo" [I de III]
- Enviar a un "amigo" [II de III]
- Enviar a un "amigo" [III de III]
***************************************************************************************************

Uno de los servicios que más curiosidad me generan siempre cuando hay una aplicación web es el de “Enviar a un amigo”. Éste es una opción que se ofrece en muchas aplicaciones para enviar por correo un link o una noticia de una web. La idea es simplificar al usuario la labor de copiar el link en un correo electrónico para conseguir mayor difusión de la noticia o ganar audiencia.

Sin embargo, en contrapartida, programar estos servicios de una manera descuidada puede generar algún que otro problema de seguridad. Vamos a ver qué se puede hacer y qué puede suceder con un sistema de estas características mal diseñado en la web.

1.- Envío de correos anónimos

Una de las características que se han podido explotar con el correo electrónico ha sido enviar mensajes con la cuenta de remitente spoofeada. Para ello bastaba con encontrar un servidor que permitiera realizar relay desde el exterior o utilizar con servidor de correo saliente el servidor de correo entrante del destinatario.
Encontrar un servidor de correo con relay permitido para el exterior es cada día más complicado debido al abusivo uso que de ellos han realizado los spammers. Esto hace que en el momento que se descubre uno y aparece en alguna lista de servidores con relay abierto acaben enseguida en listas de revocación RBLs.

La segunda acción aun sigue funcionando aunque para evitarlo se crearon los registros SPF (Sender Policy Framework). Al principio, para detectar un mail enviado con una dirección spoofeada se utilizaba el filtro de Reverse DNS en el que se buscaba que la IP de la que procedía el mail del remitente @dominioderemitente fuera una de las IP registradas como intercambiadores de correo en el MX.

Como algunas empresas metían el correo por direcciones distintas a las usadas para sacarlos se creó el registro SPF en los DNS para marcar las IPs por las que sale el correo de una empresa. Con esta IP una empresa marca porque IPs sale el correo legítimo. Si un correo de un dominio es recibido desde una IP no legítima indica que el remitente ha sido spoofeado.

Sin embargo, el filtro de Reverse DNS puede dar un falso positivo si el correo sale por un IP distinta a la que entra y en el segundo caso nos encontramos que no todas las empresas marcan por donde sale su correo, así que el uso de estos filtros no es global y si quieres seguir recibir correo legítimo de todo el mundo tienes que ser “flexible” con ellos.

Lo que se utiliza hoy en día son filtros heurísticos que tienen en cuenta la información de los filtros Reverse DNS y SPF, además de otros como la composición del mensaje o las palabras que componen el texto para generar un índice de probabilidad de que sea Spam llamado SCL (Spam Confidence Level). Ese número va entre 0 y 9 y el administrador decide los rangos para que un correo sea spam y no llegue al usuario, sea marcado como sospechoso y llegue a la carpeta de spam del usuario o sea tomado como legítimo.

Esto hace que la opción de utilizar el servidor de correo saliente del destinatario suela seguir funcionando, pero al final queda la IP del emisario en los logs del servidor entrante. Si se desea ocultar la IP ya hay que intentar utilizar un winsock/sock proxy u otro servicio de anonimato.

En algunos servicios de “Enviar a un amigo” se encuentran, vía web, sistemas para enviar correos spoofeados de forma sencilla y cómoda. En este ejemplo, se puede observar como todos los atributos de un correo pueden ser modificados.

Enviar a un amigo en una web
Como se puede ver en la imagen superior, el correo está siendo enviado desde una supuesta cuenta de gmail. Es fácilmente comprobable que esta dirección está spoofeada pues, como se puede ver en la imagen siguiente, el registro spf de gmail.com redirige a _spf.google.com y las direcciones IP válidas no incluyen la dirección que va a ser utilizada para enviar este correo.


Registros spf de Google y Gmail
Sin embargo Gmail no muestra ninguna alerta de email spoofeada, si el correo llega con un SCL correcto, el mail entra dentro. Es decir, Gmail tiene creado el registro SPF para aquellas empresas que quieran comprobar la procedencia de los correos legítimos de gmail, pero Gmail no lo utiliza. Curioso.


Correo spoofeado en gmail
Cuando se envía este correo, en sistemas como Hotmail, cuando el filtro SPF no puede ser comprobado, aparece una advertencia del correo que avisa de este hecho, pero el mail llega perfectamente si el SCL resultante del mismo entra en los márgenes establecidos en la configuración.


Hotmail muestra una alerta de comprobación SPF
En sistemas como Exchange, con el IMF2 (Intelligence Message Filter), el correo no muestra ninguna alerta si el SCL es correcto, como se puede apreciar.


Visualización OWA de correo spoofeado
En Exchange Server 2003 SP2 y Exchange Server 2007 se puede activar la comprobación del SPF como un filtro más e incluso bloquear los correos que vengan de dominios de los que no puede comprobarse la procedencia correcta.


El filtro Sender ID activa comprobación SPF
Si quieres crear un registro SPF para tu dominio, puedes utilizar el asistente de esta página.

***************************************************************************************************
- Enviar a un "amigo" [I de III]
- Enviar a un "amigo" [II de III]
- Enviar a un "amigo" [III de III]
***************************************************************************************************