OWASP FSTM, etapa 4: Extracción del sistema de ficheros

Muchos dispositivos IoT ejecutan un sistema operativo Linux empotrado que puede encontrarse incluido en la imagen del firmware, junto con los sistemas de ficheros correspondientes. Este artículo trata la identificación y extracción del sistema de ficheros de una imagen de firmware.

El sistema de ficheros contiene los ejecutables, ficheros de configuración, scripts y servicios que ejecuta el sistema operativo, por lo que acceder a él permite un análisis en profundidad del funcionamiento y las características de un dispositivo IoT. El análisis puede dividirse en unas fases iniciales de reconocimiento, la identificación de los sistemas de ficheros existentes en el firmware y su extracción o montaje.

La cuarta etapa de la metodología OWASP Firmware Security Testing Methodology tiene como objetivo identificar los sistemas de ficheros que puedan encontrarse en la imagen de un firmware, detectar el formato y extraer sus contenidos para un posterior análisis.

En las etapas anteriores, se ha obtenido y analizado el firmware del dispositivo IoT objeto de estudio. Es habitual que en estas imágenes de firmware se encuentren sistemas Linux empotrados, adaptados a los dispositivos IoT, con software y sistemas de ficheros específicos. Por ello, una de las fases más importantes del análisis es la identificación y extracción del sistema de ficheros, que contendrá los ejecutables, ficheros de configuración, scripts y servicios del dispositivo.

El posterior análisis de este sistema de ficheros permite conocer con detalle el proceso de arranque y el funcionamiento del dispositivo, lo que puede llevar a identificar ejecutables o servicios vulnerables y delimitar la superficie de ataque.

Los sistemas de ficheros contenidos en el firmware pueden encontrarse en claro o pueden estar comprimidos o cifrados. En los primeros dos casos, solo será necesario identificar el formato y utilizar la herramienta adecuada para extraerlo o montarlo en el entorno de análisis. En caso de encontrar un sistema de ficheros cifrado, se necesitará más investigación acerca del firmware y del fabricante.

En las siguientes secciones del artículo se detallan los pasos generales necesarios para obtener los contenidos del sistema de ficheros. Adicionalmente, se presentan también algunas buenas prácticas y un conjunto de herramientas útiles para el análisis de los sistemas de ficheros.

Para los ejemplos se utilizan tanto las imágenes de firmware disponibles en el proyecto de IoTGoat como imágenes extraídas de otros dispositivos IoT para ilustrar algunas de las posibles situaciones.

Identificación del formato de la imagen de firmware

Antes de tratar de identificar las secciones con sistemas de ficheros, para entender sus contenidos, es útil identificar el formato de la imagen de firmware. La utilidad file, disponible en sistemas Linux, trata de averiguar el tipo de archivo que se le indica como argumento.

$ file hola.txt
hola.txt: ASCII text

Para ello, file ejecuta tres tipos de pruebas diferentes sobre el archivo: búsqueda de información con la llamada al sistema stat, búsqueda de magic numbers e identificación del lenguaje. En el artículo anterior puede encontrarse más información al respecto.

En casos en los que el sistema de ficheros aparezca al inicio de la imagen extraída, file puede ayudar a identificarlo:

$ file squashfs

Squashfs: Squashfs filesystem, little endian, version 4.0, xz compressed, 3946402

bytes, 1333 inodes, blocksize: 262144 bytes, created: Wed Jan 30 12:21:02 2019

Aunque, en la mayoría de los casos, el firmware comenzará con una imagen del bootloader o con una sección en blanco.

Búsqueda de firmas y números mágicos

La búsqueda de firmas y números mágicos que hagan referencia a tipos de archivos y formatos es una técnica muy útil en la identificación de las secciones de un firmware, como ya se comentó en el artículo anterior de la serie, especialmente para la búsqueda de sistemas de ficheros.

Una herramienta útil para ello es la conocida strings, que muestra las cadenas de caracteres que pueden interpretarse como imprimibles en un archivo:

