OWASP FSTM, etapa 5: Análisis del sistema de ficheros

El funcionamiento de muchos dispositivos IoT y empotrados depende de un sistema operativo que almacena los ficheros de configuración y ejecutables en un sistema de ficheros incrustado en el firmware. Este artículo trata el análisis del sistemas de ficheros de un firmware IoT, que puede brindar información crucial sobre el funcionamiento y las vulnerabilidades del dispositivo.

A continuación, se expone en diferentes secciones el proceso general del análisis de los contenidos de un sistema de ficheros. Comenzaremos por comprender el proceso de arranque y los servicios que se ejecutan para después dar una visión sobre el tipo de archivos más relevantes en los que centrar la búsqueda de información.

La quinta etapa de la metodología OWASP Firmware Security Testing Methodology tiene como objetivo obtener tanta información sobre el funcionamiento del sistema como sea posible sin llegar a ejecutar ningún archivo, un paso más a la hora de realizar una auditoría de seguridad IoT. Como resultado del proceso, se busca obtener una lista de archivos de configuración, claves y ejecutables de interés para fases posteriores. También, información sobre el proceso de arranque, los servicios que se ejecutan, usuarios por defecto y otros elementos de interés para el análisis del sistema de ficheros y la explotación de vulnerabilidades.

En la etapa anterior, se han extraído uno o varios sistemas de ficheros encontrados en el firmware del dispositivo. Estos sistemas de ficheros pueden tener diferentes propósitos y no siempre se encontrará en ellos el árbol de directorios de un sistema operativo tipo Unix. Sin embargo, es muy habitual encontrar este tipo de sistemas de archivos y, en estos casos, es fundamental estudiar en profundidad los elementos que contienen.

En primer lugar, en el árbol de directorios se encuentran los archivos de configuración y los ejecutables que llevan a cabo el proceso de arranque del sistema en el nivel de usuario, una vez ha terminado el arranque del kernel. El estudio de este proceso puede brindar información sobre los periféricos que espera el dispositivo, de los servicios que se ejecutan al inicio, los usuarios que se encuentran habilitados y la configuración inicial del dispositivo.

Tras entender el proceso de arranque, en muchos casos, se obtendrán pistas suficientes para continuar el análisis del sistema de ficheros y llegar a ejecutables y ficheros de interés. Tras agotar esta vía de análisis, se ejecuta la búsqueda automatizada de ficheros para su estudio. En este proceso se buscan archivos de configuración, claves privadas, contraseñas incrustadas en el firmware y ejecutables vulnerables y no estándar.

Por último, existen muchas herramientas que automatizan gran parte del trabajo, pero cuyos resultados deben ser siempre comprobados e investigados manualmente, ya que pueden producir falsos positivos o pasar por alto elementos importantes.

Las siguientes secciones detallan los pasos del análisis del sistema de ficheros y ofrecen consejos y ejemplos para llevarlos a cabo.

Proceso de arranque

El punto de partida del análisis es el estudio del proceso de arranque, que se refiere a las tareas que se ejecutan al entrar al userspace, tras el arranque del kernel.

Existen diferentes tipos de procesos de arranque en los sistemas Unix, pero, entre los más populares, se encuentran los siguientes:

• BSD: proceso de arranque clásico de los sistemas operativos BSD, como FreeBSD y OpenBSD, que ejecuta los scripts /etc/rc, /etc/rc.local, /etc/rc.conf y los scripts contenidos en /etc/rc.d, aunque depende de la versión del sistema
• System V: proceso de arranque muy popular, implementado en BusyBox, entre otros sistemas, que lee los contenidos del fichero de configuración /etc/inittab y ejecuta los scripts encontrados en el directorio /etc/init.d, según la configuración
• systemd: proceso de arranque típico de los sistemas Linux modernos, aunque no es habitual en dispositivos empotrados, que configura el arranque lanzando servicios según los ficheros de configuración en el directorio /etc/systemd/

