Hacking con la Physical Web: Jugando con la seguridad de Web BlueTooth #BlueTooth

No hace mucho que escribía acerca de la información que se puede obtener con un simple escaneo de dispositivos Bluetooth. De cómo algunos teléfonos indican, además de su marca y modelo, el nombre de su propietario. De cómo se pueden utilizar para rastrear las entradas y salidas o la presencia de personas. De cómo las ondas de radio pueden revelar la existencia de dispositivos que no están conectados a la red. Retomemos aquí el tema y démosle otra vuelta de tuerca.

Figura 1: Hacking con la Physical Web. Jugando con la seguridad Web BlueTooth

El corto alcance de la señal Bluetooth puede suponer a la vez una ventaja y un inconveniente. Para el atacante, por un lado, limita los espacios desde los que se puede actuar pero, por otro, permite fijar con más precisión la posición del objetivo. Para el defensor, condiciona dónde colocar las cosas pero protege contra intrusos colocados a gran distancia. Hasta ahora.

Web Bluetooth

Con los años, el navegador se está convirtiendo en cliente universal para todo tipo de programas y aplicaciones. Esto hace que estas herramientas se vayan incorporando cada vez más capacidades y funcionalidades. Entre todas ellas, uno de los conceptos que comienzan a ponerse de moda es el de Web Física (Physical Web), una web capaz de interactuar con el mundo real y en cuanto hay en él.

Y, como no, le está llegando el turno a Bluetooth. Existe un estándar, aún en elaboración, para definir una API cliente (Javascript) que permita a los navegadores interactuar con dispositivos Bluetooth. Su nombre es Web Bluetooth y se pueden hacer cosas tan curiosas como controlar una carrera de coches desde la web.

Figura 2: Una carrera de coches Bluetooth controlada desde una página web

Por ahora, hasta donde yo sé, de los navegadores más utilizados, sólo Google Chrome soporta Web Bluetooth. Eso sí, con limitaciones. Y, además, viene desactivado por defecto. Si quieres activarlo, el primer problema que puedes encontrarte es tu sistema operativo: no funciona en Windows. Por si sirve como referencia, en las pruebas que se realizará más adelante se utilizará la distribución Kubuntu.

Figura 3: Programar con Web BlueTooh en Google Chrome

Si tienes algún sistema operativo de los soportados (Chrome OS, Android M, Linux u OS X) y quieres activar Web Bluetooth en tu navegador Google Chrome, pon en la barra de direcciones "chrome://flags/#enable-web-bluetooh" . y te aparecerá la opción “Habilitar”. Hazle clic y reinicia.

Figura 4: Habilitar Web BluetTooth en Google Chrome

Eso es todo. A partir de ahora tu navegador soportará esta tecnología. Y, dicho sea de paso, se volverá bastante inestable y - al menos así me pasa a mí - se cerrará él solito de vez en cuando. Tampoco esperes maravillas. No por ahora. Por ejemplo, con la versión 52.0.2743.116 sobre Kubuntu 6.04 de 64 bits, el navegador no hace el descubrimiento de dispositivos. Tienes que hacerlo tú con el sistema operativo ANTES.

Figura 5: Descubrimiento de dispositivos BlueTooth

Si vas a hacer las pruebas de forma inmediata, no hace falta que te conectes a ninguno, sólo que tu sistema operativo los encuentre. Pero, si vas a jugar un buen rato, ten en cuenta que el sistema puede “olvidar” la presencia de aquellos dispositivos que no estén emparejados con él. Ya sé. Muchos inconvenientes. Pero ya ser irán solucionando con el paso del tiempo. Se trata de una tecnología que aún está en mantillas pero que, es de esperar, a no mucho tardar comenzará a tener suficiente grado de madurez.

Tres protecciones y un riesgo

Al hablar de dispositivos Bluetooth estamos abarcando desde teclados o ratones hasta sistemas de control de aparatos de smartTV pasando, claro, por los smartphones. O por marcapasos y otro equipamiento médico. Si cualquier página web fuera capaz de conectarse a estos dispositivos y manipularlos las consecuencias podrían ser graves. Por eso existen varias medidas de seguridad en la implementación de Web Bluetooth:

• Sólo funciona sobre páginas servidas sobre protocolos seguros. O sea, funciona sobre HTTPS pero no sobre HTTP. 

• Se requiere que el usuario realice alguna acción de teclado o ratón (“user gesture” o, en otras palabras, toques, clics o pulsaciones) para que un script pueda intentar conectar con un dispositivo Bluetooth. 

