Fallo en Android permite a una aplicación sin privilegios obtener la MAC, el nombre de la red…

El sistema operativo para móviles de Google, Android, revela información sensible sobre la configuración de la red a aplicaciones instaladas que se suscriban a ciertos mensajes internos emitidos por el sistema

La dirección MAC del móvil, el BSSID, el nombre de la red, el rango IP de la red, la IP de la puerta de enlace, los servidores DNS… Toda esta información es revelada por el sistema operativo Android (sin pedir permisos adicionales) hasta su versión 8, conteniendo ya la 9 los parches necesarios para dejar de ofrecer esta información. Lo gracioso es que Android deja de ofrecer a través de la API recomendada la MAC real del dispositivo a partir de la versión 6, pero olvidaron eliminar esta información de los mensajes internos. Es necesario también indicar que esta información es accesible de forma legal siempre que se pida un permiso especial, pero este fallo permite accedir sin este permiso.

Pasamos a explicar un poco de qué va la cosa. Lo que hemos llamado “mensajes internos” en realidad se llaman broadcasts, que no son más que mensajes que se envían a cualquiera que se haya registrado para recibir ese tipo específico de mensaje. Dicho de otra forma, una aplicación se suscribe a un tipo de mensajes, y otra aplicación (o el sistema operativo Android) envía un mensaje especificando el tipo, y este mensaje lo recibirá todo aquel que esté suscrito a ese tipo de mensajes. Por debajo, es el sistema operativo el que se encarga de enviar los mensajes. Para suscribirte, basta con realizar una llamada a la API especificando un callback (un método que procese el mensaje) y para enviarlo sólo hay que hacer otra llamada a la API. Esta última llamada es asíncrona y permite que la aplicación siga ejecutándose aunque no todos los suscritos hayan recibido el mensaje.

El caso es que Android por defecto publica un par de tipos de broadcasts que puede recibir toda aplicación que se suscriba, sin necesitar permisos adicionales. Este par de tipos de broadcasts son ‘NETWORK_STATE_CHANGED_ACTION’ y ‘WIFI_P2P_THIS_DEVICE_CHANGED_ACTION’Y ambos revelan información sensible sobre la red (el primero más que el segundo). Esto nos lleva a hacernos las siguientes preguntas sobre el asunto:

  •  ¿Por qué la información filtrada se considera una vulnerabilidad?
  • ¿Qué se puede hacer con esta información?

Para empezar, información como el nombre de la red o el BSSID (que suele ser la MAC del punto de acceso) se puede cruzar con una base de datos como WiGLE para conocer la localización del punto de acceso y por tanto la localización del usuario. Esto no está bien porque el usuario no ha dado permiso en ningún momento para que una aplicación pueda obtener su localización. E información como el rango IP de la red, la IP de la puerta de enlace o los servidores DNS usados proporcionan información de la estructura de la red local, que puede facilitar la vida a un atacante. Es por esto que se considera una vulnerabilidad y por tanto ha recibido el identificador CVE-2018-9489. Al final, hay que recordar que la seguridad está presente en todo momento en el tratamiento automático de la información, o como comúnmente se conoce, la informática.

Más información:
 

Secuestran el tráfico de más de 7.500 routers MikroTik

Investigadores de la empresa china 360 NetLab han descubierto un ataque sobre routers MikroTik mediante el cual robaban el tráfico generado.

MikroTik es un fabricante letón de equipos de red y software dedicado a la administración de redes. Recientemente, en el curso de una investigación, el equipo de seguridad de la empresa china 360 NetLab descubrió que una elevado número de equipos del mencionado fabricante estaba enviando tráfico hacia servidores controlados por los atacantes.

El origen del ataque parece encontrarse en una vulnerabilidad que afecta a los routers MikroTik, en concreto, un exploit hallado en la fuga de herramientas de la CIA, Vault7, publicada por WikiLeaks. Esta vulnerabilidad, con CVE-2018-14847, permite a un atacante la lectura de archivos con información sensible, lo que posibilitaría un acceso a la gestión administrativa del dispositivo.

