Mapeo de la comunicación entre cuentas de Facebook usando un ataque de canal lateral basado en navegador


Una vulnerabilidad ahora parcheada en la versión web de Facebook Messenger permitió que cualquier sitio web expusiera con quién has estado enviando mensajes.

En una publicación anterior, mostré cómo sus "me gusta" de Facebook, su historial de ubicación y otros metadatos podrían haber sido extraídos de su cuenta de Facebook usando un ataque de canal lateral que llamé "Fuga de marcos entre sitios" o CSFL, para abreviar.

En esta publicación, formalizaré el ataque de CSFL, cubriré las últimas mejoras y revisaré la vulnerabilidad que revelé a Facebook.

¿Qué es un ataque de CSFL?

La fuga de marcos entre sitios es un ataque de canal lateral, realizado en el navegador web de un usuario final, que explota las propiedades de origen cruzado de los elementos de iframe para determinar el estado de una aplicación vulnerable.

¿Qué es un estado?

Tome una página de resultados de búsqueda como ejemplo. En términos de estado, la información más útil que el atacante podría descubrir sería si una consulta dada arrojó resultados.

Si un atacante pudiera determinar el estado de la página de resultados de búsqueda, probablemente podría inferir otra información sobre el usuario actualmente registrado. Haga clic en el breve video de prueba de concepto que demuestra esto.


Identificando la Amenaza

Como muchas personas, uso Facebook Messenger para comunicarme con mis amigos, familiares y empresas. Al igual que sucede con las aplicaciones que uso regularmente, sentí la necesidad de entender cómo funciona Facebook Messenger.

Comencé a hurgar en la aplicación web de Messenger y noté que los elementos iframe dominaban la interfaz de usuario. El cuadro de chat, así como la lista de contactos, se representaron en iframes, lo que abre la posibilidad de un ataque CSFL.

Al igual que en el error anterior, confié en la capacidad de contar el número de iframes en una página de origen cruzado ubicada en una página de fondo que podría ser controlada por un atacante. Sin embargo, en Messenger, no había forma de crear solicitudes de búsqueda sin la interacción del usuario. Además, a diferencia del error anterior, el recuento de iframe siempre llegó a tres una vez que la página estaba completamente cargada, eliminando la posibilidad de detectar un "estado" utilizando el número de elementos de iframe.

Comencé a cavar en esos tres iframes, para entender cómo, por qué y cuándo están cargados. Decidí registrar los datos del recuento de iframe a lo largo del tiempo para la mayor cantidad de puntos finales que pude encontrar, con el objetivo de descubrir estados interesantes y detectables.

Después de algunas pruebas, comencé a buscar en el punto final de la conversación. Grabé datos de "estado completo", es decir, páginas que cargarían mi conversación con un usuario con el que he estado en contacto, y algunos datos de "estado vacío", mostrando conversaciones con usuarios con los que nunca he contactado.

Después de ver cinco ejemplos, estaba claro que estaba en algo. Los gráficos de "estado vacío" producen de manera consistente un patrón interesante como se puede ver en la visualización a continuación y en el video de prueba del concepto anterior.


La línea azul superior es el recuento de iframe para el estado vacío, la línea roja inferior es el recuento para el estado completo.

Cuando el usuario actual no ha estado en contacto con un usuario específico, el recuento de iframe alcanzaría tres y luego se reduciría repentinamente durante unos pocos milisegundos. Esto permite a un atacante distinguir de manera confiable entre los estados lleno y vacío. Esto podría permitirle verificar de forma remota si el usuario actual ha conversado con una persona o empresa específica, lo que violaría la privacidad de esos usuarios.

Para resumir, al registrar los datos de recuento de cuadros a lo largo del tiempo, encontré dos nuevas formas de filtrar información de origen cruzado. Al observar patrones en lugar de un número estático, pude filtrar el "estado" de una ventana de origen cruzado, ya sea analizando el patrón sin procesar o cronometrando ciertos "hitos" del patrón.

Flujo de ataque

Para que este ataque funcione, debemos engañar a un usuario de Messenger para que abra un enlace a nuestro sitio malicioso. A continuación, necesitamos que el usuario haga clic en cualquier parte de la página. Por ejemplo, esto podría ser un botón de reproducción de video.

Una vez que se haga clic, se abrirá una nueva pestaña, manteniendo la anterior abierta en segundo plano.

La nueva pestaña comenzaría a reproducir un video, manteniendo al usuario ocupado mientras cargamos el punto final de la conversación del usuario en la pestaña de fondo.

Mientras Messenger se carga en segundo plano, registramos el recuento de iframe como expliqué anteriormente, lo que nos permite detectar si el usuario actual ha estado en contacto con usuarios específicos o con los robots de Facebook Messenger.




Mitigación

Habiendo informado sobre la vulnerabilidad a Facebook bajo su programa de divulgación responsable, Facebook mitigó el problema creando elementos iframe al azar, lo que inicialmente rompió mi prueba de concepto. Sin embargo, después de algunos trabajos, logré adaptar mi algoritmo y distinguir entre los dos estados. Compartí mi hallazgo con Facebook, que decidió eliminar por completo todos los marcos de la interfaz de usuario de Messenger.

Conclusiones

Los ataques de canales laterales basados en el navegador siguen siendo un tema que se pasa por alto, mientras que grandes jugadores como Facebook y Google se están poniendo al día, la mayoría de la industria aún no lo sabe.

Recientemente me uní a un esfuerzo para documentar esos ataques y las vulnerables API de DOM, puede encontrar más información en el repositorio xsleaks (actualmente todavía en construcción).

Como investigador, fue un privilegio haber contribuido a proteger la privacidad de la comunidad de usuarios de Facebook, como lo hacemos continuamente para nuestra propia comunidad Imperva.


Author: Ron Masas



Compartir...
Siguenos en twitter: @disoftin
Compartir en Google Plus

Acerca de Fredy Avila

Ingeniero de Sistemas, CEH, ECSA.
Twitter personal: @fredyavila
Twitter blog:@disoftin

0 comentarios:

Publicar un comentario