Pentesting IoT: superficies de ataque de dispositivos conectados

Un producto conectado rara vez es un único objeto de prueba. Hay que considerar el hardware (interfaces de depuración y de memoria, disposición de componentes), el firmware (cadena de arranque, sistema de archivos, secretos almacenados), las interfaces de radio (entre otras, Wi-Fi, Bluetooth Low Energy, Zigbee, Thread, LoRaWAN, redes móviles y protocolos propietarios sub-GHz), el backend cloud con sus API y la app móvil o web asociada. Precisamente esta división se refleja en las cinco categorías de requisitos del OWASP ISVS: IoT Ecosystem, User Space Application, Software Platform, Communication y Hardware Platform. Una revisión aislada de capas individuales suele pasar por alto las transiciones, por ejemplo el onboarding de un dispositivo en una cuenta de usuario.

El análisis de hardware comienza con la identificación de componentes y puntos de prueba en la placa. En la práctica, las consolas serie (UART) exponen con frecuencia logs de arranque, acceso al bootloader o una shell insuficientemente protegida; las interfaces de depuración como JTAG o SWD permiten, según el estado de bloqueo del controlador, detener la CPU y acceder a la memoria en lectura y escritura. Los chips flash externos conectados por SPI o I2C pueden leerse en muchos casos montados en la placa o tras desoldarlos. Por eso no solo se comprueba si existen estos accesos, sino también si los puertos de depuración están desactivados o autenticados en producción, si el secure boot es efectivo y si los parámetros sensibles se almacenan cifrados o en un elemento seguro.

El firmware se obtiene mediante descargas del fabricante, capturas de procesos de actualización o un volcado de memoria, y a continuación se desempaqueta. El análisis estático busca credenciales embebidas, claves privadas y certificados, configuraciones inseguras y componentes obsoletos, que se cotejan con vulnerabilidades conocidas mediante una lista de materiales de software (SBOM). Se complementa con un análisis dinámico sobre el sistema en ejecución o emulado. La OWASP Firmware Security Testing Methodology (FSTM) describe este procedimiento en nueve fases, desde la recopilación de información hasta la verificación de los hallazgos, pasando por la extracción y la emulación. La pregunta central sigue siendo la capacidad de actualización: ¿se verifica realmente la firma de una actualización y puede impedirse un downgrade a una versión anterior vulnerable?

Para los requisitos y la ejecución de las pruebas existen catálogos abiertos. El OWASP ISVS agrupa los requisitos de seguridad para ecosistemas IoT en cinco categorías y está disponible públicamente como Release Candidate 1.0RC; el OWASP ISTG añade, desde su versión 1.0 del 1 de marzo de 2024, una metodología de pentest con un modelo de dispositivo y de atacante y un catálogo de casos de prueba que cubre, entre otros, las interfaces de radio, las unidades de procesamiento, la memoria del dispositivo, las interfaces internas y físicas, así como el firmware y el mecanismo de actualización. A nivel de producto, ETSI EN 303 645 en su versión V3.1.3 (2024-09) define una línea base para el IoT de consumo con 13 áreas temáticas —desde la eliminación de contraseñas universales por defecto y la gestión de los reportes de vulnerabilidades entrantes hasta el almacenamiento seguro de los parámetros relevantes para la seguridad—, complementada con un capítulo sobre disposiciones de protección de datos. La metodología de evaluación correspondiente la aporta ETSI TS 103 701 (V2.1.1, 2025-05) con casos de prueba por provisión; el BSI basa su distintivo de seguridad TI (IT-Sicherheitskennzeichen) para dispositivos inteligentes de consumo en ambos documentos. Una primera autoevaluación conforme al ISVS es posible a través del self-assessment de uso libre en isvs.vamisec.com.

El Reglamento Delegado (UE) 2022/30 hace aplicables los requisitos de ciberseguridad del artículo 3, apartado 3, letras d), e) y f) de la Directiva 2014/53/UE de equipos radioeléctricos a determinadas categorías de equipos radioeléctricos: dispositivos con conexión a Internet, dispositivos que tratan datos personales (entre otros, productos de puericultura, juguetes y dispositivos que se llevan en el cuerpo) y dispositivos que procesan valores virtuales o dinero; quedan exentos los productos con regulación sectorial propia, como productos sanitarios o equipos aeronáuticos y de automoción. Los requisitos se aplican desde el 1 de agosto de 2025, después de que el Reglamento Delegado (UE) 2023/2444 aplazara doce meses la fecha original. Las normas EN 18031-1, -2 y -3 figuran en el Diario Oficial como normas armonizadas (Decisión de Ejecución (UE) 2025/138, de 28 de enero de 2025), aunque con restricciones, entre otras para las configuraciones en las que los usuarios pueden renunciar a establecer una contraseña; en esos puntos decae la presunción de conformidad. En paralelo rige el Cyber Resilience Act (Reglamento (UE) 2024/2847): las obligaciones de notificación de vulnerabilidades activamente explotadas e incidentes graves se aplican desde el 11 de septiembre de 2026 y las demás obligaciones desde el 11 de diciembre de 2027; con efecto en esa fecha, la Comisión ha decidido derogar el Reglamento Delegado (UE) 2022/30 para evitar una doble regulación.

Un pentest IoT comienza con el scoping: se definen los objetos de prueba, el modelo de dispositivo y de atacante (acceso físico y nivel de autorización), el número de muestras de prueba y los riesgos de desmontaje, complementados con un modelado de amenazas conjunto. Siguen la recopilación de información, el análisis del hardware y de las interfaces, la extracción del firmware con análisis estático y la revisión de los protocolos de radio y de red, así como de la API cloud, el proceso de onboarding y la app, verificando cada hallazgo en el dispositivo en funcionamiento. El resultado es un informe con evidencias reproducibles, una evaluación de riesgos trazable y una lista de medidas ordenada por esfuerzo e impacto; un retest acredita la eficacia de la corrección. Para los fabricantes, esta documentación es a la vez material probatorio: el anexo I, parte II del Cyber Resilience Act exige pruebas y revisiones eficaces y periódicas de la seguridad del producto, así como la identificación y documentación de vulnerabilidades y componentes, incluida una lista de materiales legible por máquina.