En el contexto de la investigación, detectaron que más de 370.000 de estos dispositivos eran vulnerables al exploit comentado. De estos, alrededor de 239.000 poseían configurado un proxy socks4 de forma presumiblemente malintencionada. Finalmente, de este conjunto, 7.500 tenían su tráfico desviado a los servidores de los atacantes. En concreto, el tráfico de los puertos FTP, SMTP, POP3 e IMAP. Además, y esto parece sorprender a los investigadores, también los puertos asociados con SNMP, el UDP 161 y 162.

Según el post de 360 NetLab, en España habría 84 dispositivos afectados, 218 en Ecuador, 189 en Argentina, 122 en Colombia, 25 en Chile, 24 en México, 20 en Nicaragua y 16 en Paraguay.

La vulnerabilidad fue parcheada hace tiempo por MikroTik, por lo que se debería actualizar el sistema operativo de los routers afectados a la última versión disponible. Adicionalmente, impedir la salida de los puertos de administración asociados a los componentes Webfig y Winbox.


7,500+ MikroTik Routers Are Forwarding Owners’ Traffic to the Attackers, How is Yours?

https://blog.netlab.360.com/7500-mikrotik-routers-are-forwarding-owners-traffic-to-the-attackers-how-is-yours-en/

Actualización de seguridad para Google Chrome

Google anuncia una nueva versión de su navegador Google Chrome 69. Se publica la versión 69.0.3497.81 para las plataformas Windows, Mac y Linux, que incluye algunas mejoras y soluciona 40 vulnerabilidades.

 

Como es habitual, Google solo proporciona información sobre los problemas reportados por investigadores externos o los considerados de particular interés. En esta ocasión, aunque se han solucionado 40 nuevas vulnerabilidades, solo se facilita información de 21 de ellas (siete de gravedad alta, trece de importancia media y tres bajas).

Se corrigen vulnerabilidades por accesos fuera de los límites de la memoria en los módulos V8BlinkWebAudioMojo y SwiftShader (CVE-2018-16065 al CVE-2018-16069 respectivamente). Desbordamientos de memoria en Skia SwiftShader (CVE-2018-16070 y CVE-2018-16082), acceso no autorizado a archivos en Devtoolsfalsificaciones de direcciones en los diálogos de permisos y en el modo de pantalla completa (CVE-2018-16079 y CVE-2018-16080) y usos de memoria después de liberarla en WebRTC yMemory Instrumentation (CVE-2018-16071 y CVE-2018-16085).

También del trabajo de seguridad interno, varias correcciones procedentes de auditoría interna, pruebas automáticas y otras iniciativas. Según la política de la compañía las vulnerabilidades anunciadas han supuesto un total de 29000 dólares en recompensas a los descubridores de los problemas.

