Intenté vigilar a mi perro, y terminé vigilando a TP-Link

• Compró una cámara Tapo para observar a su perro en casa, pero inesperadamente terminó haciendo ingeniería inversa de cómo funcionan los dispositivos y la app de TP-Link
• Para analizar el proceso de onboarding y la estructura de la comunicación API cifrada, usó varias técnicas como MITM, descompilación de APK y generación de scripts de descifrado
• Al descubrir la contraseña inicial de administrador y el proceso de derivación de claves de sesión, logró descifrar mensajes cifrados e identificar problemas de sincronización poco confiable entre el dispositivo y la cuenta en la nube
• Tras analizar el flujo completo de onboarding, automatizó con scripts de Bash las llamadas API clave, la creación de cuentas, el cambio de contraseña y la conexión Wi‑Fi
• Señala fallas en el diseño de seguridad del firmware de Tapo, una implementación de cifrado poco sofisticada y sincronización irregular de cuentas, rasgos típicos de dispositivos IoT de bajo costo

---

Resumen del proyecto

• El autor compró y usó una cámara Tapo económica para observar a su perro dentro de casa
• Durante el uso, la incomodidad de la configuración y la falta de información en línea lo motivaron a investigar a fondo cómo funcionaba el producto
• Surgieron problemas inesperados al integrarla con frigate y al activar 2way audio, lo que despertó su interés por un método de onboarding directo sin integración con la nube

Análisis de la estructura de onboarding y autenticación

• Para analizar el procedimiento de conexión de la cámara Tapo, interceptó el tráfico entre la app y la cámara usando MITM proxy y la herramienta de hooking dinámico frida
  • Como las apps recientes incluyen resistencia a este tipo de análisis, como ignorar proxies y usar certificate pinning, este enfoque con herramientas dinámicas resultó efectivo
• Después de configurar esta evasión, pudo confirmar con precisión el proceso de login de la cuenta de administrador predeterminada dentro del flujo de onboarding de la cámara
• Descubrió que la API de login predeterminada funciona con una contraseña base propia del dispositivo, separada de la contraseña de la cuenta en la nube

Estructura de cifrado y búsqueda de la contraseña predeterminada

• Mediante descompilación del APK (usando JADX) y análisis de código, obtuvo la contraseña predeterminada de la cuenta admin (TPL075526460603)
• Confirmó que, incluso si se cambia la contraseña de la nube, las cámaras ya vinculadas no detectan el cambio, lo que evidencia una sincronización imprecisa de contraseñas entre la app y la cámara
• Como ya conocía la contraseña predeterminada, implementó la lógica de derivación de claves de sesión (lsk, ivb) y pudo descifrar en tiempo real los mensajes cifrados de la API

Scripting con mitmproxy y análisis de la API

• Tomando como referencia el proyecto open source PyTapo, analizó con precisión el flujo de API del procedimiento real de onboarding de Tapo
• Con el script tapo_decrypt_pretty.py logró:
  • detectar el handshake de login
  • extraer las claves de sesión
  • descifrar la API cifrada y mostrarla de forma legible, además de guardar el JSON
• De todas las llamadas API del onboarding completo, extrajo solo los procesos principales relevantes para crear un flujo de automatización
  • consulta de lista Wi‑Fi (scanApList)
  • activación de cuentas RTSP/ONVIF
  • cambio de contraseña de administrador
  • conexión Wi‑Fi

Automatización y resultados

• Configuró un script de Bash (tapo_onboard.sh) para ejecutar automáticamente todo el proceso de onboarding anterior
  • login inicial con admin predeterminado
  • selección y conexión a Wi‑Fi
  • eliminación del logo en el feed de la cámara
  • habilitación de RTSP/ONVIF
  • restablecimiento de la contraseña de administrador
• En la estructura del firmware de la cámara encontró las siguientes características y debilidades
  • algunas APIs usan hash SHA-256, pero otras mantienen esquemas antiguos como MD5
  • existen 2 claves públicas, y no está claro en qué situaciones debe usarse cada una
  • la sincronización de contraseñas entre la app y el dispositivo es muy inestable

Conclusión e impresiones

• La estructura de seguridad del firmware y de la API de la cámara Tapo da la impresión de ser improvisada y poco refinada
• Fue una experiencia indirecta de las debilidades de seguridad de los dispositivos IoT económicos y de la realidad de sus sistemas de onboarding incompletos
• Sí logró el objetivo final del proyecto, que era revisar a su perro, y confirmó que normalmente duerme en el sofá o en la cama

