[LACNIC/Seguridad] Vulnerabilidades en las aplicaciones Facebook y Facebook Messenger para Android [STIC-2014-0529]

[Programa STIC]

      Vulnerabilidades en las aplicaciones
  Facebook y Facebook Messenger para Android


Boletín de Seguridad del Programa STIC

Fundación Dr. Manuel Sadosky - www.fundacionsadosky.org.ar



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
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: Perdida de datos, Negación de servicio
Remotamente explotable: Si
Localmente explotable: Si
Nombre CVE: CVE-2014-NNNNY, CVE-2014-NNNNX, CVE-2014-NNNNZ

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

  [CVE-2014-NNNNZ]

  Según datos financieros publicados de Facebook para el segundo cuarto
de 2014, desde el 30 de Junio la compañía tiene 1.07 billones de
usuarios activos que utilizan dispositivos móviles y un promedio de 654
millones de usuarios móviles [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*

  [CVE-2014-NNNNX]

  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*

  [CVE-2014-NNNNY]

  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
para Android

7. *Vulnerabilidad sobre videos: Paquetes vulnerables*

  . Versiones anteriores a 10.0.0.28.27 de la aplicación de Facebook
para 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
para Android.

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

9. *Información y soluciones del fabricante*

  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/