Existen fiestas que se esperan con muchas ganas, y una vez que llegan deseamos que jamás terminen para no tener que esperar hasta la próxima. Esta sensación es la que se vive año tras año con Ekoparty, el evento de seguridad informática de habla hispana, a nivel técnico el más importante de la región. El mismo es realizado anualmente en Buenos Aires, Argentina; y reúne a cientos de profesionales del mundo de la seguridad.

Pero además de ser un evento, Ekoparty es un punto de encuentro, una posibilidad de actualización, una oportunidad de conocer nuevos colegas, y mucho más. Cada año la fiesta se renueva, y este año en particular lo hizo con algunas controversias. Si bien en cada nueva edición se anuncian las novedades del sector en su aspecto más técnico (y también podríamos decir más underground) esta vez para algunos se cruzó indebidamente una línea, ya que dos especialistas anunciaron en una de las últimas conferencias, una vulnerabilidad del tipo 0-day (zero day). Una vulnerabilidad 0-day se considera a aquella para la cual existe un exploit pero no una solución. En este caso se trata nada más y nada menos que de Microsoft. Al existir una vulnerabilidad desconocida aún por la empresa de software, los clientes están desprotegidos frente a ataques que se aprovechen de dicho bug. Ahora bien, esto no hubiera sido tan grave si además no hubiera existido un exploit 0-day, es decir, un programa que permite aprovechar dicha vulnerabilidad. Y peor aún, tampoco hubiera sido tan grave si no se hubiera distribuido el exploit entre los asistentes.

Este tema suele resultar álgido a la hora de definir lo que es correcto o no lo es, por lo que un breve análisis nos puede permitir arrojar algo de luz sobre la situación. Veamos: un especialista encuentra una nueva vulnerabilidad y puede reportarla o no al fabricante. Si la reporta, el fabricante puede decidir resolverla en un determinado momento y negociar con el especialista por haberla reportado, o bien puede hacer caso omiso, ignorando la problemática o minimizándola. Si no la reporta, existirá una nueva vulnerabilidad que solo conoce el descubridor, pero si éste la publica, pasa a ser conocida por todos, incluido el fabricante, en el momento que lo hace público. Este último escenario es el peor de todos para lo que a los usuarios se refiere, ya que las empresas y organizaciones que están afectadas por la vulnerabilidad anunciada, pasan a estar expuestos a los ataques de cualquiera que sepa como hacerlo, dado que el mismo es público. Por su parte el fabricante debe apurar sus procesos para liberar un parche, y es probable que dada la velocidad a la que lo hará para evitar mayores inconvenientes, no pueda cumplir con los mismos estándares de calidad que si el error hubiera sido anunciado de otra manera.

Ver más… »

Categories: Eventos
4 Comments »

En el día de ayer Twitter se vio afectado por una importante vulnerabilidad en su plataforma twitter.com, de la cual muchos blogs y sitios web, además de medios off line, se han hecho eco. Como ya hemos comentado acá, la tendencia al hackarillismo muchas veces atenta contra la claridad con la que se entienden muchos ataques, y por eso es bueno dejar en claro qué fue lo ocurrido, para aquellos usuarios que aún tengan dudas al respecto.

¿Cómo funcionaba el ataque?

Se trata de un ataque de Cross Site Scripting, más conocido como XSS, por el cual era posible ejecutar código JavaScript en los equipos de las víctimas a través de la publicación de tweets especialmente diseñados para explotar la vulnerabilidad.

¿Cuál era el impacto del ataque?

Cuando el usuario era víctima podían ejecutarse diversos códigos, aunque en su mayoría se trató de publicación de tweets, muchos de ellos con colores especiales o mensajes llamativos o la apertura de ciertos sitios web en el navegador.

¿Cómo se podía proteger el usuario?

Mientras estuvo vigente la vulnerabilidad, la única solución era no utilizar el sitio web de Twitter.com, y hacer uso del servicio sólo a través de las aplicaciones de escritorio o móviles.

¿Está solucionado?

Sí, Twitter solucionó el inconveniente cinco horas después de haber sido publicado, y un par de horas más tarde hizo los ajustes finales. Es decir que el tiempo de vida del ataque fue corto, y ya no hay de qué preocuparse.

¿Twitter ya sabia del ataque?

Sí, la propia empresa se encargó de afirmar que recibieron el reporte hace un mes, que lo habían arreglado pero en recientes modificaciones del sitio web el mismo resurgió.

¿Hubo muchos afectados?

A pesar de que hubo miles de mensajes que se propagaron, la mayoría de ellos no tuvieron impactos importantes en los usuarios. No se detectaron casos de ejecución de código ni ataques masivos exitosos.

¿Se trata de un gusano informático?

No, aunque algunos usuarios habrán leído esa información, se trata de un ataque XSS que tiene la característica de replicarse automáticamente con la publicación de tweets sin que el usuario lo note, ya que utiliza la función onmouseover que permite ser “retwitteada” sólo al pasar el mouse por encima. Por esta característica de propagar el ataque de forma automática es que muchos lo han asemejado a un gusano informático, pero no es un software (una aplicación) por lo que este ataque no debe ser considerado malware.

Espero que con estas dudas quede bien resumido el incidente sufrido ayer que, por tratarse de un servicio con millones de usuarios como Twitter logró hacer más ruido, pero que a la vez es un XSS más de los miles que se observan periódicamente.

Sebastián Bortnik
Coordinador de Awareness & Research

Categories: Alertas
8 Comments »