Para continuar con el análisis del proceso de arranque, por tanto, es necesario identificar el tipo de proceso de arranque del dispositivo. Esta información puede mostrarse durante el arranque por el terminal, en los sistemas que disponen de uno en tiempo de ejecución, pero también puede encontrarse analizando el ejecutable init, que es el primero que se ejecuta al iniciarse el userspace. Este se encuentra habitualmente en /sbin/init, pero puede ser modificado con la opción init del kernel. Si no se encuentra la cadena init= en la imagen del firmware, probablemente el ejecutable se encuentre en /sbin/init.

Con BusyBox y System V, un caso muy habitual para dispositivos IoT, /sbin/init es realmente un enlace simbólico al ejecutable /bin/busybox, que lleva a cabo las operaciones de arranque:

$ ls -l sbin/init
lrwxrwxrwx 1 root root 14 ago 2 21:42 sbin/init -> ../bin/busybox

Con systemd, también, el fichero suele ser un enlace simbólico a /lib/systemd/systemd:

$ ls -l sbin/init
lrwxrwxrwx 1 root root 22 jul 13 16:24 sbin/init -> ../lib/systemd/systemd

En otros sistemas, /sbin/init es un ejecutable ELF:

$ file sbin/init
sbin/init: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-armhf.so.1, no section header

Se puede analizar con técnicas habituales del análisis de ejecutables: file, strings y herramientas de ingeniería inversa como Ghidra o IDA.

Una vez identificado el sistema de arranque, se procede al análisis de los archivos de configuración y scripts de inicio correspondientes. En este firmware de ejemplo, extraído de un dispositivo IoT, /sbin/init es un enlace simbólico al ejecutable de BusyBox y este hace referencia a los archivos /etc_ro/inittab y /etc/inittab, lo que confirma que el proceso de arranque es System V:

$ strings bin/busybox | grep inittab
Bad inittab entry at line %d
/etc_ro/inittab
reloading /etc/inittab

Analizando el contenido de /etc_ro/inittab, se encuentra que ejecuta el script /etc_ro/rcS y que inicia /bin/sh para el terminal ttyS1:

$ cat etc_ro/inittab
::sysinit:/etc_ro/rcS
ttyS1::respawn:/bin/sh

/etc_ro/rcS tiene los siguientes contenidos:

#!/bin/sh
#kent_chang 20091208, Enable USB power by turn GPIO_11 on and keep it on
##gpio l 11 4000 0 1 0 4000
mount -a
#cat /etc_ro/motd
mkdir -p /var/run
mkdir -p /var/log
mkdir -p /var/dev
mkdir -p /var/run/ppp
mkdir -p /proc/bus/usb
mkdir -p /proc/sys/kernel
mkdir -p /etc/mtab
mkdir -p /etc/modprobe.d
mkdir -p /etc/ppp/peers
mkdir -p /etc/Wireless/RT2870STA
mkdir -p /var/run/ppp
mkdir -p /var/spool
mkdir -p /var/spool/cron
mkdir -p /var/spool/cron/crontabs
makedevlinks.sh
nvram_daemon&
mkdir -p /var/log
ln -sf /etc_ro/fstab /etc/fstab
#ln -sf /etc_ro/udev /etc/udev
ln -sf /etc_ro/init.d /etc/init.d
ln -sf /etc_ro/Wireless/RT2870STA/RT2870STA.dat /etc/Wireless/RT2870STA/RT2870STA.dat

wan_dual_wan_backup=`nvram_get 2860 wan_dual_wan_backup`
wan_ip_assignment=`nvram_get 2860 wan_ip_assignment`
if [ $wan_dual_wan_backup -eq 99 -a $wan_ip_assignment -eq 3 ]; then
ln -sf /etc_ro/udev /etc/udev
else
mkdir -p /etc/udev
mkdir -p /etc/udev/rules.d
cp /etc_ro/udev/rules.d/70-* /etc/udev/rules.d/
cp /etc_ro/udev/udev.conf /etc/udev/
fi

