1. Información del reporte

Título: Vulnerabilidades en las aplicaciones Facebook y Facebook Messenger para Android
Reporte ID: STIC-2014-0529
Reporte URL: http://www.fundacionsadosky.org.ar/publicaciones-2
Fecha de publicación: 2014-07-28
Fecha de última actualización: 2014-07-28
Fabricantes contactados: Facebook Inc. (NASDAQ:FB)
Modo de publicación: Coordinado

2. Información de vulnerabilidades

Clase: Exposición de información por datos transmitidos [CWE-201], Exposición de información por datos transmitidos [CWE-201], Proxy o intermediario no intencional [CWE-441]
Impacto: Denegación de servicio, Filtración de datos
Remotamente explotable: Yes
Localmente explotable: Yes
Identificador CVE: CVE-2014-NNNNY, CVE-2014-NNNNX, CVE-2014-NNNNZ

3. Proxy abierto en aplicación de Facebook en Android

Según datos financieros publicados de Facebook para el segundo trimestre de 2014, al 30 de junio la compañía tiene 1.070 millones de usuarios activos que utilizan dispositivos móviles y un promedio de 654 millones de usuarios móviles activos diariamente [1]. La aplicación de Facebook para Android está entre las diez aplicaciones más descargadas con entre 500 y 1.000 millones de instalaciones a partir de 24 de junio del 2014[3].

La aplicación incluye como componente interno un servidor genérico de HTTP que es usado como proxy caché en el momento que se reproducen los videos. Este servidor se encuentra mal configurado y acepta pedidos de cualquier cliente, sea remoto o local, permitiendo a un atacante conectarse a él y utilizar el dispositivo de la víctima como proxy abierto. Como resultado, entre otras cosas, el atacante puede llevar a cabo ataques de denegación de servicio como agotar la memoria del dispositivo o consumir datos de la red 3G o LTE sobrepasando el límite del plan de datos del usuario.

4. Exposición de videos privados de usuarios en la aplicación Facebook de Android

La aplicación permite a usuarios subir videos a Facebook y configurar quienes son capaces de verlos (puede configurarse para que sea público, que sólo sea posible ver por amigos, por uno mismo o una lista personalizada de personas). La aplicación también permite a usuarios reproducir estos videos en el dispositivo. Según la política de privacidad de la compañia [2], Facebook previene que otros usuarios puedan obtener acceso a un video que ha sido marcado privado por un usuario. Sin embargo, cuando un usuario se conecta a Facebook utilizando la aplicación Android, la confidencialidad de los videos reproducidos puede ser comprometida.

Al descargar los videos para que puedan ser reproducidos en el dispositivo, la aplicación obtiene el contenido de forma insegura, permitiendo que cualquiera con acceso a la misma red o a cualquier red en la ruta del dispositivo a la red de entrega de contenidos (CDN) de Facebook pueda capturar y obtener el contenido del video sin importar la política de acceso configurada por el usuario ni la política de privacidad de Facebook.

5. Exposición de grabaciones de audio de mensajes privados de chat en la aplicación Facebook de Android

La aplicación de Facebook Messenger se encuentra también entre las 10 aplicaciones más descargadas de Google Play, con entre 500 y 1.000 millones de descargas [4] . Tanto Facebook como Facebook Messenger permiten a un usuario enviar y reproducir grabaciones de audio dentro de mensajes privados a otros usuarios. La transmisión de estas grabaciones es realizada de forma insegura, permitiendo que cualquier dispositivo conectada a la misma red o en la ruta al contenido obtener dichas grabaciones.

6. Vulnerabilidad en servidor de Caché de videos: Paquetes vulnerables

• Versiones anteriores a 13.0.0.13.14 de la aplicación de Facebook de Android

7. Vulnerabilidad sobre videos: Paquetes vulnerables

• Versiones anteriores a 10.0.0.28.27 de la aplicación de Facebook de Android hasta junio 11, 2014.

