Donald Trump es un usuario muy activo en Twitter con 32,7 millones de followers pero no es ni de lejos el usuario que tiene más seguidores. En el número uno del ranking a día de hoy se encuentra Katy Perry, con más de 100 millones. Los tweets publicados por cualquiera de ellos tienen un impacto de millones de usuarios de dispositivos móviles y ordenadores. Pero ¿y si alguien se hiciera con el control de dicha cuenta y pudiera publicar, por ejemplo, un enlace de descarga que apunte a un malware?
Las consecuencias serían realmente de proporciones "bíblicas" (como decían en nuestra querida película “Cazafantasmas”) ya que un alto porcentaje de esos seguidores ejecutarían el malware con toda tranquilidad, debido a su total confianza en la fuente. Esto que parece improbable, pudo haber estado más cerca de lo que parece, y no es la primera vez, que en el año 2014 también tuvo un CSRF peligroso que permitía robar cuentas.
En menos de un año han aparecido al menos dos fallos de seguridad relacionados con Twitter que permitían a un atacante realizar diversas acciones desde cualquier cuenta como publicar un tweet en su nombre, subir videos, borrar imágenes, ver ficheros privados, etcétera. Ambas tienen en común el mismo vector de ataque: Twitter Media Studio.
Media Studio fue lanzado en agosto de 2016 y sustituye a Video Studio. Está formado por una serie de herramientas las cuales ofrecen algunas nuevas características, como mejoras de rendimiento, nueva biblioteca de medios unificada, programación de tweets mejorada, nuevos controles de acceso, etcétera.
Los bugs de Twitter
El investigador Anand Prakash encontró la primera de ellas cuando comenzó a buscar agujeros de seguridad dentro de esta librería y se dio cuenta que todas las peticiones a la API de Studio estaban enviando un parámetro llamado “owner_id”. Este parámetro “owner_id” es un número, secuencial y público, que corresponde a un usuario real de Twitter. Desde esta página web puedes averiguar el id de cualquier usuario de Twitter:
Aunque parezca increíble, este parámetro carecía de un control de seguridad o autorización para confirmar si el usuario que estaba realizando la petición era realmente el propietario de la cuenta. Por lo tanto, simplemente cambiando este valor, era posible realizar acciones sobre cualquier cuenta de Twitter, como poner nuevos tweets, subir videos, fotos, etcétera. Todo esto sin necesidad de saber la contraseña de la cuenta de Twitter.
En este ejemplo vemos cómo se utilizó este fallo de seguridad en una petición a Studio utilizando el id de un usuario de Twitter donde “victim´s user id” puede ser cualquier id público de un usuario de Twitter:
Anand recibió 5.040 dólares según el programa de recompensas de Twitter (“bug bounty program”) por haber encontrado este fallo (aunque él reclamó más dinero, ya que pensaba que este fallo entraba en otra categoría más crítica). Pero ¿qué hubiera ocurrido si finalmente ese fallo no se hubiera encontrado y solucionado a tiempo? Charlando con mi compañero Santiago sobre esta situación, empezamos a pensar en posibles escenarios de un posible "apocalipsis" digital a través de Twitter.
Twitter tiene publicado en su web que dispone de un control para analizar el origen y contenido de los enlaces que se publican en los tweets. En función del resultado del análisis del enlace y el nivel de seguridad de la cuenta, puede mostrarnos un aviso (“warning”) cuando la URL o incluso puede llegar a bloquear dicho sitio web si este se encuentra dentro de una lista de sitios potencialmente peligrosos.
PoC: Vínculos no seguros en Twitter
Vamos realizar una prueba para comprobar el nivel de control que Twitter realiza a las URL publicadas. Para ello hemos creado dos cuentas con los parámetros de seguridad que se activan por defecto al crearlas - sin ninguna verificación extra o protección con un segundo factor de autenticación -. Desde una de las cuentas vamos a publicar dos tweets que luego veremos en la otra cuenta que está siguiendo a la primera. La cuenta que publica las URL se llama Cibertest y la cuenta follower se llama Cibertest2.
En este primer video podemos ver la publicación de un tweet con una URL y un fichero ejecutable subido al servicio de intercambio WeTransfer:
Como hemos podido observar, parece que no se ha realizado ningún proceso de análisis sobre el fichero descargado ya que lo más probable es que la URL de WeTransfer esté autorizada. De todas formas, el fichero podría ser un malware y podemos bajarlo sin problemas y ejecutarlo (en este punto también es importante el factor de protección del ordenador del usuario que lo ha descargado).
El servicio de alojamiento lo más habitual (o al menos debería de ser así) es que pueda detectar que el fichero subido contenga algún tipo de malware. Por este motivo vamos a realizar de nuevo la prueba, pero esta vez hemos creado nuestro propio servidor de ficheros usando Owncloud - siguiendo este tutorial - y publicado en Internet y hemos subido allí de nuevo el fichero ejecutable. La URL generada no está registrada en las válidas de Twitter:
De nuevo la URL se publica sin problemas, sin ningún tipo de aviso. Ocurre lo mismo que en el caso anterior, nos permite bajar el fichero, aunque esta vez Google Chrome nos avisa que el archivo es un ejecutable (no debería de ser difícil para un atacante buscar alternativas para ejecutar un programa y evitar este aviso).
Ahora supongamos por un momento tenemos un fallo 0Day en Twitter que nos permitiera publicar en cualquier cuenta sin necesidad de saber la contraseña (como el que hemos mencionado al principio del artículo) y por otro lado hemos conseguido subir y camuflar un malware utilizando una URL propia de uno de nuestros servidores de ficheros. Si publicamos un tweet utilizando sólo las tres primeras cuentas en Twitter con más seguidores y además enlazamos el malware (con diferentes versiones para cada plataforma) tendríamos potencialmente casi 300 millones de usuarios potencialmente afectados:
En definitiva, si este caso hipotético se pudiera llevar a cabo, podríamos estar ante el malware definitivo con uno de los factores de propagación e impacto más grande de la historia.
Autor: Fran Ramirez (@cyberhadesblog) escritor de libro "Microhistorias: anécdotas y curiosidades de la historia de la informática" e investigador en ElevenPaths.
 |
