Mostrando entradas con la etiqueta e-mail. Mostrar todas las entradas
Mostrando entradas con la etiqueta e-mail. Mostrar todas las entradas

13 de agosto de 2011

Otro vulgar scammer más


Aunque ya me ha pasado el 90% de las veces que me pongo a vender algo en segundamano.es, está va a ser la primera vez que publico los mails que me he cruzado con el vulgar scammer de turno, más bien motivado, porque estoy de vacaciones, aunque esto no quiere decir que me haya sobrado el tiempo, ya que vuelvo al curro la semana que viene y en la pila de cosas que quería hacer no se ha quedado en 0 elementos.

La historia es la de siempre; aprovechando el servicio de segundamano.es me he puesto a vender un artilugio que tenía por casa el cual no tengo intención de utilizar más y ya que el mundo físico no se comportar de manera tan boyante como el mundo virtual, en términos de espacio de almacenamiento, decido venderlo para sacarle algo de provecho, es decir algo de pasta.
El primer mail del vulgar scammer no era más que una pregunta que hace muchos de los posibles interesados por artículo:


Toma de contacto del scammer

Aunque ya se empezaba a notar las complicaciones que estos individuos acostumbran a tener con el Español y las costumbres que nosotros tenemos y que estos no es que se hayan informado mucho.

El tío se llama “Jose María”, vamos que más Español, el nombre no podía ser y con la gramática que había utilizado ya no encajaba mucho, pero bueno aunque es un indicio, la gente que contacta a través del formulario web no suele esmerarse mucho en escribir más o menos correcto, y cuento las faltas de ortografía, ya también soy bastante malo para eso; luego resulta que la dirección de mail es mariajose12000@yahoo.com, dejando lo de 12000, se deberá al overbooking que hay de “mariajose” en las direcciones bajo el dominio yahoo.com, el tío parece que le mola lo del cambio de sexo, y con esto no es que yo tenga algún problema con ello, tengo 100% de respeto a este asunto, ya que para mí esto es una práctica de la libertad de un derecho que no hace daño a los demás, pero no nadie negará que no es una situación extraña, sobre todo cuando las costumbres de muchos países de habla no española suelen tener un apellido y muchas veces cuando tu vas con dos apellidos se piensan que tu 1er apellido es parte de tu nombre (nombre compuesto) y el segundo es tu único apellido, con esto ya me encontré en las oficinas de Google de Zurich, cuando me fuí a visitar a un colega, no había manera de que lo encontraran, por este mismo hecho.

Dicho esto, continuamos con la historia:

El scammer se interesa en comprar al artículo y te cuenta la típica historia paternal para tocarte el corazón

Ahora le dí un poco de juego para ver como reacciona sobre una posible víctima:

Que sí que sí que me creo tu historia

Que conste que el número de cuenta, que por supuesto no es mío, lo saque de una de las múltiples webs que meten su número de cuenta bancaria para recibir cobros de clientes, es decir que la he sacado de entre información que está accesible al público.

Y ahora viene lo mejor, BANK OF AMERICAN, hace ofrece un tipo de servicios que en mi vida he visto, será porque los norte americanos son así de serviciales con los clientes que les dan bien de comer.

Bank of American nos confirma la transferencia que ha hecho el comprador, joder como se lo curran

"Ostia, no sabía yo que esto de la crisis había tocado tanto a los bancos que han tenido que vender sus dominios al mejor postor y empezar a utilizar dominos más asequibles (bank.of.american@v.gg)"

Por cierto este mail, al contrario que el resto, si que gmail, lo metió en el buzón de SPAM.

Continuamos viendo el problema detectado con el nombre utilizado, ¿es un tío o una tía?

Por si no te quedó claro con el mail anterior que encima te lo envían a ti con copia a ti mismo, el banco te envía otro, pero ahora con os he cargado las imágenes para que veáis lo corporativos que son:


Si no te ha quedado claro, te mandamos otro mail, pero con nuestras bonitas imágenes corporativas

Es más parece que si te meten unos cuantos dolares al final del mail, te va a convencer más que esto no es un bulo:

El final del segundo mail enviado por el banco viene con unos cuantos dólares

Ahora, que todo está hecho el scammer te dice que todo está hecho y te suelta el rollo de que el banco ha confirmado que el dinero está listo para entrar en tu cuenta.

"joder que amables y confiados son estos extranjeros y sobre todo agradecidos, me han dado 50 € más de lo que pedía; esto son buenos clientes y lo demás son tonterías"

El scammer informando que ha pagado y encima más de lo que pedías

Bueno llegado a este punto ya me cansé de jugar así que como no he respondido al último mail con lo que pide me ha enviado otro soltando un rollo de que es una persona honrada y que está al corriente de este tipo de timos, pero que él/ella no es así.

  El scammer jurando que es una hermanita de la caridad


Visto esto y todas las veces que me ha pasado siempre que intento vender algo en segundamano.es (y eso que ellos mismos avisan de este tipo de prácticas), creo que me queda claro que aunque a este tipo de timos se le vé el plumero por todos lados, parece que siempre, aunque parezca mentira, debe picar alguien por eso de la ley de los grande números, sino ¿porqué lo continúan intentando?

Bueno por si alguien duda estos días y decide meter buscar en google las direcciones mariajose12000@yahoo.com y bank.of.american@v.gg para ver si alguien ha reportado algo, al menterlas aquí espero que alguien dé con el post y le queden claras todas sus dudas.

