Esta técnica es tan antigua como la Web, y por este motivo (y no por otros ;-)) estamos en las listas de vendedores de viagra y alargadores de miembros todos aquellos que aún conservamos buzones desde los tiempos en que Internet era un lugar cándido y apacible. Años atrás, poner tu email real en una web, foro o tablón era lo más normal y seguro.
Pero los tiempos han cambiado. Hoy en día, publicar la dirección de email en una web es condenarla a sufrir la maldición del spam diario, y sin embargo, sigue siendo un dato a incluir en cualquier sitio donde se desee facilitar el contacto vía correo electrónico tradicional. Y justo por esa razón existen las técnicas de ofuscación: permiten, o al menos intentan, que las direcciones email sean visibles y accesibles para los usuarios de un sitio web, y al mismo tiempo sean indetectables para los robots, utilizando para ello diversas técnicas de camuflaje en el código fuente de las páginas.
Desafortunadamente, ninguna técnica de ofuscación es perfecta. Algunas usan javascript, lo cual impide su uso en aquellos usuarios que navegan sin esta capacidad (hay estadísticas que estiman que son sobre el 5%); otras presentan problemas de accesibilidad, compatibilidad con algunos navegadores o impiden ciertas funcionalidades, como que el sistema abra el cliente de correo predeterminado al pulsar sobre el enlace; otras, simplemente, son esquivables por los spammers de forma muy sencilla.
En el fondo se trata de un problema similar al que encontramos en la tradicional guerra virus vs. antivirus: cada medida de protección viene seguida de una acción en sentido contrario por parte de los spammers. Una auténtica carrera, vaya, que por la pinta que tiene va a durar bastante tiempo.
En 2006, Silvan Mühlemann comenzó un interesante experimento. Creó una página Web en la que introdujo nueve direcciones de correo distintas, y cada una utilizando un sistema de ofuscación diferente:
- Texto plano, es decir, introduciendo un enlace del tipo:
<a href="mailto:user@myserver.xx">email me</a>
- Sustituyendo las arrobas por "AT" y los puntos por "DOT", de forma que una dirección queda de la forma:
<a href="mailto:userATserverDOTxx">email me</a>
- Sustituyendo las arrobas y puntos por sus correspondientes entidades HTML:
<a href="mailto:user@server.xx">email me</a>
- Introduciendo la dirección con los códigos de los caracteres que la componen:
<a href="mailto:%73%69%6c%76%61%6e%66%6f%6f%62%61%72%34%40%74%69%6c%6c%6c%61%74%65%65%65%65%65">email me</a>
- Mostrando la dirección de correo sin enlace y troceándola con comentarios HTML, que el usuario podrá ver sin problema como user@myserver.com aunque los bots se encontrarán con algo como:
user<!-- -->@<!--- @ -->my<!-- -->server.<!--- . -->com
- Construyendo el enlace desde javascript en tiempo de ejecución con un código como el siguiente:
var string1 = "user";
var string2 = "@";
var string3 = "myserver.xx";
var string4 = string1 + string2 + string3;
document.write("<a href=" + "mail" + "to:" + string1 +
string2 + string3 + ">" + string4 + "</a>"); - Escribiendo la dirección al revés en el código fuente y cambiando desde CSS la dirección de presentación del texto, así:
<style type="text/css">
span.codedirection { unicode-bidi:bidi-override; direction: rtl; }
</style>
<span class="codedirection">moc.revresym@resu</span> - Introduciendo texto incorrecto en la dirección y ocultándolo después desde CSS:
<style type="text/css">
span.displaynone { display:none; }
</style>
Email me: user@<span class="displaynone">goaway</span>myserver.net - Generando el enlace desde javascript partiendo de una cadena codificada en ROT13, según una idea original de Christoph Burgdorfer:
<script type="text/javascript">
document.write('<n uers=\"znvygb:fvyinasbbone10@gvyyyngr.pbz\" ery=\"absbyybj\">'.replace(/[a-zA-Z]/g, function(c){return String.fromCharCode((c<="Z"?90:122)>=(cc=c.charCodeAt(0)+13)?c:c-26);}));
</script>silvanfoobar's Mail</a>
Las conclusiones que obtuvo son las siguientes: incluir la dirección de correo en texto plano y sin protección (opción 1) generó 21 Megabytes de spam; las peores técnicas, la codificación URL (4) y el troceado de la dirección con comentarios (5) lo redujeron a 7-8Mb; ya la sustitución de la arroba y puntos por las entidades HTML (3) dejó el spam en 1.6 Mb, lo que implica una reducción mayor al 90% sobre la primera alternativa. El uso de AT y DOT (2), así como la generación por javascript (6) dieron como resultado la práctica ausencia de spam, que ya con los tres métodos restantes se redujo a cero absoluto.
Por tanto, atendiendo al resultado de este experimento, si estamos desarrollando una página que asume la existencia de javascript podríamos utilizar el método del ROT13 (9) para generar los enlaces
mailto:
con ciertas garantías de éxito frente al spam. Podéis usar el código anterior, cambiando el texto codificado (en negrita) por el que generéis desde esta herramienta (ojo: hay que codificar la etiqueta de apertura completa, como <a href="mailto:loquesea">
, incluidos los caracteres de inicio "<" y fin ">", pero sin introducir el texto del enlace ni el cierre </a>
de la misma).También podemos utilizar alternativas realmente ofuscadoras, como la ofrecida por el Enkoder de Hivelogic, una herramienta on-line que nos permite generar código javascript listo para copiar y pegar, cuya ejecución nos proporcionará un enlace
mailto:
completo en nuestras páginas.Pero atención, que el uso de javascript no asegura el camuflaje total y de por vida de la dirección de correo por muy codificada que esté en el interior del código fuente. Un robot que incluya un intérprete de este lenguaje y sea capaz de ejecutarlo podría obtener el email finalmente mostrado, aunque esta opción, por su complejidad y coste de proceso, no es todavía muy utilizada; sí que es cierto que algunos recolectores realizan un análisis del código javascript para detectar determinadas técnicas, por lo que cuando más ofuscada y personalizada sea la generación, mucho mejor.
En caso contrario, si no podemos usar javascript, lo tenemos algo más complicado. Con cualquiera de las soluciones CSS descritas en los puntos 7 y 8 (ambas han conseguido aguantar el tiempo del experimento sin recibir ningún spam), incluso una combinación de ambas, es cierto que el usuario de la página podrá leer la dirección de correo, mientras que para los robots será un texto incomprensible. Sin embargo, estaremos eliminando la posibilidad de que se abra el gestor de correo del usuario al cliquear sobre el enlace, así como añadiendo un importante problema de accesibilidad en la página. Por ejemplo, si el usuario decide copiar la dirección para pegarla en la casilla de destinatario de su cliente, se llevará la sorpresa de que estará al revés o contendrá caracteres extraños. Por tanto, aunque pueda ser útil en un momento dado, no es una solución demasiado buena.
La introducción de "AT" y "DOT", o equivalentes en nuestro idioma como "EN" y "PUNTO", con adornos como corchetes, llaves o paréntesis podrían prestar una protección razonable, pero son un incordio para el usuario y una aberración desde el punto de vista de la accesibilidad. Además, el hecho de que se haya recibido algún mensaje en el buzón que utilizaba esta técnica ya implica que hay spambots que la contemplan y, por tanto, en poco tiempo podría estar bastante popularizada, por lo que habría que buscar combinaciones surrealistas, más difíciles de detectar, como "juanARROBICAservidorPUNTICOcom", o "juanCAMBIA_ESTO_POR_UNA_ARROBAservidorPON_AQUI_UN_PUNTOcom". Pero lo dicho, una incomodidad para el usuario en cualquier caso.
Hay otras técnicas que pueden resultar también válidas, como introducir las direcciones en imágenes, applets java u objetos flash incrustados, redirecciones y manipulaciones desde servidor, el uso de captchas, y un largo etcétera que de hecho se usan en multitud de sitios web, pero siempre nos encontramos con problemas similares: requiere disponer de algún software (como flash, o una JVM), una característica activa (por ejemplo scripts o CSS), o atentan contra la usabilidad y accesibilidad del sitio web.
Como comentaba al principio, ninguna técnica es perfecta ni válida eternamente, por lo que queda al criterio de cada uno elegir la más apropiada en función del contexto del sitio web, del tipo de usuario potencial y de las tecnologías aplicables en cada caso.
La mejor protección es, sin duda, evitar la inclusión de una direcciones de email en páginas que puedan ser accedidas por los rastreadores de los spammers. El uso de formularios de contacto, convenientemente protegidos por sistemas de captcha gráficos (¡los odio!) o similares, pueden ser un buen sustituto para facilitar la comunicación entre partes sin publicar direcciones de correo electrónico.
Publicado en: www.variablenotfound.com.
Publicado por José M. Aguilar a las 9:52 p. m.
Etiquetas: css, javascript, ofuscación de emails, scripting, spam, web, xhtml
DKIM pretende controlar los mensajes haciendo que el servidor de correo del que proceden firme digitalmente los envíos. De esta forma se consigue, en primer lugar, poder verificar el dominio al que pertenece el remitente de un mensaje y, en segundo lugar, asegurar la integridad del mismo permitiendo detectar si el contenido de éste ha sido alterado durante su tiempo de tránsito por el ciberespacio.
Según proponen, para echar a andar DKIM en un servidor de mensajes SMTP, deberían generarse un par de claves, pública y privada. La primera de ellas sería publicada a través del servicio estándar DNS, mientras que la segunda sería utilizada internamente para firmar digitalmente los mensajes.
Cuando un usuario autorizado envía un correo, el servidor generaría la firma del contenido en tiempo real y la añadiría a los encabezados del mensaje. El servidor del destinatario extraería la firma del mensaje y, mediante una consulta al DNS del origen, obtendría su clave pública, con lo que podría verificar la validez de la firma.
De esta forma, en función del resultado de la comprobación, el destinatario podría aplicar políticas locales de filtrado. Por ejemplo, si el dominio origen del mensaje existe y la firma es válida, es probable que se trate de un mensaje que debe ser entregado al destinatario, pero se le podrían pasar filtros basados en contenido para una mayor seguridad. Si la firma no es correcta o no aparece, podrían tomarse medidas de descarte o marcado del mensaje.
¿Y quién anda detrás de este invento? Pues ni más ni menos que Yahoo! (iniciadores del proyecto), Cisco, PGP y Sendmail, y según comenta su inventor, Mark Delany, también han contado con la colaboración de IBM, Earthlink, Microsoft, Spamhaus, Google, PayPal y Alt-N, entre otros.
En resumen, se trata de un nuevo intento para acabar con el envío de mensajes desde destinatarios incorrectos o servidores "no creíbles", basándose esta vez en la utilización de criptografía de clave pública. Si bien no es de por sí una tecnología que resuelva el problema al 100%, sí que podría colaborar mucho. Además, lo más probable es que la solución final sea una combinación de distintas técnicas, así que bienvenida sea.
Particularmente me convence la idea de aplicar técnicas criptográficas para asegurar el correo, así como la utilización de estándares y soluciones colaborativas consensuada entre proveedores. Sin embargo, este último aspecto es su punto más débil: necesita una adopción global para que su efectividad pueda ser razonable.
En cualquier caso, todo esto forma parte de la lógica y necesaria evolución de tecnologías que tiene que acontecer hasta que la humanidad consiga dar con la forma para la eliminación definitiva del spam, phishing, spoofing y otras lindezas virtuales.
Publicado por José M. Aguilar a las 8:01 p. m.
Etiquetas: antispam, estándares, protocolos, seguridad, servicios on-line, spam
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.
Recordemos que los contenidos textuales se presentan en las imágenes mezclados con figuras y fondos que complican enormemente su detección automática. Si a la dificultad de detectar texto en esta maraña binaria se une que el mensaje está troceado en varias imágenes, las cuales se maquetan y posicionan después para que la lectura tenga sentido, esto se convierte en una labor prácticamente imposible.
Observad este ejemplo. El mensaje"Viagra" ha sido dividido en 6 imágenes, que se maquetan de forma consecutiva; prácticamente ninguna de ellas contiene texto que pudiera ser detectado por un OCR, y sin embargo se puede leer perfectamente.
Es posible que la solución a este problema sea intentar renderizar (¡uuf, vaya verbo, menos mal que la Wikipedia lo incluye!) el contenido de los mensajes, incluyendo sus imágenes, y someter el resultado a un OCR, de forma que si existen textos queden al descubierto. Sin embargo, además de la tremenda potencia de cálculo que hace falta para procesar en tiempo real esta información, sería fácil esquivarlo incluyendo secuencias animadas, como ya se comentó en un post anterior.
Si encuentro alguna solución brillante al problema, os la cuento. ;-)
Sí, y no estoy hablando de incluir personajes de la Warner en los mensajes. Se trata de enviar a los destinatarios mensajes con archivos gráficos (normalmente gifs) que contienen varios frames que, siendo visualizados de forma consecutiva, dan la sensación de movimiento, como si se tratase de una película.
Habitualmente, los primeros frames van en blanco, o con elementos de ruido para despistar a las herramientas OCR, que, parece ser, en un principio asumían que el archivo a rastrear sólo contenía una imagen. Los frames siguientes van componiendo el mensaje de forma sucesiva, a veces entremezclando los textos con píxeles y líneas de ruido.
También escuché hace tiempo que esto mismo se utilizaba para enviar spam con mensajes subliminales, que se servían de GIFs animados para mostrar durante un lapso de tiempo prácticamente imperceptible el texto describiendo el producto a vender... Esto, a diferencia del resto de técnicas que comento en los posts, no lo he visto nunca con mis propios ojos; no sé si es porque soy demasiado lento y mi subconsciente es incapaz de asimilar estos mensajes, o bien debido a que nunca he recibido un mensaje de este tipo.
Vía Slashdot, he encontrado un interesante artículo donde se propone una técnica para luchar contra el spam distinta a todas las comentadas hasta el momento. Pienso que no es la panacea, pero está bien saber que, al menos, hay gente dispuesta a acabar con esta lacra (además de Bill Gates, que como prometió hace un par de años, debe estar ya a punto de erradicarla ;-)).
El sistema consiste en centrarse en el análisis estadístico del tráfico desde varias ópticas, obviando el contenido de los mensajes. Como recogen en su artículo, los expertos de HexView recalcan que:
- Los mensajes son relativamente pequeños.
- Se envían en bloques.
- Los mensajes enviados en cada bloque son muy similares.
- El emisor de los mensajes envía muchos en un periodo muy corto de tiempo.
Tomando como partida estas premisas, y a que hay únicamente dos aspectos no manipulables por los spammers en los mensajes, que son las direcciones IP de origen y destino usadas por la conexión TCP sobre la que se transmiten, estos señores proponen el análisis de patrones según una metodología a la que llaman STP (de Source Trust Prediction, que viene a ser algo así como Predicción de Veracidad del Emisor).
A grandes rasgos, consiste en establecer un servidor intermedio (STP server) al que cada MTA (Mail Transport Agent, Agente de Transporte de Correo, o software de servidor encargado de gestionar los envíos como Exchange, Postfix, etc.) informaría, antes de aceptar un mensaje, de la dirección IP del remitente y algunos datos básicos del mismo. Dado que el servidor STP estaría al mismo tiempo recibiendo esta información de multitud de STPs, podría analizar los patrones y devolver a cada uno la probabilidad de que se trate de Spam.
Hay muchos más detalles en la web de los creadores de la idea.
En mi opinión, vale más como filosofía que como idea implementable en el mundo real, pues presenta numerosas dificultades y contraindicaciones, apuntadas por sus propios autores:
- La dificultad de crear sistemas capaces de gestionar en tiempo real las peticiones de los MTAs, ¿imagináis la cantidad de información de que se trata? ¿quién podría disponer de esa infraestructura y mantenerla? ¿a cambio de qué?
- La enorme dificultad de poner de acuerdo a una gran mayoría de servidores y fabricantes de software para que adoptaran el método. Posiblemente, si se pudiera llegar a un acuerdo, existirían muchas más soluciones, y con toda probabilidad más eficientes y eficaces que esta.
- Podría suponer un peligro para la privacidad: en un único punto se podría concentrar demasiada información sobre el comportamiento de los usuarios en cuanto al envío de mensajes.
Personalmente, me gusta la idea de analizar el tráfico, combinarla con el análisis de contenidos y, siempre, de forma personalizada. Por ejemplo, las probabilidades de que me interese un mensaje recibido en mi buzón un domingo a las 3:00am escrito en inglés, con una imagen y algunas palabras dispersas son bastante escasas.
En cualquier caso, como comentaba antes, es interesante ver las novedades que aparecen en este mundillo, aunque sean puramente conceptuales.
Una de ellas consiste en añadir ruido a la imagen. El ser humano, a diferencia de los sistemas OCR, es perfectamente capaz de distinguir texto en el interior de un elemento gráfico aunque éste se encuentre rodeado de todo tipo de "adornos", como se muestra en la siguiente captura.
En el ejemplo, se puede observar cómo el texto que contiene el mensaje publicitario se ha incluido sobre un fondo no uniforme ni en sus formas ni en los colores utilizados. Incluso a ojo a veces es complicado leer determinados fragmentos... difícil tarea la del sistema de reconocimiento óptico, ¿eh?
Además, si lo que se pretende es llamar la atención del lector, no se puede negar que el resultado es de lo más llamativo.
Sin embargo, cuando, además de las imágenes, se incluye texto en el mensaje, las probabilidades de que una herramienta de filtrado de spam lo detecte como spam son enormes, por lo que entonces simplemente estaremos haciendo los mensajes más pesados y la efectividad seguirá siendo nula... ¿Cuál podría ser la solución al problema?
Efectivamente, prescindir de los elementos textuales en los correos publicitarios, o usarlos simplemente como elementos de despiste, e incluir todos los mensajes dentro de las imágenes enviadas a las víctimas. Un ejemplo se muestra en la imagen adjunta, tomada de un correo no deseado que he recibido recientemente.
En el mensaje se incluía esta imagen, acompañada de un texto enorme que con toda seguridad dejaría fuera de juego a un sistema de detección de spam basado en simples estadísticas de aparición de textos:
had a guess of what was coming. I saw I must speak soon before my strange after the wind rose, for at first it was dead calm to see the tempted to lend him a round sum, and see the last of him for good; but like a peal of bells, her face gay as a May morning; and I own, He told you to. she cried. It is no sense denying it, you said He heard the business out with a great deal of eagerness; and when it constancy upon my studies; and made out to endure the time till Alan never have been so troublesome as make the offer. But when he as good door. I made my disposition, and paid and dismissed the men so that yours from the first day, if you would have had a gift of me. she of a prospect, where there stood out over a brae the two sails of a with her head down, looking constantly on the sand, and made so tender forth. My mind misgives me, it will be some ill to Alan. Open it, know you have had more since you were here in Leyden, though you where was no man to be seen, nor any house of man, except just Bazins By your leave, Miss Drummond, said I, I must speak to your father by what a mercy had befallen me; and sitting over against her, with her out of Scotland and prompted by the same affair, which was the death of side, there is no objection to the marriage, but I have good reason to faithfully expended on my daughter, who is well, and desires to be I bid you beware. I will stand no more baiting, he broke out. I am unfit to come into a young maids life, and perhaps ding down her She shook her head at me with that same smile I could have struck her The which we did until the girl returned, and I must suppose would have no more let a wife be forced upon myself, than what I would let a The door was opened so quickly, even before I had the word out, that I streams of water running down, I would scarce think shame to weep hillock. Scarce any road came by there; but a number of footways position, where she had been entrapped into a moments weakness, and Alan smacked his lips. An unco lonely bit, said he, and I thought by For it was of course in my own rooms that I found them, when I came to Silvermills. But cheer up, my dear. yere bonnier than what he said. before ever I saw her; God knows I can be happy enough again when I alone in it; for, James More returning suddenly, the girl was changed Well, said I, this that I have got to say is very difficult, and I
La solución a esta nueva técnica ha sido la integración de OCRs y sistemas de análisis de imágenes en las herramientas de filtrado, que son capaces de acceder al contenido de los recursos gráficos y determinar si los textos incluidos en ellos son mensajes publicitarios o no.
No es tarea fácil: si envío a un familiar una foto mía junto a un cartel de coca-cola, ¿es spam?
La técnica en cuestión consistía en el envío de mensajes HTML en los que eran incluidas referencias a imágenes externas. Si conocéis algo este lenguaje de marcas, sabréis que para hacer referencia a una imagen en un contenido hipertexto basta con utilizar el tag IMG como se muestra a continuación:
<img src="DirecciónDeLaImagen" alt="Contenido textual alternativo" >
El texto "DirecciónDeLaImagen" es la URL del recurso gráfico en cuestión, por ejemplo, http://www.google.com/images/logo_sm.gif. De esta forma, cuando un browser encuentra una marca de este tipo, acude a la dirección especificada, descarga el archivo (imagen, en este caso) y lo muestra al usuario integrado en el contenido de la página.
El caso es que una URL puede contener algo más que la dirección de un recurso, puede ir acompañada de parámetros. Por ejemplo, es perfectamente válido, y lo habréis visto más de una vez el uso de cadenas más complejas, de tipo http://www.loquesea.com/imagen?usuario=jmaguilar. Esto provoca que, cuando el navegador va a la dirección indicada a obtener el archivo, transmite al servidor el parámetro indicado (en el ejemplo, le transmitiría un parámetro llamado 'usuario' con un valor igual a 'jmaguilar'). El servidor en el que se aloja, a la vista de ese parámetro, puede actuar como considere oportuno.
Aplicado al siniestro mundo del spammer, esto ofrece unas posibilidades realmente interesantes. Pongamos que envío un mensaje a una víctima, incluyendo una imagen en cuyo origen (src) añado un parámetro que permite al servidor determinar el usuario que está solicitando la misma. Cada vez que este incauto individuo abra este mensaje, recibiré en mi servidor una petición de la imagen que, gracias al parámetro, sé de quién proviene, permitiéndome por ejemplo:
- primero y principal: asegurar que la dirección de email a la que envié el mensaje es correcta, y pasarla a mi carpeta de "destinatarios seguros". Puedo seguir enviando, pues, mensajes a esta persona con la seguridad de que lo va a recibir. De hecho, supongo que este es el motivo de que los que usamos la misma cuenta desde hace años, recibamos tal cantidad de spam. Seguro que en su día hemos confirmado, sin saberlo, nuestra existencia, y estamos en las "listas selectas".
- contar el número de veces que la persona abre el mensaje. ¿Podría esto servirme para determinar que realmente mi víctima está algo más interesado de lo normal en mi producto?
- modificar la imagen al vuelo, variando detalles del mensaje. Por ejemplo, si es la primera vez que el usuario accede, utilizar un mensaje publicitario; si accede de nuevo, ofrecerle una oferta más jugosa; si vuelve a acceder, emplear técnicas más agresivas de venta.
Afortunadamente, desde hace tiempo los clientes de correo basados en aplicaciones de escritorio no permiten, sin consentimiento del usuario, la descarga de imágenes externas, lo que evita la petición del fichero al servidor. Hay otros tipos de cliente, como los webmails que, en cambio, siguen descargando del origen cualquier recurso externo.
En cualquier caso, la técnica es interesante y demuestra, una vez más, la habilidad de los expertos del lado oscuro para aprovechar las posibilidades (o agujeros) existentes en cada momento en beneficio propio.
Publicado por José M. Aguilar a las 9:39 p. m.
Etiquetas: antispam, nostalgia, programación, protocolos, spam, tags, técnicas de spam
Esto, unido a la posibilidad de incluir mensajes publicitarios mucho más espectaculares que llamaran la atención a potenciales clientes de los servicios o productos ofertados, hizo que pronto comenzaran a proliferar los mensajes con imágenes, que enviaban o bien incrustadas en el contenido del mensaje (cortesía del estándar MIME) o bien a través de un mensaje HTML en el que se introducía una imagen externa (con el tag IMG).
En cualquier caso, hace tiempo que las imágenes forman parte del fenómeno spam. Próximos posts irán dedicados a analizar distintas técnicas aplicadas para hacer más efectivos y menos detectables por herramientas automáticas los mensajes no deseados.
Un ejemplo:
.ed$$$$$eec.
.e$$$$$$$$$$$$$$$$$$eeeee$$$$$c
d$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$c
.$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$b.
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $b
d$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$F
.$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
.$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$**$ ^$$$$
4 $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$*" 4$$F
4 '$$$$$$$$$$$$$$$$$$$$$$$$$$$" 4$$
4 $$$$$$$$$$$$$$$$$$$$$$$$$$$ .$$%
d $$$$$ $$$$$*$$$$$$c ..e$$"
- 4$$$$ ^$$$$ *$$$$$F ^"""
4$$$$ 4$$$$ z$$$$$"
4$$$$ 4$$$$ ^$$$P
^$$$$b '$$$$e "F
El inocente elefantito podría ser el logotipo del producto que nos itentan vender, y un mensaje con este contenido pasaría absolutamente desapercibido para los sistemas automáticos de detección de spam.
Ahí va otro, este de creación propia, con un mensaje más directo:
## ## ## ###### ###### ##### ######
## ## ## # # # # # # #
## ## ## ###### # ## ##### ######
### ## # # ###### # # # #
Este último ejemplo se aproxima bastante a la realidad de este tipo de mensajes; lo habitual es que se envíen textos cortos, mensajes directos con publicidad explícita, dibujados a base de incluir cientos de caracteres. Se puede ver un ejemplo en la siguiente captura de pantalla.
¿Y cómo se combate esto? Probablemente, el mejor método sea, de nuevo, el análisis estadístico de la información contenida en el mensaje, teniendo en cuenta tanto los caracteres que aparecen como los espacios. Sin embargo, no parece muy sencillo determinar unas reglas que indiquen, sin riesgo a equivocación, que se trata de un mensaje de correo basura, por lo que sería un buen candidato a ser detectado por sistemas de aprendizaje automático y reconocimiento de patrones.
Quizás la suerte que tengamos los sufridos usuarios sea que los mensajes a transmitir por esta vía deben ser bastante cortos ("Viagra $2,5" o similares) por limitaciones lógicas de espacio, lo cual, sin duda, repercutirá en una utilización muy baja por parte de los spammers, que seguro prefieren la espectacularidad de otros medios.
Un ejemplo simplista: en un mensaje con el texto "Vendo Viagra Barato, Paisa", el 25% del contenido hace referencia al conocido medicamento, un 50% contiene palabras relacionadas con la venta, y un 25% restante no está claramente clasificado. Con estas proporciones, podemos asegurar que se trata de un mensaje intentando comercializar este producto.
Sin embargo, si al mensaje anterior le anexamos un capítulo del Quijote, los porcentajes anteriormente obtenidos caerían hasta ser prácticamente nulos, de forma que no podría determinarse con claridad el sentido del mensaje, justo al contrario que antes.
Esto está bien, pero, siguiendo con el ejemplo, ¿cómo colocan un capítulo del Quijote en un mensaje? He observado varias técnicas:
- la primera, anexándolo sin más. Es decir, después del contenido que pretenden enviar al usuario, algunos retornos de carro, y seguidamente, el capítulo del libro de Cervantes.
- otra, utilizando texto con el mismo color que el fondo del mensaje. Por ejemplo, texto blanco sobre fondo blanco, De esta forma, el usuario no es consciente ni siquiera de la existencia del mensaje.
- más, cambiando el tamaño de letra a tamaños de pixel. Así, el usuario puede, a lo sumo, divisar unas leves líneas al final del mensaje publicitario.
- una combinación de las dos anteriores. Esto no hay quien lo vea.
Ea, seguimos en el próximo post, que ya será después del viaje.
Es decir, la V mayúscula sería sustituída por V, dado que el 86 es el código ASCII de este carácter. Aplicando esta técnica a la palabra VIAGRA, cuya secuencia ASCII equivalente es {82, 73, 65, 71, 82, 65}, obtendríamos en el cuerpo del mensaje:
VIAGRA
Lo cual es algo más difícil de detectar (aunque no mucho, todo sea dicho de paso) por parte de las herramientas de filtrado.
Conceptualmente es bastante simple: si en el cuerpo de un mensaje aparece la palabra "viagra", ya hay bastantes probabilidades de que se trate de un correo basura; si, además, en el cuerpo aparecen otras expresiones ("barato", "compre ahora", etc.), las probabilidades crecen bastante, ¿está claro, no?
Obviamente, los spammers debieron darse cuenta de este detalle, así que rápidamente dieron con una técnica, simple donde las haya, para esquivar este contratiempo: separar las letras que componen las palabras conflictivas con espacios o caracteres invisibles, de forma que los parsers no pudieran encontrar esas cadenas en el cuerpo de los mensajes.
Así, he encontrado distintas variantes de esta técnica; la primera de ellas se utiliza tanto en mensajes HTML como en texto plano, mientras que las dos siguientes son propias de los mensajes enriquecidos:
- separar con espacios, es decir, utilizar "V I A G R A" en vez de "viagra", por ejemplo.
- separar con entidades, como , que generará en pantalla el mismo efecto que el punto anterior, pero con la diferencia de que no puede ser eliminado realizando trimming a los textos. El ejemplo anterior quedaría codificado como "V I A G R A". Obviamente, es bastante más difícil encontrar así un texto que si está incluido directamente en el contenido. Existen gran cantidad de entidades a utilizar cuya visualización no afecta a la lectura del texto, por lo que las posibilidades son muchas.
- separar con tags, aprovechando que los navegadores o visores de HTML ignorarán las etiquetas desconocidas. Por ejemplo, podríamos usar "V<xx />I<xx />A<xx />G<xx />R<xx />A", lo que complica un poco su detección.
- separar con otros caracteres, que aunque dificultan algo la lectura por parte del cliente potencial, más la complican para los sistemas de búsqueda de cadenas de texto. Supongamos algo así: V-I-A-G-R-A. Seguimos leyendo Viagra, ¿verdad? ¿Y si decimos V_I_A_G_R_A? ¿O V.I.A.G.R.A? ¿A que hay cientos (miles) de combinaciones?
Por ello, estamos contemplando una auténtica competición entre ambos bandos, similar a la existente entre los creadores de virus y los fabricantes de antivirus. Si el spammer utiliza una técnica X para colar los mensajes, la técnica Y de los filtradores la contrarresta, lo que hace que los primeros desarrollen el método X+1, que a su vez, será compensado por la tecnología Y+1 de los segundos, y así sucesivamente.
En esta primera entrega veremos la forma más simple de evitar la detección, que, como en la vida misma, es tirar la piedra y esconder la mano.
Desde el principio de los tiempos, el correo basura se envía falseando las direcciones de correo del remitente y la razón es obvia: no descubrir a quien realmente envía los mensajes, acto que, en determinados países, incluso es constitutivo de delito.
¿Y es esto evitable? Difícilmente.
Gracias a la inocencia con que fue diseñado el protocolo SMTP, es perfectamente posible la suplantación del remitente de una forma increíblemente sencilla. Esto es fácilmente comprobable simplemente modificando las propiedades de la cuenta de correo de nuestro cliente favorito (Outlook, Thunderbird...).
Esta característica es aprovechada por los spammers para evitar ser detectados por filtros de tipo 'lista negra', utilizando orígenes de lo más pintorescos: remitentes en blanco, nombres y dominios generados de forma aleatoria, nombres reales pertenecientes a dominios inexistentes, o nombres auténticos dentro de dominios existentes. De esta forma, es absolutamente inviable determinar si un mensaje es spam o no a partir del remitente.
Una variante curiosa es el uso de direcciones pertenecientes al mismo dominio en el que nos encontramos. De hecho, de vez en cuando me llega un email publicitario de uno de mis compañeros de trabajo. En otras palabras, si mi buzón de correo es xxx@yyy.com, puedo recibir spam con un remitente del tipo zzz@yyy.com. Ahora bien, el nombre zzz puede ser real y pertenecer a un usuario que también tienen en sus listas de destinatarios, o bien ser totalmente falso. Hace unos años este pequeño truco hacía que los filtros fueran más compasivos con estos mensajes, sin embargo, hoy en día, que el remitente sea del propio dominio no es tomado como un criterio de veracidad.
Todo eso hace que en los sistemas actuales de filtrado el remitente se tome como un criterio de rechazo, pero nunca de aceptación incondicional de un mensaje.
Por tanto, los métodos actuales de detección de spam están basados, fundamentalmente, en el contenido de los mensajes. El próximo día que postee comentaré unas técnicas básicas para evitar ser detectados.
Publicado por José M. Aguilar a las 8:51 p. m.
Etiquetas: antispam, protocolos, spam, técnicas de spam
Estas barreras, ciertamente frenan un 90% de los mensajes basura que recibo, esto es un hecho. Pero no es menos cierto que, a pesar de ello, una vez al día tengo que perder mi
Seguro que a todos los tenemos direcciones de correo algo añejas nos ocurre lo mismo. Como en otros aspectos de la vida, a principios de los noventa podíamos relacionarnos con otros sin precauciones. Recuerdo cómo podía participar alegremente en foros utilizando mi nombre y dirección email habitual. Eso en la actualidad esto es impensable, y seguro que todos tomamos precauciones; en general, la mejor opción es la difusión racional de las direcciones de correo, y para ello se pueden encontrar algunas ayudas, como la que ya comenté hace algún tiempo, el uso de buzones temporales.
A pesar de todo, es interesante observar el talento y la creatividad que existe a veces detrás de estos mensajes. Como en el caso de los creadores de virus, troyanos y similares, me resulta admirable cómo los creadores de estos engendros evolucionan con el tiempo, adaptándose a los cambios y modificando su forma de actuar para estar siempre por delante de aquellos que intentan detenerlos.
Por ello, me he decidido a iniciar esta serie de artículos en los que iré comentando distintas técnicas que emplean estos individuos para conseguir transmitirnos un mensaje sin ser detectados por los complejos sistemas de filtro existentes en la actualidad.
Está claro, nuestras direcciones de e-mail forman parte de enormes listas que son compartidas (o vendidas) entre los spammers, y difícilmente podemos salir de ellas. O mejor dicho, es imposible salir de ellas.
Desde luego, de nada vale devolverles el mensaje escribiéndoles inocentemente "Porfa, no me envíes más correos". Peor aún, de esta forma estamos confirmándoles que la dirección que tienen es buena, y podrán ponerle una marca como indicando "dirección pata negra". Y eso suponiendo que el mensaje les llegara, puesto que normalmente los envían desde direcciones inexistentes, debido a la falta de seguridad inherente al protocolo SMTP.
Hay sistemas, a veces implementados en los clientes de correo y otras en los servidores, que son capaces de analizar los mensajes entrantes y, a base de reglas, listas negras y reconocimiento de palabras o patrones, pueden apartar (o marcar) mensajes que consideran spam, de forma que molesten algo menos. Otro día, si me acuerdo, comentaré distintas técnicas que he visto que usan los spammers para evitar ser detectados.
Aparte de utilizar estas herramientas, he encontrado algo que, aunque no ayuda a evitarlo, por lo menos puede contribuir a que no siga creciendo.
Se trata de servicios gratuitos de buzones temporales, como el disponible en esta dirección. Se trata de buzones que se generan de forma automática al recibir un mensaje y que es posible consultar desde la propia web sin necesidad de clave ni nada parecido. Por ejemplo, en el caso del servicio Mailinator, puedo asumir que dispongo de un buzón llamado loqueyoquiera@mailinator.com y consultar si tiene mensajes en cualquier momento. Por ejemplo, si pulsas aquí, tú mismo podrás ver si ese buzón ha recibido algún e-mail.
Obviamente, no es conveniente utilizarlo para recibir secretos de estado, pues cualquiera puede verlos. Sin embargo, lo he visto muy útil para registrarse en páginas web y probar servicios on-line a los que hay que suministrar una dirección de correo (por ejemplo para recibir las claves).