Parte: 13 — Seguridad móvil, IoT e inalámbrica · Fuente: Practical IoT Hacking (Chantzis et al.) y OWASP IoT Top 10 ⏱️ Duración estimada: 90 min · Nivel: Intermedio
Construir un modelo mental completo de la superficie de ataque de un dispositivo IoT: aplicación móvil, API/nube, comunicaciones de red, firmware y hardware físico. El alumno aprenderá a mapear metódicamente esas capas, a aplicar el OWASP IoT Top 10 y a planificar una evaluación de seguridad de un dispositivo conectado propio, sentando las bases para las clases prácticas de firmware, hardware y radio que siguen.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Anatomía de un producto IoT | Define todas las capas atacables |
| 2 | OWASP IoT Top 10 | Marco de referencia de riesgos |
| 3 | Enumeración de red y servicios | Punto de partida del ataque remoto |
| 4 | APIs y comunicación con la nube | Suele ser el eslabón más débil |
| 5 | Threat modeling del dispositivo | Prioriza el esfuerzo de pruebas |
| 6 | Laboratorio aislado | Evita impacto en producción/terceros |
| 7 | Credenciales y actualización | Fallos endémicos del sector |
Un producto conectado combina dispositivo, aplicación móvil, servicio cloud, identidad, red local, actualización y soporte. Una cerradura puede proteger bien su radio y exponer cuentas en la API; una cámara puede tener firmware firmado y una contraseña compartida. El modelo sigue datos y comandos entre capas durante instalación, operación, actualización, transferencia y retiro.
NIST IR 8259A define una base de capacidades técnicas: identificación, configuración, protección de datos, control de interfaces, actualización, conocimiento del estado y seguridad del dispositivo. Es un punto de partida que se adapta al riesgo; no una certificación automática. IR 8259B añade capacidades de soporte del fabricante. El ciclo de soporte, divulgación y fin de vida importa tanto como una contraseña inicial.
La amenaza física cambia supuestos: el atacante puede abrir carcasa, cortar energía o leer flash. La respuesta no siempre es hacer todo inviolable, sino proteger claves, detectar manipulación cuando sea viable, limitar privilegios y recuperar de forma segura. Privacidad considera inferencias: un sensor sin audio puede revelar ocupación por horarios.
Un sensor recibe firmware firmado, pero su app usa una API sin separación entre hogares. El control de actualización no cubre autorización cloud. El inventario por capas descubre ambos propietarios y produce pruebas distintas. La seguridad del producto se evalúa por el camino completo del comando.
| Término | Definición útil |
|---|---|
| Producto IoT | Dispositivo y servicios necesarios para su función. |
| Capability baseline | Conjunto adaptable de capacidades, no lista de aprobación. |
| Provisioning | Incorporación inicial de identidad, claves y configuración. |
| Fin de vida | Momento y proceso en que cesa soporte y se gestiona retiro. |
| Efecto físico | Cambio sobre entorno o seguridad causado por el producto. |
Existe dominio cuando el alumno dibuja todas las capas y actores, sigue un dato y un comando, adapta la base NIST al impacto y propone soporte, actualización y retiro verificables.
# Descubrir y enumerar el dispositivo en la red de laboratorio
nmap -sn 192.168.50.0/24 # host discovery
nmap -sV -p- 192.168.50.23 # servicios y versiones
tcpdump -i wlan0 host 192.168.50.23 -w iot.pcap
⚠️ Aísla el dispositivo en una red separada; nunca escanees equipos que no sean tuyos.
Elabora un mapa de superficie de ataque de un dispositivo IoT propio que cubra las cinco capas y un plan de evaluación priorizado. Criterio de aceptación: el plan identifica al menos un servicio de red expuesto (con evidencia de Nmap) y determina, con captura de tráfico, si la comunicación con la nube va cifrada o en claro.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| Nmap no encuentra el dispositivo | Aislamiento de red o firewall; verifica la VLAN y usa -sn |
| Tráfico a la nube ilegible | Va por TLS; intercéptalo desde la app con proxy y CA propio |
| El dispositivo deja de funcionar | Escaneo agresivo lo bloqueó; reduce la intensidad (-T2) |
| No hay puertos abiertos | Solo se comunica saliente a la nube; céntrate en app/API |
| Emparejamiento falla en laboratorio | Requiere Internet; permite salida controlada y monitorízala |
❓ ¿Por dónde empiezo a auditar un dispositivo IoT? Por el modelado de la superficie: enumera red, revisa la app y las APIs. Suelen ser el camino más rápido antes de abrir el hardware.
❓ ¿Por qué el IoT es tan inseguro históricamente? Costes bajos, ciclos de desarrollo cortos, falta de actualizaciones, credenciales por defecto y reutilización de firmware sin endurecer.
❓ ¿Necesito abrir el dispositivo desde el principio? No siempre. El análisis de red, app y nube da mucho valor sin tocar el hardware; el análisis físico se reserva para profundizar (clases 267–268).
Clase 265 — Ingeniería inversa de aplicaciones móviles