Por otra parte, para quien no esté al corriente, hay que tener en cuenta que por mucho que vengan los mails de direcciones con el dominio apropiado a la entidad bancaria, no es una fuente de garantía, y si usáis gmail, hace un tiempo, no sé si actualmente continúa igual, no siempre avisa.


Hasta la próxima enfermos.

1 de mayo de 2011

SPF v1 en Gmail ¿como funciona?


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:
  1. 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.
  2. 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.
  1. 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.
  2. 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.


6 de abril de 2011

Si eres un banco, cuida tu SPF


El otro día pedí una información, por email, de los servicios que ofrece una de las nuevas entidades bancarias que están apareciendo con el revuelo económico que últimamente está habiendo con las cajas de ahorro.

Aunque lo que realmente pedí fue que me llamasen, posterior conversación telefónica me enviaron un email con todo lo que me habían comentado por teléfono, junto con un enlace donde darse de alta como cliente.


Parte del cuerpo del email de bancacivica.es con el enlace al formulario de alta de nuevos clientes

Debido a todo lo que leo, escucho, etc. de todo lo que pasa con la seguridad del mundo virtual y después de leer informes de claramente indican que zapato calzan las organizaciones criminales que se encuentran detrás, a uno le entra la paranoia constante de sino te están intentando timar además de tener la inseguridad de que cada vez que inicio sesión en el la extranet de una entidad financiera no te estarán robando los credenciales bancarios para que puedan hacer una mejor administración e inversión de la que tu haces con tus ahorros.

Bueno, debido a que al leer el correo entré en estado paranoico, me aseguré de verificar un poco las cabeceras del email recibido para ver de donde viene y por donde ha pasado (que me refiero a lo que ha quedado registrado).


Cabeceras del email recibido de bancacivica.es con el enlace al formulario de alta de nuevos clientes

Todo me parecía normal si no fuese porque el resultado del SPF había dado error, y como no, Gmail no había notificado mediante algún aviso de ello.


Cabecera del email bancacivica.es sin aviso alguno del fallo SPF

El error que se había producido era un “temperror” debido a un timeout en la consulta DNS para la obtención del valor del registro TXT del dominio.
Así que no me quede muy tranquilo viendo esto, por lo entonces un simple fallo en la consulta puede originar que no se verifique el filtro SPF, dando un “temperror” y el mail se cuele sin aviso alguno.
Lo primero que pensé es que debía haber sido un error esporádico, pero no fue así ya que como tenía otro correo recibido, desde la misma dirección de envío, anterior a este, me fui a ver las cabeceras de este y … ¡sorpresa! Se había producido el mismos error.

“Pues vaya, vamos a ver que pasa con el registro SPF de bancacivica.es”; así que me fui ha consultar el registro TXT del dominio y ver si podía sacar algo en claro.

Valor del registro TXT del dominio consultado en varios servidores DNS

Como podéis ver en la captura anterior al intentar conseguir el valor del registro TXT del dominio desde el servidor DNS de Google, se origina un error de timeout, así que de ahí que se explique el resultado que obtiene los servidores de Gmail. No obstante también podéis ver el resultado de la consulta sobre otros dos servidores DNS, el de Terra y el OpenDNS, los cuales no generan error y nos devuelven el resultado del registro.

Claramente podemos ver que tienen una sintaxis incorrecta: ~all- (el guión final no debería estar).

Verificación de la sintaxis del registro TXT en Kitterman

Bueno son cosas que pasan, todos nos equivocamos y muchas veces a la hora de teclear se nos van los dedos, pero claramente podemos ver que después de aplicar el filtro nadie se ha preocupado de verificarlo.

Con todo esto acabo de aprender dos cosas:
  1. Gmail no me dará ningún aviso si hay un error de timeout sobre la verificación SPF.
  2. Si me toca crear algún filtro SPF en futuro, acordarme que luego lo verifique (sobre todo si es para un sector donde la autenticidad de los emails es importante, como una entidad bancaria).


Hasta la próxima enfermos.

14 de enero de 2011

Sin papelera de reciclaje en el buzón de correo de Notes


En el post que comentaba la historia del regreso de los buzones de correo electrónico, de ciertos empleados de la empresa donde trabajo, al "Bing Bang", comenté que escribiría alguna entrada sobre aspectos del funcionamiento de Lotus Notes que desconocía y que me sorprendieron.
Una de esos posts fue Autenticación de Lotus Notes Server y otra de las que tenía pendiente es esta.

Después de recrear los buzones de correo de los empleados que lo perdieron, me avisaron de que cuando eliminaban correos, se eliminaban de manera permanente, es decir que no iban a la típica "papelera de reciclaje".
Observando el comportamiento que me habían indicado, observé que en la barra de herramientas del buzón de correo no aparecía el típico icono de una papelera y en vez de él aparecía una X.

Barra de herramientas del buzón de correo con el icono en X para la acción de eliminación

A raíz, de esto, lo primero que se me ocurrió mirar es en las preferencias de la aplicación haber si se tenía que activar algo para que la funcionalidad de reciclaje estuviese activa, aunque eso tenía que ser extraño ya que no se había hecho ninguna intervención en las aplicaciones clientes (por ejemplo una resinstalación), por lo que no tenía mucho sentido que la configuración se hubiese alterado; no obstante, lo hice (cosas más raras he visto), sin llegar a obtener mucho éxito.
Lo de revisar la configuración de la aplicación cliente, es lo más habitual, cualquier aplicación con las que tratamos, cambiamos su comportamiento a través de algún menú de preferencias ( análogamente opciones), pero como el cliente de Notes no solo es una aplicación de cliente de correo, sino es más bien una aplicación cliente de acceso aplicaciones de Lotus, es normal que las preferencias que dependen exclusivamente de una aplicación en concreto no aparezcan dentro de la configuración de las preferencias de la aplicación cliente, sino en las preferencias de la configuración de la aplicación de Lotus. Dicho esto me puse a revisar las preferencias de laaplicación de Lotus, en este caso un buzón de correo, sin tampoco obtener mucho éxito.