#wan_ip_assignment=`nvram_get 2860 wan_ip_assignment`
modprobe lm
modprobe dwc_otg
# modprobe usb-storage
/bin/sh -x /etc/init.d/udev.sh > /dev/console
#nvram_daemon&
goahead >/dev/console&
#for telnet debugging
telnetd &

Entre los puntos de interés del script, se observa lo siguiente:

• Ejecuta el script makedevlinks.sh
• Inicia un servicio nvram
• Crea enlaces simbólicos de /etc_ro/fstab y /etc_ro/init.d en /etc
• Llama al script /etc/init.d/udev.sh y manda el resultado a /dev/console
• Inicia goahead y manda el resultado a /dev/console
• Inicia un servicio telnetd

Si se accede al archivo /etc/init.d/udev.sh, se encuentra que es este script el que inicializa los ficheros /etc/group y /etc/passwd, y que el usuario root puede iniciar sesión sin contraseña:

$ cat etc_ro/init.d/udev.sh
#!/bin/sh
#Tom add for 3G device manager 05-11-2009 begin
wan_3g_model=`nvram_get 2860 wan_3g_model`

…
echo “root::0:0:root:/root:/bin/ash” >> /etc/passwd
echo “bin:x:1:1:bin:/bin:/sbin/nologin” >> /etc/passwd
echo “lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin” >> /etc/passwd
echo “uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin” >> /etc/passwd
echo “ntp:x:38:38::/etc/ntp:/sbin/nologin” >> /etc/passwd
echo “ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin” >> /etc/passwd
echo “nobody:x:99:99:Nobody:/:/sbin/nologin” >> /etc/passwd
echo “Starting udev…” > /dev/console
#/sbin/udevd –daemon –debug-trace
/sbin/udevd –daemon
#/sbin/udevsettle
# get date/time is less then 2010/01/01
nowdate=”`date -u +\”%Y%m%d\”`”
[ “$nowdate” -lt “20110101” ] && date -u 010100002011.00 && echo “set date/time -> `date`”

wan_dual_wan_backup=`nvram_get 2860 wan_dual_wan_backup`
wan_ip_assignment=`nvram_get 2860 wan_ip_assignment`
[ $wan_dual_wan_backup -eq 99 -a $wan_ip_assignment -eq 3 ] && /sbin/3gd &
[ $wan_dual_wan_backup -ne 99 ] && killall -q 3gd
[ “`nvram_get 2860 wanConnectionMode`” -eq “USB-WLAN” ] && /sbin/3gd &
systime=`bc_nvram_get 2860 acc3g_systime`
date -s $systime
sync
date -u > /dev/console
date -u +”%m%d%H%M%Y.%S” >/etc/ntp.date
synctime=`cat /etc/ntp.date`
sync
#Tom add for 3G device manager 05-11-2009 end

Además del estudio de los servicios levantados en el inicio, los ficheros del directorio /etc_ro/init.d, son los ficheros de configuración de los servicios disponibles en el sistema:

$ ls -l etc_ro/init.d
total 248
-rwxr-xr-x 1 dummy dummy 191056 jul 20 2017 3g.sh
-rwxr-xr-x 1 dummy dummy 3650 jul 20 2017 cron.sh
-rwxr-xr-x 1 dummy dummy 2317 jul 20 2017 hostname.sh
-rwxr-xr-x 1 dummy dummy 5813 jul 20 2017 load_balance.in
-rwxr-xr-x 1 dummy dummy 189 jul 20 2017 load_balance_re.sh
-rwxr-xr-x 1 dummy dummy 6884 jul 20 2017 load_balance.sh
-rwxr-xr-x 1 dummy dummy 3337 jul 20 2017 ntp.sh
-rwxr-xr-x 1 dummy dummy 1934 jul 20 2017 static_ip.sh
-rwxr-xr-x 1 dummy dummy 2752 jul 20 2017 udev.sh
-rwxr-xr-x 1 dummy dummy 244 jul 20 2017 update_flash_systemtime.sh
-rwxr-xr-x 1 dummy dummy 3507 jul 20 2017 wan_l2tpc.sh
-rwxr-xr-x 1 dummy dummy 3136 jul 20 2017 wan_pppoe.sh
-rwxr-xr-x 1 dummy dummy 3329 jul 20 2017 wan_pptpc.sh
-rwxr-xr-x 1 dummy dummy 2541 jul 20 2017 wan_udhcpc.sh

