Libro de recetas para hackers: cómo explotar los electrodomésticos IoT con WHIDBOARD

HUNGRY FOR HARDWARE HACKS

Recientemente he completado la I+D de un nuevo juguete llamado WHIDBOARD y, para probarlo, decidí echar un vistazo a un aparato de cocina IoT que compré reacondicionado en Amazon. ¡El resultado fue inesperadamente divertido!

El objetivo

El DUT (dispositivo bajo prueba) de esta entrada del blog es un aparato de cocina inteligente llamado Mambo Touch de Cecotec, una empresa española.

Este dispositivo de cocina todo en uno es un procesador de alimentos multifuncional con 37 funciones que tiene una pantalla táctil de 5 pulgadas y se puede controlar de forma remota a través de su aplicación móvil (como puede ver en las imágenes de abajo), y se conecta a través de una red WiFi.

Como el reacondicionado era más barato... y de todos modos nunca lo voy a usar para cocinar... ¡me decidí directamente por él!

Reacondicionado ≠ Restablecimiento de fábrica

Por lo general, Amazon permite a los clientes devolver algunos artículos que no les gustan o que no cumplen con sus expectativas...

Pero surge una pregunta legítima... ¿dónde terminan después? ¿Cómo se renuevan? ¿Qué pasa con el restablecimiento de fábrica ANTES de la reventa?

Después de encenderlo, me conecté a mi red WiFi e intenté emparejarlo con la aplicación móvil... pero ocurrió algo curioso. El dispositivo ya estaba emparejado con otro propietario (probablemente el anterior)...

Me pregunto qué diría un DPO sobre esto...

Desmontaje del DUT

Tras una inspección inicial del exterior, es posible encontrar una primera pista... un puerto micro USB oculto.

Sin embargo, no ocurre nada muy interesante una vez conectado a un ordenador... El siguiente paso fue abrir el dispositivo... y, entre todos los demás componentes (pantalla táctil, interruptores, sensores, motores, fuente de alimentación, etc.), me recibió la placa base.

Aquí podemos ver fácilmente los componentes principales:

• A213Y Amlogic SoC
• KLM8G1GETF-B041 es una memoria flash eMMC de 8 GB con una huella FBGA-153
• RS256M16V0DB-107AT DDR SDRAM con huella FBGA-96

Y también algunos puntos de entrada interesantes para interfaces de depuración...

Pero el punto de entrada más interesante estaba en el otro lado... algunas almohadillas de prueba etiquetadas con la disposición habitual de pines de la interfaz de depuración UART... (es decir, GND, RX, TX).

El siguiente paso fue sencillo... soldar un par de cables en esas almohadillas, coger mi WHIDBOARD y comprobar con el analizador lógico y el enumerador de pines si realmente se trataba de una interfaz de depuración UART...

Primero, conecté todos los cables al bloque de terminales del analizador lógico de WHIDBOARD para obtener algunos datos... y esto es lo que obtuve en Pulseview:

Obtención de root a través de UART

¡Genial! Confirmamos fácilmente que las tres almohadillas de prueba de la parte posterior de la PCB son realmente una consola UART que funciona. Podemos ver cómo el DUT escupe la secuencia de arranque desde el analizador lógico. A continuación, intentemos conectarnos directamente con WHIDBOARD y el enumerador de pines.

La función Pin Enumerator de WHIDBOARD se basa en el JTAGulator (lamentablemente descatalogado) creado por Joe Grand. Permite descubrir pines de interfaces de depuración como UART, JTAG y SWD. Pero en mi caso utilicé principalmente su función Passthrough para comunicarme con el objetivo conectado a su bloque de terminales (y, obviamente, confirmar la combinación correcta de pines UART).

Una vez confirmado con el Pin Enumerator que efectivamente se encontraba ante un puerto de depuración UART... utilizó la función Passthrough y fue recibido por una encantadora consola de terminal con acceso root. ¡BOOM! :D :D :D

¿Qué sigue?

En este punto, vemos claramente que el dispositivo puede verse comprometido fácilmente. Pero quería seguir jugando y comprobar cómo funciona la conexión remota...

En primer lugar, habilité la conexión remota ADB a través de WiFi con los siguientes comandos:

Y confirmé que todo funcionaba a la perfección:

Ahora ya tenemos una conexión remota (es decir, la misma LAN) persistente con el DUT. Dado que el demonio del servidor ADB persistirá incluso después del arranque.

Lo siguiente fue hacer un reconocimiento y buscar algo interesante... Primero enumeré las aplicaciones instaladas para comprobar dos cosas: qué versión de Android se está ejecutando y cuáles son las principales aplicaciones del proveedor (es decir, Cecotec).

Las dos aplicaciones más interesantes son:

• package:/data/app/com.zavier.androidrk3326functiontest-1.apk=com.zavier.androidrk3326functiontest
• package:/data/app/com.kitchenidea.cecotec.k2501-2.apk=com.kitchenidea.cecotec.k2501