[helio]

Parece que el CVE-2022-37255 tiene una puntuación de 7.5.

[GN⁺]

Comentarios en Hacker News

• Me sorprendió ver que usaron mi script de Frida; se puede revisar aquí. Me alegra que parezca funcionar bien en un entorno real, y me gustaría saber si le agregaron o modificaron algo.

  • HTTP Toolkit me parece una herramienta realmente buena; gran trabajo de Tim.
  • De las herramientas que he usado, Http toolkit me parece la mejor. También he probado mitmproxy, proxyman y charles proxy, pero httptoolkit fue la mejor y además es open source.

• Como referencia, para usar audio bidireccional en frigate hay que aplicar la configuración tapo:// de go2rtc al stream principal en lugar del típico rtsp://. TP-Link solo ofrece audio bidireccional a través de su propia API. El problema es que con esa configuración ONVIF (control de paneo/inclinación de la cámara con herramientas open source) deja de funcionar, así que resulta incómodo. Si quieres usar ambas funciones, necesitas un flujo bastante agresivo de: detener la lectura del stream tapo:// → ejecutar el cliente ONVIF/ajustar paneo e inclinación → cerrar ONVIF → reiniciar tapo://.

• Creo que la seguridad de IoT en general es un desastre, y me preocupa especialmente que los routers de consumo sean cajas negras no auditables por donde pasa todo el tráfico de red. Mucha gente ni siquiera sabe que el firmware de su router no se actualiza desde hace años y que ya existen vulnerabilidades conocidas. Me parece que el modelo de confianza de la cadena de suministro del hardware de red está completamente roto.

  • Coincido en que la seguridad de IoT deja mucho que desear. En lo personal, a veces solo quiero que el dispositivo IoT se conecte bien, e incluso me gustaría poder usar algún exploit para saltarme las limitaciones de depender de estar en línea. Pero también hay casos de uso reales para IoT con integración en la nube, así que creo que durante la configuración inicial el dispositivo debería preguntarle al usuario qué quiere y funcionar solo en el modo elegido. Si necesitas MFA en la nube, deberías poder elegirlo, y si solo quieres controlarlo por programación, debería poder quedarse offline.
  • Entre el usuario y el destino hay incontables routers, y no se pueden auditar todos. Los dispositivos finales ya asumen que el router puede estar comprometido y por eso envían todos los datos verificados y cifrados; así que, salvo que el router se use para abusos como DDoS o minería de criptomonedas, no creo que su seguridad en sí misma tenga tanta relevancia.
  • La mayoría de la gente usa el router que les da y configura su ISP, así que en la práctica conectan una caja negra a otra caja negra. A menudo veo casos donde al conectarse al Wi‑Fi reciben el SSID y la contraseña definidos por el ISP, y me sorprende cuánto poder se le entrega al proveedor.
  • Eso aplica a productos de consumo general, pero si subes a hardware prosumer como Ubiquiti o Mikrotik, sí puedes tener actualizaciones de seguridad rápidas y soporte de firmware confiable.

• Me pareció que esta entrada de blog está excepcionalmente bien escrita. Hoy en día muchos textos de este estilo son generados por LLM y resultan incómodos de leer, pero este logra muy bien el equilibrio entre lo técnico y lo ameno. (Sé que la imagen de portada fue generada con IA, pero me parece irrelevante para la esencia del texto).

  • Yo uso uBlock Origin para bloquear por defecto archivos multimedia pesados y ahorrar recursos. Las imágenes de portada muchas veces quedan bloqueadas desde el inicio y casi no sirven de nada; me da pena que hoy en día la gente gaste recursos en generarlas.