Menú de acceso a las preferencias de aplicación de Lotus de correo

Lo siguiente que se me ocurría era que al crear los nuevos buzones, la hubiera cagado no seleccionando la plantilla correcta. Para los que no estén en la onda de Lotus Notes, yo solo lo estoy un poco, a mí entender las aplicaciones Lotus Notes se componen de un formato único de fichero (extensión nsf) que almacena en su interior todo lo relacionado a a la aplicación (vistas, formularios, procedimientos, etc.), parte que se llama, o yo le llamo plantilla, y los datos de la aplicación; es decir que en este caso, estoy hablando de una aplicación que tiene una plantilla de buzón de correo y como datos va a tener correos electrónicos, entradas de agenda, etc.
Revisé que la plantilla que se estaba aplicando fuera la correcta, y que fuera la última versión, ya que la plantilla que se utiliza en la empresa es una modificación de la plantilla estándar de Lotus Notes, para permitir exportar los e-mails al servidor de ficheros; todo era correcto. Luego pasé a preguntarle a mi compañero, que se encarga de programar las modificaciones de las plantillas, si dicho comportamiento podía tener que ver con las modificaciones que el hace en la plantilla, pero su respuesta fue que no, a no ser que hubiese modificado algo sin darse cuenta, algo que descartaba porque la plantilla que yo había aplicado era la misma que estaba aplicada a los buzones de correo que no se perdieron, y el borrado de datos en estos últimos se comportaba de manera habitual, es decir enviándolos a la papelera.
Ya empezaba a estar un poco hasta los hue... del tema; intenté utilizar el Sr. Google, haber si él podía resolvernos el problema, pero era complicado como formularle las preguntas correctas, porque no encontré nada de interés.
Dándole vueltas a la cabeza y repasando que no me hubiese dejado nada importante en la creación de los nuevos buzones, se me ocurrió que no había mirado en las propiedades de una aplicación de Lotus, así que me puse a ello; entonces descubrí que había una propiedad que se llamaba "Soft Deletions" y que estaba deshabilitada, así que por el nombre (“borrados suaves”) se puede intuir que tienes que ver con la salvaguarda de los borrados de datos, así que la activé.

 Acceso a las propiedades de una aplicación de Lotus
 Dialogo de Propiedades de una aplicación de Lotus (Pestaña avanzado)
Una vez activada y después de cerrar y abrir la aplicación, el icono de la X se había cambiado por una papelera y cuando borrabas correos estos se iban a la "papelera de reciclaje".

Barra de herramientas del buzón de correo con el icono de la papelera para la acción de eliminación

Además dentro de las preferencias de la aplicación de correo habían aparecido nuevas opciones de configuración sobre el eliminado, una de estas la misma que la que se podía indicar en las propiedades, la de el tiempo límite de permanencia de los datos eliminados.

Dialogo de preferencias de aplicación de Lotus de correo con la opción “Soft Deletions” deshabilitada
Dialogo de preferencias de aplicación de Lotus de correo con la opción “Soft Deletions” habilitada

En resumen, la opción de “Soft Deletions” es una propiedad de cualquier aplicación de Lotus, por lo que se debería poder hacer uso de esta característica en cualquiera de ellas.


Hasta la próxima enfermos.

7 de diciembre de 2010

Autenticación de Lotus Notes Server

El día que tuve que ir por la empresa, donde actualmente trabajo a tiempo completo, a restaurar el servidor de correo Lotus Notes, de la oficina de Barcelona, aprendí a marchas forzadas a instalar un servidor de Lotus Notes desde 0.

En la fase de restauración tuve que registrar un nuevo elemento servidor en el Domino, ya que en la instalación del servidor se requiere que le indiques el nombre que tiene en el Domino y también le proporciones su ID.

Hasta la fecha, yo sabía que el ID, era un fichero que lleva los credenciales de autenticación de un usuario registrado en el Domino, siendo necesario cuando el usuario abre sesión desde de el cliente de escritorio, ya que el acceso desde un cliente web (navegador) no es necesario. Podéis encontrar algo de información de este inusual sistema de autenticación, aquí. Ahora que me encontré con esta situación, he sabido que los ficheros IDs no solo se usan para autenticar a los usuarios, sino también a los servidores.

De mis rutinarias tareas de administración de usuarios en el Domino, se que cuando se registra un usuario el ID se almacena en el names (BBDD donde Domino gestiona todos los elementos registrados), o eso es lo que pensaba, ya que cuando en la empresa registramos a los usuarios, siempre marcamos esa opción.

Formulario de registro de servidor en Domino de Lotus Notes.

Pero resulta que aunque se indique dicha operación, no siempre se puede llevar a cabo, porque si lamentablemente se ha indicado un nivel 0 de complejidad de contraseña, el sistema no permite realizar la operación.

Selección de nivel de complejidad de contraseña

Alerta de obligación de contraseña para adjuntar un ID en el Domino

Por esta razón, o la menos esa es mi deducción, ningún servidor registrado en el Domino de la empresa, tiene adjunto su ID.
Este hecho me provoco ciertos dolores de cabeza, ya que al no tener ese ID y no encontrarlo por ningún directorio de los distintos servidores, ni en los espacios de datos compartidos que utilizamos en el departamento de TI, perdón, de sistemas y cosas varias, tuve que registrar de nuevo un servidor en el Domino, generando de esta manera su ID correspondiente, y esta vez sí, adjuntado al registro del servidor en el names.