8. Vulnerabilidad sobre grabaciones de audio: Paquetes vulnerables

• Versiones anteriores a 10.0.0.28.27 de la aplicación de Facebook de Android.
• Versiones anteriores a 5.0.0.25.1 de la aplicación de Facebook Messenger de Android

9. Información y soluciones del vendedor

Facebook confirmó y arregló las tres vulnerabilidades. Según la compañía, la vulnerabilidad sobre grabaciones de audio ya era conocida y un arreglo para la misma estaba en marcha para la versión beta. Primero salieron arreglos para los problemas de audio y de video a principios de junio 2014. Mientras que el arreglo al problema de audio requería una actualización, el arreglo de la vulnerabilidad de video funciona con versiones anteriores de la aplicación que soportan obtener el contenido del CDN utilizando HTTPS.

La nueva versión 13.0.0.13.14 de Facebook arregla el problema de proxy abierto simplemente configurando al servidor de caché de videos para que solo escuche pedidos locales y no remotos.

Para determinar que versión de la aplicación tiene instalada en su dispositivo de Android, puede ir a "Ajustes|Aplicaciones" y luego hacer click en Facebook o Facebook Messenger.

10. Crédito

Las vulnerabilidades fueron descubiertas e investigadas por Joaquín Manuel Rinaudo. La publicación de este reporte fue coordinada por Programa Seguridad en TIC.

11. Descripción técnica

Facebook utiliza un servidor HTTP como proxy para contenido audiovisual encargado de obtener los pedidos de CDN y almacenarlos en la caché. Este servidor está incluido en el espacio del proceso de la aplicación móvil y escucha pedidos en un puerto local no fijo de TCP. El constructor de la clase com.facebook.video.server.VideoServerBase embebido en la aplicación instancia un objeto GenericHttpServer. La instancia creada escucha a los pedidos de cualquier cliente, sea local o remoto, permitiendo a atacantes hacer pedidos a servidores de terceros mediante él.

El servidor acepta tres tipos de pedidos de GET: /proxy, /cache-window and /cache-thru. Los parámetros para estos pedidos son 'remote-uri' cuyo valor es una URL y 'vid' que actua como identificador. Al recibir un pedido, el servidor primero realiza un pedido de HEAD a la URL indicada por 'remote-uri' para obtener el encabezado content-length del recurso. Después, el servidor realiza una serie de pedidos de tipo GET hasta alcanzar el content-length declarado. Cualquier redirección al pedido de HEAD es seguido por pedidos de GET al sitio redirigido.

Mientras que el pedido de 'proxy' tiene como efecto que el servidor simplemente reenvie el contenido al cliente, los pedidos de 'cache-thru' y 'cache-window' indican que además de reenviar el pedido, el servidor almacene una copia local en la memoria interna del dispositivo en el directorio data/data/com.facebook.katana/files/video-cache.

Un atacante puede utilizar el móvil de una víctima que tenga la aplicación de Facebook instalada como proxy abierto realizando pedidos al servidor embebido por /proxy y pasando como parámetro una versión acortada de URL que apunte a cualquier sitio destino. Como las redirecciones son seguidas, un atacante podría usar una versión acortada de la URL destino obtenida de sitios como goo.gl. También puede causar que el dispositivo agote su memoria interna realizando pedidos de /cache-thru y destinando como 'remote-uri' a algún sitio que contenga un archivo de gran tamaño. Lo mismo puede hacerse para consumir el plan de datos del usuario.

Se pueden seguir los siguientes pasos para reproducir la vulnerabilidad:

1) Conectarse con adb shell al dispositivo corriendo Facebook y correr netstat para identificar el puerto en el cual escucha el servidor.

Desde un dispositivo en la misma red ejecutar el comando telnet [dirección IP del telefono] [puerto TCP de obtenido en paso 1] con el siguiente pedido HTTP:

