La implementación de
la política del mismo origen en las etiquetas HTML multimedia es insuficiente,
lo que permite peticionar páginas externas de las que es posible extraer cierta
información
Extraer información
de tu perfil personal de Facebook si tienes iniciada sesión en él y visitas una
web maliciosa. Esta es la prueba de concepto llamativa para esta
vulnerabilidad. Es posible extraer tu edad, tus likes, tu histórico de
localización... Esta vulnerabilidad ha sido reportada por Imperva, una empresa
de seguridad informática dedicada entre otras cosas al análisis de eventos de
seguridad. Se dieron cuenta de ella cuando investigaban el comportamiento del
mecanismo CORS (Cross-Origin Resource Sharing) en las distintas etiquetas HTML.
Lo que encontraron
fue ciertamente interesante... Pero antes es necesario explicar lo básico, para
que la vulnerabilidad no nos suene a chino. Primero, es necesario saber que el
navegador, por seguridad, restringe bastante las peticiones que puede hacer una
página web a otra página web que no esté en su dominio. ¿Qué quiere decir esto?
Que la página de facebook.com tal y como se ejecuta en tu navegador, no puede
hacer cierto tipo de peticiones a google.com. ¿Por qué este comportamiento? Un
ejemplo simple: imagínate que entras a paginamala.com y ésta se pone a hacer
peticiones a bancosantander.com, teniendo abierta la banca online... En
realidad luego no es tan sencillo, ya que existe otra serie de medidas para
evitar que esto ocurra aunque no se respete esa restricción, pero es un control
necesario más.
Lo que acabamos de
contar arriba no es ni más ni menos que la famosa "same-origin
policy" (política del mismo origen), cuyo nombre tras la breve explicación
cobra sentido. Lo que pasa es que la web, por definición, no tiene sentido como
nodos aislados, y una página funcional necesita recursos de otras webs. No
estamos hablando de estar en google.com y desde allí pinchar en un enlace a
facebook.com, no. Esto se considera como una acción intencionada del usuario, y
no es la misma página la que ejecuta la acción (ni recibe el contenido de facebook.com).
Hablamos de facebook.com necesitando una fuente de texto especial alojada en
google.com (que tiene una sección para obtener fuentes), para poder mostrarte
un texto con esa fuente.
Es por esto que para
que una web pueda acceder a recursos de otra (siempre que esta otra quiera), se
crea el mecanismo CORS antes mencionado, que define una serie de situaciones y
acciones que se deben llevar a cabo en éstas que permiten compartir recursos
entre orígenes distintos. Y esto es lo que significa CORS básicamente,
"intercambio de recursos de origen cruzado". En la práctica esto se
implementa haciendo el navegador una petición de prueba antes de la real, para
preguntar al dominio externo si permite peticiones completas desde otros
dominios, y si no lo permite explícitamente, no se hace la petición completa.
En algunos casos más relajados se permite hacer directamente la petición
completa, pero si el servidor no especifica explícitamente que cierta página
externa puede peticionarla (ya sea por no haber sido configurado o por otras
razones), el mismo navegador no permite a la página leer la respuesta a la
petición.
Ya disponemos de las
bases para entender la vulnerabilidad. Como bien sabemos, la parte principal de
una web está compuesta por HTML, que a su vez se compone de etiquetas
especificando el contenido de la web. Pues bien, en Google Chrome, las
etiquetas 'audio' y 'video', tienen un pequeño fallo. Estas etiquetas son
usadas para insertar audio y vídeo en las páginas, y uno de sus atributos es la
URL en la que está el recurso, (audio o vídeo). El fallo que tienen es que no
comprueban el tipo de recurso (básicamente, que sea audio o vídeo) antes de
permitir acceder a cierta información del recurso. Concretamente, sin saber si
el recurso es audio o vídeo y mientras lo descarga, esta etiqueta lanza una
serie de eventos que el código JavaScript de la página puede capturar y extraer
información de éstos.
¿Cuál es el problema
de ésto? Que según el número de eventos de cierto tipo que arroje la etiqueta
HTML mientras va cargando el recurso sea audio o no, es posible estimar el
tamaño del recurso. ¿Realmente esto es un problema? Sí. Y lo entenderemos
describiendo el escenario del ataque propuesto por el autor:
- Crea una página
en Facebook
- Publica un post
restringido a personas con 18 años
- Publica otro
post restringido a persona con 19 años
- Publica más
posts con la misma idea hasta cubrir todo el rango de edad, año a año
- Crea una página
maliciosa con tantas etiquetas 'audio' como posts has creado en Facebook,
y que cada una apunte a un post.
- Controla la
cantidad de veces que se lanza este evento por cada etiqueta, para estimar
el tamaño de cada página.
- Consigue que la
víctima visite tu página maliciosa
La idea de esto es
que el post restringido a la edad que tiene el usuario tendrá un tamaño
distinto al resto de páginas, que serán más pequeñas porque en vez del ofrecer
el contenido del post, devolverán un mensaje del estilo "no estás
autorizado a ver este post". El autor describía esto como jugar a un juego
de preguntas de sí o no para adivinar algo, al estilo de Quién es Quién. Este
escenario en concreto quizás no se pueda reproducir ahora mismo, ya que
Facebook ha cambiado hace poco el sistema de restricción y parece que no se
puede restringir por edad a nivel de año, sino por rangos concretos.
Igualmente, el autor describe otros campos que se pueden extraer y no sólo es
posible con Facebook, sino con cualquier web en realidad que tenga
características similares.
Afortunadamente, este
fallo (CVE-2018-6177) se reportó por las vías adecuadas (a Google de forma
privada) y actualmente se encuentra corregido en la versión estable 68. ¿Cómo
lo ha corregido Google? Ahora no permite que se dispare ese evento hasta que el
navegador no sepa a ciencia cierta que lo que está cargando es un recursos de
audio o vídeo. Esta vulnerabilidad es compleja, aunque comparada con el resto
de vulnerabilidades que se suelen encontrar hoy en día tampoco es
extraordinaria. Eso permite hacerse una idea de la cantidad de conocimiento que
es necesario tener sobre un sistema para encontrar una vulnerabilidad medio
grave en éste, sobre todo si es el navegador más usado en todo el mundo.
Más información:
·
A
Bug in Chrome Gives Bad Actors License to Play ‘20 Questions’ with Your Private
Data https://www.imperva.com/blog/2018/08/a-bug-in-chrome-gives-bad-actors-license-to-play-20-questions-with-your-private-data/
·
Stable
Channel Update for Desktop - Tuesday, July 24, 2018 https://chromereleases.googleblog.com/2018/07/stable-channel-update-for-desktop.html
·
Control
de acceso HTTP (CORS) https://developer.mozilla.org/es/docs/Web/HTTP/Access_control_CORS
·
Política
Same-origin https://developer.mozilla.org/es/docs/Web/Security/Same-origin_politica
·
Security:
Cross Site Resource Size Estimation via OnProgress events https://bugs.chromium.org/p/chromium/issues/detail?id=826187
·
defeat
cors attacks on audio/video tags https://chromium.googlesource.com/chromium/src.git/+/4504a474c069d07104237d0c03bfce7b29a42de6
Fuente: Hispasec