Sorprendentemente, por el momento no hemos detectado ninguna anomalía correspondiente a que el Domino no identifique el servidor como tal, ya que en sí, debería ser otro servidor, con un mismo nombre de un servidor que ya existía; como es normal, ser perdieron configuraciones que el antiguo servidor tenía, ya que debían estar almacenadas en su propio disco local, pero los clientes que atacan a las BBDD, ya sean de correo o de otros menesteres, han continuado operando sin problema alguno.

Para finalizar, me autorespondo, en base a mis propias deducciones, a ciertas preguntas que yo me hice en su momento:
  • ¿Porque si se indica el nivel de seguridad 0 de contraseña (nivel que permite dejar la contraseña en blanco) no se permite adjuntar el ID al registro del elemento en el names?
    La deducción más obvia, es porque el nivel de seguridad de acceso a ese fichero ID, debe ser muy débil; y claramente es así, el names es una BBDD accesible por cualquier usuario registrado, sea administrador o el usuario con menor privilegio; así que cualquier usuario registrado puede acceder a ese registro y extraer el ID, y si no tuviese contraseña, suplantar la identidad del elemento en cuestión.

  • Si el ID del servidor, tienen una contraseña ¿cómo puedo configurar el arranque del servidor de manera automática (arranque al inicia Windows, desde un cron, etc.)?
    Es posible que esta pregunta tenga varias respuestas, pero en mi caso, lo solucioné, autenticándome desde un cliente de escritorio de Notes con el ID del servidor y cambiando la contraseña del ID, por ninguna; esta operación cambia la contraseña de esa copia del ID, no de ninguna otra copia, ni del fichero original adjunto en el registro del servidor en el names.


Hasta la próxima enfermos.

21 de noviembre de 2010

Mi mailbox ha regresado al “Big Bang”


Descripción del entorno
Lotus Notes es una aplicación que se clasifica dentro de la categoría de colaboración de grupos o equipos de trabajo.
En la empresa, en la cual empleo la mayor parte de mi tiempo, utiliza esta herramienta desde hace mogollón de años, aunque parece que a nadie le acabe de satisfacer, la herramienta sigue ahí y bien viva ya que se van pidiendo la implementación de nuevas funcionalidades sobre ella.

Nosotros, los del departamento de TI, tenemos que sufrir las constantes críticas de la mayor parte de los usuarios, incluyendo usuarios con potestad para impulsar un cambio (la dirección), pero este nunca llega, ya que aunque nosotros no somos unos fans de Notes, somos realistas y exponemos las realidades que hay cuando se nos dice “¿por que no ponemos Outlook?” (He dicho Outlook, porque para el usuario es Outlook y nada más, es decir Exchange no existe).
En resumen, el cambio nunca llega porque cuando empiezan a sonar los números, los que pagan ya se echan para tras, y eso que solo llegan a escuchar el dinero de adquisición de la licencia de Exchange, sin haber escuchado lo que cuesta otra herramienta que supla las funcionalidades que ofrece Notes y no Exchange, desarrollo de aplicaciones y BBDD de “negocio” y su migración.

En fin dentro de este berenjenal a nosotros nos toca lidiar con la administración de Notes y las constante insatisfacción y todo eso con una política, de puertas hacia dentro, de inversión mínima en TI.

Como de costumbre, el gran perjudicado en una insuficiente inversión en el importante ámbito actual de las TI, no se lo lleva el personal del departamento de TI que tenemos que plantarnos fuera de horarios para apagar fuegos, aprender de manera autodidacta y normalmente a base de “ostias”, etc., sino que se lo lleva los usuarios y sobre todo la continuidad de negocio de la empresa.

Regresando al “Big Bang”
Hace poco más de una semana, el servidor de Notes de Barcelona dejó de funcionar, al estropearse dos discos de un RAID 5, así que los datos se quedaron en el limbo, ya que no hay tiempo para mandar esos discos a un empresa de recuperación de datos, ya que el servidor se tiene que restablecer lo antes posible; el tema económico, ni lo menciono ya que no lo llegamos ni a consular, pero con la política de inversión mencionada anteriormente, se puede prever con cierta exactitud la respuesta.

La incidencia hasta aquí la normal, no hay disco hot spare, así que a reinstalar servidor y su servicio, después de cambiar los dos discos.

Lo que sucedió, es que ciertos usuarios no tenían una copia de su BBDD de correo, así que volvieron a “Big Bang”, buzón vacío y si tenías algo importante te las apañas para recuperar lo o continuas tu actividad sin esa información como puedas. He dicho ciertos usuarios, por otros si tenían una copia, ya que usan correo web y para eso necesitamos tener replicada su BBDD en otro servidor Notes, y casualidad o no, suele coincidir con el correo de los usuarios de mayor importancia (hablando en términos organizativos).

Restableciendo el servidor
Yo, que de administrar el Notes, sé lo del día a día, ya que el tiempo de la extendida jornada laboral, con el personal que somo en TI, no deja para estar jugando con los sistemas, e invertir en formación del personal de TI (y otros tantos departamentos, más bien casi todos a excepción uno y medio) no cabe en los presupuestos de la empresa; tuve que reinstalar un servidor de Notes entero y meterlo en el Domino existente, sin más ayuda hasta la fase de poner la guinda al pastel, ya que mi compañero no estaba localizable.