• Me pregunto si se podrá seguir usando herramientas como Frida o mitmproxy con apps de Android, y qué pasará el próximo año cuando entren en vigor los requisitos de firma.

  • En general probablemente sí se podrá, pero las apps que requieran attestation van a volverse mucho más difíciles. Incluso hoy, dispositivos como los Pixel, donde se permite OEM unlock y root, todavía pueden seguir usándose para desarrollo. Eso sí, en ese caso el dispositivo queda marcado por estar desbloqueado y falla la attestation de Google. También espero que siga siendo posible desempaquetar una app, inyectarle Frida y hacer sideload con una cuenta de desarrollador, como en iOS, aunque eso también quedará expuesto a fallos de attestation y a ataques anti-tampering/anti-debugging.
  • En realidad no espero que esos cambios afecten directamente tanto, porque la ingeniería inversa casi siempre se hace en dispositivos rooteados y emuladores. En casos menos comunes, cuando se inyecta Frida en modo gadget dentro del APK en un dispositivo sin root, sí se pondrá más difícil, pero creo que todavía quedará la vía de compilar e instalar APKs en modo desarrollador. Si bloquearan eso por completo, desarrollar apps para Android sería directamente imposible; así que probablemente restrinjan el sideload en dispositivos de usuarios comunes y dejen abiertos mecanismos como agregar certificados de desarrollador. Al final, lo que se vuelve más difícil es distribuir apps reales, mientras que el desarrollo y la ingeniería inversa probablemente sigan siendo posibles. La amenaza mayor es la expansión de device attestation: cada vez más apps podrían empezar a obsesionarse con verificar si el dispositivo está sin modificar, incluso en equipos rooteados o no oficiales. Por ahora eso se ve sobre todo en apps financieras grandes; además, la cantidad de gente que realmente tiene que preocuparse por eso (usuarios de GrapheneOS) sigue siendo reducida, y hay costos extra como montar servidores adicionales, así que no parece algo fácil de masificar por ahora, aunque podría cambiar más adelante.
  • De hecho, ya siento que usar Frida no es nada fácil. Para usar Frida necesitas root, pero cada vez hay más modelos donde root es prácticamente imposible, además de que existen SDKs muy potentes de detección de root y medidas contra Play Integrity.

• Como referencia, hay casos relacionados como The Tapo C200 Research Project y PyTapo: librería de Python para cámaras Tapo.

• Otro material relacionado: (descifrado de firmware de TP-Link y análisis del bootloader de la cámara en la nube C210 V2) está aquí.

• Sospecho que la razón por la que el perro del OP se mueve de la cama al piso podría ser simplemente que se enciende la calefacción (radiador). Parece que harían falta más datos de sensores.

  • O quizá simplemente siente frío.

• Siento que ya llegamos al punto en que encontrar una contraseña de administrador hardcodeada ya ni sorprende.

  • Entiendo que solo es una contraseña predeterminada hardcodeada, no un backdoor permanente. Según el texto, durante el proceso de onboarding el usuario cambia la contraseña. La mayoría de las apps funcionan así.
  • Si la contraseña se cambia durante la instalación en el flujo normal, me parece que no hay tanto problema. Después de pasar los últimos 5 años montando en mi casa tantos dispositivos IoT/smarthome como me fue posible, mi conclusión es que casi todas las empresas venden productos cuya funcionalidad deja dudas, y que armar un hogar inteligente completo es muy difícil si no te casas con un solo proveedor. Y aun así, los proveedores “buenos” no cubren todas las necesidades. En mi teléfono tengo instaladas apps de Ecobee, Lutron, Hue, varios vendors de cámaras, Meross, Smart Life y otras; de todas ellas, solo Lutron y Hue pueden controlarse directamente mediante hub/HomeKit, así que no hace falta usar sus apps. Matter y Thread llevan tiempo estandarizados, pero sigue habiendo muchísimos productos baratos basados en Wi‑Fi en lugar de dispositivos compatibles, y la mayoría son malos: solo se pueden administrar con la app y están diseñados para empujarte hacia servicios en la nube. Haber comprado cuatro cámaras también es culpa mía, pero la verdad es que cada vendor tiene fortalezas distintas y es difícil culpar al consumidor por repartir sus compras.
  • Una contraseña de administrador hardcodeada que no te deja usar el dispositivo si no la cambias no me parece un gran problema.
  • La verdad, creo que esta tecnología simplemente ya me irrita y por eso reaccioné así; aquí no se puede decir que sea un problema.
  • También está la visión de que el smartphone es el dispositivo originalmente hostil por excelencia; al menos con los equipos de red todavía puedes enterarte de lo que pasa o descubrirlo de esta manera.

• Quisiera una referencia que resuma qué modelos de cámaras tapo soportan RTSP. La c210 funciona más o menos bien para mí (aunque no captura en la nube) y la uso integrada con frigate. Hoy compré una c402 (para exterior), pero esa no tiene camera account en la configuración avanzada, lo cual me decepcionó. El precio bajo es atractivo, pero siento que falta consistencia entre funciones. Si alguien puede recomendar una buena cámara exterior barata, con soporte para stream RTSP y panel solar, me interesaría.

  • Aunque la cámara no soporte rtsp://, probablemente se pueda usar la fuente de stream tapo:// de go2rtc. Dejo como referencia mi configuración de frigate aquí.