Pentest IoT: qué atacamos y qué encontramos
Qué cubre un pentest IoT, desde los puertos de depuración y el firmware hasta la radio, las apps y la nube, qué hallazgos se repiten y cómo preparar su dispositivo.
Zyberum Security Team · Publicado · 7 min de lectura
Un producto IoT nunca es solo un dispositivo. Es hardware, firmware, un enlace de radio, una app y un servicio en la nube, y a un atacante le basta con que uno de ellos sea débil. Un pentest IoT los examina todos juntos, porque los ataques interesantes suelen cruzar las fronteras entre ellos.
Esto es lo que hacemos de verdad en una prueba de este tipo y lo que encontramos una y otra vez.
Las cinco capas que atacamos
1. Hardware
Lo primero es abrir el dispositivo. En la placa buscamos interfaces de depuración (UART, JTAG, SWD), puntos de prueba y el chip de flash. Una consola serie que da directamente una shell de root sigue siendo uno de los hallazgos más habituales en productos reales.
Si el puerto de depuración está bloqueado, intentamos obtener el firmware por otra vía: leyendo directamente el chip de flash o provocando un glitch en el procesador para que se salte una comprobación.
2. Firmware
Con el firmware extraído, lo desempaquetamos y lo leemos. Preguntas típicas:
- ¿Hay contraseñas, claves de API o claves privadas incrustadas en el código?
- ¿Qué componentes de código abierto contiene y qué antigüedad tienen?
- ¿Existe una cadena de arranque seguro, y cada etapa verifica de verdad la siguiente?
- ¿Cómo se comprueban las actualizaciones? ¿Están firmadas o solo se comparan con un checksum?
3. Radio e interfaces locales
Bluetooth LE, Wi-Fi, Zigbee, Thread, LoRaWAN o un enlace propietario sub-GHz: capturamos el tráfico, lo reproducimos y lo modificamos. El emparejamiento es un objetivo predilecto, porque muchos dispositivos aceptan a cualquiera que lo pida en el momento adecuado.
4. App
La app asociada suele saber más de lo que debería. La descompilamos, buscamos secretos y observamos cómo habla con el dispositivo y con la nube.
5. Nube y API
Aquí comprobamos si un cliente puede llegar a los dispositivos de otro cliente. El control de acceso defectuoso sobre los ID de dispositivo es el clásico: se cambia un número en una petición y se controla el producto de otra persona.
Lo que encontramos con más frecuencia
| Hallazgo | Por qué importa |
|---|---|
| Consola de depuración abierta (UART/JTAG) | Control total con acceso físico y un camino rápido hacia el firmware |
| Credenciales o claves incrustadas en el firmware | Un solo dispositivo extraído compromete toda la flota |
| Actualizaciones sin firmar o con verificación débil | Un atacante puede instalar su propio firmware |
| Componentes obsoletos con vulnerabilidades conocidas | Los exploits públicos funcionan sin adaptación |
| Emparejamiento sin autenticación real | Cualquiera que esté cerca puede tomar el control del dispositivo |
| La API cloud confía en el ID del dispositivo | Acceso a los dispositivos y datos de otros clientes |
| La misma contraseña por defecto en todos los dispositivos | Compromiso masivo desde internet |
Nada de esto requiere técnicas exóticas. Requiere que alguien mire.
Cómo se desarrolla una prueba
- Llamada de definición del alcance. Quince minutos para acordar el dispositivo, sus interfaces y la profundidad de la prueba.
- Desmontaje y firmware. Entramos en el dispositivo y extraemos lo que se ejecuta en él.
- Ataque. Hardware, radio, app y nube, y después las combinaciones entre ellos.
- Informe y sesión de resultados. Cada hallazgo con su prueba de concepto, su severidad y su corrección, explicado a sus ingenieros.
- Retest. Comprobamos que las correcciones aguantan.
Cómo prepararse
- Envíe al menos dos dispositivos. Puede que uno no sobreviva.
- Facilite un entorno de pruebas en la nube, separado de producción.
- Entréguenos las imágenes de firmware y la documentación si las tiene. Ahorra días.
- Designe a un ingeniero que pueda responder preguntas con rapidez.
Por qué ahora
Desde el 1 de agosto de 2025, los requisitos de ciberseguridad de la Directiva de Equipos Radioeléctricos (RED) se aplican a los dispositivos inalámbricos, y a partir de diciembre de 2027 el Cyber Resilience Act se aplica a casi todo lo que tenga elementos digitales. Ambos esperan que los productos se prueben antes de salir al mercado.
¿Quiere saber cómo aguanta su dispositivo? Consulte nuestras pruebas de seguridad IoT o solicite una oferta de pentest.
FAQ
Preguntas frecuentes
¿Qué necesitan de nosotros para un pentest IoT?
Dos o tres dispositivos, a ser posible uno de ellos con el acceso de depuración habilitado, la app asociada, una cuenta de pruebas para la nube y la documentación que exista. Cuanto más recibimos, más a fondo podemos llegar en el mismo tiempo.
¿La prueba dañará el dispositivo?
Los ataques de hardware pueden hacerlo. Abrimos los dispositivos, soldamos en los puntos de prueba y a veces retiramos los chips de flash, por eso pedimos más de una muestra.
¿Basta un pentest IoT para el Cyber Resilience Act?
Es una pieza importante: el CRA exige que los productos se comercialicen sin vulnerabilidades explotables conocidas y que se sometan a pruebas. Además necesita procesos de desarrollo seguro, gestión de vulnerabilidades y documentación.