Un estudio detallado de los servicios del sistema queda fuera del objetivo del artículo, pero puede ser de gran utilidad. Por ejemplo, en el fichero /etc_ro/init.d/cron.sh se observa una llamada al script /sbin/custom_config.sh:

$ cat etc_ro/init.d/cron.sh
#!/bin/sh

. /sbin/custom_config.sh
…

En el cual se encuentran algunos parámetros de configuración por defecto, entre los que se encuentra la contraseña por defecto de la consola de administración web:

$ cat sbin/custom_config.sh
CINFO_WEB_Admin_Password=”admin”
CINFO_Manufacturer_Title=”ALFA Networks”
CINFO_Manufacturer_Name=”ALFA Networks”
CINFO_Manufacturer_URL=”https://www.alfa.com.tw”
CINFO_Model_Title=”ALFA-R36″
CINFO_Model_Name=”ALFA”
CINFO_Model_Number=”R36″
CINFO_Model_Description=”USB Wi-Fi Router”
CINFO_Model_URL=”https://www.alfa.com.tw”
CINFO_AUTO_REBOOTING_TIME=”0″
CINFO_Country_Region=”5″
CINFO_Country_RegionABand=”7″
CINFO_Country_Code=””
CINFO_Host_Name=”R36″
CINFO_Domain_Name=”alfa.com.tw”
CINFO_NTP_Server_IP=”time.nist.gov”
CINFO_NTP_Sync=”6″
CINFO_AP_DEFAULT_CHANNEL=”1″
CINFO_AP_WMM_Capble=”0″

En este caso, con la información que se ha obtenido en el análisis del proceso de arranque es suficiente para tratar de encontrar un servicio telnet abierto o un puerto serie que permita abrir un terminal, en el que se podrá iniciar sesión como root sin necesidad de contraseña, o para tratar de acceder a la consola de administración web con la contraseña por defecto. Además, se han identificado ejecutables como goahead que están involucrados en el arranque de servicios y pueden ser de interés para análisis posteriores.

Como se puede observar, es habitual que el estudio del proceso de arranque lleve a un conocimiento en mucha mayor profundidad del funcionamiento del dispositivo y puede descubrir importantes vulnerabilidades, por lo que es importante obtener tanta información como sea posible sobre configuración inicial y servicios en el sistema.

Búsqueda de ficheros de interés

Tras analizar el proceso de inicio y con una idea más clara de los servicios disponibles y su funcionamiento en general, puede ser de gran utilidad realizar una búsqueda exhaustiva en el sistema de ficheros con el objetivo de encontrar ficheros de configuración, claves ejecutables, scripts y otros tipos de ficheros que no dependan directamente del proceso de arranque.

Algunos de los elementos de interés que se buscan durante esta fase son:

• Servidores desactualizados, inseguros o mal configurados.
• Credenciales predeterminadas o almacenadas de forma insegura, como nombres de usuario, contraseñas, claves de APIs o claves de SSH.
• Servicios de API predeterminados y detalles de su funcionamiento.
• Funcionalidades y servicios de actualización.
• Código fuente y scripts de inicio.
• Ejecutables compilados.

A partir de estos elementos, se pueden encontrar vulnerabilidades en el sistema que permitan la ejecución de diferentes tipos de ataque, como la intrusión al sistema, ejecución de código o denegación de servicio.