La verdad es que el Notes, as nivel de interfaz y de la lógica de ejecutar las acciones es rebuscado, de ahí su baja popularidad entre los usuarios, pero para administrarlo no lo es mucho, aunque la lógica de ejecución y realización de operaciones sobre él sigue siendo la misma, pero para los IT Pros no hay mucho problema ya que nos dedicamos a probar lo todo.

En resumen, la instalación del software, es un siguiente, siguiente, siguiente, … si no te encuentras que te falta algo como me pasó a mí. Como tenía que restaurar un servidor, necesitaba conseguir el ID (fichero de registro de los elementos registrados en el Domino: máquinas, servidores, etc.) del servidor antiguo y justo este ni estaba en el names (BBDD donde Domino gestiona todos los elementos registrados) y menos lo encontré perdido por algún directorio de los múltiples que tenemos en la empresa.
De tenerlo, creo que hubiese podido asociar esa nueva instalación al servidor ya registrado, pero al no ser así tuve que crear un nuevo servidor, al cual le puede poner el mismo nombre que antiguo, préviamente habiendo renombrado al antiguo, y no hizo falta mucho más para que el Domino continuara tratando el nuevo servidor como el servidor existente.

Evaluación
Finalmente la experiencia no ha estado más, ahora ya sé instalar un servidor Lotus Notes, añadirlo a un Domino existente, además de haber aprendido y encontrado múltiples herramientas y operaciones de administración que Lotus Notes tiene.
Para los usuarios y la continuidad de negocio, ha sido un mal menor, ser perdió poca información importante, al menos para la empresa, para el usuario que la ha perdido parece algo más importante, y como siempre, si se hubiese tenido una copia de seguridad en toda regla el impacto de perdida de información hubiese sido minúsculo, pero si no la hay, puedo constatar que es por falta de inversión en TI, no solo en máquinas (que si que hace falta) sino en aplicaciones y en recursos humanos.

Tengo previsto, espero que sea en un breve espacio de tiempo, escribir alguna entrada sobre algunas cosas que he descubierto de Lotus Notes, que me han sorprendido como funcionan, y que me han tenido perdiendo una parte del tiempo, ya que remendando por Internet, en Google y en la documentación de IBM, no logré encontrar, con el objetivo de que a alguien le puedan ser útiles.


Hasta la próxima enfermos.

17 de junio de 2010

Malware con nombres de ficheros sospechosos

Mientras escribía el anterior post me empecé a plantear porque en el nombre de esos troyanos que habíamos recibido por e-mail se habían utilizado un chorro de "_"  justo después del nombre, terminado en .doc, y la extensión del fichero, que era la de un ejecutable de Windows, .exe; el objetivo, como ya mencioné, está claro, es el de confundir al usuario para que llegue a creer que lo que está recibiendo es un fichero de Word de Microsoft Office, es decir un .doc, haciendo énfasis la utilización del icono asociado al ejecutable de Word. Mi planteamiento no era el objetivo en sí, sino de porque utilizar guiones bajos y no utilizar espacios en blanco ya que seguramente es más fácil confundir a la posible víctima debido a su invisibilidad.

Así que, ya que me lo plantee, he decido probarlo y ver si realmente los espacios en blanco cumplirían mejor su objetivo que los guiones bajos utilizados y teniendo en cuenta la vista que estemos utilizando en explorador  de ficheros. Los resultados han sido los siguientes:
  1. Vista detalles



    Como podemos ver en la imagen anterior, los espacios en blanco es la mejor opción para la eficacia del engaño. De los tres ficheros que aparecen, el de en medio no tiene ningún carácter entre el .doc y la extensión y en en el caso de no tener activada la opción de "Ocultar las extensiones de archivo para tipos de archivos conocidos" sería la más eficaz porque entonces no aparecerían los "..." en el extremo derecho de la columna "Nombre", pero teniendo dicha opción desactivada queda delatada la verdadera extensión del fichero, algo que es lo que pretenden evitar los espacios en blanco o lo guiones bajos.
    No obstante esta vista puede ser la que mejor convenga para detectar que realmente es un ejecutable, ya que en la columna "Tipo" aparece lo que realmente son los ficheros, así que si la posible victima ve eso, fácilmente puede detectar que se trata de un engaño.

  2. Vista lista



    En esta vista, si el ancho de la ventana, bueno concretamente el de la zona de listado de ficheros y carpetas, es mayor que el número de caracteres utilizados para ocultar la extensión, y tenemos desactivada la opción de ocultación de extensiones, comentada en el punto anterior, claramente queda delatada la extensión en cualquiera de las tres opciones. En el caso de tener activada opción de ocultar extensiones, en ninguno de los tres casos se detecta la extensión real, aunque en el caso de  utilizar guiones bajos dará indicios a pensar que algo raro sucede; esto mismo también sucede si aún teniendo desactivada dicha opción, la longitud horizontal de la ventana de lista de archivos y carpetas es inferior a la del nombre real del fichero (nombre con los caracteres para ocultar la extensión), tal y como podemos ver en la imagen de a continuación.



  3. Vista iconos



    Este tipo es muy similar a la del punto 1, el resultado sería el mismo, pero el usuario no tendría la posibilidad de ver de manera rápida que el fichero se trata de un ejecutable, ya que en esta vista no tenemos una columna informativa sobre el tipo de fichero.

Aunque hay otras vistas disponibles, no he citado más porque el resultado del resto  no aportaría nada nuevo ya que el comportamiento de cualquiera de estas es igual  a alguna de las 3 mencionadas.