Esta actualización está disponible a través de Chrome Update automáticamente en los equipos así configurados o a través de “Información sobre Google Chrome” (chrome://chrome/). O descargar directamente desde: google.com/chrome.

Más información:
 

Backswap ataca ahora a la banca española

Nueva versión de Backswap ataca ahora a seis entidades bancarias españolas.

 

Ya hablamos en la Una al Día de BackSwapuna variante de Tinba, un pequeño (10-50kB) pero sofisticado troyano bancario que implementa algoritmos de generación de dominios(para la comunicación con el C&C), captura de credenciales de usuario desde formularios o la inyección en diferentes procesos.

Existen múltiples versiones de Backswap, la mayoría tienen como objetivo bancos polacos o monederos de criptomonedas.

Como su nombre indica, el malware “intercambia” (swap) el número de cuenta de la víctima directamente por el de la “mula” que retirará el dinero.

Mediante un ataque MitB (Man-in-the-Browser), el atacante intercambia los números de cuenta inyectando código JavaScript directamente en la consola del navegador. Todo ello sin que la víctima se de cuenta.

Las últimas muestras encontradas han ampliado sus objetivos y apuntan ahora a bancos españoles. En total seis importantes entidades se han visto afectadas por este malware.

Backswap se propaga en campañas de spam, por lo que recomendamos no abrir nunca correos con adjuntos no solicitados. Además de mantener siempre actualizados sus sistemas de seguridad.


Indicadores de compromiso:

  • hxxps://5[.]61[.]47[.]74/batya/give.php
  • hxxps://103[.]242[.]117[.]248/batya/give.php
  • hxxps://mta116[.]megaonline[.]in
  • hxxps://czcmail[.]com (IP: 119[.]23[.]128[.]176)

Muestras recientes:

Más información:
 

Actualización de seguridad para Apache Struts

Apache ha confirmado una vulnerabilidad en el proyecto Apache Struts que podría permitir a un atacante remoto ejecutar código arbitrario.

 

Struts es un entorno de trabajo de código abierto para el desarrollo de aplicaciones web en Java EE bajo el patrón MVC (Modelo Vista Controlador). Desarrollado por la Apache Software Foundation, en un primer momento formaba parte del proyecto Jakarta, convirtiéndose en proyecto independiente en 2005.

La vulnerabilidad, considerada de gravedad crítica (con CVE-2018-11776), se debe a una validación insuficiente de los datos introducidos por el usuario. Esta vulnerabilidad reside en el core del framework y existen varios vectores de ataque:

  1. Cuando se utilizan resultados que no especifican un espacio de nombres (ni el el fichero de configuración de Struts ni en el propio código Java)
  2. Cuando se utiliza la etiqueta ‘url’ en una plantilla sin especificar una acción y un valor.

A través de estos vectores un atacante remoto podría inyectar un espacio de nombres arbitrario pasándolo como parámetro en una petición HTTP.

Para que el ataque se haga efectivo, se tienen que cumplir dos condiciones:

  1. El parámetro ‘alwaysSelectFullNamespace’ debe estar a ‘true’ en la configuración de Struts.
  2. El fichero de configuración de Struts contiene una etiqueta ‘<action …>’ que no especifica ningún espacio de nombres.

La forma más sencilla para evitar las vulnerabilidades es actualizar a Apache Struts versiones 2.3.35 o 2.5.17; disponibles desde: http://struts.apache.org/download.html#struts-ga

Más información:
 
S2-057 – Apache Struts
https://cwiki.apache.org/confluence/display/WW/S2-057

Semmle Discovers Critical Remote Code Execution Vulnerability in Apache Struts

https://semmle.com/news/apache-struts-CVE-2018-11776

Filtración de información confidencial a través de Philips IntelliSpace y Xcelera

Las vulnerabilidades han sido descubierta por el equipo de control de emergencia cibernética de sistemas de control industrial (ICS-CERT) junto con el equipo de Philips Hearhcare en los software Philips’ IntelliSpace Cardiovascular (ISCV) y en el software de administración de información e imagen cardiovascular Xcelera los cuales alertaron después de descubrir esta vulnerabilidad.

Extraída de https://www.philips.com/
Según ICS-CERT una explotación exitosa de las vulnerabilidades podría permitir a un atacante local con privilegios en el servidor ISCV/Xcelera elevar privilegios y ejecutar código arbitrario en el servidor.

A las vulnerabilidades encontradas se les han asignado los identificadores CVE-2018-14787 y CVE-2018-14789. La primera vulnerabilidad es debida a una gestión incorrecta de los privilegios, y la segunda es debida a un error de sanitización de los parámteros en el campo de búsqueda.

Aunque por separado, estas vulnerabilidades no son críticas, ambas juntas podrían permitir a un atacante ejecutar código arbitrario, lo que puede provocar a la obtención de detalles de los pacientes existentes en el sistema.

A día de hoy, según el Philips no han recibido datos ni indicios de que estas vulnerabilidades hayan sido explotadas.

Las vulnerabilidades afectan a la versión 3.1 o anterior de IntelliSpace Cardiovascular y a la versión 4.1 o anterior de de Xcelera.

Actualmente no hay parche oficial disponible que corrija estos problemas. Los parches que corrigen estas vulnerabilidades serán lanzados en su próxima versión prevista para el mes de octubre. Mientras tanto, Philip recomienda que se revisen los permisos a los archivos de todos los usuarios de la red.


Jose Ignacio Palacios
jipalacios@hispasec.com
@jpalaciosortega
Más información:
 
E Hacking News: Cybersecurity Vulnerabilities in Philips IntelliSpace System Exposes Sensitive Cardiac Patient Information:

Fallo en OpenSSH permite la enumeración de usuarios

OpenSSH, es una popular suite de utilidades criptográficas que permiten establecer una comunicación cifrada entre cliente y servidor.  Prácticamente omnipresente en el ámbito UNIX, OpenSSH fue escrita como parte del proyecto OpenBSD a partir de un fork de SSH; posee una licencia de código BSD.

El problema se ha hallado en la función userauth_pubkey. Como podemos ver en el código original:

authctx es una estructura que contiene información del contexto de autenticación, entre los valores que la componen, valid es un entero. Cómo podemos observar de los comentarios anexos, si posee un 0 el usuario no existe (lo contrario, existe y se le permite hacer login):

Tal y como comenta el reporte original, si el usuario no es válido la función vuelve (línea 100 de la primera captura) y el servidor enviaría un mensaje al cliente, SSH2_MSG_USERAUTH_FAILURE, indicando este error. Sin embargo, y siempre que la petición ssh de autenticación posea un formato erróneo, si el usuario existe, procede a verificar la petición y al no ser correcta falla en la función sshpkt_get_u8, con lo que se ejecutaría la función fatal y el servidor cerraría la conexión con el cliente de inmediato.

Es decir, siempre y cuando el usuario sea válido y la petición tenga un formato no válido, sabremos por el cierre de la conexión que el usuario existe en el sistema. Esto nos permite obtener un método de prueba y error para enumerar los posibles usuarios de un sistema.

Hasta ahora, OpenSSH ha tenido otras vulnerabilidades relacionadas con este tipo de ataques, del tipo timming, donde se explota una diferencia en tiempo o cantidad de datos en la respuesta entre un usuario válido u otro que no exista. Posibilitando, por lo tanto, un método para derivar la existencia.

Por ejemplo, esta, donde si un usuario existía en el sistema el servidor ssh respondía con dos segundos aproximados de retraso frente a la respuesta inmediata si el usuario no existía.

La corrección de este fallo se ha traducido en postergar la comprobación authctxt->valid que hemos visto después de comprobar que la petición posee un formato correcto, impidiendo que existan diferencias tanto si existe o no un usuario concreto. Observemos el cambio de posición del bloque de código afectado:

El fallo afecta, en principio, a todas las versiones de OpenSSH, aunque ya ha sido parcheado en la versión 7.7

No tardaremos en ver exploits y módulos de nmap explotando este error, por lo que habrá que estar atentos a los registros de eventos para comprobar como se comen el espacio en disco a base de martillear los servidores ssh.


Más información:
 

Vulnerabilidades en PimCore

Se han hecho públicas 3 vulnerabilidades en PimCore que podrían permitir extraer información de la base de datos y realizar ataques Cross-site Request Forgery yCross-site Scripting. Una de ellas permanece sin corregir.

PimCore es una plataforma de software empresarial de código abierto que combina funcionalidades de gestión de información de productos y datos (PIM/MDM), gestión de activos digitales (DAM), gestión de la experiencia del usuario (CMS/UX), y comercio electrónico. Es utilizado por empresas como T-Mobile, Peugeot, Intersport o Carrefour.

Las vulnerabilidades son las siguientes:

* CVE-2018-14057: existen múltiples funciones en la aplicación que no cuentan con la protección de un token anti-CSRF. Esto podría permitir la realización de ataques Cross-site Request Forgery (CSRF) para, entre otras acciones, añadir, actualizar o eliminar entradas.

Algunas de las funciones vulnerables son las siguientes:

CVE-2018-14057 – Funciones vulnerables

* CVE-2018-14058: se han identificado múltiples fallos que podría permitir inyecciones SQLen la API REST. Un atacante que disponga de una clave válida de la API y con al menos permiso de “Activos”, “Documentos” u “Objetos” podría extraer información sensible de la base de datos.

A continuación se muestran algunas de las funciones vulnerables:

CVE-2018-14058 – Funciones vulnerables

* CVE-2018-14059: se han encontrado errores de falta de filtrado en múltiples campos de texto y entradas de datos por parte del usuario que podrían permitir a un atacante autenticado llevar a cabo ataques Cross-site Scripting (XSS) persistentes y, entre otras acciones, editar cuentas de usuario, tipos de documento, propiedades predefinidas, metadatos de activos predefinidos, valores de cantidad, rutas, miniaturas, clasificación de un item, etc.

Cabe destacar que la empresa desarrolladora ha declarado que no corregirá estos últimos errores (a pesar de la insistencia de los descubridores), al considerar que únicamente afectan a funcionalidades administrativas y se requieren permisos elevados para utilizarlas y por tanto estimar que se trata de un gasto adicional sin ningún beneficio para la seguridad.

Todas las vulnerabilidades anteriores han sido encontradas en PimCore 5.2.3. Se ha lanzado una nueva versión, la 5.3.0 que corrige los problemas de seguridad (excepto los identificados como CVE-2018-14059), y se encuentra disponible para su descarga desde la página oficial.

Más información:
 
SQL Injection, XSS & CSRF vulnerabilities in Pimcore software:

Foreshadow, nuevo ataque basado en la ejecución especulativa

Foreshadow, nuevo ataque basado en la ejecución especulativa

 

A Spectre y Meltdown se les suma un nuevo ataque (en realidad son varios) del tipo “ejecución especulativa”. Las consecuencias, al igual que los anteriores ataques, es la capacidad de leer zonas de la memoria a las que no se debería de tener acceso.

Este tipo de ataques se basan, como ya hemos mencionado, en la ejecución especulativa. ¿Qué es? Es una técnica de optimización que utilizan los microprocesadores para ir “adelantando” trabajo. Mientras que un grupo de instrucciones se está ejecutando, otro hilo del procesador puede ejecutar instrucciones futuras o acceder a recursos adicionales basado simplemente en la especulación, es decir, en “creer” que el proceso va a necesitar esos cálculos o recursos en un futuro. Naturalmente, eso es una apuesta con sus correspondientes probabilidades, siendo normal y factible que todo ese trabajo que se ha adelantado no sirva para nada, dado que el proceso puede derivar perfectamente en otro cauce de ejecución.

Por poner un ejemplo más mundano, supón que un día ves con tus amigos dos capítulos de una serie, preparáis las bebidas, palomitas y os acopláis en el sofá. Al día siguiente hacéis lo mismo, al otro también y como supones que eso va a ocurrir al siguiente del siguiente (porque a la serie le quedan dos capítulos para que termine), preparas el refrigerio y acomodas el salón antes de que tus amigos aparezcan, pero llega el momento y tus amigos no llegan. ¿Qué haces? Te comes el refrigerio tu sólo porque no ha servido para lo que pensabas. Has adelantado trabajo “especulando” qué podría ocurrir.

Las víctimas de “Arquitectura de Computadores I, II y III”, saben que diseñar microprocesadores de cierta complejidad es una tarea destinada a unos pocos seres humanos con cierto volumen craneal, necesario para evitar la expansión cerebral que produce el calentamiento inherente al diseño de estos ingenios. Y como con todo lo que conlleva la palabra humano: nada es perfecto. Así que cuando diseñaron la forma en la que se traducen direcciones de la memoria virtual de un proceso de usuario a memoria física (o real), incluyeron también la posibilidad de mapear la memoria del kernel y de paso, la de otros procesos. ¿Qué podría salir mal?

Ojo, que esto no significa que a las bravas puedas leerlo. No, no, no. De ningún modo. Un proceso de usuario no puede venirse arriba y decir: “Venga, voy a aprovechar que tengo pendiente una lectura de disco y me voy a guardar cuatro páginas enteras de memoria del kernel y de paso un par del proceso bash del vecino”. Para ello existe un mecanismo que comprueba si dicho proceso posee derechos de acceso a esas partes de la memoria. Una especie de aduana digital donde se comprueba la mercancía que se está intentando llevar un proceso. “Oiga, pollo, pare, pare. ¿De donde ha sacado usted esos 256 bytes con pinta de clave RSA privada. ¿Ah, que es de un amigo? ¡Claro!, como no. Venga por aquí.”

Vale, vale, pero ¿Cómo se explota?

Bien, hemos comentado a muy alto nivel que todo esto se basa en adelantar trabajo, ya sea ejecutando de antemano saltos en el código que podrían o no ejecutarse (predicción de saltos), procesar conjuntos de instrucciones que se pueden ejecutar de forma independiente al conjunto en ejecución actual (ejecución fuera de orden), etc. Y por otro lado, hemos dicho que en la memoria de un proceso, por diseño, se mapean las direcciones de la memoria del kernel y otros procesos (debido a que se está traduciendo memoria virtual a física y viceversa).

Pues el problema principal de seguridad es que cuando se está produciendo la ejecución especulativa, no se están revisando los privilegios de un proceso respecto a esa zona de memoria. Se dejan para después, cuando se hace efectiva la ejecución adelantada. Mientras tanto, los datos de esas zonas de memoria a las que no se debería acceder, permanecen en la memoria caché, donde mediante la aplicación de ciertas técnicas, pueden ser leídas. Esto es en lo que, de forma general, se basan este tipo de vulnerabilidad.

Foreshadow y Foreshadow-NG

Foreshadow fue descubierta por un grupo de investigadores procedentes de varias universidades y centros de investigación. Pertenece a la familia de fallos sobre los que ya hemos hablado, ataques sobre la ejecución especulativa. En particular, este ataque se centra sobre una característica en particular SGX (Software Guard Extensions). Esta tecnología permite a un proceso de usuario proteger una zona de memoria incluso del acceso por parte de procesos más privilegiados.

Por poner un ejemplo, supongamos que mapeamos 16 kilobytes de memoria y la protegemos mediante SGX, pues se supone que ni siquiera un proceso root podría tener acceso a ese fragmento de datos. Esto permite un nivel de protección muy útil cuando queremos proteger datos de importancia sin recurrir a cifrado.

El grupo que descubrió el fallo reportó los detalles a Intel para que contrastaran los hallazgos. Pues además de confirmar el fallo, el propio equipo de Intel ha descubierto una nueva forma de ataque que han denominado “L1 Terminal Fault” y que posibilitaría la lectura completa de la caché L1.

La caché L1 es la más cercana al procesador (existe una jerarquía de memorias caché, clasificadas según la “cercanía” al procesador), lo que significa que posee poca capacidad relativa de memoria pero una alta velocidad en la recuperación de datos e instrucciones. Esto se traduce en una memoria muy viva, con datos de procesos que están siendo ejecutados en ese momento y por supuesto, muy relacionada con la ejecución especulativa de estos últimos. Razón por la cual, con los elementos que ya hemos explicado, la hace objeto de la tormenta perfecta.

Consecuencias. Es posible leer la caché L1, pieza útil en mecanismos como el ya descrito SGX, memoria del kernel y máquinas virtuales, además de memoria del modo SMM (System Management Mode) que regula funciones de muy bajo nivel relacionadas con el hardware subyacente, por ejemplo, la gestión de energía, etc. Como apuntan en el estudio, esto tiene importantes consecuencias en la nube, donde el uso de la virtualización forma la espina dorsal del paradigma.

Intel ha actualizado el microcódigo de los procesadores afectados, aunque señala que habrá que actualizar sistemas operativos y las soluciones de virtualización para impedir la explotación del fallo. Tanto Microsoft como el kernel Linux han aportado ya una solución para la causa en la parte que les toca.

Se han asignado los siguientes CVEs para las distintas variedades del ataque:

– CVE-2018-3615 para el ataque sobre SGX
– CVE-2018-3620 para la memoria del kernel y SMM
– CVE-2018-3646 para el que afecta a máquinas virtuales

Podéis encontrar una amplia lista de procesadores afectados en esta página.

Bonus track:

Foreshadow es una palabra inglesa que hace mención a una figura o recurso literario que anticipa al lector unos hechos que han de producirse, pero de una forma tan sutil que impide que este se haga una idea directa y clara de ese futuro. En español se denominaría: presagio.

Más información:
 

Un fallo en Google Chrome permite extraer información sensible de otras páginas

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 defacebook.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.

Error en Chrome por realizar una petición que viola la política del mismo origen

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 CORSbá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:

  1. Crea una página en Facebook
  2. Publica un post restringido a personas con 18 años
  3. Publica otro post restringido a persona con 19 años
  4. Publica más posts con la misma idea hasta cubrir todo el rango de edad, año a año
  5. Crea una página maliciosa con tantas etiquetas ‘audio’ como posts has creado en Facebook, y que cada una apunte a un post.
  6. Controla la cantidad de veces que se lanza este evento por cada etiqueta, para estimar el tamaño de cada página.
  7. 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 yno 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 (aGoogle 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 graveen é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

Security: Cross Site Resource Size Estimation via OnProgress events
defeat cors attacks on audio/video tags