| Figura 1: Cómo unos "descuidos" de seguridad en Twitter pueden usarse para dominar el mundo |
Las consecuencias serían realmente de proporciones "bíblicas" (como decían en nuestra querida película “Cazafantasmas”) ya que un alto porcentaje de esos seguidores ejecutarían el malware con toda tranquilidad, debido a su total confianza en la fuente. Esto que parece improbable, pudo haber estado más cerca de lo que parece, y no es la primera vez, que en el año 2014 también tuvo un CSRF peligroso que permitía robar cuentas.
En menos de un año han aparecido al menos dos fallos de seguridad relacionados con Twitter que permitían a un atacante realizar diversas acciones desde cualquier cuenta como publicar un tweet en su nombre, subir videos, borrar imágenes, ver ficheros privados, etcétera. Ambas tienen en común el mismo vector de ataque: Twitter Media Studio.
 |
| Figura 2: Twitter Media Studio |
Media Studio fue lanzado en agosto de 2016 y sustituye a Video Studio. Está formado por una serie de herramientas las cuales ofrecen algunas nuevas características, como mejoras de rendimiento, nueva biblioteca de medios unificada, programación de tweets mejorada, nuevos controles de acceso, etcétera.
Los bugs de Twitter
El investigador Anand Prakash encontró la primera de ellas cuando comenzó a buscar agujeros de seguridad dentro de esta librería y se dio cuenta que todas las peticiones a la API de Studio estaban enviando un parámetro llamado “owner_id”. Este parámetro “owner_id” es un número, secuencial y público, que corresponde a un usuario real de Twitter. Desde esta página web puedes averiguar el id de cualquier usuario de Twitter:
 |
| Figura 3: Página web para obtener el id de cualquier cuenta de Twitter |
Aunque parezca increíble, este parámetro carecía de un control de seguridad o autorización para confirmar si el usuario que estaba realizando la petición era realmente el propietario de la cuenta. Por lo tanto, simplemente cambiando este valor, era posible realizar acciones sobre cualquier cuenta de Twitter, como poner nuevos tweets, subir videos, fotos, etcétera. Todo esto sin necesidad de saber la contraseña de la cuenta de Twitter.
En este ejemplo vemos cómo se utilizó este fallo de seguridad en una petición a Studio utilizando el id de un usuario de Twitter donde “victim´s user id” puede ser cualquier id público de un usuario de Twitter:
POST /1/tweet.json HTTP/1.1En este otro ejemplo vemos la forma de subir cualquier contenido multimedia a la cuenta atacada:
Host: studio.twitter.com
{"account_id":"attacker's account id","owner_id":"victim's user id","metadata":
{"monetize":false,"embeddable_playback":false,"title":"Test tweet by attacker",
"description":"attacker attacker","cta_type":null,"cta_link":null},"media_key":"",
"text":"attacker attacker"}
POST /1/library/add.json HTTP/1.1Anand Prakash encontró el problema el mismo día de su lanzamiento, pero no fue hasta mayo de 2017 cuando decidió hacerlo público. Twitter asegura que lo solucionó en menos de 24 horas y que ninguna cuenta se vio comprometida. Además, argumentan que, durante el lanzamiento, sólo los desarrolladores autorizados por Twitter tuvieron acceso a estas nuevas herramientas de Studio.
Host: studio.twitter.com
{"account_id":"attacker's accountid","owner_id":"victim's id","metadata":{"monetize":false,"name":"abcd.png","embeddable_playback":true,"title":"Attacker","description":"","cta_type":null,"cta_link":null},"media_id":"","managed":false,"media_type":"TweetImage"}
 |
