TP-Link Tapo C200: claves hardcodeadas, desbordamientos de búfer y privacidad en la era de la ingeniería inversa asistida por IA

• El análisis del firmware de la cámara IP económica TP-Link Tapo C200 mediante ingeniería inversa asistida por IA reveló múltiples vulnerabilidades de seguridad
• El firmware incluye una clave privada SSL hardcodeada, lo que permite descifrar tráfico HTTPS dentro de la misma red
• Durante el análisis se usaron herramientas de IA (Grok, GhidraMCP, Cline, etc.) para automatizar la comprensión de la estructura del firmware y el análisis del significado de funciones
• Entre las principales vulnerabilidades encontradas están desbordamiento de búfer (CVE-2025-8065), desbordamiento de enteros (CVE-2025-14299) y secuestro de WiFi (CVE-2025-14300); algunas permiten ataques remotos sin autenticación
• Este caso es visto como un ejemplo de cómo la IA mejora la eficiencia de la investigación en seguridad y al mismo tiempo expone vulnerabilidades estructurales en dispositivos IoT

---

Obtención y descifrado del firmware

• Al hacer ingeniería inversa de la app Android de Tapo, se descubrió un bucket S3 público de TP-Link, desde el cual era posible descargar sin autenticación el firmware de todos los dispositivos
  • Comando de ejemplo: aws s3 ls s3://download.tplinkcloud.com/ --no-sign-request --recursive
• El firmware se descifró usando la herramienta tp-link-decrypt
  • La clave RSA puede extraerse del material de publicación de código GPL de TP-Link
• El firmware descifrado está compuesto por una estructura de bootloader, kernel y sistema de archivos raíz SquashFS

Ingeniería inversa asistida por IA

• Se automatizó el análisis del firmware usando Ghidra, GhidraMCP, Cline, Anthropic Opus/Sonnet 4 y otras herramientas
• La IA explicó el rol de las funciones y renombró variables con nombres significativos para mejorar la legibilidad del código
• Gracias a este proceso se mapearon handlers HTTP, protocolos de descubrimiento y rutinas criptográficas
• Se confirmó que la clave privada SSL dentro del firmware no se genera en el arranque, sino que viene integrada
  • Un atacante en la misma red puede descifrar tráfico HTTPS

Principales vulnerabilidades

• CVE-2025-8065 (desbordamiento de memoria en el parser XML SOAP de ONVIF)

  • El servidor /bin/main del puerto 2020 no tiene validación de límites para la cantidad de elementos XML
  • Al enviar grandes volúmenes de solicitudes XML se produce desbordamiento de memoria y caída de la cámara
  • Puntaje CVSS v4.0: 7.1 (High)

• CVE-2025-14299 (desbordamiento de enteros en HTTPS Content-Length)

  • El servidor HTTPS del puerto 443 procesa el encabezado Content-Length con atoi() sin validación
  • En sistemas de 32 bits provoca caídas por desbordamiento
  • Puntaje CVSS v4.0: 7.1 (High)

• CVE-2025-14300 (secuestro de WiFi)

  • La API connectAp puede ser accedida sin autenticación y sigue activa incluso después de completar la configuración
  • Un atacante puede conectar la cámara a una red controlada por el atacante y capturar el tráfico de video
  • Puntaje CVSS v4.0: 8.7 (High)

• API de escaneo WiFi sin autenticación (scanApList)

  • Devuelve SSID, BSSID, intensidad de señal y configuración de seguridad de las redes WiFi cercanas
  • Con herramientas como Apple BSSID Locator es posible rastrear la ubicación GPS exacta
  • Un atacante remoto puede identificar la ubicación real de la cámara

Divulgación y respuesta

• El 22 de julio de 2025 se realizó el primer reporte al equipo de seguridad de TP-Link, incluyendo PoC y video
• Tras 150 días (19 de diciembre) se hizo la divulgación pública, y luego TP-Link publicó un aviso de seguridad
• TP-Link cuenta con autoridad propia para emitir CVE (CNA), por lo que controla directamente el proceso de reporte y divulgación de vulnerabilidades en sus productos
• En su sitio web usa el menor número de CVE frente a competidores como métrica de marketing, lo que generó críticas por conflicto de interés

Conclusión

• Las herramientas de IA maximizan la eficiencia de la ingeniería inversa y amplían el acceso a la investigación en seguridad
• Sin embargo, claves hardcodeadas, APIs sin autenticación y estructuras de parser débiles dejan en evidencia la falta de seguridad de base en los dispositivos IoT
• El caso de TP-Link muestra de forma simbólica el problema de equilibrio entre la investigación de seguridad en la era de la IA y la responsabilidad de los fabricantes

[GN⁺]

Opiniones de Hacker News

• Da pena que este tipo de textos mezcle casos de fracaso reales con problemas que hasta FAANG tiene dificultades para resolver. En particular, es un enfoque equivocado tratar de forma crítica la parte de “el repositorio de firmware de TP-Link estaba en un bucket de S3 público sin autenticación”. Más bien, me parece un buen ejemplo de evitar la seguridad por oscuridad (security through obscurity). Este tipo de artículos incluso podría llevar a que la gerencia dé instrucciones erróneas de “reforzar el candado”.

  • El texto en sí era fácil de leer, pero se sentía un tono como escrito por un LLM. Los textos escritos por IA suelen carecer de matices sutiles y tienden a presentar todo como excesivamente nuevo, o como claramente bueno o malo. No es un mal texto, pero hay que leerlo con cuidado. Últimamente, la mayoría de los posts que llegan a HN parecen haber recibido ayuda de IA.
  • Al comentario de “el repositorio de firmware está público” alguien hizo la broma de “mejor no hablemos de Linux”.
  • Estos blogs de ingeniería inversa son simplemente una forma divertida y educativa de contar historias. Yo mismo he escrito varios textos así, y este en particular me pareció realmente interesante. De hecho, “cómo consiguieron el firmware” es probablemente la parte menos importante de esta historia.
  • No percibí en absoluto un matiz negativo en la parte de que el firmware estuviera público. Me da curiosidad si alguien sí lo sintió así.
  • Creo que el firmware siempre debería ser público. Ese es el rumbo correcto.

• Es muy probable que la mayoría de los otros modelos de cámara también compartan vulnerabilidades de seguridad similares. Según la página de la comunidad de TP-Link, el firmware más reciente del C200 aparece como la versión 1.4.4, pero en el artículo se menciona la 1.4.2. Es decir, sí hubo algunas actualizaciones, pero aparentemente no se aplicaron parches de seguridad.

  • Cuando antes analicé productos de Zyxel, llegué a la misma conclusión. Muchos fabricantes siguen un esquema de vender hardware genérico con distinta marca. Textos de análisis relacionados: Part 1, Part 2
  • Estas cámaras sirven para conexiones locales, pero para usuarios comunes siguen teniendo muchos problemas de usabilidad.

• Por eso mismo, la segmentación de red para IoT es indispensable. Hay que poner todas las cámaras inteligentes y dispositivos IoT en una VLAN separada, y restringir el acceso a internet mediante el firewall. Configuración recomendada para usuarios de cámaras TP-Link:

  1. Desactivar UPnP en el router
  2. Separar los dispositivos IoT con VLAN
  3. Permitir tráfico saliente solo a los endpoints necesarios
  4. Si es posible, cambiar a firmware abierto
  5. Revisar actualizaciones periódicamente El problema de las claves hardcodeadas es especialmente grave y afecta a toda la línea de productos.
  • Una vez probé la red doméstica de un amigo y pude acceder a toda la red interna a través de un sistema de intercom PoE. No había separado sus dispositivos IoT con VLAN y tampoco tenía un sistema de alertas. Ese día terminó aprendiendo en carne propia la importancia de la segmentación por VLAN y de limitar accesos. Me imagino que mucha gente está exponiendo su red interna de forma parecida.
  • También hubo quien preguntó si existe alguna guía que explique paso a paso cómo configurar VLAN. Técnicamente se puede, pero hacen falta procedimientos concretos.

• Al parecer, Thingino soporta el C200.

  • Pero en realidad solo soporta algunas de las 5 versiones del C200. Para verificar el chipset exacto hay que consultar OpenIPC.
  • El firmware creado por la comunidad de Thingino es realmente impresionante. Si tienes una cámara compatible, vale mucho la pena probarlo.

• Yo uso todas mis cámaras en una VLAN sin acceso a internet. Con HomeKit puedo acceder localmente, así que funcionan bien sin app adicional.

• Un nivel de seguridad tan deficiente casi parece intencional. Cuesta entender cómo pueden vender millones de unidades sin hacer ni siquiera verificaciones básicas de vulnerabilidades. Creo que la mayoría de las cámaras Wi-Fi de menos de $150 tendrán problemas parecidos. Si de verdad quieres usarlas de forma segura, prácticamente no queda otra que construir tú mismo un adaptador Wi-Fi ↔ Ethernet no propietario.

  • Esta cámara se vende en el sitio oficial por $17.99. Si descuentas hardware, empaque, logística, pruebas, devoluciones, etc., queda menos de $5 de ganancia por unidad. Gastar $100,000 adicionales en desarrollo equivale a quemar 20,000 unidades. En una empresa con tantas líneas de producto como TP-Link, ese costo puede inflarse a decenas de millones de dólares al año. Al final, el modelo termina siendo enviar productos con el mínimo desarrollo posible.
  • Algunas cámaras alimentadas por USB soportan adaptadores de red USB. Quien tenga experiencia técnica puede montar un entorno solo local con firmware de Thingino.
  • Nunca se debería poner este tipo de cámaras en una red no confiable. Es un principio demasiado obvio.
  • Estoy totalmente de acuerdo con la idea de que “todas las cámaras Wi‑Fi tienen problemas parecidos”.

• No sé cuánto tiempo seguirá abierto el repositorio S3 de firmware de TP-Link. Son alrededor de 990GiB de datos, así que estaría bien que alguien hiciera un respaldo en archivo o torrent.

• Yo uso esta cámara con Unifi + ONVIF solo para tareas no críticas. La puse en una VLAN separada y le bloqueé internet, y por suerte funciona sin problemas.

• Al investigar cámaras, consulté el sitio drmnsamoliu.github.io.

• He hecho ingeniería inversa del feed de video de un dron de juguete usando Ghidra y AWS Amazon Q. Probablemente habría sido mucho más rápido si hubiera usado GhidraMCP.