GET /cache-thru?remote-uri=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Dz9Uz1icjwrM&vid=a HTTP/1.1

3) El dispositivo realiza un pedido de HEAD al link, al que los servidores de youtube responderán con un 302 con sitio redirigiendo el pedido a m.youtube.com. La víctima obtendrá luego el contenido de esta URL, la almacenará en la memoria interna y lo reenviará al cliente de telnet.

Los videos almacenados en la red CDN de Facebook son obtenidos vía HTTP. Cuando un usuario hace un pedido a la aplicación de reproducción de uno de ellos, una instancia de la clase VideoServerBase realiza un pedido a la instancia de GenericHTTPServer con el parámetro de '/caching-thru' apuntando como URI a la dirección del CDN donde el video está almacenado. Dado que el esquema de la URI es HTTP, el pedido del servidor de caché al CDN es realizado de forma insegura.

Cualquiera con acceso a la red local o en la ruta entre el dispositivo y el CDN de Facebook puede obtener la URL del pedido de contenido de video realizado por el servidor de caché capturando los paquetes de la red y a partir de esta URL puede obtener el contenido del video directamente al CDN.

Pasos para reproducir la vulnerabilidad:

1) Descargar y instalar la aplicación de Facebook.

2) Autenticarse a Facebook utilizando cualquier cuenta (llamemosla "cuenta A").

3) Usando un navegador, autenticarse a Facebook utilizando otra cuenta separada ("cuenta B"), publicar un video y permitirle el acceso a sólo las dos cuentas mencionadas.

4) Usando la aplicación de Facebook de Android, buscar la publicación del video pero no hacer click para reproducirlo.

5) Configurar un proxy para el dispositivo Android, como por ejemplo ZAP, Burp, etc. Esto hará que los pedidos HTTPS dejen de funcionar pero no es necesario que sigan funcionando para reproducir la vulnerabilidad.

6) Reproducir el video en el dispositivo Android.

7) Copiar la URL del pedido GET obtenido en el proxy (esto emula una atacante capturando tráfico) y copiar este link en un navegador para obtener una copia del video sin necesidad de autenticarse.

La tercera vulnerabilidad está relacionada con las grabaciones de audio enviadas desde un usuario de Facebook a otro mediante chat sea en la aplicación de Facebook o Facebook Messenger. La aplicación del remitente de la grabación sube la misma utilizando un pedido de POST de HTTPS a graph.facebook.com. Luego un pedido GET de HTTPS a api.facebook.com/method/messaging.getAttachment es respondido con una redirección hacia al contenido de la grabación. Aunque los pedidos iniciales de POST y GET son enviados utilizando HTTPS y autenticados utilizando el token del usuario, la redirección del pedido se realiza utilizando HTTP. Por otro lado, la aplicación del usuario receptor descarga la grabación haciendo un pedido a api.facebook.com/method/getAttachment que es contestado con una redirección a attachment.fbsbx.com que se obtiene por HTTP donde el contenido está almacenado. El parámetro de uid de ambos pedidos indican los IDs de Facebook del usuario receptor y remitente.

La vulnerabilidad se encuentra en la clase com.facebook.ui.media.fetch.MediaRedirectHandler en el método getLocationURI en paquetes previos a la versión 10.0.28.27 . Este método llama a uno privado que traduce la esquema de la dirección de HTTPS a HTTP para cualquier pedido de redirección al dominio de attachment.fbsbx.com.

Como resultado de lo anterior, un atacante con acceso a la misma red que el dispositivo víctima o en la ruta entre el dispositivo y la red attachment.fbsbx.com puede capturar y obtener las grabaciones de audio de usuarios de Facebook.

Pasos para reproducir la vulnerabilidad de grabaciones de audio:

1) Logearse a Facebook utilizando la aplicación Android.

2) Capturar los paquetes de la red utilizando una herramienta de captura (por ejemplo, wireshark).