| Figura 4: Twitter Bug Bounty Program en HackerOne |
Anand recibió 5.040 dólares según el programa de recompensas de Twitter (“bug bounty program”) por haber encontrado este fallo (aunque él reclamó más dinero, ya que pensaba que este fallo entraba en otra categoría más crítica). Pero ¿qué hubiera ocurrido si finalmente ese fallo no se hubiera encontrado y solucionado a tiempo? Charlando con mi compañero Santiago sobre esta situación, empezamos a pensar en posibles escenarios de un posible "apocalipsis" digital a través de Twitter.
 |
| Figura 5: Vínculos no seguros en Twitter |
Twitter tiene publicado en su web que dispone de un control para analizar el origen y contenido de los enlaces que se publican en los tweets. En función del resultado del análisis del enlace y el nivel de seguridad de la cuenta, puede mostrarnos un aviso (“warning”) cuando la URL o incluso puede llegar a bloquear dicho sitio web si este se encuentra dentro de una lista de sitios potencialmente peligrosos.
PoC: Vínculos no seguros en Twitter
Vamos realizar una prueba para comprobar el nivel de control que Twitter realiza a las URL publicadas. Para ello hemos creado dos cuentas con los parámetros de seguridad que se activan por defecto al crearlas - sin ninguna verificación extra o protección con un segundo factor de autenticación -. Desde una de las cuentas vamos a publicar dos tweets que luego veremos en la otra cuenta que está siguiendo a la primera. La cuenta que publica las URL se llama Cibertest y la cuenta follower se llama Cibertest2.
En este primer video podemos ver la publicación de un tweet con una URL y un fichero ejecutable subido al servicio de intercambio WeTransfer:
Figura 6: Comportamiento de Twitter con tweet con malware en WeTransfer
Como hemos podido observar, parece que no se ha realizado ningún proceso de análisis sobre el fichero descargado ya que lo más probable es que la URL de WeTransfer esté autorizada. De todas formas, el fichero podría ser un malware y podemos bajarlo sin problemas y ejecutarlo (en este punto también es importante el factor de protección del ordenador del usuario que lo ha descargado).
El servicio de alojamiento lo más habitual (o al menos debería de ser así) es que pueda detectar que el fichero subido contenga algún tipo de malware. Por este motivo vamos a realizar de nuevo la prueba, pero esta vez hemos creado nuestro propio servidor de ficheros usando Owncloud - siguiendo este tutorial - y publicado en Internet y hemos subido allí de nuevo el fichero ejecutable. La URL generada no está registrada en las válidas de Twitter:
Figura7: Comportamiento de Twitter con tweet con malware en OwnCloud
De nuevo la URL se publica sin problemas, sin ningún tipo de aviso. Ocurre lo mismo que en el caso anterior, nos permite bajar el fichero, aunque esta vez Google Chrome nos avisa que el archivo es un ejecutable (no debería de ser difícil para un atacante buscar alternativas para ejecutar un programa y evitar este aviso).
 |
| Figura 8: Publicación de un tweet con una URL propia desde un servidor de ficheros propio |
Ahora supongamos por un momento tenemos un fallo 0Day en Twitter que nos permitiera publicar en cualquier cuenta sin necesidad de saber la contraseña (como el que hemos mencionado al principio del artículo) y por otro lado hemos conseguido subir y camuflar un malware utilizando una URL propia de uno de nuestros servidores de ficheros. Si publicamos un tweet utilizando sólo las tres primeras cuentas en Twitter con más seguidores y además enlazamos el malware (con diferentes versiones para cada plataforma) tendríamos potencialmente casi 300 millones de usuarios potencialmente afectados:
 |
| Figura 9: Tres de las cuentas con más followers de Twitter |
En definitiva, si este caso hipotético se pudiera llevar a cabo, podríamos estar ante el malware definitivo con uno de los factores de propagación e impacto más grande de la historia.
Autor: Fran Ramirez (@cyberhadesblog) escritor de libro "Microhistorias: anécdotas y curiosidades de la historia de la informática" e investigador en ElevenPaths.
Me sorprende que tenga un fallo como ese, es un bypass muy bien estudiado para encontrarlo, muy buen trabajo.
ResponderEliminar