% strings IoTGoat-raspberry-pi2.img
OWRT
…
hsqs5
7zXZ
0~*}
9E+_X{
JwG#g
5`ds
…

Para el firmware IoTGoat-raspberry-pi2.img, se encuentran las siguientes cadenas interesantes para la búsqueda del sistema de ficheros:

– hsqs: número mágico de sistemas de ficheros squashfs en little endian

– 7zXZ: parte del número mágico de ficheros comprimidos con LZMA2

También puede ser útil buscar números mágicos en hexadecimal, ya que, en algunos casos, los números mágicos no están formados por caracteres imprimibles. Para esto, se puede utilizar un editor hexadecimal, como hexedit, que permita la búsqueda de cadenas de bytes. Algunos números mágicos correspondientes a sistemas de ficheros habituales en dispositivos IoT son los siguientes:

– CramFS: 45 3D CD 28
– UBIFS: 31 18 10 06
– JFFS2: 85 19
– SquashFS: 73 71 73 68 (sqsh), 68 73 71 73 (hsqs)

En el mismo firmware IoTGoat-raspberry-pi2.img también se encuentran las etiquetas FAT16 y FAT32, pero estos sistemas de archivo no contienen ficheros de interés. Se utilizan para permitir escribir la imagen en un pendrive USB.

Otros números mágicos de interesantes pueden ser los relacionados con archives comprimidos, como los siguientes:

– zip: 50 4B 03 04 (PK..)
– rar: 52 61 72 21 1A 07 01 00 (Rar!….)
– 7z: 37 7A BC AF 27 1C (7z¼¯’.)
– xz: FD 37 7A 58 5A 00 (ý7zXZ.)

Al buscar una firma o número mágico, hay que tener en cuenta que las imágenes de firmware pueden estar en little endian o big endian, lo que afecta al orden de los bytes dentro de la firma.

Además, para ciertos sistemas de ficheros y formatos de compresión pueden encontrarse firmas no estándar. Muchos fabricantes de dispositivos utilizan firmas modificadas para indicar el formato. Por ejemplo, el firmware open source DD-WRT para routers puede utilizar la firma tqsh para indicar un sistema de ficheros SquashFS (big endian).

Estudio de entropía

En algunos casos, secciones dentro del firmware pueden encontrarse cifradas o comprimidas. En caso de estar comprimidas, es habitual encontrar una firma que identifique el formato, aunque no siempre existe. Sin embargo, identificar una sección cifrada requiere de otro tipo de análisis.

En teoría de la información, la entropía de una fuente de datos codificados es una medida de la cantidad media de información que se obtiene con cada carácter. Por el propio diseño de los algoritmos de cifrado, una muestra de información cifrada debe tener una entropía muy cercana a 1, el valor máximo, mientras que las secciones de código y datos sin cifrar suelen tener una entropía variable que se mueve entre 0,3 y 0,8. Los algoritmos de compresión también producen resultados con entropía alta. Un estudio de la entropía a lo largo de una imagen de firmware, por tanto, puede revelar secciones cifradas o comprimidas.

La herramienta de análisis de firmware binwalk cuenta con una función de estudio de la entropía, que produce un resultado similar al siguiente:

$ binwalk -E IoTGoat-raspberry-pi2.img

DECIMAL       HEXADECIMAL     ENTROPY
——————————————————————————–
0             0x0             Falling entropy edge (0.002664)
4718592       0x480000        Falling entropy edge (0.833424)
4997120       0x4C4000        Falling entropy edge (0.837713)
5095424       0x4DC000        Falling entropy edge (0.840429)
5341184       0x518000        Falling entropy edge (0.839935)
5570560       0x550000        Falling entropy edge (0.849444)
5636096       0x560000        Falling entropy edge (0.834985)
5799936       0x588000        Falling entropy edge (0.840472)
5849088       0x594000        Falling entropy edge (0.840706)
5996544       0x5B8000        Falling entropy edge (0.849569)
6275072       0x5FC000        Falling entropy edge (0.849042)
6373376       0x614000        Falling entropy edge (0.848267)
6553600       0x640000        Falling entropy edge (0.848343)

6701056       0x664000        Falling entropy edge (0.678427)
6914048       0x698000        Rising entropy edge (0.965015)
6930432       0x69C000        Falling entropy edge (0.619229)
7356416       0x704000        Falling entropy edge (0.831099)
7487488       0x724000        Falling entropy edge (0.842073)
7585792       0x73C000        Falling entropy edge (0.836944)
7667712       0x750000        Falling entropy edge (0.593631)
7798784       0x770000        Falling entropy edge (0.667160)
12058624      0xB80000        Rising entropy edge (0.950634)
12075008      0xB84000        Falling entropy edge (0.560117)
29360128      0x1C00000       Rising entropy edge (0.998248)

En el terminal, se muestran las direcciones donde se encuentran los flancos de subida y bajada de la entropía, que puede ser útil para delimitar las secciones. En la gráfica se aprecian varias secciones de información no cifrada al inicio y una sección de información cifrada o comprimida al final.

Si se accede con el editor hexadecimal hexedit a la sección de alta entropía, que, según los resultados de binwalk, empieza en la dirección 0x1C00000, se encuentran los siguientes datos:

La firma hsqs5, que ya se ha detectado en la búsqueda de cadenas, indica un sistema de ficheros squashfs en esa dirección, mientras que 7zXZ, unas líneas más adelante, indica información comprimida en formato xz. No se trata, por tanto, de una región cifrada, sino comprimida.

El siguiente ejemplo muestra un estudio de entropía para un firmware cifrado:

$ binwalk -E firmware

DECIMAL       HEXADECIMAL     ENTROPY
——————————————————————————–
0             0x0             Rising entropy edge (0.971675)
4716544       0x47F800        Rising entropy edge (0.976452)

En este caso, por un lado, sólo encontramos regiones de alta entropía apenas separadas entre sí. En hexedit, en la dirección 0x0, se encuentra algo de información no cifrada precediendo una región de información aleatoria, pero ninguna firma reconocible:

En la dirección 0x47F800, se encuentra una situación similar:

Estos casos indican una sección cifrada en el firmware. Para resolverlo y acceder a la información que contienen, será de gran utilidad hacer una investigación más profunda sobre el fabricante, formatos de cifrado que pueda utilizar, claves filtradas y versiones anteriores del firmware. En algunos casos, estas versiones no se encuentran cifradas y pueden ofrecer mucha información sobre el funcionamiento del dispositivo, incluso sobre el cifrado que utiliza.

En casos más complejos, se debe esperar a las fases de análisis dinámico y en tiempo de ejecución para obtener más información.

Extracción del sistema de ficheros

Dependiendo del tipo de sistema de ficheros que se encuentre en el firmware, se requerirán herramientas diferentes para proceder a la extracción del sistema de ficheros.

La herramienta binwalk trata de automatizar el proceso de detección y extracción para la mayor parte de sistemas de ficheros encontrados habitualmente en el firmware:

$ binwalk firmware

Con este mandato, se puede obtener código, archivos y sistemas de ficheros contenidos en las secciones del firmware según el motor de binwalk. Para ello, la herramienta recorre la imagen buscando coincidencias con números mágicos, firmas y cadenas que identifiquen secciones dentro del firmare. El siguiente es el resultado para el firmware de ejemplo de IoTGoat:

$ binwalk IoTGoat-raspberry-pi2.img

DECIMAL       HEXADECIMAL     DESCRIPTION
——————————————————————————–
4253711       0x40E80F        Copyright string: «copyright does *not* cover…
…
4329472       0x421000        ELF, 32-bit LSB executable, version 1 (SYSV)
4762160       0x48AA30        AES Inverse S-Box
4763488       0x48AF60        AES S-Box
…
12061548      0xB80B6C        gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
12145600      0xB953C0        CRC32 polynomial table, little endian
12852694      0xC41DD6        xz compressed data

…
29360128      0x1C00000       Squashfs filesystem, little endian, version 4.0, compression:xz, size: 3946402 bytes, 1333 inodes, blocksize: 262144 bytes, created: 2019-01-30 12:21:02

En este caso, binwalk detecta varios archivos comprimidos y un sistema de ficheros SquashFS, lo que coincide con las firmas que se han detectado previamente. Binwalk cuenta también con la función de extracción automática, que, al mismo tiempo que analiza los contenidos del firmware, trata de extraerlos. Esto se obtiene con el siguiente mandato:

$ binwalk -e firmware

La opción -e extrae los contenidos. Los resultados se almacenan en _firmware/filesystem_type, donde filesystem_type es el tipo de sistema de ficheros que la herramienta ha encontrado.

Binwalk es capaz de encontrar y extraer sistemas squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs e initramfs, pero, debido al método de análisis basado en firmas y al uso de diferentes herramientas para cada sistema de ficheros, también son frecuentes los falsos positivos. Estos son especialmente frecuentes con firmas cortas, de 1 o 2 bytes, que pueden aparecer en un firmware sin que esto signifique que se ha encontrado una sección con este formato, por lo que siempre se deben revisar los resultados de binwalk utilizando un editor hexadecimal, como hexedit, para inspeccionar la zona donde se ha detectado la firma, sobre todo, si no coinciden con la información recopilada con anterioridad.

Además, en ocasiones, binwalk puede introducir errores al intentar extraer una sección del firmware, por lo que, si al intentar descomprimir o montar el archivo se producen errores de formato, es útil realizar una extracción manual con la herramienta dd y descomprimir o montar el sistema de ficheros con la herramienta apropiada, como se explica más adelante.

Por ejemplo, en un firmware extraído de otro dispositivo IoT, binwalk arroja el siguiente resultado:

$ binwalk firmware.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
——————————————————————————–
5107699       0x4DEFF3        MySQL MISAM compressed data file Version 8
8532033       0x823041        Intel x86 or x64 microcode, sig 0xfc208000, pf_mask 0xf0c100, 1C18-01-30, rev 0x22000000, size 1796
8951861       0x889835        bix header, header size: 64 bytes, header CRC: 0x79079084, created: 1970-01-01 04:59:12, image size: 33591409 bytes, Data Address: 0x10183013, Entry Point: 0x102001F, data CRC: 0xE0208000, image type: Binary Flat Device Tree Blob image name: «»

La primera firma indica un fichero MySQL MISAM compressed data file, que, tanto por su ubicación como por su firma de sólo tres bytes (0xFE 0xFE 0x07), resulta sospechoso. Si se accede a la dirección con hexedit, se puede comprobar que el formato de los bytes anteriores y posteriores no se corresponde con el de un documento de este tipo:

Este tipo de errores es muy común. También es posible que binwalk no tenga registrada una firma modificada para un tipo de archivo común. En estos casos, buscar firmas propias del fabricante del dispositivo puede ser muy útil. También puede ocurrir que sea incapaz de extraer una sección, pero sí sea capaz de detectar su ubicación en el firmware. Para estos casos, se puede utilizar la información de binwalk o información específica sobre los formatos del fabricante para extraer manualmente la sección que contiene el sistema de ficheros con dd:

$ binwalk firmware.img

DECIMAL       HEXADECIMAL     DESCRIPTION
——————————————————————————–
0             0x0             uImage header, header size: 64 bytes, header CRC: 0x4EA03918, created: 2017-07-20 02:34:00, image size: 6164416 bytes, Data Address: 0x80000000, Entry Point: 0x80294000, data CRC: 0x8D40BD44, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: «Linux Kernel Image-al-2.32»
64            0x40            LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 2818364 bytes
851968        0xD0000         Squashfs filesystem, little endian, non-standard signature, version 3.0, size: 5309286 bytes, 781 inodes, blocksize: 65536 bytes, created: 2017-07-20 02:33:58

$ dd if=firmware.img of=squashfs bs=1 skip=851968 count=5309286
5309286+0 records in
5309286+0 records out
5309286 bytes (5,3 MB, 5,1 MiB) copied, 7,25504 s, 732 kB/s
dd if=firmware.img of=squashroot bs=1 skip=851968   0,78s user 6,40s system 98% cpu 7,259 total

Con la sección del sistema de ficheros separada, se debe utilizar la herramienta adecuada para extraer los archivos.

Para el formato squashfs, las herramientas unsquashfs o sasquatch, disponible en sistemas Linux, se pueden utilizar para descomprimir el sistema de ficheros:

$ sasquatch squashroot
SquashFS version [3.0] / inode count [781] suggests a SquashFS image of the same endianess
Non-standard SquashFS Magic: shsq
Parallel unsquashfs: Using 1 processor
Trying to decompress using default gzip decompressor…
Trying to decompress with lzma…
Detected lzma compression
688 inodes (901 blocks) to write

[=================================================================/] 901/901 100%

created 533 files
created 93 directories
created 155 symlinks
created 0 devices
created 0 fifos

Otras herramientas para formatos comunes son:

• cpio para formatos cpio
• jefferson para formatos jffs2
• uncramfs o cramfsck para formatos cramfs

Como resultado, se obtiene el sistema de ficheros en un directorio similar a squashfs-root.

También es posible encontrar imágenes de firmware que contienen, directamente, tablas de particiones con sistemas de ficheros incrustados. Esto puede darse en dispositivos que requieren del uso de sistemas como FAT, NTFS o ext. Para detectar este caso, es útil la herramienta fdisk:

$ fdisk -l IoTGoat-raspberry-pi2.img
Disco IoTGoat-raspberry-pi2.img: 31,76 MiB, 33306112 bytes, 65051 sectores
Unidades: sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico/físico): 512 bytes / 512 bytes
Tamaño de E/S (mínimo/óptimo): 512 bytes / 512 bytes
Tipo de etiqueta de disco: dos
Identificador del disco: 0x5452574f

Disposit.                          Inicio Comienzo  Final Sectores Tamaño Id Tipo
iotgoat/IoTGoat-raspberry-pi2.img1 *          8192  49151    40960    20M  c W95 FAT32 (LBA)
iotgoat/IoTGoat-raspberry-pi2.img2           57344 581631   524288   256M 83 Linux

En la imagen de ejemplo de IoTGoat, se observa una tabla de particiones con dos sistemas de ficheros directamente contenidos en el firmware: una partición FAT32 y una partición con la imagen del sistema Linux.

Se puede utilizar la herramienta kpartx para crear dispositivos virtuales (dispositivos loop) para las particiones contenidas en la tabla. Para crear dispositivos con las particiones en el firmware, se utiliza la opción -a:

$ sudo kpartx -a IoTGoat-raspberry-pi2.img
device-mapper: reload ioctl on loop0p2 (254:1) failed: Invalid argument
create/reload failed on loop0p2
$ lsblk -f
NAME      FSTYPE   FSVER LABEL UUID      FSAVAIL FSUSE% MOUNTPOINTS
loop0
├─loop0p1 vfat     FAT16       78D2-382B
├─loop0p1 vfat     FAT16       78D2-382B
└─loop0p2 squashfs 4.0

Aunque hay un error con la partición p2, se crean 2 dispositivos de loop: loop0p1 y loop0p2. Estas particiones se pueden montar en el árbol de directorios con la herramienta mount:

$ sudo mount /dev/mapper/loop0p1 /mnt/iotgoat/fat
$ ls -l /mnt/iotgoat/fat
total 9366
-rwxr-xr-x 1 root root   22493 mar 29  2020 bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root root   23588 mar 29  2020 bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root   23707 mar 29  2020 bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root   22342 mar 29  2020 bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root   52116 mar 29  2020 bootcode.bin
-rwxr-xr-x 1 root root     133 mar 29  2020 cmdline.txt
-rwxr-xr-x 1 root root   30725 mar 29  2020 config.txt
-rwxr-xr-x 1 root root   18693 mar 29  2020 COPYING.linux
-rwxr-xr-x 1 root root    2622 mar 29  2020 fixup_cd.dat
-rwxr-xr-x 1 root root    6695 mar 29  2020 fixup.dat
-rwxr-xr-x 1 root root 5817564 mar 29  2020 kernel.img
-rwxr-xr-x 1 root root    1494 mar 29  2020 LICENCE.broadcom
drwxr-xr-x 2 root root   10240 mar 29  2020 overlays
-rwxr-xr-x 1 root root  678372 mar 29  2020 start_cd.elf
-rwxr-xr-x 1 root root 2864164 mar 29  2020 start.elf

Al intentar montar la segunda partición, se produce un error como el siguiente:

$ sudo mount /dev/loop0p2 /mnt/iotgoat/squashfs
mount: /mnt/iotgoat/squashfs: /dev/loop0p2 ya está montado o el punto de montaje está ocupado.
dmesg(1) may have more information after failed mount system call.
$ sudo dmesg | grep -v audit | tail
[ 7453.070938] loop2: detected capacity change from 0 to 7707
[ 8259.648960] /dev/loop0p2: Can’t open blockdev
[ 8281.520899] /dev/loop0p2: Can’t open blockdev
[ 8304.153145] loop0: detected capacity change from 0 to 65051
[ 8304.171992]  loop0: p1 p2
[ 8304.172392] loop0: p2 size 524288 extends beyond EOD, truncated
[ 8304.240350] device-mapper: table: 254:1: loop0 too small for target: start=57344, len=524288, dev_size=65051
[ 8304.240355] device-mapper: core: Cannot calculate initial queue limits
[ 8304.240357] device-mapper: ioctl: unable to set up device queue for new table.
[ 8316.660386] /dev/loop0p2: Can’t open blockdev

En este caso, se ha detectado que existe un problema con el tamaño de la partición squashfs que impide montarla como un dispositivo loop. Sin embargo, si se extrae esta partición en un archivo, como se ha indicado en secciones anteriores, se puede montar el archivo con la herramienta squashfuse:

$ sudo squashfuse -d squashfs /mnt/iotgoat/squashfs
FUSE library version: 2.9.9
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
unique: 2, opcode: INIT (26), nodeid: 0, insize: 104, pid: 0
INIT: 7.36
flags=0x73fffffb
max_readahead=0x00020000
INIT: 7.19
flags=0x00000011
max_readahead=0x00020000
max_write=0x00020000
max_background=0
congestion_threshold=0
unique: 2, success, outsize: 40

En otro terminal, puede observarse el resultado:

$ sudo ls -l /mnt/iotgoat/squashfs
total 1
drwxr-xr-x  2 root root   0 ene 30  2019 bin
drwxr-xr-x  2 root root   0 ene 30  2019 dev
-rwxrwxrwx  1 root root 797 ene 30  2019 dnsmasq_setup.sh
drwxr-xr-x 18 root root   0 ene 30  2019 etc
drwxr-xr-x 11 root root   0 ene 30  2019 lib
drwxr-xr-x  2 root root   0 ene 30  2019 mnt
drwxr-xr-x  2 root root   0 ene 30  2019 overlay
drwxr-xr-x  2 root root   0 ene 30  2019 proc
drwxr-xr-x  2 root root   0 ene 30  2019 rom
drwxr-xr-x  2 root root   0 ene 30  2019 root
drwxr-xr-x  2 root root   0 ene 30  2019 sbin
drwxr-xr-x  2 root root   0 ene 30  2019 sys
drwxrwxrwt  2 root root   0 ene 30  2019 tmp
drwxr-xr-x  7 root root   0 ene 30  2019 usr
lrwxrwxrwx  1 root root   3 ene 30  2019 var -> tmp
drwxr-xr-x  4 root root   0 ene 30  2019 www

Este montaje del sistema de ficheros puede realizarse también para otros formatos, creando un dispositivo loop, ya sea con kpartx u otras herramientas como losetup o, directamente, mount, y montando el resultado en un punto del árbol de directorios.

También existen ciertos casos en los que el fabricante modifica las firmas y el formato de un sistema de ficheros para adaptarlo a sus dispositivos o para ofuscarlo y dificultar el análisis. En estos casos, las herramientas automáticas como binwalk, probablemente, no serán capaces de obtener resultados coherentes y será necesario realizar un análisis manual del archivo.

Los datos obtenidos sobre el fabricante durante las fases anteriores pueden ser de gran ayuda, así como el análisis del código que pueda haberse encontrado en el firmware. En algunos casos existen foros especializados en un tipo de dispositivos IoT en los que se puede encontrar información descubierta por otros investigadores e, incluso, herramientas de extracción, aunque no es común.

Después del trabajo de análisis y extracción del sistema de ficheros alojado en el firmware se puede pasar a la fase de análisis de sus contenidos, donde se analizará el funcionamiento y las características internas desde un punto de vista estático.

Conclusiones

Como se ha podido ver, la extracción y análisis del sistema de ficheros es una fase fundamental en el análisis del firmware de un dispositivo. Uno de los pasos que se pueden llevar a cabo cuando se lleva a cabo una auditoría de seguridad IoT.

Existen diferentes formatos que pueden contener un sistema de ficheros en la imagen de un firmware. Los más populares son los sistemas squashfs y cramfs, pero también es común encontrar sistemas jffs2, ubifs, rom, cpio o archivos comprimidos. También se pueden encontrar, en algunos casos, imágenes de sistemas de ficheros directamente incrustadas en el firmware.

Para analizar y lograr la extracción del sistema de ficheros son muy útiles las herramientas automáticas como binwalk, pero es necesario tener en cuenta que fallan frecuentemente y los resultados deben ser revisados manualmente, con otras herramientas como file, strings, hexedit, dd y fdisk.

En los casos en los que el firmware contenga secciones cifradas, será necesario profundizar en la investigación sobre el fabricante y las secciones en claro, o esperar a las fases de análisis dinámico y en tiempo de ejecución. Los resultados de esta etapa del proceso serán de gran ayuda para el análisis posterior, por lo que siempre merece la pena extraer toda la información que sea posible.

Referencias

• https://github.com/scriptingxss/owasp-fstm
• https://www.kali.org/tools/firmware-mod-kit/
• https://github.com/OWASP/IoTGoat/
• https://www.pentestpartners.com/security-blog/how-to-do-firmware-analysis-tools-tips-and-tricks/
• https://blog.k3170makan.com/2018/06/reverse-engineering-primer-unpacking.html