"ChromeCrash" o cómo jugar con tu Google Chromecast sin autenticarse

En vacaciones estuve utilizando mucho Google ChromeCast, y el utilizar mucho una cosa te hace pensar en ciertas cosas que la constituyen y hacen que funcione. Me propuse no hacer mucho en vacaciones, pero ya sabéis que el veneno es el veneno y la tecnología, para mí, lo es. Tuve que abrir Kali Linux, un ZAProxy y habilitar unas reglas iptables. Mi objetivo era sencillo, ver el tipo de tráfico que se generaba entre la aplicación Google Home y mi ChromeCast.

Figura 1: "ChromeCrash" o cómo jugar con tu Google Chromecast sin autenticarse

Lo primero fue estudiar el protocolo SSDP, ya que al abrir el Wireshark me encontré con muchos paquetes de este estilo. El SSDP, Simple Service Discovery Protocol, nos permite realizar descubrimiento sencillo de servicios. En este caso, observando los paquetes SSDP, Chromecast devolverá un paquete con este contenido:

"urn:dial-multiscreen-org:device:dial:1"

Tal y como se puede ver en el siguiente fragmento de script en Ruby, tenemos una librería que permite realizar búsquedas a través de SSDP de forma sencilla. Este código lo que realiza es la búsqueda de diferentes Chromecast en una red de área local. Cuando descubrimos uno, lo almacenamos en un array.

Figura 2: Script en Ruby sobre Kali Linux para detectar Google Chromecast en la red

Para ayudar a entender esto, vamos a ejemplificar las peticiones que ocurren recogidas con OWASP ZAP. La petición es un GET que se realiza apuntando al puerto 8008 y al recurso /ssdp/device-desc.xml. La petición que se puede ver en la imagen corresponde con la que la aplicación Google Home realiza, en este caso desde un iPhone, el cual ya ha sido actualizado a día de hoy ;-). Es importante que la petición lleve la cabecera Origin con la dirección URL de Google.

Figura 3: Petición al dispositivo Chromecast desde ZAP

En el caso de la respuesta, ya veríamos el fichero XML con la información del dispositivo obtenida. Como se puede ver, Chromecast admite algunos métodos HTTP y se puede ver bastante información sobre el dispositivo en el XML entregado. Entre esta información encontramos el nombre del dispositivo, en este Chromecastbed, el UUID y el modelo del dispositivo.

Figura 4: Información del dispositivo Chromecast obtenida

Hasta aquí todo normal. Entre comillas, puede llamar la atención de que en ningún momento el Chromecast pida una autenticación para realizar cualquier petición o que todo el tráfico vaya por HTTP. Es entendible estamos protegidos por la red WiFi.

Ataque de Hijacking a Chromecast

En este instante, me paré a ver si existía algún tipo de ataque sobre este tipo de dispositivos y la verdad es que sí. Existe la posibilidad de realizar un hijacking de Chromecast, desde el año 2014.


Figura 5: PoC Hijacking a Chromecast

El ataque es sencillo:

1. Hay que encontrar un dispositivo conectado a la red WiFi a través de la MAC. Esto se puede hacer con airmon y airodump. Las direcciones físicas de los clientes que son Chromecast comienzan por una forma concreta, por lo que se pueden identificar. 

2. En este instante, se puede llevar a cabo la desautenticación de los clientes Chromecast, a través del uso de aireplay. 

3. Si esto funciona y el dispositivo es desautenticado, Chromecast generará una red WiFi ad-hoc, con la que el atacante puede conectarse e iniciar el proceso de configuración de red. Es decir, podrá conectar el Chromecast que está a su alcance a la red que quiera, por ejemplo, la del atacante. 

4. Por último, el Chromecast estará conectado a la televisión de la víctima, pero a la WiFi del atacante, por lo que el control de lo que él verá será del atacante.

Dicho esto, es algo que me gustaría probar con mi propio Chromecast, ya que me pareció un ataque curioso. Seguí mirando que más cosas podrías hacer mediante el protocolo HTTP sin tener algún tipo de autenticación y fue sorprendente, pero hay que recordar que necesitas acceso a la red WiFi, no como el anterior ataque expuesto.

Hay una función cuando arrancamos la aplicación de Google Home que es ejecutada y permite a la aplicación obtener una gran cantidad de información del Chromecast. De nuevo esto son funciones de lectura las cuales nos permiten ser meros observadores de información que podemos sacar con la aplicación Google Home. Pero claro, si estamos en la misma red WiFi y cuando la aplicación Google Home cambia una configuración no hay ningún tipo de autenticación, ¿Podemos replicarlo con ZAP y un script?

PoCs con Chromecast

Empecé a mirar las diferentes opciones de setting que tiene la aplicación Google Home sobre el Chromecast y hay varias opciones. Todas sin necesidad de introducir algún código o algo que permita evitar que alguien pueda modificar e, incluso, reiniciar tu Chromecast. La primera prueba, el cuál es el típico “Hello World” en estos ámbitos, es cambiar el nombre del dispositivo.

El parámetro name pasado por POST permite modificar el nombre del dispositivo, de nuevo sin ningún tipo de requisito más que la petición en sí. Para muchos es suficiente la protección de la red WiFi, pero si llevas un Chromecast a un hotel podrías tener grandes problemas de seguridad.

Figura 6: Cambio de nombre de Google Chromecast sin autenticar

Dejaré algunas de las posibilidades, como, por ejemplo, hacer olvidar la contraseña y la red WiFi a la que tu Chromecast, para otro día o para que cualquiera pruebe su Chomecast. Para acabar, quise probar si se podría reiniciar de forma indefinida y sin ningún problema el Chromecast. Lo primero fue ver qué petición HTTP enviaba la aplicación de Google Home.

Figura 7: Reiniciando Google Chromecast sin autentificación

Como se puede ver en la imagen, con la instrucción /setup/reboot podemos dejar el Chromecast fuera de juego, porque esa orden le hará reiniciarse. Lógicamente, si se realiza un script dónde se automatiza el descubrimiento de un Chromecast y el reinicio de este tipo de dispositivos pues dejaríamos al usuario sin posibilidad de utilizar el Chromecast.

El script de momento me lo guardo, aunque es fácil de realizar este tipo de scripts en Python o Ruby. De nuevo decir que, aunque estamos detrás de la red WiFi que nos protege, el dispositivo no maneja protecciones en la comunicación, por lo que estamos expuestos a los DoS en nuestra programación de video que hagamos con nuestro Chromecast.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths