TP-Link Kasa EC71: RSA global y MD5 sin sal expuestos en CVE-2026-9770

⏱️ Lectura: 12 min

Un investigador extrajo físicamente el firmware de una cámara Kasa Spot EC71 con un programador CH341A y destapó una falla de seguridad IoT que TP-Link arrastraba desde hace años: miles de cámaras firmadas con la misma llave RSA.

📑 En este artículo

1. TL;DR
2. Qué es y por qué importa
3. Cómo funciona una auditoría de firmware IoT
   1. Extracción física por SPI
4. Ejemplos prácticos
5. Cómo empezar a auditar firmware de tu propio dispositivo IoT
   1. Instalar binwalk
6. Casos de uso reales: la cadena de fallas de la Kasa EC71
7. Errores comunes y buenas prácticas
8. Comparativa: decisiones criptográficas y de protocolo
9. Profundizando: por qué el GPS tardó una década en cerrarse
10. Preguntas frecuentes
    1. ¿Qué es una llave RSA fleet-wide y por qué es un problema?
    2. ¿Por qué MD5 sin sal ya no sirve para guardar contraseñas?
    3. ¿Cómo sé si un dispositivo IoT expone datos sin autenticación?
    4. ¿Qué firmware debo instalar si tengo una cámara Kasa Spot EC71?
    5. ¿Qué es la divulgación coordinada de vulnerabilidades?
    6. ¿Por qué TP-Link tardó seis meses en cerrar el hallazgo de GPS?
11. Referencias

Sumado a contraseñas guardadas con MD5 sin sal y a una exposición de coordenadas GPS sin autenticación, el hallazgo terminó en dos CVE publicados el 16 de julio de 2026, tras seis meses de divulgación coordinada con el fabricante.

TL;DR

• Vas a entender cómo se extrae firmware IoT físicamente con un programador CH341A sobre el chip SPI.
• Vas a distinguir por qué una llave RSA compartida entre miles de dispositivos es mucho más grave que una llave por unidad.
• Vas a saber por qué MD5 sin sal para contraseñas ya no es aceptable, ni en 2026 ni antes.
• Vas a poder capturar tráfico UDP no autenticado de un dispositivo IoT con tcpdump o Wireshark.
• Vas a conocer el proceso real de divulgación coordinada detrás de CVE-2026-9770 y CVE-2026-13230.
• Vas a tener una tabla para elegir entre MD5, PBKDF2, bcrypt y Argon2 según el caso.
• Vas a saber qué firmware instalar hoy si tenés una cámara Kasa EC71 (2.4.1).

Qué es y por qué importa

La Kasa Spot EC71 es una cámara de interior de TP-Link. Un análisis de seguridad IoT publicado por el investigador Christopher Childress (BadChemical) sobre el firmware 2.3.26 (build 20240425, release 33797) encontró tres cadenas de fallas que comprometían confidencialidad, integridad y disponibilidad del dispositivo.

La primera es una llave RSA compartida por toda la flota de dispositivos, registrada como CVE-2026-9770. La segunda, parte del mismo CVE, es el almacenamiento de credenciales con MD5 sin sal. La tercera es la exposición no autenticada de coordenadas GPS precisas, registrada como CVE-2026-13230. TP-Link remedió las tres en el firmware 2.4.1 tras un rediseño arquitectónico de seis meses.

Importa porque ninguna de las tres fallas es exótica. Son errores de diseño que cualquier equipo que construya un producto IoT puede cometer, y que un lector puede aprender a detectar en su propio hardware con herramientas de código abierto.

Cómo funciona una auditoría de firmware IoT

Auditar un dispositivo IoT cerrado empieza casi siempre por el mismo cuello de botella: sacar el firmware de adentro del chip antes de poder leer una sola línea de código. En este caso, el investigador no tenía una actualización OTA descargable a mano, así que recurrió a extracción física.

Extracción física por SPI

La mayoría del hardware IoT barato guarda el firmware en un chip de memoria flash SPI soldado en la placa. Un programador como el CH341A, una placa de menos de diez dólares, se conecta directo a las patas del chip con un clip SOIC8 y vuelca el contenido completo a un archivo binario, sin pasar por el sistema operativo del dispositivo.

flashrom -p ch341a_spi -r firmware_kasa_ec71_2.3.26.bin

Este comando le pide a flashrom que lea (-r) el contenido completo del chip conectado vía el programador CH341A y lo guarde en un archivo local. El resultado es un volcado binario crudo: todavía no es código legible, es la representación byte a byte de la flash.

flowchart TD
A["Camara Kasa EC71"] --> B["Desmontaje fisico"]
B --> C["Clip SOIC8 + programador CH341A"]
C --> D["Volcado binario del chip SPI"]
D --> E["Extraccion con binwalk"]
E --> F["Busqueda de credenciales y llaves"]

Con el binario en mano, el siguiente paso es identificar qué hay adentro: bootloader, kernel, sistema de archivos y, con suerte para el atacante, credenciales o llaves criptográficas embebidas en texto plano o en configuraciones poco protegidas.

Ejemplos prácticos

El primer paso analítico suele ser correr binwalk sobre el volcado para identificar firmas conocidas y extraer automáticamente cada sección:

$ binwalk -e firmware_kasa_ec71_2.3.26.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes
64            0x40            LZMA compressed data
1245184       0x130000        Squashfs filesystem, little endian, version 4.0

El flag -e le indica a binwalk que, además de identificar firmas, extraiga cada sección reconocida (kernel, sistema de archivos SquashFS, etc.) a una carpeta local. A partir de ahí ya se puede navegar el sistema de archivos del dispositivo como si fuera un disco montado, buscando archivos de configuración, certificados y binarios de servicio.

Un segundo ejemplo, más cercano al fallo real de la Kasa EC71, es reproducir en Python la diferencia entre un hash sin sal y uno correctamente derivado:

import hashlib
import os

def hash_md5_sin_sal(password: str) -> str:
    return hashlib.md5(password.encode()).hexdigest()

def hash_pbkdf2_con_sal(password: str, salt: bytes) -> str:
    return hashlib.pbkdf2_hmac("sha256", password.encode(), salt, 200_000).hex()

salt = os.urandom(16)
print(hash_md5_sin_sal("Camara123"))
print(hash_pbkdf2_con_sal("Camara123", salt))

La primera función reproduce el error de la Kasa EC71: el mismo texto siempre genera el mismo hash, así que una tabla arcoíris precalculada lo revierte en segundos. La segunda agrega una sal aleatoria por credencial y 200.000 iteraciones, lo que vuelve inviable precalcular la tabla y encarece cada intento de fuerza bruta.

Cómo empezar a auditar firmware de tu propio dispositivo IoT

No hace falta un laboratorio de hardware caro para replicar el primer paso de este tipo de auditoría de seguridad IoT. Esto es lo mínimo para arrancar hoy:

1. Conseguí un programador SPI: un CH341A cuesta menos de diez dólares y trae clips SOIC8 para no tener que soldar.
2. Instalá binwalk para desempaquetar el volcado.
3. Corré binwalk sobre el archivo .bin para identificar sistema de archivos, bootloader y strings embebidos.
4. Buscá credenciales y llaves con grep sobre los archivos extraídos: rutas típicas son /etc/passwd, certificados .pem y archivos de configuración JSON.

Instalar binwalk

En Linux (Debian/Ubuntu):

sudo apt update && sudo apt install binwalk

En macOS (con Homebrew):

brew install binwalk

En Windows, la vía más estable es WSL, porque binwalk depende de herramientas de extracción de Linux:

wsl --install
wsl sudo apt update && sudo apt install binwalk

💡 Tip: corré binwalk primero con -B (solo identificación de firmas) antes de -e (extracción completa): así confirmás qué hay adentro sin llenar el disco de archivos que quizás no necesitás.

Casos de uso reales: la cadena de fallas de la Kasa EC71

El reporte inicial se envió al equipo de seguridad de producto el 5 de enero de 2026. El vendor confirmó los hallazgos 1 (llave RSA) y 2 (credenciales inseguras) el 27 de enero, mientras cerraba otros hallazgos menores como riesgo aceptado. El 23 de marzo pidió una extensión hasta junio para un rediseño arquitectónico entre sistemas, y en esa misma fecha se sumó el hallazgo de GPS con su propio PoC.

El proceso no fue lineal. El 29 de mayo, la respuesta de triage del vendor sobre el hallazgo de GPS mencionó un campo de hash MD5 que no existía ni en el payload reportado ni en la respuesta JSON real del dispositivo, evidencia de que el hallazgo no se había revisado antes de responder. El investigador respondió con un video PoC documentando esa falla de triage.

El 15 de junio, un firmware beta 2.4.00 entregado para validar el parche dejó el dispositivo de prueba permanentemente sin respuesta: el LED quedó marcando un patrón de aproximadamente 25 pulsos verdes seguidos de uno rojo, en ciclo continuo, y el vendor confirmó el 19 de junio que no había ruta de recuperación por software. El firmware final 2.4.1, con las tres fallas corregidas, se publicó junto al advisory el 16 de julio de 2026.

Errores comunes y buenas prácticas

El error más caro de esta historia no es técnico, es de proceso: TP-Link cerró varios hallazgos menores como riesgo aceptado sin una revisión arquitectónica completa, y eso permitió que la misma clase de falla de GPS sobreviviera de un producto a otro.

⚠️ Ojo: restaurar un dispositivo IoT de segunda mano a valores de fábrica no garantiza que las credenciales o coordenadas GPS del dueño anterior se borren del backend del fabricante.

Otro error recurrente: reutilizar una sola llave criptográfica en toda una línea de producción para simplificar la fabricación. Es más barato firmar una vez y grabar la misma llave en cada unidad, pero convierte el firmware de un solo dispositivo comprado por cualquiera en la llave maestra de toda la flota.

Comparativa: decisiones criptográficas y de protocolo

Opción	Cuándo usarla	Ventaja	Limitación
Llave RSA por dispositivo	Producción a escala de fábrica	Comprometer una unidad no afecta al resto de la flota	Más complejidad en el proceso de manufactura y gestión de claves
Llave RSA compartida (fleet-wide)	Nunca recomendable	Más simple de fabricar	Un solo dump de firmware compromete toda la flota, como en la Kasa EC71
Hash MD5 sin sal	Nunca recomendable para credenciales	Rápido de calcular	Vulnerable a tablas arcoíris precalculadas
PBKDF2 / bcrypt / Argon2 con sal	Almacenamiento de credenciales en 2026	Resiste fuerza bruta y tablas precalculadas	Mayor costo de CPU por diseño (es intencional)

Profundizando: por qué el GPS tardó una década en cerrarse

La exposición de GPS no era un hallazgo nuevo para la industria. Es públicamente conocida desde agosto de 2020 en la línea de cámaras de TP-Link, y desde julio de 2016 para el protocolo no autenticado subyacente que la hace posible. TP-Link ya había corregido una clase de vulnerabilidad idéntica en su línea de enchufes inteligentes en noviembre de 2020, pero nunca extendió esa corrección a las cámaras.

Ese patrón, remediar de forma incremental y puntual en vez de hacer una revisión arquitectónica completa, es la explicación técnica de por qué un dato tan sensible como una ubicación GPS precisa siguió expuesto sin login durante años en un producto activo.

sequenceDiagram
participant A as Dispositivo en la red local
participant D as Camara Kasa EC71
A->>D: paquete de descubrimiento UDP sin credenciales
D-->>A: JSON con coordenadas GPS precisas
Note over A,D: no se solicita autenticacion alguna

El impacto de la llave RSA compartida se entiende mejor como un árbol invertido: una sola llave extraída de una sola cámara compromete criptográficamente a cada unidad vendida bajo ese mismo firmware.

flowchart TD
K["Una llave RSA compartida"] --> D1["Camara EC71 unidad 1"]
K --> D2["Camara EC71 unidad 2"]
K --> D3["Camara EC71 unidad N"]
subgraph Impacto
D1
D2
D3
end

El advisory documenta además un vector de mercado secundario: dispositivos revendidos que conservan, en el backend del fabricante, credenciales y coordenadas GPS del dueño anterior aun después de un reseteo de fábrica.

💭 Clave: la seguridad IoT de un dispositivo no termina en su firmware: incluye qué guarda el backend del fabricante sobre cada unidad vendida.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: descargá el firmware público de un router viejo que ya no uses y corré binwalk -e sobre él para practicar la extracción antes de tocar un dispositivo en producción.

Preguntas frecuentes

¿Qué es una llave RSA fleet-wide y por qué es un problema?

Es una única llave criptográfica grabada en todas las unidades de un modelo. Si se extrae de un solo dispositivo comprado legalmente, compromete a toda la flota que comparte esa llave.

¿Por qué MD5 sin sal ya no sirve para guardar contraseñas?

Porque genera siempre el mismo hash para el mismo texto, lo que permite precalcular tablas arcoíris y revertirlo en segundos, sin necesidad de fuerza bruta real.

¿Cómo sé si un dispositivo IoT expone datos sin autenticación?

Capturando su tráfico de red con tcpdump o Wireshark mientras la app asociada lo descubre en la red local, y revisando si el dispositivo responde con datos sensibles sin pedir credenciales.

¿Qué firmware debo instalar si tengo una cámara Kasa Spot EC71?

La versión 2.4.1, que corrige las tres fallas descritas en CVE-2026-9770 y CVE-2026-13230.

¿Qué es la divulgación coordinada de vulnerabilidades?

Es el proceso donde un investigador reporta una falla en privado al fabricante y acuerda un plazo para que la corrija antes de publicarla, para minimizar el riesgo a los usuarios.

¿Por qué TP-Link tardó seis meses en cerrar el hallazgo de GPS?

Porque requería un rediseño arquitectónico entre varios sistemas, no un simple parche puntual, y ese rediseño arrastró extensiones de plazo, un firmware beta que dejó un dispositivo de prueba sin respuesta y una respuesta de triage que no revisó el hallazgo original.

Referencias

• Advisory original de BadChemical en GitHub: reporte completo, timeline de divulgación y detalles técnicos de los tres hallazgos.
• NVD: CVE-2026-9770: ficha oficial de la llave RSA compartida y el almacenamiento inseguro de credenciales.
• NVD: CVE-2026-13230: ficha oficial de la exposición no autenticada de coordenadas GPS.
• Repositorio de binwalk en GitHub: herramienta usada para identificar y extraer sistemas de archivos de un volcado de firmware.
• Repositorio python-kasa en GitHub: implementación de referencia, abierta, del protocolo de descubrimiento de dispositivos Kasa.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de Denis Nuțiu en Unsplash