• Algunos tipos de dispositivos pueden tener un acceso restringido o no ser accesibles mediante esta tecnología. Por ejemplo, no sería bueno que se pudiera controlar el teclado, pues se podría realizar operaciones de keylogging. La lista de las funcionalidades limitadas puede encontrarse en esta blacklist.

Figura 6: BlackList de acciones en Web BlueTooth

Como no todo iba a ser pros, una contra a tener en cuenta. Existe una forma de habilitar Web Bluetooth para tu sitio web: participar en un programa de experimentación “Origin Trial” de Google Chrome. Como se indica en una de las referencias, ésta posibilidad acabará en Enero de 2017. Para entonces la especificación deberá estar lo bastante avanzada como para no necesitar más pruebas. Con toda esta información, ha llegado la hora de ponerse en la piel de un atacante y ver cómo subvertir tanta cosa buena.

Salvando escollos

Vamos a ver cómo podría un atacante tratar de evitar las protecciones mencionadas, más alguna otra que iremos encontrando. Empecemos con el código fuente de una página maliciosa. Va en dos partes. Primero el código HTML y luego el código JavaScript.

Figura 7: Código HTML de nuestra página de prueba con Web BluetTooth

Y abajo el código JavaScript. En pocas palabras, en cuanto el usuario inicia una pulsación de ratón o de teclado, incluso de teclas como CTRL o SHIFT, sin esperar siquiera a que termine, se le muestra un mensaje engañoso y se inicia el proceso de selección de dispositivo Bluetooth.

Figura 8: Código JavaScript de esta PoC

Para conseguir que funcione, la página debe ser servida sobre HTTPS. Supongamos que el dominio “example.org” pertenece al atacante.

Figura 9: Página web del atacante bajo HTTPs

Sólo queda esperar que algún incauto pase por ella e intente seleccionar el texto para copiarlo. Con la interacción de teclado o ratón se activará el script que, gracias a ello, podrá utilizar las funcionalidades de Web Bluetooth.

Figura 10: Cuando se pulsa teclado o ratón se activan las funciones de Web BlueTooth

Se supone que el mensaje de “Error general” debería ser más convincente. Con mejor presencia. Y quizá convendría usar imágenes que simularan la existencia de una ventana de error del sistema operativo. Pero, como no tengo tiempo de preparar algo tan elaborado, dejemos trabajar a tú imaginación y valga para estas pruebas con algo tan cutre.

Cuando el usuario seleccione su teléfono para intentar mantener la conexión y haga clic en “Conectar”, la página web sabrá el nombre del dispositivo y lo enviará al atacante. Con tan poca cosa nos contentaremos aquí, aunque es seguro que, dependiendo de cada dispositivo, en un caso real serían posibles otras actuaciones mucho más dañinas.

Pero, aunque el mensaje de error sea más convincente que el aquí presentado, hay aún un elemento que no termina de gustarme: el cuadro de selección de dispositivo da demasiada información al usuario. ¿Podríamos quitar eso que aparece en la imagen de “www.example.org quiere conectarse a:”?

Ocultando el orgen del ataque

El anterior mensaje muestra el nombre del equipo que está intentando interactuar con Web Bluetooth y eso no le conviene al atacante. Así que le toca hacer pruebas. Por ejemplo... ¿Qué pasa si la página es servida sobre un equipo con un nombre más largo?

Figura 11: El nombre aparece truncado en la selección de dispositivos

¡Eso está mejor! Ya no aparece el nombre de dominio completo, aunque el mensaje sigue siendo rarillo. Jugando con los nombres de dominio y la forma en que aparecen en el cuadro de diálogo, vi que los guiones funcionan de forma ligeramente diferente a números y letras: si separan dos palabras y la segunda no cabe... la pone en la siguiente línea e intenta seguir mostrando caracteres. Eso me hizo pensar en un nombre de equipo que aprovechara al máximo las posibilidades. El que terminé sacando fue:

esta.es.la.lista.de.dispositivos.a.elimi- nar.del.sistema.de.forma.permanente.0------------------------------------------------------0- si.desea.mantener.alguno.de.ellos.de-be.marcarlo.y.clickar.el.boton.de.que.example.org

Sirviendo la página desde este equipo, el mensaje será:

Figura 12: El mensaje final para ocultar el origen del ataque

Debo señalar aquí que es posible que la apariencia de los mensajes varíe en otros equipos (sobre todo en smartphones) o si se usan configuraciones de pantalla o de navegador distintas a las del equipo que utilicé para las pruebas. En un caso real posiblemente sea necesario hacer un fingerprinting del navegador y su entorno para garantizar el efecto deseado.

Otra cosa es que, dada la sintaxis de la lengua inglesa y sus construcciones terminadas en preposición (como “the device you want to connect to”), en este idioma creo que será mucho más fácil crear frases con sentido. Pero ahora lo que no me gusta es la barra de la URL. La dirección de la ventana es muy rara y quisiera que fuera algo más discreta.

Ocultando la dirección de la barra de URL

Lo primero que se me ocurrió fue crear una página con una URL más normalita (digamos “https://www.example.org/iframe.html”) e insertar en ella un IFRAME que llene toda la ventana. En este IFRAME, sin barra de URL que valga, se cargaría nuestra página maliciosa. Pero no funciona. No se permite el uso de Web Bluetooth desde IFRAMES de dominios distintos al de la página principal.

Figura 13: Protección contra carga de iframes en diferentes dominios

El problema es que la ventana que tiene que mostrar el diálogo de selección de dispositivo es de un dominio distinto al de la página que lo solicita. Tenemos que abrir una ventana nueva pero evitando que en ésta aparezca el nombre de equipo en la barra de URL. Si pudiéramos abrir una ventana sin barra de URL todo estaría resuelto. Pero los navegadores suelen tomar precauciones contra esta práctica. Habrá que pensar en otra cosa.

La que se me ocurrió quizá no sea la única. Pero funcionar... funciona. Cuando se realiza un “window.open” con la URL “about:blank”, Google Chrome asigna a la nueva ventana el mismo origen de aquella desde la que se realizó la llamada. De modo que, desde el IFRAME, abrimos una ventana nueva, la rellenamos mediante scripting con un código similar al ya presentado... et voilà! Un poco de JavaScript obra la magia:

Figura 14: JavaScript para ocultar la barra de dirección URL

Ya sólo queda tener otra página que incluya a la anterior en un IFRAME:

Figura 15: Código que carga la web maliciosa

La apariencia final es relativamente inofensiva, ya que solo es una web para acceder a un tutorial.

Figura 16: Aspecto final de la web maliciosa

Cuando la víctima intente visualizar el tutorial se abrirá una nueva ventana con la dirección “about:blank” con el aspecto que se puede ver a continuación. Todo muy tranquilo y normal. Ninguna alarma ni cosa rara.

Figura 17: Apariencia final de la web con el iframe malicioso

Y cuando intente copiar la instrucción, al pulsar cualquier tecla o intentar hacer clic con el ratón...

Figura 18: Se lanza el acceso a los dispositivos BlueTooth pareados

Y si pudiéramos ver el tráfico de red seríamos testigos de como al seleccionar el teléfono y hacer clic en el botón “Conectar” el atacante recibe una notificación con el nombre del dispositivo y poder acciones sobre él. Si el usuario ha sido engañado, podrá controlar el terminal desde la lejanía.

Figura 19: El servidor recibe la llamada desde el cliente con la info BlueTooth

Para ir acabando

Sí, a Web Bluetooth quizá le falte más de un hervor. Pero es de esperar que termine siendo algo integrado en todos nuestros navegadores. Interacturá quizá con discos en la nube como Google Drive, Microsoft OneDrive y similares. Servirá para controlar elementos domóticos. O industriales (SCADA controlado por Bluetooth a través de Internet... ¡guau!). Monitorizará en tiempo real el estado de salud. Formará parte de los juguetes (y no estoy pensando sólo en los infantiles). Etc, etc, etc. En pocas palabras: Bluetooth en la nube.

Y entonces será un objetivo para quienes ponen a prueba la seguridad de las aplicaciones. Tanto para los bienintencionados como para los criminales. Y también para los que estén a medio camino entre unos y otros. En ese entorno, creo que la Ingeniería Social jugará un papel muy importante y que es necesario que los navegadores pongan en práctica cuantas protecciones sea posible para evitar que los usuarios sean objeto de engaños.

Y, claro, que los diseños de estas protecciones no tengan fallos. Pero... ¡es tan difícil conseguirlo!

Autor: Enrique Rando
Escritor de los libros "Hacking con Buscadores", "Hacking Web: SQL Injection", "Hacking Web Technologies"