En vacaciones estuve utilizando mucho 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.
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, el Chromecast nos 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.
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.
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.
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.
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.
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.
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 y
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?
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.
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 Chomecat. 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.
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.