Sin embargo, antes de seguir investigando, ejecuté rápidamente la aplicación habitual de ajustes de Android (con este comando am start -n com.android.settings/.Settings) para comprobar más información sobre la versión del sistema operativo... y, como era de esperar, el DUT ejecutaba una versión antigua de Android: 4.4.2.

Bien... sigamos investigando... ¡Es hora de reconocer la red! Al mirar la salida de netstat, puedo ver algunas conexiones con direcciones IP de Internet:

Nada muy sofisticado, pero una me llamó la atención... obviamente, como se trata de un backend que no es de su propiedad... se consideró fuera de alcance y seguí adelante...

A continuación, empecé a buscar las herramientas habituales de los hackers que se pueden utilizar para exfiltrar o revertir el shell de los objetivos IoT... una para todo... Su majestad BUSYBOX :D

Y, de hecho, esta venía con todo lo necesario:

Solo con él, podía extraer, cargar y manipular datos, así como obtener un shell inverso con netcat. ¡Pero sigamos adelante! Como ya tenemos el shell ADB persistente... esta vez no necesitamos BusyBox. :P

En general, con ADB Explorer extraje todos los archivos interesantes que encontré. Sin embargo, nada muy interesante... Este dispositivo no tiene micrófono ni cámara... ni siquiera podemos espiar a la gente de forma remota... meh... :(

Análisis de APK

En este punto, centré mi atención en los APK del proveedor:

• package:/data/app/com.zavier.androidrk3326functiontest-1.apk=com.zavier.androidrk3326functiontest
• package:/data/app/com.kitchenidea.cecotec.k2501-2.apk=com.kitchenidea.cecotec.k2501

El com.zavier.androidrk3326functiontest-1.apk parece un conjunto de pruebas funcionales para comprobar si todos los sensores y controladores del motor funcionan correctamente. Tenga en cuenta que este electrodoméstico de cocina IoT tiene una báscula, un calentador, un motor para mezclar los alimentos y varios sensores integrados. Y, aparentemente, todos ellos están controlados por estas dos aplicaciones (también de forma remota desde el teléfono móvil del usuario...).

En cuanto a com.kitchenidea.cecotec.k2501-2.apk , rápidamente me di cuenta de que es una copia del otro update.apk que se encuentra en /sdcard/, por lo que no es necesario comprobar ambos:

Al examinar el segundo APK, no encontré demasiadas señales de alarma, pero sí confirmé que la aplicación tiene acceso completo a todos los sensores, el calentador, el motor, etc. En teoría, podríamos crear un malware que pudiera interferir con la víctima de forma remota enviando comandos arbitrarios a los puertos serie... :P

También comprobé dos veces si había otras URL/IP interesantes codificadas en esas dos aplicaciones... pero parece que son la basura habitual:

Como se me hacía tarde y estaba molesto, finalmente ejecuté MobSF para obtener una visión general rápida del nivel de riesgo de esas dos aplicaciones...

TL;DR: Nada demasiado grave. Una aplicación mediocre para un producto mediocre. 8)

En general, está claro que existe la posibilidad de convertir este dispositivo en un arma con un APK personalizado que pueda ser controlado de forma remota por un atacante y manipular las funciones internas para causar daños físicos (por ejemplo, ¿anular las medidas de seguridad?, ¿sobrecalentar la olla?, etc.).

Bromas y shell inverso

Como último ejercicio, antes de terminar y devolver esta porquería a Amazon... quería comprobar si una shell inversa meterpreter funcionaría y si a través de ella podría ejecutar DOOM o gastarle alguna broma a mi esposa... Bueno... :D

Primero preparemos un APK meterpreter para enviarlo con ADB:

A continuación, enviémoslo a través de ADB e instalémoslo:

Ahora ejecutémoslo:

Mientras tanto, en la máquina virtual WHIDOS ya se había configurado con el listener MSF:

Ahora, cada vez que se reinicie el dispositivo, se ejecutará automáticamente el shell inverso y se llamará al C2 del atacante:

En este punto, instalar y ejecutar DOOM fue cuestión de segundos... :D

Conclusión

El mercado del IoT es conocido por estar lleno de dispositivos vulnerables. Por desgracia para el consumidor medio, la mayoría de las empresas no se toman la seguridad de los productos lo suficientemente en serio. La mayoría de las veces, un dispositivo IoT comprometido puede no tener un gran impacto en la vida de los consumidores, pero en algunos casos puede causar daños físicos. Como en este caso, en el que la aplicación controla de forma remota el calentador y el motor, y un posible atacante también podría controlarlos...

Además, está claro que comprar dispositivos IoT reacondicionados... a veces... puede NO ser una decisión acertada.

¿Y si hubiera dejado alguna carga maliciosa antes de devolver el dispositivo a Amazon? (Aclaración: no, no lo hice).