El objetivo de este post no ha sido ni mucho menos generar nuevas ideas a los atacantes, ya que para mí los atacantes maliciosos son mi enemigo del día a día, además la idea es muy simple y de carácter no técnico; si he decido escribir esto es para poner en alerta al usuario del día a día que no duda cuando recibe estos ficheros aunque se vea de lejos que el e-mail no va dirigido a él y/o a su empresa y/o ha su responsabilidad dentro de ella y que si con el truco de los guiones bajos está colando, con el uso de espacios seguro que todavía colaría más.
Este tipo de avisos los tengo que estar dando yo a los usuarios de la empresa para la cual trabajo para concienciar les que la industria del malware es un peligro real y presente hoy en día , aunque la mayoría de las veces me llevo comentarios del tipo "informáticos estáis obsesionados con la seguridad y  sois unos exagerados y lleváis este más allá de la realidad", aunque yo no voy a desistir por escuchar este tipos de gilipolleces. Considero que explicarles este tipo de medidas de como detectar técnicas sencillas de engaño les puede ayudar a que eviten ciertos contagios, tanto en sus equipos personales como en los de la empresa,  quedando claro que los problemas generados en estos últimos  me atañen a mí.

Por último solo quiero mencionar que en el post anterior ya hice mención que los antivirus/antimalware y más concretamente los filtros antispam que también analizan los ficheros adjuntos podrían llevar un mecanismo de alerta, en el caso de los primeros, y de mover el correo al buzón de SPAM, en el caso de los segundos, solo por el simple hecho de que los nombres de los ficheros tuviesen un patrón asociado a la distribución de malware como lo es el citado en este post; sin duda creo que sería de gran ayuda para evitar contagios con técnicas tan técnicamente simples como estas.

Hasta la próxima enfermos.

10 de junio de 2010

Facturas para no olvidar

Ayer en la empresa volvimos a recibir otro de los famosos troyanos, un .exe, camuflados  en un ZIP, con icono de Microsoft Word y con el clásico nombre en cual aparece la palabra "Factura" por algún lugar y ".doc" justo antes de un chorro de guiones bajos que preceden su verdadera extensión (.exe).

Hace no más de un mes, recibimos un fichero de este tipo, menos mal que el usuario receptor fue precabido y me avisó antes de ejecutar nada, ya que el mail con el que llegaba, cantaba un bastante lo que traía con él. En ese momento estábamos probando nuestro nuevo proveedor de correo por lo que en fase de pruebas y que un filtro antispam y antivirus no parase ese mail con un fichero adjunto, que por su nombre y extensión gritaba "Soy un troyano", era para suspender la fase de pruebas y no contratar sus servicios.
Como no me gusta sacar conclusiones a la ligera, lo analicé con el antivirus corporativo que tenemos y al obtener un falso negativo, se me ocurrió subirlo a Virus Total; el resultado fue desolador tan solo 1 de los 41 motores lo detectaba, así que decidí subirlo a varias veces durante unos cuantos días y postear los resultado obtenidos aquí.
El servicio antispam y antimalware se salvaba de que no lo contratásemos, ya que con ese índice inicial de detección no podemos justificar que el servicio no es el correcto. 


Como de nuevo esta vez el motor antispam y antimalware lo ha vuelto a dejar pasar sin ningún tipo de advertencia, lo he subido, como hice con el anterior, a Virus Total y el resultado ha sido:
  • En mi primer análisis por mi parte, ya que ya había sido analizado una vez dos horas antes aproximadamente, un solo motor lo detectaba; podéis ver el informe aquí.
  • En mi segundo análisis, medido día más tarde aproximadamente, lo detectaban cuatro motores; podéis ver el informe aquí.
Así que de nuevo estamos no veo lícito realzar reclamación alguna ya que el índice de detección cuando nos ha entrado es extemadamente bajo.

No obstante si que veo lógico abrir una reclamación por no detectarlo como SPAM, ya que con un mega potente motor antispam y antimalware que está en la nube, así es como lo venden, no dé ningún tipo de advertencia o catalogue el mail como SPAM, solo por el simple hecho de llevar un .exe comprimido en un ZIP y con nombre que obedece el clásico patrón comentado al inicio de este post.

Para finalizar solo me gustaría añadir que los antivirus podrían añadir un sistema de advertencia al usuario al estilo de "Posible fichero malicioso", cuando detectasen ficheros con nombres con patrones sospechosos, no creo que sea tan difícil añadir un sistema de advertencia de este tipo, ¿no?


Hasta la próxima enfermos.

22 de mayo de 2010

Seguimiento de detección de un fichero sospechoso

Esta semana, en el curro, entró por mail el típico spam con un fichero adjunto sospechoso, muy fácil de detectar, por cualquier técnico, que se trata de un fichero ilícito, pero donde muchos usuarios, sobre todo los que se dedican llevar la facturación, pueden llegar a picar.

El mail, muy clásico, tenía el siguiente contenido:
Asunto: Fwd: New_Factura!!!
Cuerpo:
Buenos dias, xxxxxx@dominiodelaempresa.es.
La factura que debe ser abonada antes de la semana siguiente.
Los detalles estan dentro del archivo.
--
Con los mejores votos,
Departamento              mailto:canduxo@otrodominio.com
Fichero adjunto: 56_Factura.zip

