Parte: 13 — Seguridad móvil, IoT e inalámbrica · Fuente: Practical IoT Hacking (Chantzis et al.) y OWASP FSTM ⏱️ Duración estimada: 120 min · Nivel: Avanzado
Aprender a obtener, desempaquetar y analizar el firmware de un dispositivo embebido para descubrir credenciales, claves, binarios vulnerables y backdoors, y a emular el firmware para pruebas dinámicas. El alumno recorrerá la metodología OWASP FSTM: obtención, extracción del sistema de ficheros, análisis estático, emulación y verificación de la cadena de actualización.
⚠️ Nota ética: trabaja solo con firmware de dispositivos propios o de descargas oficiales del fabricante para tu equipo, o con imágenes de práctica (DVRF, IoTGoat). No redistribuyas firmware con copyright.
Al finalizar, el alumno podrá:
binwalk y utilidades relacionadas.| # | Tema | Por qué importa |
|---|---|---|
| 1 | Obtención del firmware | Sin la imagen no hay análisis |
| 2 | Formatos y binwalk |
Identifica y extrae componentes |
| 3 | Sistemas de ficheros (SquashFS, JFFS2) | Contienen binarios y configs |
| 4 | Búsqueda de secretos | Credenciales y claves embebidas |
| 5 | Análisis de binarios | Vulnerabilidades en servicios propios |
| 6 | Emulación con QEMU | Prueba dinámica sin el hardware |
| 7 | Seguridad de la actualización | Firma/cifrado del OTA |
Una imagen puede contener cabecera del fabricante, bootloader, kernel, device tree, rootfs, configuración, particiones de recuperación y firma. binwalk reconoce patrones; un patrón es candidato, no prueba. La extracción conserva el original y su hash, identifica arquitectura y offsets y registra cada transformación.
El análisis busca cuentas, scripts de inicio, certificados, claves privadas, servicios y mecanismos de actualización. Una cadena encontrada puede ser una clave pública o dato de prueba; se valida uso. Contraseñas con hash requieren revisar algoritmo y política, no intentar acceso fuera del dispositivo propio.
Firmar actualizaciones protege autenticidad e integridad si la raíz de confianza y la verificación están protegidas. Anti-rollback evita instalar una versión antigua firmada pero vulnerable. NIST SP 800-193 organiza resiliencia en proteger, detectar y recuperar. Cifrar la imagen puede dificultar extracción, pero la clave y el código de descifrado deben existir en algún punto del producto.
La emulación rara vez reproduce hardware, drivers, secure elements o nube. Sirve para observar servicios bajo supuestos y debe marcarse como parcial. Una prueba que funciona en QEMU no demuestra el mismo impacto en el dispositivo.
Dos imágenes oficiales contienen la misma clave privada de servidor. La evidencia se confirma comparando huellas en unidades propias. El problema no es solo «secreto en firmware»: una clave compartida impide identidad única y complica rotación. La corrección provisiona credenciales por dispositivo y define revocación y actualización.
| Término | Definición útil |
|---|---|
| Rootfs | Sistema de archivos raíz usado por el runtime embebido. |
| Bootloader | Código inicial que prepara y carga etapas posteriores. |
| Anti-rollback | Control que rechaza versiones anteriores aun si están firmadas. |
| Root of trust | Componente protegido en el que comienza una decisión de confianza. |
| Emulación parcial | Ejecución aproximada que no reproduce todo el hardware. |
El alumno domina la clase cuando conserva offsets y hashes, distingue detección de validación, explica firma y rollback, identifica una exposición con flujo de uso y limita las conclusiones de la emulación.
unsquashfs.# Extracción
binwalk firmware.bin # mapa de componentes
binwalk -e firmware.bin # extraer recursivamente
unsquashfs squashfs-root.bin # extraer SquashFS
# Búsqueda de secretos en el rootfs extraído
grep -rniE "password|passwd|admin|api[_-]?key|BEGIN .*PRIVATE KEY" squashfs-root/
find squashfs-root/ -name "*.conf" -o -name "shadow" -o -name "*.pem"
# Emulación
git clone https://github.com/attify/firmware-analysis-toolkit
./fat.py firmware.bin
binwalk firmware.bin y observa entropía con binwalk -E para detectar cifrado.binwalk -e o unsquashfs; localiza /etc, /bin, /www.shadow/passwd, claves privadas, certificados, cadenas de conexión y credenciales hardcodeadas.strcpy, system).system() en un binario del firmware.Analiza una imagen de firmware (propia o de práctica) y produce un informe con al menos dos hallazgos: una credencial/clave embebida y una función potencialmente vulnerable en un binario. Criterio de aceptación: para el binario, señalas la dirección/función concreta en Ghidra y explicas por qué el uso es peligroso; para la credencial, indicas el fichero exacto donde la hallaste.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
binwalk no extrae nada |
Firmware cifrado (alta entropía); busca la clave o vuelca el flash directamente |
unsquashfs falla |
Variante/compresión no estándar (LZMA/XZ); usa binwalk con soporte o sasquatch |
| Emulación no arranca la web | Falta NVRAM/hardware; usa Firmadyne que la simula |
| Binario no corre en QEMU | Arquitectura equivocada; usa qemu-<arch> correcto y libs |
| Solo veo un blob | Partición única; segméntala por offsets de binwalk |
❓ ¿Cómo obtengo el firmware si no hay descarga oficial? Puedes volcarlo del chip de flash por SPI/JTAG (clase 268), interceptar una actualización OTA, o extraerlo desde la app/nube del fabricante.
❓ ¿Qué hago si el firmware está cifrado? Busca la clave en el bootloader o en una versión previa sin cifrar, o vuelca la RAM/flash tras el descifrado en tiempo de ejecución mediante acceso hardware.
❓ ¿La emulación reemplaza al hardware real? Para muchas pruebas de la interfaz web y servicios sí, pero periféricos y comportamiento dependiente de hardware requieren el dispositivo físico.
Clase 266 — Seguridad de IoT: panorama y superficie de ataque