Durante el análisis, deben comprobarse los contenidos de los directorios de forma ordenada, empezando por las ubicaciones de interés en el sistema de ficheros, como pueden ser:

• /etc/passwd: listado de los usuarios del sistema y detalles sobre su configuración.
• /etc/shadow: contiene las contraseñas de los usuarios, almacenadas en forma de resumen hash junto con la salt criptográfica, y puede ofrecer información sobre los usuarios con permiso para iniciar sesión.
• /etc/group: listado de los grupos del sistema.
• /etc/fstab: listado de volúmenes que se montan en el inicio del sistema y su configuración.
• /etc/init.d: scripts de inicio, en caso de que no se hayan estudiado en la fase anterior.
• /etc/runlevels y /etc/inittab: configuración de los scripts de inicio, en caso de que no se hayan estudiado en la fase anterior.
• /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin y /usr/local/sbin: ejecutables y herramientas.
• /etc: otros ficheros de configuración.
• /var/log: logs de sistema y de aplicaciones.
• /root y /home: directorios de root y usuarios de sistema.

Tras una búsqueda inicial en las ubicaciones habituales, puede ser de gran utilidad ejecutar búsquedas automáticas con herramientas como find, que permite buscar archivos en base a patrones en todo el sistema de ficheros o en un directorio. Algunos criterios para la búsqueda de ficheros de interés son los siguientes:

• Ficheros relacionados con SSL y claves de cifrado, con extensión .pem o .crt
• Ficheros de configuración, con extensión .con
• Scripts, con extensión .sh
• Ficheros con permisos de ejecución.
• Ficheros “binarios”, sin indicación de formato, con extensión .bin
• Servidores web conocidos, como nginx o apache.
• Ejecutables y servicios que expongan interfaces de red como ssh, telnet, tftp o dropbear.

En una búsqueda más exhaustiva, se pueden inspeccionar los contenidos de los ficheros de configuración en busca de contenidos de interés como pueden ser:

• Palabras clave como admin, pass, password, remote o key.
• Funciones de C vulnerables o susceptibles de ser mal utilizadas, como gets, strcpy, stpcpy, strcat, printf o sprintf.
• URLs, direcciones IP o direcciones de correo electrónico.

En el firmware de ejemplo, al realizar una búsqueda de archivos con extensión .sh, se encuentran diferentes archivos interesantes:

$ find . -name ‘*.sh’
./etc_ro/init.d/static_ip.sh
…
./sbin/config.sh
./sbin/chpasswd.sh
./sbin/hotspot.sh
./sbin/pppoe.sh
./sbin/vpn-passthru.sh
./sbin/automount.sh
…

Entre ellos, /sbin/config.sh contiene la configuración por defecto del dispositivo, donde puede hallarse la configuración del terminal serie que se detectó durante el análisis del arranque:

$ cat sbin/config.sh
CONFIG_MIPS=y
…
CONFIG_CMDLINE=”console=ttyS1,115200n8 root=/dev/mtdblock4″
…

La línea de configuración mostrada indica que el terminal serie ttyS1 recibe conexiones con una velocidad de 115.200 baudios.

Herramientas de automatización

Para esta tediosa tarea de búsqueda e identificación, hay disponibles herramientas públicas que ejecutan un análisis automatizado de los contenidos del sistema de ficheros de un firmware, como es el caso de firmwalker, FACT o EMBA.

Firmwalker

Firmwalker es una herramienta de software libre desarrollada en bash script para automatizar la búsqueda de elementos de interés en un sistema de ficheros de un firmware extraído o montado en el entorno de análisis. Se puede encontrar en el repositorio del proyecto en GitHub.

Su uso básico es tan simple como la ejecución del siguiente mandato:

$ ./firmwalker filesystem_root

Donde filesystem_root es la raíz del sistema de ficheros. El resultado es similar al siguiente:

$ ./firmwalker.sh ~/firmware/squashfs-root
***Search for password files***
##################################### passwd
t/usr/bin/passwd