Hasta aquí todo muy claro de detectar, sin ni si quiera tener que abrir el archivo:
  • No saben como nos llamamos, resulta que nuestro nombre es la dirección de mail, sin dignarse a quitar el dominio.
  • Resulta que nos lo envía un tal yyyyy@dominodelspam.com pero que si queremos contactar con alguien que tiene un mail en otro dominio, con un nombre más legítimo canduxo@otrodominio.com y encima nos ponen mailto tal cual, no es el mailto de un enlace.
  • Y, claro esta que lo más normal del mundo en España es despedirse diciendo: "Con los mejores votos".

En esta ocasión el usuario, fue precabido y me acabó llamando para que le asegurará si realmente era un spam; aunque estaba claro, por esas cosas que tiene la curiosidad, decidí jugar un poco, a un juego fácil, que no voy sobrado de tiempo, con el fichero adjunto. 
  1. Analicé el fichero con nuestro antivirus corporativo; el resultado fue un falso negativo, es decir no detecto nada.
  2. Lo abrí con un descompresor desde una maquina virtual, por si acaso. El zip estaba bien formado; en su interior había un fichero .exe con un icono de MS Word y con el mismo nombre que el zip pero en vez de .zip, era .doc y a continuación unos cuantos guiones bajos para que no se viese que el fichero terminaba con la extensión .exe.

      
    Contenido del fichero zip
  3. Bueno visto lo visto en el paso 1 y 2, me decidí a subir a Virus Total (podéis encontrar explicación del servicio ofrecido por Virus Total al principio del siguiente post) y aquí empezó lo que me hizo gracia, porque al subirlo, de los 41 motores de análisis que utiliza Virus Total, solo lo detectaba uno; en vista de esto y que al día siguiente nuestro antivirus corporativo me lo detecto como un troyano me enredé durante los siguientes días a subirlo varias veces de nuevo a Virus Total y hacer un seguimiento de detección.
    El resultado de este seguimiento lo podéis ver en la siguiente tabla y gráfico:

Tabla de valores de la evolución de la detección

Gráfica de evolución de la detección

Pasados más de 4 días, de los 41 motores, solo lo detectan 17; realmente ya no sé si se trata de un troyano o no, porque a raíz de la gran noticia que saltó durante el mes de febrero de este año uno ya no sabe que pensar, la noticia que me refiero es la que se puede ver en el mismo link que he dejado más arriba donde he mencionado que se hace una breve explicación del servició ofrecido por Virus Total.

A continuación os dejo los enlaces a los diez análisis, por orden cronológico, que he realizado de la misma muestra.
  1. http://www.virustotal.com/es/analisis/0818...174895
  2. http://www.virustotal.com/es/analisis/0818...269705
  3. http://www.virustotal.com/es/analisis/0818...285975
  4. http://www.virustotal.com/es/analisis/0818...293558
  5. http://www.virustotal.com/es/analisis/0818...337572
  6. http://www.virustotal.com/es/analisis/0818...355766
  7. http://www.virustotal.com/es/analisis/0818...382462
  8. http://www.virustotal.com/es/analisis/0818...426420
  9. http://www.virustotal.com/es/analisis/0818...473799
  10. http://www.virustotal.com/es/analisis/0818...541009

Hasta la próxima enfermos.

13 de marzo de 2010

Cabinas telefónicas con servicio de e-mail

Estando de visita a un colega por Zurich y aprovechando el viaje para hacer turismo por allí me he topado con una cabina telefónica curiosa, al menos para mí, ya que nunca antes lo había visto.
La cabina telefónica a parte del clásico teléfono que tenía, también tenía un aparato a parte con una pantalla y un teclado, así que al verlo he entrado para curiosear y he podido ver que en Zurich, las cabinas te dan posibilidad de enviar e-mails y FAX por el precio de 0,50 CHF.

Interior de una cabina telefónica de Zurich (Suiza)

Ah algunos os parecerá que es una tontería, y es que ahora con todo el mundo llevando tarifas de datos en el móvil que llevamos en el bolsillo, lo parece, pero yo hace ya algún tiempo, cuando estas tarifas no eran tan asequibles, me había encontrado con la necesidad de tener que enviar un e-mail y no poder hacerlo, y ya sé que hay cybers y todo eso, pero cuando necesitas uno no lo encuentras.