3) Utilizando la aplicación de Facebook, enviar una grabación de audio a otro usuario.

4) Obtener el pedido GET al dominio attachment.fbsbx.com entre el tráfico capturado. Utilizar un navegador para obtener dicha grabación de audio.

12. Cronología del reporte

• 2014-05-13: El investigador envió una descripción técnica de las vulnerabilidades a Facebook.
• 2014-05-13: Facebook reconoció la vulnerabilidad de audio y declaró que un arreglo para dicha vulnerabilidad estaba en marcha para usuarios de la versión beta y que una actualización para el resto de los usuarios seguiría en el futuro cercano.
• 2014-05-19: La compañía admitió la vulnerabilidad de los videos y requirió información acerca del dispositivo usado para las pruebas.
• 2014-05-19: El investigador envió la información requerida.
• 2014-05-29: El investigador pidió información acerca del estado de las vulnerabilidades y notificó a Facebook de los planes de para publicar un reporte de seguridad para notificar a los usuarios afectados. Se preguntó a la compañía de la red social si se podía continuar la comunicación por medio de email y no utilizando el sistema de reporte de vulnerabilidades de Facebook debido a que este requería que tanto el coordinador como el investigador tengan una cuenta en la red social.
• 2014-06-04: Facebook se comunicó con Programa Seguridad en TIC vía email. Programa Seguridad en TIC estableció como el 18 de junio como fecha de publicación del reporte de seguridad e indicó a la compañía de evidencia de vulnerabilidades similares siendo activamente explotadas por terceros para recolectar contenido privado de usuarios.
• 2014-06-05: Facebook pidió por evidencia de explotación activa y aseguró que estaba trabajando en arreglar las vulnerabilidades.
• 2014-06-06: Programa Seguridad en TIC envió una referencia a las diapositivas 82 a 87 [5] de las presentaciones de la NSA filtradas por Glenn Greenwald acerca de captura de tráfico para obtener imágenes de Facebook almacenadas en servidores de Akamai.
• 2014-06-12: Una nueva actualización de la aplicación de Facebook fue publicada en el mercado. El investigador analizó la misma y encontró que las vulnerabilidades 2 y 3 habían sido arregladas.
• 2014-06-14: Facebook informó al investigador acerca que las vulnerabilidades de audio y video habían sido reparadas y pidió por la confirmación del investigador.
• 2014-06-16: El investigador confirmó a la red social que ambas vulnerabilidades se encontraban resueltas. Programa Seguridad en TIC preguntó a Facebook sobre el estado de la vulnerabilidad de proxy abierto que seguía siendo un problema.
• 2014-06-16: Facebook pidió por una prueba de concepto para reproducir la vulnerabilidad de proxy abierto.
• 2014-06-16: Joaquín Manuel Rinaudo envió pasos para reproducir la vulnerabilidad.
• 2014-06-16: Una versión preliminar del reporte es enviada a Mitre solicitando una asignación de identificadores de CVE para las vulnerabilidades.
• 2014-06-20: Mitre responde argumentando que ninguna de las vulnerabilidades de audio y video cumplían los criterios de inclusión para CVE.
• 2014-06-22: Programa Seguridad en TIC requirió a Facebook información acerca del estado del problema del servidor de caché.
• 2014-06-23: Facebook responde asegurando que está trabajando con el equipo y que estará en contacto cuando tenga información nueva para compartir.
• 2014-06-24: Un nuevo email a Mitre es enviado pidiendo una asignación de CVE al problema de proxy abierto y proveyendo información adicional sobrelas otras vulnerabilidades y opiniones de por qué cumplían el criterio de inclusión de CVE.
• 2014-07-01: Facebook envía una nueva confirmación que sigue trabajando en la solución a la vulnerabilidad.
• 2014-07-02: Programa Seguridad en TIC expresa su preocupación hacia Facebook respecto del tiempo transcurrido desde el reporte original y sobre por que un arreglo tan simple tarde tanto en implementarse.
• 2014-07-02: Facebook responde que sigue trabajando activamente en resolver el problema.
• 2014-07-03: Se le envía un nuevo mail a Mitre preguntando por decisión de los identificadores en vista a la nueva información prevista en el anterior email.
• 2014-07-08: El investigador le recuerda a Facebook que el reporte estaba originalmente programado para junio 18 y que todavía no había un tiempo estimado para la resolución del problema del servidor de caché, así que una nueva fecha de publicación fue establecida para Julio 16, 2014 y que esa fecha era final pero que Programa Seguridad en TIC consideraría moverla sobre la base de recibir información nueva acerca de los planes de solucionar la vulnerabilidad.
• 2014-07-08: Nuevo email a Mitre pidiendo información acerca de los identificadores de CVE.
• 2014-07-09: Facebook pidió a los investigadores atrasar la publicación una semana más, asegurando que la solución estaría online para entonces.
• 2014-07-11: Programa Seguridad en TIC cambió la fecha de publicación para Julio 23, 2014.
• 2014-07-11: Facebook informó que un parche estaba activo en su versión beta para Android.
• 2014-07-11: El investigador confirmó que Facebook había resuelto el problema en la versión beta.
• 2014-07-16: Se envió un nuevo email a Mitre indicando que no se había obtenido respuesta alguna y era necesario conocer su respuesta dado a la publicación era inminente ya que las vulnerabilidades habían sido arregladas.
• 2014-07-17: Mitre contestó que el grupo de asignación de CVE no tenía una conclusión final acerca de las vulnerabilidades reportadas y recomendó que se publique el reporte sin los identificadores. El grupo de asignación de CVE siente que las observaciones de la investigación ocupan una frontera entre software controlado por el cliente y cosas específicas del sitio.
• 2014-07-21: Facebook informó que una actualización estaba disponible al 5% de sus usuarios.
• 2014-07-21: La red social informó que la actualización llegó al 50% de los usuarios.
• 2014-07-21: La red social informó que la actualización llegó al 100% de los usuarios.
• 2014-07-22: Programa Seguridad en TIC preguntó si la cifra correspondía a la disponibilidad o a la cantidad de instalaciones de la actualización.
• 2014-07-22: Facebook confirmó que el porcentaje corresponde a la disponibilidad de la actualización.
• 2014-07-28: El reporte fue publicado.

