WindosLive.com ~all

Tiempo ha, cuando empezamos a revisar un poco cuales eran los mecanismos de seguridad en la identidad del correo electrónico que proporcionaban Hotmail.com, Yahoo! y Gmail, tuvimos un pequeño debate sobre por qué no utilizaba Microsoft una política para la configuración SPF de tipo hardfail en lugar de la política softfail que tiene actualmente. En aquel entonces no supe que responder salvo que al menos no era como la de Gmail, que es neutral. Sin embargo, el día 30 de diciembre recibí un correo de WindowsLive.com que me dejó claro el asunto.

En teoría, el dueño de un dominio es libre de marcar una política en su registro SPF del DNS. Esa política les indica a los servidores de correo electrónico que reciben un e-mail desde un supuesto usuario de su organización desde que IPs debe venir para ser legítimo y que hacer en caso de que no venga de una de esas IPs autorizadas. Así, en el registro SPF se marcan las IPs autorizadas y la política, que puede ser Hardfail (-all) que indica el deseo de que ese correo NO sea entregado o si se hace que se haga con información de peligrosidad al usuario, Softfail (~all) que indica que el correo debe ser entregado pero con alertas de seguridad o en la Junk Folder, Neutral (?all) que lo deja a la elección del receptor del mensaje y Pass (+all) que indica que debe ser tomado como bueno, venga de donde venga.


Figura 1: Configuración SPF Windowslive.com
Gmail tiene configuración Neutral, Hotmail tiene Softfail y Windowslive.com tiene también Softfail, tal y como se puede ver en la figura superior. Pero... ¿por qué? La única explicación es que todos los correos legítimos que se envían desde WindowsLive.com no están siendo enviados desde esas direcciones IP. Y así es.

El día 30 me llegó un mail de publicidad de WindowsLive.com que entró en la bandeja de entrada y sin ninguna alerta de seguriad, pero, como yo tengo mi super-Apolo configurado en mi super IE8, pues rápidamente me salió una alerta amarilla. ¡Coño! ¿Una alerta amarilla en un e-mail enviado desde WindowsLive a Hotmail? ¿Qué sucede?


Figura 2: Alerta de seguridad de Apolo en el correo de Windowslive.com
La explicación es sencilla, Spectra utiliza unos servidores de un dominio interno, llamados phx.gbl para muchas tareas de control en los servicios MSN, y, entre ellas está la de hacer los envíos de e-mail publicitarios.


Figura 3: Correo de Windowslive.com enviado desde phx.gbl
¿Es esto lo correcto? Pues sus razones tendrán para hacerlo pero, desde luego, el número de alertas que se van a levantar sera grande en aquellos servidores que no -sean propios y, por supuesto, no es lo que deberían hacer si el envío es legítimo. Si realmente tienen un servidor de esas características para enviar e-mailings, deberían autorizarlo en el registro SPF y listo, así no habría ninguna confusión y no nos volverían locos a los IT Pros y administradores de correo que deben hacer, en ocasiones, auténticas filigranas para que entre el correo legítimo y no se llenen los buzones de spam sólo porque algunos no configuran bien sus servicios de correo electrónico.

En fin, año nuevo pero con mismos detallitos.

Saludos Malignos!

PD: Apolo lo vamos a mostrar en la Gira Up To Secure 2010

El proyecto Apolo

Aunque os pueda parecer mentira, el nombre de este proyecto no lo puse yo. Siempre suelo ser el que pone los nombres a las cosas, el que se inventa los palabros raros y decide que algo se llame MetaShield Protector, FOCA o Asegúr@IT, pero en este caso, no tengo nada que ver.

El proyecto Apolo si que parte de una idea mia, una idea que se me ocurrió al terminar de escribir el artículo sobre las Correos falsos en Gmail, Yahoo! y Hotmail. Dicho artículo termina con un algoritmo que se debería comprobar para, en uno de estos tres motores de correo, eliminar las carencias que tienen a la hora de comprobar la autenticidad de los mensajes que llegan.

- Hotmail no da sorporte a DKIM, lo que no me parece bien, pero hay que reconocer que es quizá el menos extendido y que para el futuro, el camino que seguirá será el de Mutual TLS, más que DKIM.

- Yahoo! no da soporte a SPF, lo que es algo bastante malo cuando se trata de algo muy extendido hoy en día.

- Gmail da soporte a medias a DKIM, ya que no tiene establecida la política de DKIM y, aunque implementa y comprueba SPF, luego no utiliza el valor de la comprobación. Fail total, que permite que entren correos en Gmail que jamás deberían haber entrado [y 2].

Conociendo estas carencias, y añadiendo un filtro de comprobación MX para identificar correos legítimos en servidores sin SPF ni DKIM, construimos un algoritmo para identificar en estos correos aquellos que son falsos. Eso es Apolo.

El nombre se lo puso mi compañero Joshua Saenz [MVP de Exchange Server], tras presentarlo por primera vez al público en la charla de los Diez años de Informática64 que dio sobre MS Exchange Server 2010, Quest Message Stats y el propio Apolo.

A día de hoy tenemos el proyecto en Beta, pero ya tiene cierto soporte para Gmail. Se instala sobre Internet Explorer 8, por supuesto, como un BHO (Browser Helper Object) y, como somos buenos y queremos que os fiéis de él el día que lo publiquemos, va firmado digitalmente.


Figura 1: Apolo instalado como complemento
Después, funciona automáticamente cuando estás en la bandeja de entrada de tu correo. El componente realiza las comprobaciones descritas en el algoritmo que describimos en la última parte del artículo y pone varios iconos de colores.


Figura 2: Icono rojo, en este caso Hardfail de SPF
El correo de la Figura 2, lo he enviado suplantando mi propia dirección de Informática64. En Hotmail no entra, en Yahoo! entra porque no hay soporte para SPF y en Gmail, a pesar de que recibe una alerta de SPF Fail, por su cara bonita lo casca en el inbox. Apolo detecta que es un correo falso y le pone "la cara colorada" al Gmail.


Figura 3: Icono verte, SPF Pass
Este es un correito auténtico, enviado desde mi querido y amado Exchange Server, desde una de las IP del registro SPF, autenticado y correcto. Y Apolo le da la razón a Gmail poniendo un iconito verde.


Figura 4: Cuidadín
En este caso el correo es falso, pero está suplantando a un dominio que no tiene política DKIM ni política SPF, así que no hay herramientas para poder comprobarlo. No está en verde porque no viene de una de las IP del registro MX, así que tiene que quedarse con una alerta que informa de todo esto.

Al final, lo que está haciendo Apolo deberían hacerlo los propios interfaces de los clientes web, ¿no creéis?.

Hoy, junto a MetaShield Protector, van a ser presentados en sociedad en CEUS V y cuando esté más crecidito lo pondremos a disposición de todos aquellos que deseen ser monitorizados por Informática64 y su malévolo BHO.

Saludos Malignos!