Hace más de un mes os anunciamos una iniciativa promovida por el investigador Aviv Raff que proponía publicar cada día, durante el mes de Julio, una serie de vulnerabilidades que afectaban a un servicio de internet que en cierto modo estuviese involucrado con el servicio de microblogging twitter, que utilizase su API, etc etc. A dicha iniciativa la llamaría TwitPwn, y si nos seguís en nuestro twitter, habreis comprobado que hemos ido referenciando cada día a la vulnerabilidad publicada.Bien, pues ya acabó este experimento, y en mi opinión, con detalles y conclusiones interesantes y que merecen cierta mención. Un total de 42 vulnerabilidades, que pasamos a analizar a continuación:
- Servicios afectados
En los 31 advisories que forman esta iniciativa, podríamos englobar a todas las "víctimas" bajo las siguientes categorías o funciones que ofrecen:
- Acortadores de URLs = bit.ly, tr.im (entrad rápido a esta porque dentro de poco desaparecerá...)
- Clientes de twitter = hootsuite.com, bigtweet.com, twitiq.com, m.slandr.net, talker.co.il, twhirl.org, twitstat.com/m, tweetdeck.com
- Multimedia sharing = twitwall.com, twitsnaps.com, twitpic.com, yfrog.com, tweetube.com, posterous.com, chart.ly
- Indexador de Tweets = twitterfall.com, tweetgrid.com, tweetmeme.com, stocktwits.com
- Directorios de cuentas Twitter = twellow.com, tweeplepages.com
- Trackers de URLs = twitturly.com, tweetburner.com
- Red Social = brightkite.com
- Replicadores de mensajes en varias redes = hellotxt.com, mobypicture.com, ping.fm
- Utilidades para Twitter = twittercounter.com
- Buscador de Tweets = buscador de twitter.com
Seguro que muchos os suenan, o incluso usais en vuestra vida twittidiana en caso de que la tengais. A continuación os dejo una gráfica que muestra el porcentaje de las vulnerabilidades totales según el tipo de servicio:
- Acortadores de URLs = bit.ly, tr.im (entrad rápido a esta porque dentro de poco desaparecerá...)
- Clientes de twitter = hootsuite.com, bigtweet.com, twitiq.com, m.slandr.net, talker.co.il, twhirl.org, twitstat.com/m, tweetdeck.com
- Multimedia sharing = twitwall.com, twitsnaps.com, twitpic.com, yfrog.com, tweetube.com, posterous.com, chart.ly
- Indexador de Tweets = twitterfall.com, tweetgrid.com, tweetmeme.com, stocktwits.com
- Directorios de cuentas Twitter = twellow.com, tweeplepages.com
- Trackers de URLs = twitturly.com, tweetburner.com
- Red Social = brightkite.com
- Replicadores de mensajes en varias redes = hellotxt.com, mobypicture.com, ping.fm
- Utilidades para Twitter = twittercounter.com
- Buscador de Tweets = buscador de twitter.com
Seguro que muchos os suenan, o incluso usais en vuestra vida twittidiana en caso de que la tengais. A continuación os dejo una gráfica que muestra el porcentaje de las vulnerabilidades totales según el tipo de servicio:
Casualmente, los servicios que cuentan con más vulnerabilidades son los que se utilizan para twittear y compartir fotos, videos y demás. Básico.
- Tipos de vulnerabilidades detectadas
De las más de 40 vulnerabilidades detectadas, realmente estamos ante 4 tipos diferentes de las que ya os hemos hablado por aquí y que vamos a repasar:
* Cross-Site Scripting (XSS) no persistente - Vulnerabilidad web que permite incrustar código HTML o javascript en una página web por una validación incorrecta en los datos que puede proporcionar un usuario. Explotando satisfactoriamente esta vulnerabilidad, por ejemplo es posible robar las cookies de la sesión del usuario víctima que ejecute la sentencia para que así el atacante pueda realizar acciones con esa sesión. También conocido como Cross-Site Scripting reflejado, para que este ataque funcione, es necesario que otro usuario acceda a una dirección URL formada especialmente por el atacante.
* Cross-Site Scripting (XSS) persistente - Los datos técnicos de esta vulnerabilidad son exactamente iguales que los de los Cross-Site Scripting no persistentes o reflejados. La diferencia con la anterior es que para llevar a cabo este ataque, no es necesario que el usuario víctima ejecute la dirección URL que contiene el código HTML o javascript, si no que el atacante ha conseguido que dicho código haya sido almacenado ya en la aplicación, ya sea por haberlo podido incrustar en una noticia, post de un foro, etc. Gracias a esto, cualquier usuario que acceda a la página en el que esté incrustado el código ajeno, será víctima del ataque. Este Cross-Site Scripting también es conocido como directo.
* Cross-Site Request Forgery (CSRF) - Al contrario que en los ataques de Cross-Site Scripting, los CSRF o XSRF explotan la confianza que un sitio o aplicación web tiene en el usuario que los visita. Podríamos definirlo como un Cross-Site Scripting evolucionado, y consiste en conseguir que un usuario realice una petición a una aplicación Web con su propia cuenta. Esto añade la gravedad de que en su posterior investigación, sea más complicado saber quien ha realizado realmente esa petición. Para el caso en el que nos encontramos, podríamos por ejemplo enviar tweets a otras personas haciendo que figure el nombre de usuario de otro. Hace unos meses Yago contaba en este post de que manera Skype sufrió este tipo de ataques en su frontal web. La suplantación en los tiempos que corren, no es para tomársela a broma.
* Canal inseguro de comunicaciones - Muchos se dedican a robar wifis de sus vecinos en su lugar de vacaciones. Algunos quieren internet, otros simplemente enchufar su sniffer preferido a ver que peticiones corretean por esas ondas que nos permiten estar conectados con el portátil desde la terraza viendo el mar. El no utilizar un canal seguro para según que comunicaciones en algunas aplicaciones puede dar lugar a entrometernos por ejemplo en un proceso de actualización de software, y en vez de dar el .exe que corresponde, redirigir la descarga a otro .exe que tengamos preparados nosotros mismos, o incluso redirigirlo al binario de una versión anterior del software que nos permita explotar otras vulnerabilidades que se arreglaban con las nuevas. Es un tema que da muchísimo juego, con el que me detendré más adelante en el apartado de conclusiones.
La siguiente gráfica muestra el porcentaje de vulnerabilidades según su tipo:
* Cross-Site Scripting (XSS) no persistente - Vulnerabilidad web que permite incrustar código HTML o javascript en una página web por una validación incorrecta en los datos que puede proporcionar un usuario. Explotando satisfactoriamente esta vulnerabilidad, por ejemplo es posible robar las cookies de la sesión del usuario víctima que ejecute la sentencia para que así el atacante pueda realizar acciones con esa sesión. También conocido como Cross-Site Scripting reflejado, para que este ataque funcione, es necesario que otro usuario acceda a una dirección URL formada especialmente por el atacante.
* Cross-Site Scripting (XSS) persistente - Los datos técnicos de esta vulnerabilidad son exactamente iguales que los de los Cross-Site Scripting no persistentes o reflejados. La diferencia con la anterior es que para llevar a cabo este ataque, no es necesario que el usuario víctima ejecute la dirección URL que contiene el código HTML o javascript, si no que el atacante ha conseguido que dicho código haya sido almacenado ya en la aplicación, ya sea por haberlo podido incrustar en una noticia, post de un foro, etc. Gracias a esto, cualquier usuario que acceda a la página en el que esté incrustado el código ajeno, será víctima del ataque. Este Cross-Site Scripting también es conocido como directo.
* Cross-Site Request Forgery (CSRF) - Al contrario que en los ataques de Cross-Site Scripting, los CSRF o XSRF explotan la confianza que un sitio o aplicación web tiene en el usuario que los visita. Podríamos definirlo como un Cross-Site Scripting evolucionado, y consiste en conseguir que un usuario realice una petición a una aplicación Web con su propia cuenta. Esto añade la gravedad de que en su posterior investigación, sea más complicado saber quien ha realizado realmente esa petición. Para el caso en el que nos encontramos, podríamos por ejemplo enviar tweets a otras personas haciendo que figure el nombre de usuario de otro. Hace unos meses Yago contaba en este post de que manera Skype sufrió este tipo de ataques en su frontal web. La suplantación en los tiempos que corren, no es para tomársela a broma.
* Canal inseguro de comunicaciones - Muchos se dedican a robar wifis de sus vecinos en su lugar de vacaciones. Algunos quieren internet, otros simplemente enchufar su sniffer preferido a ver que peticiones corretean por esas ondas que nos permiten estar conectados con el portátil desde la terraza viendo el mar. El no utilizar un canal seguro para según que comunicaciones en algunas aplicaciones puede dar lugar a entrometernos por ejemplo en un proceso de actualización de software, y en vez de dar el .exe que corresponde, redirigir la descarga a otro .exe que tengamos preparados nosotros mismos, o incluso redirigirlo al binario de una versión anterior del software que nos permita explotar otras vulnerabilidades que se arreglaban con las nuevas. Es un tema que da muchísimo juego, con el que me detendré más adelante en el apartado de conclusiones.
La siguiente gráfica muestra el porcentaje de vulnerabilidades según su tipo:
Quizás el Cross-Site Scripting no persistente o reflejado no se considere una vulnerabilidad tan grave como podría ser una inyección de comandos o un remote file inclusion, pero para el caso de estos servicios basados en twitter, en el que se mandan siempre URLs enmascaradas en acortadores de direcciones y que compartimos en mensajes tales como "http://bit.ly/juas <- mirad que bueno!" o "http://tinyurl.com/lalala <- más info de la caída de facebook", que implican poca ingenieria social ya que el 99% tiende a hacer click en los enlaces sin comprobar antes las URLs, si hay que tenerlos en cuenta.- Estado de parcheado al publicar las vulnerabilidades
Más de las tres cuartas partes de las vulnerabilidades reportadas fueron arregladas, tardando más o menos tiempo (algunos incluso llegaron a arreglar las vulnerabilidades en sus servicios en apenas dos horas desde que Aviv mandó el primer e-mail), antes de que se avisara de que se procedería a su publicación en el proyecto TwitPwn. Para el resto de vulnerabilidades, a día de hoy no hay constancia de que se hayan parcheado o no, o ni siquiera se ha contestado al e-mail enviado explicando los detalles de las vulnerabilidades.
Entre las vulnerabilidades no parcheadas nos encontramos con aquellas que se encontraron en el cliente de twitter Tweetdeck, muy utilizado por cierto, no estableciendo un canal seguro de comunicaciones, ídem para otro cliente, twhirl. Tampoco se han parcheado, o ni siquiera hecho caso de los e-mails, las vulnerabilidades de tr.im, twittercounter.com/twitterRemote.com, tweetube.com, tweeplepages.com, tweetburner.com, chart.ly...
Entre las vulnerabilidades no parcheadas nos encontramos con aquellas que se encontraron en el cliente de twitter Tweetdeck, muy utilizado por cierto, no estableciendo un canal seguro de comunicaciones, ídem para otro cliente, twhirl. Tampoco se han parcheado, o ni siquiera hecho caso de los e-mails, las vulnerabilidades de tr.im, twittercounter.com/twitterRemote.com, tweetube.com, tweeplepages.com, tweetburner.com, chart.ly...
- Conclusiones y opinión personal
Al principio me quedaban dudas sobre si TwitPwn iba a ser lo típico de "saco una vulnerabilidad y la repito en el resto porque se usa lo mismo", pero al final, y después de realizar el seguimiento que os prometimos, puedo decir que me he llevado varias sorpresas.
La primera de ellas, el pasotismo, del que os hemos hablado varias veces en este blog, del que pecan muchos, tanto por la seguridad en sus desarrollos como a la hora de responder un e-mail que únicamente trata de ayudarles para mejorar lo máximo posible. Aviv ha publicado vulnerabilidades que se acercaban muchísimo a aquellas que de repente un día saltan a los medios (y más ahora, que hasta las caídas de twitter o facebook salen en las noticias de televisión...sin comentarios) y cuentan que alguien había entrado en el twitter de Britney y había dicho que se había muerto.
La segunda sorpresa, vulnerabilidades tales como la de las conexiones inseguras que sufren algunos clientes twitter de los más utilizados. Si juntamos lo siguiente en una coctelera:
* Wifi por defecto o insegura, me meto en tu red y veo lo que haces y por dónde navegas.
* ¿Todo el mundo? usa twitter
* Le doy a [Aceptar] si mi cliente twitter me dice de repente que tiene una actualización nueva.
* Le doy a [Aceptar] a que la actualización se ha descargado y que se va a instalar.
* Lo reflejado en el punto anterior.
Vaya cocktail.
En resumen, Aviv nos ha entretenido este pasado mes de Julio con este proyecto tan interesante y curioso, que quizás no haya tenido mucha repercusión mediática pero que si ha seguido demostrando como vulnerabilidades tan típicas siguen existiendo, y que en según que ámbitos pueden alcanzar mayor criticidad de la que normalmente tienen.
La primera de ellas, el pasotismo, del que os hemos hablado varias veces en este blog, del que pecan muchos, tanto por la seguridad en sus desarrollos como a la hora de responder un e-mail que únicamente trata de ayudarles para mejorar lo máximo posible. Aviv ha publicado vulnerabilidades que se acercaban muchísimo a aquellas que de repente un día saltan a los medios (y más ahora, que hasta las caídas de twitter o facebook salen en las noticias de televisión...sin comentarios) y cuentan que alguien había entrado en el twitter de Britney y había dicho que se había muerto.
La segunda sorpresa, vulnerabilidades tales como la de las conexiones inseguras que sufren algunos clientes twitter de los más utilizados. Si juntamos lo siguiente en una coctelera:
* Wifi por defecto o insegura, me meto en tu red y veo lo que haces y por dónde navegas.
* ¿Todo el mundo? usa twitter
* Le doy a [Aceptar] si mi cliente twitter me dice de repente que tiene una actualización nueva.
* Le doy a [Aceptar] a que la actualización se ha descargado y que se va a instalar.
* Lo reflejado en el punto anterior.
Vaya cocktail.
En resumen, Aviv nos ha entretenido este pasado mes de Julio con este proyecto tan interesante y curioso, que quizás no haya tenido mucha repercusión mediática pero que si ha seguido demostrando como vulnerabilidades tan típicas siguen existiendo, y que en según que ámbitos pueden alcanzar mayor criticidad de la que normalmente tienen.
2 comments :
Creo que twitter es la aplicación web que conozco con más fallos de seguridad ...
Exelente resumen sobre el "TwitPwn" y si realmente no ha tenido la difusión que tal vez se esperaba y en parte creo que influyo el tema de los DDoS sufridos por este entre otros temas de seguridad que esta pasando Twitter por estos días...
Incluso uno de los fundadores de Twitter reconoció que enfocaron todos sus esfuerzos en aumentar el sitio que nunca se preocuparon mucho por la seguridad y la verdad que es inamisible en estos tiempos pensar tan grande para crear algún proyecto en la red, con tanto dinero de inversión y no preocuparse por la seguridad del sitio y de sus usuarios.
Felicidades por "Security By Default" es el tercer post que leo y ya me encanto por lo que me estoy suscribiendo al feed.
Salu2
Marcelo.
Publicar un comentario