13. Referencias

[1] http://investor.fb.com/releasedetail.cfm?ReleaseID=861599
[2] https://www.facebook.com/note.php?note_id=%20322194465300
[3] https://play.google.com/store/apps/details?id=com.facebook.orca
[4] https://play.google.com/store/apps/details?id=com.facebook.katana
[5] http://hbpub.vo.llnwd.net/o16/video/olmk/holt/greenwald/NoPlaceToHide-Documents-Compressed.pdf

14. Acerca Fundación Dr. Manuel Sadosky

La Fundación Dr. Manuel Sadosky es una institución público privada cuyo objetivo es favorecer la articulación entre el sistema científico – tecnológico y la estructura productiva en todo lo referido a la temática de las Tecnologías de la Información y la Comunicación (TIC). Creada a través del Decreto Nro. 678/09 del Poder Ejecutivo Nacional, la Fundación es presidida por el ministro de Ciencia, Tecnología e Innovación Productiva. Sus vicepresidentes son los presidentes de las cámaras más importantes del sector TIC: CESSI (Cámara de Empresas de Software y Servicios Informáticos) y CICOMRA (Cámara de Informática y Comunicaciones de la República Argentina). Para más información visitar http://www.fundacionsadosky.org.ar

15. Derechos de autor

El contenido de este reporte tiene copyright (c) 2014 Fundación Sadosky y se publica bajo la licencia Creative Commons Attribution Non-Commercial Share-Alike 4.0: http://creativecommons.org/licenses/by-nc-sa/4.0/