Un día mirando un poco el buzón de SPAM de una cuenta de Gmail me encontré con un correo de phishing de Twitter el cual Gmail, además de haberlo etiquetado como SPAM, le había metido una alerta, muy resaltada, avisando de que el email no era legítimo del emisor indicado.
Mensaje clasificado como SPAM con aviso de un remitente no legítimo
A raíz de esto me empezó a picar la curiosidad y decidí ver las cabeceras de ese email.
Además me fui al link informativo ("Learn more") para ver que me contaban más acerca de este aviso (echarle un ojo al link si queréis ver que dice gmail acerca de todo esto).
Todo esto me hizo recordar a un conjunto de post que escribió el Maligno, los cuales me leí con mucho mimo para entender bien lo que explicaba y ahora que los menciono aquí aprovecho para darle las gracias por escribirlos; en ellos explicaba las sutiles diferencias entre SPF y SenderID y como eran interpretados por los servicios de correo de Gmail y Hotmail.
Maligno nos indicaba como conclusiones de sus pruebas que Gmail, las cuales cito de nuevo a continuación:
- PRIMERO: Gmail aplica From: y no Sender:.
- SEGUNDO: No elimina el correo aún cuando lee la política del dominio que él ha decidido.
- TERCERO: No muestra ninguna alerta al usuario.
Claro está que la conclusiones que él sacó eran totalmente ciertas para la prueba que realizó, pero después de haber visto el correo comentado arriba ya no tengo claro si siempre es así o no.
En el caso de este correo phisheado de Twitter, parece que:
- Gmail no siempre coge el campo From: para verificar el resultado de SPF (Sender Policy Framework); en este caso deduzco que ha cogido el campo Return-Path: o a saber el que durante la transmisión del email a los servidores de Gmail.
- A veces si que muestra alertas.
A parte de estas evidencias, me dedique a revisar la política SPF del dominio indicado en la dirección presente en el campo Return-Path: (pcavote.com). Revisando dicha política, yo no logré identificar que la IP [85.92.129.132] que envió el correo, que correspondía al servidor reseller06.pcextreme.nl, fuese un servidor reconocido del domino pcavote.com; aunque la política de dicho dominio es SOFTFAIL (~), es decir que el receptor debería dejar pasar los correos recibidos de servidores no reconocidos por la política SPF, si que es cierto que puede clarificarlos de manera especial para alertar al usuario, que parece que es lo que ha hecho Gmail al etiquetarlo como SPAM, pero realmente si revisamos dichas cabeceras, no es así, ya que el resultado del SPF es PASS, y según is observaciones (ATENCIÓN puedo haberme equivocado) el emisor no está reconocido por la política así que el resultado tendría que ser SOFTFAIL.
A continuación os dejo la serie de consultas DNS para lograr obtener todas las IPs que estarían autorizadas para enviar correos bajo el dominio pcavote.com:
> server 8.8.8.8
Servidor predeterminado: google-public-dns-a.google.com
Address: 8.8.8.8
> set type=txt
> pcavote.com
Servidor: google-public-dns-a.google.com
Address: 8.8.8.8
Respuesta no autoritativa:
pcavote.com text =
"v=spf1"
"mx"
"a:mailhost.sparkred.com"
"include:sparkred.com"
"~all"
> set type=mx
> pcavote.com
Servidor: google-public-dns-a.google.com
Address: 8.8.8.8
Respuesta no autoritativa:
pcavote.com MX preference = 10, mail exchanger = dmx1.bfi0.com
>set type=a
>dmx1.bfi0.com
Servidor: google-public-dns-a.google.com
Address: 8.8.8.8
Respuesta no autoritativa:
Nombre: dmx1.bfi0.com
Address: 208.70.143.4
> set type=a
> mailhost.sparkred.com
Servidor: google-public-dns-a.google.com
Address: 8.8.8.8
Respuesta no autoritativa:
Nombre: mailhost.sparkred.com
Address: 67.228.250.41
> set type=txt
> sparkred.com
Servidor: google-public-dns-a.google.com
Address: 8.8.8.8
Respuesta no autoritativa:
sparkred.com text =
"v=spf1"
"a"
"mx"
"a:mailhost.sparkred.com"
"~all"
> set type=a
> sparkred.com
Servidor: google-public-dns-a.google.com
Address: 8.8.8.8
Respuesta no autoritativa:
Nombre: sparkred.com
Address: 75.126.129.131
> set type=txt
> sparkred.com
Servidor: google-public-dns-a.google.com
Address: 8.8.8.8
Respuesta no autoritativa:
sparkred.com text =
"v=spf1"
"a"
"mx"
"a:mailhost.sparkred.com"
"~all"
> sparkred.com
Servidor: google-public-dns-a.google.com
Address: 8.8.8.8
Respuesta no autoritativa:
sparkred.com MX preference = 10, mail exchanger = webmail.sparkred.com
> set type=a
> webmail.sparkred.com
Servidor: google-public-dns-a.google.com
Address: 8.8.8.8
Respuesta no autoritativa:
Nombre: webmail.sparkred.com
Address: 174.37.50.21
Y el resultado de IPs obtenido de las consultas anteriores:
En este punto ya no entendía nada, es decir, o yo no entiendo como funciona bien el SPF y por lo tanto algo se me escapa, o Gmail no implementa el SPF como se índica en el estándar (RFC 4408); debido a esto no me quedé tranquilo y me fui a buscar lugares donde pudiese hacer alguna prueba de concepto más, como hizo el Maligno en su día.
Así que me busque una bonita web que me dejase enviar cosas a los colegas y envié un email al Gmail indicando que era un pavo de La Caixa (lacaixa.es), es decir utilicé el mismo dominio que utilizó el Maligno en sus pruebas.
Envío de email a través del formulario de “enviar a un amigo” de una web
Recepción en Gmail del email enviado desde el formulario web “envía a un amgio”
Y el resultado obtenido es el mismo, se colo en buzón de entrada sin ningún tipo de alerta y con un resultado de SPF a FAIL; aunque esta vez la cabecera del correo no lleva ni el campo Sender: ni X-Sender:, pero sí Retun-Path:.
Cabeceras del email recibido enviado desde el formulario web de “envía a un amigo”
Aún después de todo esto no me quedé satisfecho y decidí probar el mismo ejemplo sobre otra web de las que también permite enviar cosas a colegas y ver de nuevo que pasaba.
Recepción en Gmail del email enviado desde otro formulario web “envía a un amgio”
El resultado obtenido con esta última prueba fue sutilmente distinto, se coló en el buzón de entrada, pero el resultado del SPF fue PASS, tampoco tenía campos Sender: ni X-Sender:, pero si que tenía también el campo Return-Path:, pero no con el valor de la cuenta de correo del supuesto emisor, sino con una cuenta del dominio que envía los correos introducidos en el formulario web, de ahí a que el resultado del SPF fuese PASS, ya que este dominio no tiene una política SPF definida.
Cabeceras del email recibido enviado desde otro formulario web de “envía a un amigo”
Y las consultas que hice sobre el dominio voc-servicios2.sarenet.es fueron:
> set type=a
> voc-servicios2.sarenet.es
Servidor: google-public-dns-a.google.com
Address: 8.8.8.8
Respuesta no autoritativa:
Nombre: voc-servicios2.sarenet.es
Address: 194.30.33.176
> set type=txt
> voc-servicios2.sarenet.es
Servidor: google-public-dns-a.google.com
Address: 8.8.8.8
sarenet.es
primary name server = ns1.sarenet.es
responsible mail addr = dnsmaster.sarenet.es
serial = 2011032204
refresh = 86400 (1 day)
retry = 7200 (2 hours)
expire = 2592000 (30 days)
default TTL = 300 (5 mins)
> set type=mx
> voc-servicios2.sarenet.es
Servidor: google-public-dns-a.google.com
Address: 8.8.8.8
sarenet.es
primary name server = ns1.sarenet.es
responsible mail addr = dnsmaster.sarenet.es
serial = 2011032204
refresh = 86400 (1 day)
retry = 7200 (2 hours)
expire = 2592000 (30 days)
default TTL = 300 (5 mins)
De todo esto puedo sacar algunas conclusiones, además de las que ya sacó el Maligno, como que Gmail no garantiza un aviso aunque el resultado SPF de los emails recibos sea FAIL.
- Gmail utiliza el dominio del campo Return-Path: para calcular el resultado SPF.
He podido observar que en varios emails que el campo siempre está presente, o con una dirección (parte local, o del dominio o ambas) distinta del campo From: o sino con el mismo valor. - Si el valor del campo Return-Path: difiere del campo From: entonces aparece en los detalles de la cabecera del email un campo denominado mailed-by con el dominio de la dirección presente en el campo Return-Path:.
Hasta la próxima enfermos.