Introducción

Este ejercicio consiste en un análisis estático de firmware — examinar el firmware de un dispositivo sin ejecutarlo ni interactuar con él en tiempo real — sobre la imagen de actualización de una cámara IP Xiaomi IMI Home Security Camera 1080P (tf_recovery.img). El objetivo: identificar sistema operativo, sistema de ficheros, servicios en ejecución y usuarios, trabajando únicamente sobre el binario del firmware.

A diferencia del análisis dinámico (ejecutar el firmware en un emulador o en el propio dispositivo para observar su comportamiento), el estático no necesita el hardware ni ejecutar nada — lo que lo hace ideal para las primeras fases de una investigación, cuando el objetivo es preservar la evidencia sin alterar el estado del dispositivo.

Identificar el sistema operativo

Primero, file sobre el binario del firmware, sin extraer nada:

file tf_recovery.img

Salida de file: u-boot legacy uImage, Linux-3.3.0, Linux/ARM

Ya de entrada: u-boot legacy uImage, nombre de imagen "Linux-3.3.0". Para confirmarlo y ver la estructura completa, binwalk:

binwalk tf_recovery.img

Salida de binwalk mostrando el kernel Linux ARM y los sistemas de ficheros embebidos

Binwalk confirma un kernel Linux ARM boot ejecutable (zImage, little-endian), kernel 3.3.0. El sistema operativo es Linux embebido.

Sistema de ficheros

La misma salida de binwalk ya muestra los sistemas de ficheros presentes. Para inspeccionarlos de verdad, extraje el firmware:

binwalk -e tf_recovery.img

Dos sistemas de ficheros distintos:

Servicios expuestos

Con el sistema de ficheros ya extraído, inspeccioné el script de arranque (/etc/init.d/rcS) y el directorio de binarios de servicios (/usr/sbin/):

ls _tf_recovery.img.extracted/squashfs-root/usr/sbin/

Listado de binarios en /usr/sbin/ del firmware extraído

De ahí sale una lista de servicios que dice bastante sobre la superficie de ataque del dispositivo:

Servicio Función
telnetd Acceso remoto por consola
httpd Interfaz web de configuración
ftpd Transferencia de ficheros
ntpd Sincronización de hora
wpa_supplicant Conexión WiFi con WPA/WPA2
hostapd El dispositivo actuando como punto de acceso WiFi
inetd Superservidor de red bajo demanda
crond Tareas periódicas
udhcpd Servidor DHCP ligero
mosquitto Broker MQTT — comunicación IoT

telnetd y ftpd en un dispositivo doméstico ya son, de entrada, dos servicios de acceso remoto sin cifrar en la superficie de ataque.

El usuario root sin contraseña

El fichero /etc/passwd de cualquier sistema Linux es de lectura pública y contiene la lista de cuentas:

cat _tf_recovery.img.extracted/squashfs-root/etc/passwd

Contenido de /etc/passwd mostrando el campo de contraseña vacío para root

Junto a los usuarios de sistema esperables (daemon, bin, sys, www-data, nobody, dbus, mosquitto…), el que importa es el primero: root::0:0:root:/root:/bin/sh. El segundo campo —donde debería ir una x (contraseña gestionada en /etc/shadow) o un hash— está vacío. Eso significa que el usuario administrador no tiene contraseña configurada en absoluto.

Combinado con telnetd activo, la consecuencia es directa: cualquiera con acceso a la consola serie o a la red donde esté ese Telnet expuesto puede entrar como root sin autenticarse.

Conclusión

El resumen del dispositivo: Linux embebido (kernel 3.3.0, ARM) sobre SquashFS de solo lectura más JFFS2 para persistencia, con una superficie de servicios de red bastante amplia para tratarse de una cámara doméstica (telnetd, httpd, ftpd), un broker MQTT que confirma el patrón típico de comunicación IoT, y una cuenta root sin contraseña que convierte cualquier acceso a esos servicios en acceso administrativo completo. Nada de esto exigió tocar el dispositivo ni ejecutar una sola línea de su firmware — es la cantidad de información que se puede sacar de un binario estático con dos herramientas y algo de paciencia la que hace que el análisis estático valga la pena como primer paso, antes de plantearse siquiera encender el dispositivo real.