Mostrando entradas con la etiqueta phishing. Mostrar todas las entradas
Mostrando entradas con la etiqueta phishing. Mostrar todas las entradas
domingo, 8 de abril de 2007
Vía una entrada en Barrapunto, llego a un artículo en el País titulado "Proveedores de Internet se unen contra el correo basura" donde se recoge la noticia de que los 26 principales proveedores españoles se han puesto de acuerdo en utilizar SPF para luchar contra el spam. Lógico, teniendo en cuenta que sólo un 15% de los mensajes que pululan por sus servidores y redes son reales, lo que indica que la mayor parte de sus recursos están siendo utilizados por el lado oscuro.
SPF (Sender Policy Framework) es una especificación experimental publicada por la IETF en la RFC 4408 (abril 2006), y describe un conjunto de técnicas para evitar la utilización de dircciones de email falsas en los mensajes que circulan por la red.
Aunque creo que esto ya lo he comentado en otras ocasiones, uno de los principales problemas que hacen florecer el spam, scam, phishing, y alguna que otra atrocidad más, es la inocencia con la que fue creado el protocolo SMTP, utilizado para los envíos de mensajes de correo electrónico entre servidores. En este estándar no se establece ninguna técnica para asegurar la veracidad del remitente, por lo que cualquiera puede escribir en nombre de otro, hacerse pasar por quien desee, o simplemente inventar sobre la marcha un emisor, existente o no.
Por eso los mensajes de spam que recibimos pueden provenir incluso de personas que conocemos, pertenecientes a nuestro propio dominio, compañeros que tenemos sentados justo a nuestro lado, etc.
El SPF pretende acabar con esto, pues define un sistema de comprobación en tiempo real de la veracidad del remitente, así como del servidor desde el que se envía un mensaje, consistente, por una parte, en incluir en los registros MX de cada dominio emisor de correos una línea donde se indique la dirección IP desde la que pueden ser enviados. De esta forma, cuando otro servidor SMTP recibe un mensaje con un remitente del dominio anterior, puede consultar esos registros y comprobar si la IP desde la que está recibiendo el email está autorizada para enviarlo.
Lo vemos con un ejemplo real, por suerte (?) tengo bastantes para elegir. Hoy he recibido un correo desde la dirección finkenhoferqov0@hotmail.com aconsejándome soluciones para mis terribles problemas de erección (¿cómo se habrán enterado? :-D). Por suerte, según me indican, la mitad de los varones los sufren, el que no se consuela es porque no quiere.
Si rastreo el mensaje, veo que ha llegado a mi servidor desde la dirección IP 71.186.100.38, cuyo nombre parece ser pool-71-186-100-38.chi01.dsl-w.verizon.net. Si seguimos escarbando, podemos obtener la siguiente información de esta IP:
Y aunque las herramientas de geoposicionamiento de direcciones IP no son el colmo de la precisión, podríamos incluso atrevernos a conjeturar dónde se encuentra el spammer, en Washington.
A la vista de estos datos, se trata de un equipo que utiliza una dirección IP dinámica, conectado a través de una DSL que, de forma voluntaria o no, está enviando spam, cual poseso, al resto del mundo. Está claro que ningún spammer decente dejaría ver todos sus datos así, por lo que, o bien se trata de un PC secuestrado (zombie), o bien toda la información que deja ver es falsa.
En cualquier caso, está claro que no se trata de Hotmail, de donde era, como recordaréis, el remitente del mensaje.
Si tanto mi servidor como Hotmail utilizaran SPF, se habría rechazado el mensaje de forma directa. Al recibir la dirección del remitente, habría acudido a los registros MX de Hotmail para averiguar si la IP desde la que se ha producido la conexión es válida para envíos @hotmail.com, y, obviamente, de esta comprobación siempre se determinaría que el emisor es inválido.
Todo esto está muy bien, personalmente creo bastante en este tipo de soluciones colaborativas y de consenso para luchar contra el spam, más incluso que en las de análisis de contenido que, como ya he comentado en posts anteriores, tienen bastantes dificultades para garantizar el filtrado correcto dada la gran variedad de trucos utilizados.
El problema es precisamente su implementación en la práctica, y eso que en el caso del SPF no es especialmente compleja, todo lo contrario. Está claro que si todos los ISP del mundo utilizaran este método, el spam, fishing y en general cualquier historia basada en la utilización de remitentes falsos tendrían los días contados... al menos en la forma en que hoy los conocemos, claro.
SPF (Sender Policy Framework) es una especificación experimental publicada por la IETF en la RFC 4408 (abril 2006), y describe un conjunto de técnicas para evitar la utilización de dircciones de email falsas en los mensajes que circulan por la red.
Aunque creo que esto ya lo he comentado en otras ocasiones, uno de los principales problemas que hacen florecer el spam, scam, phishing, y alguna que otra atrocidad más, es la inocencia con la que fue creado el protocolo SMTP, utilizado para los envíos de mensajes de correo electrónico entre servidores. En este estándar no se establece ninguna técnica para asegurar la veracidad del remitente, por lo que cualquiera puede escribir en nombre de otro, hacerse pasar por quien desee, o simplemente inventar sobre la marcha un emisor, existente o no.
Por eso los mensajes de spam que recibimos pueden provenir incluso de personas que conocemos, pertenecientes a nuestro propio dominio, compañeros que tenemos sentados justo a nuestro lado, etc.
El SPF pretende acabar con esto, pues define un sistema de comprobación en tiempo real de la veracidad del remitente, así como del servidor desde el que se envía un mensaje, consistente, por una parte, en incluir en los registros MX de cada dominio emisor de correos una línea donde se indique la dirección IP desde la que pueden ser enviados. De esta forma, cuando otro servidor SMTP recibe un mensaje con un remitente del dominio anterior, puede consultar esos registros y comprobar si la IP desde la que está recibiendo el email está autorizada para enviarlo.
Lo vemos con un ejemplo real, por suerte (?) tengo bastantes para elegir. Hoy he recibido un correo desde la dirección finkenhoferqov0@hotmail.com aconsejándome soluciones para mis terribles problemas de erección (¿cómo se habrán enterado? :-D). Por suerte, según me indican, la mitad de los varones los sufren, el que no se consuela es porque no quiere.
Si rastreo el mensaje, veo que ha llegado a mi servidor desde la dirección IP 71.186.100.38, cuyo nombre parece ser pool-71-186-100-38.chi01.dsl-w.verizon.net. Si seguimos escarbando, podemos obtener la siguiente información de esta IP:
OrgName: Verizon Internet Services Inc.
OrgID: VRIS
Address: 1880 Campus Commons Dr
City: Reston
StateProv: VA
PostalCode: 20191
Country: US
NetRange: 71.160.0.0 - 71.191.255.255
CIDR: 71.160.0.0/11
NetName: VIS-BLOCK
Y aunque las herramientas de geoposicionamiento de direcciones IP no son el colmo de la precisión, podríamos incluso atrevernos a conjeturar dónde se encuentra el spammer, en Washington.A la vista de estos datos, se trata de un equipo que utiliza una dirección IP dinámica, conectado a través de una DSL que, de forma voluntaria o no, está enviando spam, cual poseso, al resto del mundo. Está claro que ningún spammer decente dejaría ver todos sus datos así, por lo que, o bien se trata de un PC secuestrado (zombie), o bien toda la información que deja ver es falsa.
En cualquier caso, está claro que no se trata de Hotmail, de donde era, como recordaréis, el remitente del mensaje.
Si tanto mi servidor como Hotmail utilizaran SPF, se habría rechazado el mensaje de forma directa. Al recibir la dirección del remitente, habría acudido a los registros MX de Hotmail para averiguar si la IP desde la que se ha producido la conexión es válida para envíos @hotmail.com, y, obviamente, de esta comprobación siempre se determinaría que el emisor es inválido.
Todo esto está muy bien, personalmente creo bastante en este tipo de soluciones colaborativas y de consenso para luchar contra el spam, más incluso que en las de análisis de contenido que, como ya he comentado en posts anteriores, tienen bastantes dificultades para garantizar el filtrado correcto dada la gran variedad de trucos utilizados.
El problema es precisamente su implementación en la práctica, y eso que en el caso del SPF no es especialmente compleja, todo lo contrario. Está claro que si todos los ISP del mundo utilizaran este método, el spam, fishing y en general cualquier historia basada en la utilización de remitentes falsos tendrían los días contados... al menos en la forma en que hoy los conocemos, claro.
lunes, 22 de mayo de 2006
Según la Wikipedia, el término Phishing viene del inglés Fish (pescar), debido a que precisamente se trata de las técnicas que usan los pobladores del lado oscuro de la red para pescar datos personales y confidenciales de incautos navegantes utilizando señuelos y trampas, a veces sofisticadas, a veces bastante inocentes.
Este es el mensaje que he recibido hoy de la dirección (falsa, por supuesto) support@cajamadrid.es, no os lo perdáis porque no tiene desperdicio:
Bueno, si partimos de que Luis Perez Monreal (nombre inventado, con toda seguridad) no maneja muy bien el castellano, podremos entender cómo un señor designado por una prestigiosa institución financiera para informarnos sobre nuevas medidas de seguridad es capaz de cometer tal cantidad de atropellos a esta lengua en tan poco espacio. En cualquier caso, se trata de un experto en seguridad, no de García Márquez. ;-)
¿Y qué me dicen de basar el acceso a los datos, cuentas y fondos personales en una pregunta personal del tipo "Nombre de su primer colegio"? ¿Eso es lo que da de sí el departamento antifraude? :-D Es simplemente ridículo.
Desde luego esto debería ser suficiente para no creérselo. Si, además, sumamos la gran cantidad de apariciones en los medios y la propia difusión que hacen desde estas entidades de que no deben prestar atención a este tipo de mensajes, parece asombroso que todavía haya usuarios que piquen el anzuelo.
Pero no podía resistirme: cual cándido pececillo, he picado el enlace del mensaje y me he encontrado con una página impecablemente copiada de la original de Caja Madrid. Sólo he echado en falta el candado en el pie del navegador indicando que se trata de una página web segura. Por lo demás, tanto el interfaz visual como los mecanismos de interacción son idénticos (de hecho, copiados a nivel de código HTML) del original.
Una vez allí, el usuario es guiado por un asistente en el que se solicitan distintos datos de acceso: DNI, número de contrato, claves de acceso, y algunos datos más, aunque aparentemente inofensivos. Al finalizar, nos obsequian con un texto de agradecimiento (sincero, eso sí) y nos redireccionan a la página, esta vez real, de la Caja. Buen trabajo, sí señor.
Uno, que es curioso por naturaleza, ha ido a consultar el whois en un registrador de dominios, a ver qué se conoce de los propietarios de bancamadrid.com, al que hace referencia el mensaje, obteniendo:
Obviamente, los datos de registro también son falsos... La empresa MapInfo existe, tiene una sede en Windsor, incluso Iain Daws es uno de sus directivos. Ahora bien, dudo mucho que se dedique a hacer estas cosas.
Destaca, además, la fecha de creación del dominio, el 21 de mayo, ¡ayer! Se ve que el organizador de esta fiesta no tenía otra cosa mejor que hacer un domingo por la tarde que registrar un dominio con un nombre comercial atractivo, bastante similar al de la entidad financiera, y ponerse a enviar correos a diestro y siniestro.
Como último dato, buscando la dirección IP en la que está montado el servicio web (69.248.133.121) en varios localizadores geográficos gratuitos, resulta que está en Estados Unidos, más concretamente en New Jersey o Virginia, según la fuente que consultemos. Como para ir a buscarlos, vaya.
En fin, valga todo esto para, una vez más, recordar que nunca debe prestársele atención a un correo procedente de una entidad bancaria que le solicite introducción o envío de datos personales o claves, por mucho que parezca haber sido remitido desde las mismas.
Este es el mensaje que he recibido hoy de la dirección (falsa, por supuesto) support@cajamadrid.es, no os lo perdáis porque no tiene desperdicio:
Apreciado Cliente de Banca en Linea,
Caja Madrid siempre trata de encontrar sus expectativas mas altas. Por eso usamos la ultima tecnologia en seguridad para nuestros clientes.
Por lo tanto nuestro departamento de antifraude ha desarrollado un nuevo sistema de seguridad que elimine cualquier posibilidad del acceso de la tercera persona a sus datos, cuentas ni fondos.
Este sistema esta construido en la utilizacion de una pregunta secreta y respuesta.
Su respuesta secreta seria usada para confirmar su identidad cuando haga una operacion de pagos.
Es obligatorio para todos los clientes de Caja Madrid Banca en Linea usar este sistema de seguridad.
Nosotros consejo para usted es que introduzca su pregunta secreta y su respuesta de su cuenta cuanto antes.
Si el registro no es realizado dentro de 14 dias su cuenta sera suspendida temporalmente hasta que su registro sea completado.
Esto solo le va a costar unos minutos de su tiempo y va a tener una seguridad mucho mas elevadar.
Para comenzar el registro por favor pinche aqui : http://oi.bancamadrid.com/
Atentamente,
Luis Perez Monreal.
Departamento de seguridad y
asistencia al cliente.
Caja Madrid.
Bueno, si partimos de que Luis Perez Monreal (nombre inventado, con toda seguridad) no maneja muy bien el castellano, podremos entender cómo un señor designado por una prestigiosa institución financiera para informarnos sobre nuevas medidas de seguridad es capaz de cometer tal cantidad de atropellos a esta lengua en tan poco espacio. En cualquier caso, se trata de un experto en seguridad, no de García Márquez. ;-)
¿Y qué me dicen de basar el acceso a los datos, cuentas y fondos personales en una pregunta personal del tipo "Nombre de su primer colegio"? ¿Eso es lo que da de sí el departamento antifraude? :-D Es simplemente ridículo.
Desde luego esto debería ser suficiente para no creérselo. Si, además, sumamos la gran cantidad de apariciones en los medios y la propia difusión que hacen desde estas entidades de que no deben prestar atención a este tipo de mensajes, parece asombroso que todavía haya usuarios que piquen el anzuelo.
Pero no podía resistirme: cual cándido pececillo, he picado el enlace del mensaje y me he encontrado con una página impecablemente copiada de la original de Caja Madrid. Sólo he echado en falta el candado en el pie del navegador indicando que se trata de una página web segura. Por lo demás, tanto el interfaz visual como los mecanismos de interacción son idénticos (de hecho, copiados a nivel de código HTML) del original.
Una vez allí, el usuario es guiado por un asistente en el que se solicitan distintos datos de acceso: DNI, número de contrato, claves de acceso, y algunos datos más, aunque aparentemente inofensivos. Al finalizar, nos obsequian con un texto de agradecimiento (sincero, eso sí) y nos redireccionan a la página, esta vez real, de la Caja. Buen trabajo, sí señor.
Uno, que es curioso por naturaleza, ha ido a consultar el whois en un registrador de dominios, a ver qué se conoce de los propietarios de bancamadrid.com, al que hace referencia el mensaje, obteniendo:
domain: bancamadrid.com
owner: Iain Daws
organization: MapInfo Ltd
email: xprojectp6@yahoo.com
address: Minton Place
city: Windsor
state: --
postal-code: SL4 1EG
country: GB
phone: 01753848240
created: 2006-05-21 19:24:10
modified: 2006-05-21 21:35:04
expires: 2007-05-21 15:24:10
Obviamente, los datos de registro también son falsos... La empresa MapInfo existe, tiene una sede en Windsor, incluso Iain Daws es uno de sus directivos. Ahora bien, dudo mucho que se dedique a hacer estas cosas.
Destaca, además, la fecha de creación del dominio, el 21 de mayo, ¡ayer! Se ve que el organizador de esta fiesta no tenía otra cosa mejor que hacer un domingo por la tarde que registrar un dominio con un nombre comercial atractivo, bastante similar al de la entidad financiera, y ponerse a enviar correos a diestro y siniestro.
Como último dato, buscando la dirección IP en la que está montado el servicio web (69.248.133.121) en varios localizadores geográficos gratuitos, resulta que está en Estados Unidos, más concretamente en New Jersey o Virginia, según la fuente que consultemos. Como para ir a buscarlos, vaya.
En fin, valga todo esto para, una vez más, recordar que nunca debe prestársele atención a un correo procedente de una entidad bancaria que le solicite introducción o envío de datos personales o claves, por mucho que parezca haber sido remitido desde las mismas.