Lo curioso de todo esto, que ya que pones una pantalla con un teclado, porque no se da acceso a Internet también, ¿será que tienen miedo que se use para hacer hacking? (esta última pregunta me la planteo después de llevar algún tiempo leyendo temas de seguridad y hacking ético el cual me ha provocado una especie de obsesíon por la seguridad y no es de extrañar, cada día ves cosas nuevas y es que la gente que se dedica a este mundo lo peta absolutamente todo.

Por cierto, aparte de lo comentado, hay que decir que las cabinas, son cabinas, ya sea por el tema del frio o porque en este país puede que estén más acostumbrados ha darle un par de vueltas a las cosas antes de hacerlas, pero hablar en estas cabinas es algo bastante factible, ya que en las de España, según que calles, la comunicación solo es a una banda.


Exterior de una cabina telefónica de Zurich (Suiza)

Hasta la próxima enfermos.

30 de agosto de 2009

Protección contra el envío de SPAM (2/2)

conjuntoEntradas() {
  Protección contra el envío de SPAM (1/2)
  Protección contra el envío de SPAM (2/2)
}

Invita a un amigo
Ya hace un tiempo que me pregunto que sentido continua teniendo la utilidad de Gmail de “Invita a un amigo”, porque ahora, no como al principio, cualquiera puede ir a Gmail y solicitar una cuenta de manera gratuita, digo ahora, porque al principio, cuando surgió el servicio no tepodías crear una si no era a través de una invitación que tenía que haber sido enviado desde dicha utilidad. La utilidad en si no es mi duda, es el número limitado de invitaciones, ya que la utilidad es una manera de facilitar que los usuarios hagan publicidad del servicio a sus conocidos y además aprovechar en que medida que usuarios han abandonado su cuenta anterior (de otro proveedor ya que saben además de cual se trata debido que es a la dirección que se les ha enviado la invitación) por una de Gmail en función de la utilidad que les están dando a esta y también mantener una relación entre cuentas de Gmail.

Ahora con la nueva medida la utilidad parece que vuelve a cobrar sentido, ya que si un colega tuyo recibe una invitación podrá crear una cuenta saltando se la engorrosa medida de seguridad de tener que meter su número de móvil, eso si, si te has ganado la reputación. La reputación, no sé como te la ganas, pero si la invitación proviene de una cuenta vinculada a una cuenta que se ha estado utilizando durante bastante tiempo (entiendo que de forma lícita) la nueva medida de seguridad no se aplica, al menos hasta un nivel de jerarquía 2, pongo un ejemplo:

Yo he probado con mi cuenta X de Gmail, con bastante antigüedad con la cual no he hecho cosas malas, invito a un amigo y este se crea una cuenta Y saltándose la medida de seguridad, luego Y ha invitado a otro y ha creado la cuanta Z el cuál también se ha saltado la medida de seguridad.

Desconozco la profundidad de la jerarquía, pero lo que si es cierto es que si la invitación se envía de una cuenta recién creada (en esta has pasado por la medida de seguridad) el invitado tendrá que pasar también por la medida de seguridad.

Después de tantas pruebas ya empezaba a dudar si esto no era así, ya que podrían estar filtrando mi IP, pero la conclusión es que no porque después de probar la invitación desde una cuenta sin reputación, he podido crear otra saltando la medida de seguridad ya que la he enviado desde una cuenta con reputación.

Parece que si que hay un filtrado de cuentas sobre el envío de invitaciones a una misma cuenta, al menos en un breve espacio de tiempo, es decir en cierta medida el envío de invitaciones a una misma cuenta se descartan sin informar al usuario; retomando el ejemplo anterior he podido enviar una de X y Y a una misma cuenta y las he recibido sin problema, pero cuando he intentado enviar otra más pero desde la cuenta sin reputación (la cuenta que he creado pasando por la medida de seguridad) la invitación no ha llegado y he tenido que utilizar otra para poder probar lo ya comentado.

Otras medidas de seguridad
Para finalizar solo me gustaría mencionar otras de las medidas de seguridad que ofrece Gmail:
  1. Utilizar el correo con acceso SSL (Se activa en las opciones de configuración).
  2. Información de los 5 últimos accesos a la cuenta (Se puede encontrar al final de la página central de cualquier vista).
  3. Reportar phishing (Se encuentra dentro al principio de un correo, dentro del menú de opciones de este).


    Menú de opciónes de un correo

Hasta la próxima enfermos

26 de agosto de 2009

Protección contra el envío de SPAM (1/2)

conjuntoEntradas() {
  Protección contra el envío de SPAM (1/2)
  Protección contra el envío de SPAM (2/2)
}

Gmail ha decidido añadir un granito más de arena a la protección de sus usuarios y a la lucha contra el abuso que se le puede dar a su servicio de cuentas de correo electrónico gratuito.

La última medida tomada
La última medida que ha puesto en funcionamiento para proteger el registro de nuevas cuentas y así evitar que se puedan crear de manera indiscriminada para el envío de spam ha sido la de tener que registrar un número de teléfono móvil.

Según indican de esta manera pueden tener controlado el número de cuentas creadas por un mismo número de teléfono, además de poder limitar el número de cuentas que se puedan crear con este mismo número.

La medida se basa en enviar un SMS con un código de invitación que te permite registrar la cuenta que deseabas crear y cuyos datos ya has introducido en el formulario de la página anterior.

Es una medida interesante y la verdad es que les permite controlar la creación de sus cuentas, pero la verdad es que pierde usabilidad y es bastante intrusiva.

Se pierde usabilidad por varias razones:
  1. Es posible que no tengas teléfono móvil. Es algo bastante improbable pero puede pasar; ellos ya lo anticipan y dicen que le puedes pedir a un amigo que te haga el favor de permitir poner su número para poder recibir el código de invitación que te solicitan.
  2. Es posible que el operador de telefonía que utilices te cobre por ese mensaje, por lo que la creación de la cuenta deja de ser totalmente gratuita.
  3. Se puede dar el caso que no lo recibas. Te indican que esperes un plazo es de 24 horas y si no lo recibe lo vuelvas a solicitar. 24 horas para crear una cuenta es bastante tiempo, además hay que añadirle que es posible que lo tengas que volver a solicitar.
  4. Hay países que no funciona. Por lo que depende donde vivas ya no tienes posibilidad de tener una cuenta Gmail.
  5. El formulario de registro lo llenas antes, y luego te encuentras con esto, por lo que si no te gusta que Google tenga tú móvil, has perdido un valioso tiempo llenando el formulario de registro. No estaría de más aviarlo antes de empezar a llenar el formulario de registro.
Es intrusiva porque te están solicitando un número de móvil, algo que te limita si quieres mantener el anonimato, o aunque no lo quieras mantener, es posible que no quieras que Google tenga que tener tu número de móvil solo por el simple hecho de tener una cuanta de correo con ellos. Goolge, como es lo que se espera, indica que solo utilizará el número para limitar el número de cuentas creadas con ese número y par más información te invita a que te leas la política de privacidad de Gmail.
Hasta la próxima enfermos