Emulación de firmware de dispositivo MIPS con Qemu
Durante un análisis de seguridad de un dispositivo embebido, que mostraba un comportamiento anómalo tras a una entrada de datos malformada en un servicio ftpd que escuchaba remotamente, se extrajo el firmware.
Las pruebas de fuzzing mostraban que este comportamiento anómalo podía estar relacionado con un desbordamiento de buffer pero tras un análisis inicial del binario MIPS no se encontraban pistas de ese vector de ataque.
Por todo ello, se decidió que la mejor estrategia era ejecutar el servicio vulnerable en un entorno emulado donde se pudiese disponer de herramientas adecuadas para su análisis (strace, gdb,..).
Haciendo uso del sistema de archivos recuperado, en formato squashfs, se procedió a ejecutar el firmware del dispositivo en un entorno virtual. El sistema operativo anfitrión es una distribución Kali 1.0 de GNU/Linux y el emulador utilizado es QEMU en su versión 1.1.2.
Para poder emular el firmware del dispositivo es necesario emular el procesador, la placa y los componentes. Por lo tanto, es necesario descargar una imagen compilada para MIPS:
wget https://people.debian.org/~aurel32/qemu/mips/debian_lenny_mips_standard.qcow2También es necesario descargar una configuración hardware tipo, en este caso la placa Malta:
wget https://people.debian.org/~aurel32/qemu/mips/vmlinux-2.6.26-2-4kc-maltaSe utilizará el módulo NBD, Network Blocking Device, para montar la imagen del kernel descargada y modificarla, añadiéndole el firmware del dispositivo.
Se habilita el módulo ‘NBD’, utilizando el parámetro ‘max_part’ establecido a 16. A continuación se emula la imagen utilizando el módulo específico de ‘qemu’ para ‘nbd’. Una vez la emulación se encuentra en ejecución debemos indicar al sistema, con el comando ‘partprobe’, que las nuevas particiones deben ser releídas. Por último, se monta la partición del sistema ‘guest’ en el sistema anfitrión para poder modificarla.
Imagen – Proceso de montado del sistema de ficheros de base
Una vez se dispone el sistema emulado debemos copiar el firmware del dispositivo directamente sobre la imagen montada:
cp -R ~/Desktop/squashfs-root/* /mnt/routerFS/Puede ser necesario restablecer el fichero /etc/passwd con el contenido por defecto:
0:unhDuTfeDCy7w:0:0:root:/home:/bin/sh
ftp:lnuHE/3WA3B2U:0:0:ftp user:/mnt:/bin/shPor último se emula la shell del dispositivo utilizando el siguiente comando:
qemu-system-mips -M malta -kernel vmlinux-2.6.26-2-4kc-malta -hda debian_lenny_mips_standard.qcow2 -append "root=/dev/hda1 console=ttyS0 rw init=/bin/busybox ash" -net nic -net tap -nographic
Imagen – Firmware del dispositivo funcionando en entorno virtual
De este comando cabe destacar que se establece una máquina/arquitectura tipo Malta, con kernel ‘vmlinux-2.6.26-2-4kc-malta’ y sistema de ficheros, la imagen modificada con el firmware del dispositivo añadida ‘debian_lenny_mips_standard.qcow2’:
-M malta -kernel vmlinux-2.6.26-2-4kc-malta -hda debian_lenny_mips_standard.qcow2También se debe configurar la emulación en modo lectura-escritura para permitir tanto la creación de logs y ficheros necesarios para la ejecución del sistema, como la escritura y edición de ficheros por parte del usuario:
-append "root=/dev/hda1 console=ttyS0 rw init=/bin/busybox ash"Se establece un fichero de inicio que será el encargado de cargar el sistema. Después de una serie de pruebas se consiguió cargar la ‘shell’ contenida en el entorno ‘busybox’ que gestiona el dispositivo.
-append "root=/dev/hda1 console=ttyS0 rw init=/bin/busybox ash"Por último, la conexión a la red de la emulación se establece de modo que crea una nueva interfaz en el anfitrión, que será a la que se conecta el sistema ‘guest’.
-net nic -net tapUna vez en este punto se puede ejecutar el proceso ftpd en el entorno virtualizado e interactuar con el remotamente, de la misma forma que se haría con el dispositivo físico, pero antes debe establecerse la dirección IP de la interfaz de salida, en este caso eth0:
# /bin/bftpd -d
Imagen – Ejecución del ‘daemon’ del servicio ftp en el entorno virtual.
Para comprobar que el servicio ftp está activo y funcional se realiza un escaneo de puertos remotamente:
Imagen – Escaneo de puertos muestra puerto ftp abierto
A partir de este momento, se pudieron concluir las pruebas de análisis con fuzzing y análisis de comportamiento. Lo que se descubrió es que el fallo estaba provocado por el espacio libre del dispositivo que, tras generar varias conexiones, se llenaba el log del sistema y provocaba una caída del dispositivo.
También se identificaron otros fallos de seguridad en otros servicios, explotables remotamente. Pero eso lo dejamos para otra ocasión.
Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/
En TarlogicTeo y en TarlogicMadrid.