La semana pasada volví del MAAWG tras varios días en Heidelberg(Alemania).
El congreso como tal dio mucho de sí y se hablaron de cosas muy interesantes. Estaban presentes todos los “grandes” del mundo de Internet y del correo electrónico, tales como Microsoft, AOL, AT&T, ComCast, Yahoo, SpamHaus, IronPort, Cisco, Symantec…etc y la agenda del evento estuvo repleta de charlas y conferencias. A continuación un mini-resumen de alguna de ellas.
Gracias a Vicente Martínez Gil y a CloudMark, la semana que viene (10-12 de Junio) asistiré al MAAWG (“Messaging Anti-Abuse Working Group”) un congreso del estilo del Foro Abuses pero a nivel internacional que se celebra en Heidelberg, Alemania. A dicho congreso asiste la elite mundial del correo electrónico para hablar y tratar de temas de abuso de dicho servicio, spam y todo lo que gira alrededor de esto; no hay más que ver el listado de miembros.
CloudMark es una empresa creada por Vipul Ved Prakash, creador a su vez de Razor, un programa de detección de spam en base a checksums de mensajes muy utilizado, sobre todo desde SpamAssassin. Uno de los servicios de pago de Cloudmark, es similar a dicho programa pero con muchas más funcionalidades y con la ventaja de que la base de datos de checksums de mensajes son bajados al servidor. La verdad, tras las pruebas realizadas, da muy buen resultado en detección de spam.
En cuanto al MAAWG, ciertamente, pinta muy bien; la agenda es privada pero puedo adelantar que existen diversas conferencias de gente de Sendmail, AOL, Comcast, SpamHaus, Ironport o Symantec. Las botnets y la reputación de IPs parecen que van a ser importantes puntos a tratar. A la vuelta podré contar más al respecto y todo lo que ha dado de sí.
Tschüss! ;-)
Parece que hay rumores de que los servidores de correo de Google tienen una vulnerabilidad que podría permitir el envío de mensajes masivos desde éstos.
Por ahora parece que en el informe no hay demasiados detalles a la espera de una respuesta por parte de Google, pero según acaban de comentar en Bugtraq un integrante del equipo de INSERT:
Hi,
We are not talking about backscattering. Our attack uses Google’s MX servers like open SMTP relays.
Messages are delivered as sent, and not as a delivery failure notification.
We are still expecting to hear from Google, but we will be releasing more details about the issue
together with the PoC exploit shortly.
Sería interesante que Google desmintiese esta noticia si es falsa o si es verdad, anuncie la resolución de dicha vulnerabilidad.
Me encuentro con un interesante artículo de SecureWorks que hace referencia al “Top” de botnets más grandes y que más spam generan.
La primera de ellas es Srizbi, de la que ya hablé en este blog hace unos meses. Según dicho estudio, Srizbi (perteneciente a la RBN), dispone de unas 315.000 máquinas bajo su control; toda una plataforma para el envío de spam que generaría unos 60 billones de mensajes de spam al día. A destacar también que casi todas usan un sistema de control con cifrado, ya sea HTTP o mediante algún otro protocolo.
Ciertamente, las botnets son las mayores emisoras de spam a día de hoy. Para poder mitigar su impacto, sería interesante que los ISPs de conectividad, como está haciendo Telefónica desde hace tiempo, empiecen a cortar el tráfico SMTP de salida desde sus redes dinámicas y residenciales. Otros ISPs están pensando en aplicar medidas similares dado el excelente resultado que esta medida está dando. Esperemos que sea así pronto :)
Estamos teniendo últimamente algunas denuncias de páginas alojadas con una web fraudulenta de escrow. El timo en cuestión consiste en algo parecido al phishing, en el que la víctima accede al contenido web pensando que es una empresa de escrow seria.
Los días 22 y 23 de Abril en la UPC de Barcelona, se celebrará la sexta reunión del Foro Abuses.
Básicamente, el Foro ABUSES es un espacio para técnicos de Operadores (telcos o ISPs) que gestionan o están interesados en solucionar incidentes de seguridad y abusos en Internet. En estas reuniones del Foro ABUSES se pretende mejorar la confianza entre ISPs españoles a través de reuniones participativas que generen conclusiones y acciones. En pasadas reuniones por ejemplo, se acordó el impulso de SPF desde todos los ISPs; dicho acuerdo se vio reflejado cuando Hostalia implantó SPF en más de 25000 dominios hace unos meses. Se realizó una nota de prensa que tuvo repercusión en diversos medios.
La agenda de la reunión, es la siguiente:
Dia 22 (martes)
10.00-10.30 Bienvenida
10.30-14.00h Sesión1 (mañana): Presentaciones y debate sobre:
GSMA Launches Mobile Alliance Against Child Sexual Abuse: Telefónica España
Improving E-mail Deliverability into MSN Hotmail and Windows Live Mail. Microsoft España
Cert Caixa
Telefonica Empresas
16.00-18.00h Sesión2 (tarde): Intercambio de experiencias entre miembros del Foro
TusProfesionales
Hostalia
CCN-cert
esCERTupc
INTECO-cert
y mas…
Día 23 (miércoles)
10.00-11.30h Sesión3 (mañana): Asuntos internos Foro ABUSES
ListaBlanca: Overview Interface de gestión
Spamtraps
Politica postmaster
Resultados encuesta
Otros
12.00-13.00h Sesión 4 (mañana): Clasificación e intercambio de incidentes
Clasificación y protocolo de intercambio de incidentes entre miembros del Foro ABUSES
13.00-13.30h Sesión final: Conclusiones y próxima reunión
Interesante :-) Contaré los puntos que se puedan hacer públicos de esta sexta reunión.
Al buzón de correo de abuse de todo ISP, suelen llegar bastantes quejas sobre los alojamientos, servidores, dominios…etc de los que dicho ISP es responsable. La mayoría de avisos suelen ser por mensajes de spam enviados de una determinada IP, quejas sobre ataques UDP o contra páginas web que tengan como origen algún servidor al que le hayan colado algún tipo de malware o por webs fraudulentas de phishing, que están alojadas sin el consentimiento del propietario de un dominio. De hecho, últimamente están llamando por teléfono bastante, por ejemplo desde la RSA, para informar telefónicamente de la existencia de una web de phishing en un determinado servidor y solicitar la inmediata suspensión del sitio web, para agilizar los trámites.
En todos estos casos, cuya naturaleza es clara, la política a seguir es:
1.- Contactar con el cliente
2.- Suspensión del sitio web
3.- Guardado de evidencias y eliminación de todo rastro
4.- Aplicar las medidas necesarias para que no se repita
5.- Habilitar de nuevo el alojamiento
Este tipo de quejas son, como decía, sobre situaciones de las que el cliente no tiene conocimiento y no es culpable directo de lo sucedido.
El problema reside en otro tipo de quejas o avisos que no son tan claros y que requieren una actuación más directa contra el cliente. Por ejemplo, una queja de un sitio web que pueda ser ofensivo contra una o varias personas, o que diga que contiene material con copyright y que está siendo usado sin permiso…etc. Ante este tipo de casos, lo que se hace es solicitar al emisor de la queja que ponga una denuncia en la comisaría de policía más cercana :) Solo se podrá actuar contra un cliente nuestro con una orden judicial de por medio, como ya nos ha sucedido alguna vez.
Todo esto viene a raíz de que hay mucha gente que piensa que por enviar a abuse una queja, ya automáticamente debemos de actuar. Esto no es así, y como decía, para realizar ciertas acciones contra un cliente con el cuál tenemos un contrato, hace falta una orden judicial.
Creo además que es la forma correcta de hacer las cosas, no hace falta recordar el polémico artículo 17bis que iba a permitir a las sociedades de gestión de derechos de autor cerrar páginas web sin orden judicial alguna y que finalmente, fue rechazado.
El 31 de Diciembre del 2006, ORDB, una de las listas negras más conocidas hasta el momento y con buena reputación, cerraba para siempre. El cambio de técnicas usadas por los spammers para el envío de su email basura, hizo que los open relays ya casi no fueran utilizados, por lo que ORDB ya no tenía mucho que listar.
Desde hace unos días, ORDB, responde como positivo las consultas que se le hacen para cualquier IP, por ejemplo:
$ dig 4.64.194.82.relays.ordb.org +short 127.0.0.2 $ dig 152.175.55.65.relays.ordb.org +short 127.0.0.2 $ dig 240.246.14.72.relays.ordb.org +short 127.0.0.2
Los servidores de Hostalia, Hotmail y Google, serían calificados como “emisores de spam”. Supongo que esta medida la habrán tomado para que los postmasters descuidados espabilen un poco :)
Un cliente nos comunicaba que estaba teniendo problemas para enviar correos a un servidor. El mensaje devuelto era relativo a ORDB, algo que nos extrañó bastante y que nos llevó al origen del problema.
Así, que ya sabéis, si no lo habíais hecho ya, quitad ORDB de todos vuestros chequeos antispam (incluido el SpamAssassin!) para evitaros problemas. Los que tengan appliances que sean una caja negra…lo tendrán más difícil :-/
Pues a pesar de lo que comentaba el otro día sobre la nueva versión de Plesk ( versión 8.3 ) y su soporte para el puerto 587 (esto sí que está implementado), el otro punto que comentaba era que “parece” que se había parcheado su Qmail para que declarase la variable de entorno SMTPAUTHUSER, que según su soporte iba a ser realizado para esta versión.
Estos días, tras hacer unas nuevas pruebas para crear un plugin para qmail, veo que no es así. Vuelta a escribir al soporte de Plesk y esta vez su respuesta es:
Qmail in Plesk in compiled with qmail-spp patch, but it still does not set
SMTPAUTHUSER and SMTPAUTHMETHOD variables according to http://qmail-spp.sourceforge.net/doc/
This feature is having the critical status and will be implemented in Plesk version 8.4.
Sí, ya sé que el qmail de Plesk está compilado con el parche para SPP…de eso no tengo dudas, de lo que realmente sí tengo dudas es de si en la versión 8.4 se implementará o seguirán dando largas :(
Cosas que se pueden hacer en el Exim de CPanel con una simple ACL en su exim.conf, en el qmail de Plesk, ni programándote un plugin para hacerlo…:-/
El mes pasado, nos enterábamos de que el captcha de Yahoo había sido “roto” según un grupo de investigación ruso que facilitaba incluso el software que lo “rompe”. Desgraciadamente, no se puede ver el código fuente :( :
split@debian:/tmp/CaptchaServ$ ls -l total 240372 -rw-r--r-- 1 split split 4627277 ago 6 2007 3005 -rw-r--r-- 1 split split 239860412 ago 3 2007 34997 -rw-r--r-- 1 split split 4008 ene 16 14:40 CaptchaServ.cpp -rw-r--r-- 1 split split 911 dic 15 15:18 CaptchaServ.sln -rw-r--r-- 1 split split 8704 ene 16 13:26 CaptchaServ.suo -rw-r--r-- 1 split split 3616 ene 16 13:30 CaptchaServ.vcproj -rw-r--r-- 1 split split 2270 ene 16 14:54 Capthca.jpg -rw-r--r-- 1 split split 1232223 ago 6 2007 segmentation_yahoo.ctf -rw-r--r-- 1 split split 36864 ago 6 2007 segmentation_yahoo.dll -rw-r--r-- 1 split split 81920 ene 16 01:42 yahoo_m.dll -rw-r--r-- 1 split split 294 ene 16 13:37 yahoo_m.h -rw-r--r-- 1 split split 2240 ene 16 00:42 yahoo_m.lib
Roto el captcha de Yahoo, que comentaban que era el más fuerte o difícil de romper, hace poco caía también el de Windows Live y hace unos pocos días, se rompía también el de Gmail. Todo ello, por segunda vez, ya que durante Julio del 2007 se crearon más de 500.000 cuentas en estos servicios para el envío de spam.
El proceso se puede ver en el estudio hecho por WebSense para el caso de Hotmail y para el caso de Gmail en el que se muestran capturas de tráfico de red de bots que realizan la operación. En el caso de Gmail de hecho, el bot envía la información de la imagen a un host en concreto para que realice el “crackeo” de la imagen y devuelva el resultado al bot para que proceda a crear las cuentas.
La creación de este tipo de cuentas es bastante peligroso debido principalmente a que Yahoo, Hotmail y Gmail no son normalmente filtrados ni por listas negras ni por otros análisis antispam, así que ya se pueden poner las pilas :)
Comments(1)