##################################### shadow

##################################### *.psk
…

***Search for files***
##################################### *.conf
t/etc_ro/udev/udev.conf
t/etc_ro/lld2d.conf
t/etc_ro/radvd.conf
t/etc_ro/miniupnpd.conf
…
——————– pwd ——————–
t/bin/wpa_supplicant
t/bin/openssl
t/bin/busybox
t/lib/udev/path_id
t/lib/libuClibc-0.9.28.so
t/usr/sbin/msmtp
…

——————– telnet ——————–
t/etc_ro/l7-protocols/telnet.pat
t/etc_ro/rcS
t/bin/busybox
t/lib/libcrypto.so.0.9.8
…

El resultado arrojado por la herramienta, como en todos los casos de herramientas automáticas, debe ser considerado como indicaciones sobre algunos puntos de interés en el firmware, que deberán ser analizados manualmente y con mayor profundidad para la búsqueda de vulnerabilidades. Sirve como un buen punto de partida para un análisis de los elementos que se muestran, no como un informe final.

The Firmware Analysis and Comparison Tool

The Firmware Analysis and Comparison Tool o FACT es otra herramienta de análisis que tiene como objetivo automatizar la mayor parte del proceso completo de análisis de un firmware, incluyendo la identificación de contenidos, la extracción del sistema de ficheros y su análisis. El proyecto se puede encontrar en el repositorio de Github.

FACT tiene funciones de detección de claves y certificados, detección de implementaciones débiles listadas en el Common Weakness Enumeration (CWE) y comparación de versiones de ficheros conocidos, entre otras

El framework está disponible en la imagen de docker FACT_docker o puede ser instalado mediante un script. Se inicia ejecutando start_all_installed_fact_components como root y se accede a través de una web situada en los puertos 5000 y 80: https://localhost:5000 y https://localhost.

$ sudo ./start_all_installed_fact_components

Embedded Analyzer

Embedded Analyzer o EMBA es otro framework, este desarrollado en bash scripting, destinado a automatizar el proceso completo de análisis de firmware. El proyecto se encuentra disponible en el repositorio de GitHub (si quieres consultarlo pincha aquí).

El proyecto EMBA condensa el uso de múltiples herramientas disponibles previamente y cuenta con múltiples funcionalidades, como la extracción del sistema de ficheros, análisis estático de ejecutables o la identificación de vulnerabilidades conocidas.

Para su instalación, EMBA recomienda el uso de una máquina virtual de Kali Linux o Ubuntu y provee un script de instalación, de descarga una imagen de docker sobre la que se ejecuta el framework. La ejecución se realiza con el siguiente mandato:

$ sudo ./emba.sh -l ./log_file -f /firmware_image

También se encuentra disponible EMBArk, una adaptación de EMBA con una interfaz web orientada a un entorno empresarial.

En los dispositivos IoT que cuentan con un sistema operativo y contienen un sistema de ficheros en el firmware, que son mayoritarios, el análisis del sistema de ficheros es fundamental para entender el funcionamiento y las posibles vulnerabilidades.

Aunque existen herramientas automáticas para realizar el reconocimiento inicial de los puntos de interés, el análisis manual, con ayuda de herramientas como find, file, strings y algún editor hexadecimal, sigue siendo necesario para encontrar las vulnerabilidades a las que la automatización no puede llegar.

En particular, el análisis pormenorizado del proceso de arranque del dispositivo arroja una gran cantidad de información sobre su funcionamiento, los servicios que se ejecutan e, incluso, posibles vías de entrada.

En última instancia, la experiencia y el conocimiento del analista son fundamentales para identificar y seguir las pistas que pueden revelar configuraciones inseguras, servicios o ejecutables vulnerables y otros fallos de seguridad.

Referencias

• https://github.com/scriptingxss/owasp-fstm
• https://github.com/craigz28/firmwalker
• https://github.com/fkie-cad/FACT_core
• https://github.com/e-m-b-a/emba