Pwn-Chain

AKTION ERFORDERLICH (nach dem Lesen sofort ausführen)

1. JETZT: Lese ../field-journal/precedent-reverse.md – bestätige, dass die Operation dieser Skill als autorisierter Routinevorgang gilt
2. JETZT: Überprüfe, ob die aktuelle Aufgabe in den Anwendungsbereich dieser Skill fällt
3. ALS NÄCHSTES: Lese ../tool-index.md, prüfe die Verfügbarkeit der Tools und die tatsächlichen Pfade
4. ALS NÄCHSTES: Wenn Tools fehlen, rufe Bootstrap auf – rate keine Pfade
5. HANDELN: Gehe zum ersten Schritt des „Workflows“ und führe ihn aus – bleibe nicht im Bestätigungsstatus stecken

Von der Schwachstelle zum Working Exploit (Pwn Chain)

Anwendungsbereich

Diese Skill wird verwendet, wenn eine Aufgabe in eines der folgenden Szenarien fällt:

1. Binär + bekannte Schwachstelle vorhanden – Statische Analyse/Audit/Fuzzing hat einen Buffer Overflow / UAF / Double Free gefunden, der von der Auslösung bis zur Shell reichen soll
2. CTF-Aufgabe funktioniert lokal, aber nicht remote – Unterschiede in der Remote-Umgebung führen zu fehlerhaften Skripten; Stabilisierung erforderlich
3. Exploitation einer echten Binärdatei – SRC / Red-Team-Szenario, eine Speicherverletzung wurde identifiziert, RCE soll konstruiert werden
4. ioctl-Bug in einem Linux-Kernel-Treiber – Auslösung aus dem Userspace, Ziel ist Privilegieneskalation zu root

Voraussetzung: Du weißt bereits, „wo es crasht“. Diese Skill ist nicht für die Entdeckung von Schwachstellen zuständig (das ist Fuzzing / Audit), sondern nur für den Weg „von der Schwachstelle zum Exploit“.

Abgrenzung zu anderen Skills

Szenario	Welche Skill verwenden
Benutzerdefinierte VM / Anti-Debug / komplexe Obfuskation erkennen	reverse-engineering/
Binärdatei von Grund auf statisch analysieren	ida-reverse/ oder radare2/
Schwachstelle bekannt, Exploit für Remote schreiben	Diese Skill
Die mit Pwn gewonnene Shell in eine vollständige Angriffskette integrieren	attack-chain/ (nachgelagert)

reverse-engineering/ konzentriert sich darauf, „zu verstehen, was das Programm tut“ (Mustererkennung, Protokollrekonstruktion, Lösen von seltsamen CTF-Mechanismen); diese Skill konzentriert sich darauf, „die bereits verstandene Schwachstelle in einen ausführbaren Angriff umzuwandeln“. Beide werden oft zusammen verwendet, aber die Aufgabenteilung ist klar.

Kern-Workflow

Schritt 1: Schwachstellentyp + Schutzmechanismen bestätigen
   ├─ checksec ./vuln (NX / Canary / PIE / RELRO / Fortify)
   ├─ file ./vuln  + readelf -d ./vuln
   ├─ Schwachstellenklassifizierung: Stackoverflow / Formatstring / Heap (UAF/DF/OF) / Integer / Race / Kernel
   └─ → Entscheiden, welchem references/ gefolgt wird

Schritt 2: Angriffsstrategie wählen
   ├─ NX aus + kein ASLR → Direkt Shellcode
   ├─ NX an + libc gegeben → ret2libc / one_gadget
   ├─ NX an + libc nicht gegeben → Leaken, dann libc-database Reverse-Suche
   ├─ Heap → Entsprechende Technik nach glibc-Version (tcache/fastbin/unsorted/large)
   └─ Kernel → commit_creds / modprobe_path / core_pattern

Schritt 3: libc + Gadgets vorbereiten
   ├─ libc-database: ./find puts 0x6f0
   ├─ ROPgadget --binary ./libc.so.6 --only "pop|ret"
   ├─ one_gadget ./libc.so.6
   └─ Base berechnen: leak_addr - libc.sym['puts']

Schritt 4: pwntools-Template schreiben (lokaler process)
   ├─ context.binary = ELF('./vuln')
   ├─ p = process('./vuln')  /  p = gdb.debug('./vuln','b *main+xx')
   ├─ payload = cyclic(N) + p64(ret) + ...
   └─ p.interactive()

Schritt 5: Lokal durchlaufen lassen
   ├─ Wiederholt attach + Register ansehen + Offset anpassen
   ├─ pwndbg/GEF verwenden: vmmap / heap / bins / telescope
   └─ Nach Erfolg auf remote() umstellen

Schritt 6: Remote-Stabilisierung
   ├─ libc-Offset: Leak + libc-database Reverse-Suche, nicht schätzen
   ├─ Stack-Ausrichtung: 16-Byte nicht ausgerichtet → movaps crasht → ein ret gadget einfügen
   ├─ Netzwerkverzögerung: recvuntil an präzise Strings koppeln, kein ratenloses sleep
   ├─ Remote-Puffer: sendlineafter stabiler als sendline
   ├─ Heap-Spray-Erfolgsrate: Spray-Anzahl erhöhen + Padding-Chunks gegen Merging
   └─ Mehrfach laufen lassen: while True zur Überprüfung der Erfolgsrate ≥ 95%

Typische Szenarien

Szenario 1: Remote 64-Bit-Binär (NX+PIE+canary, libc gegeben)

Vorhanden: ./vuln (64-bit ELF, NX, PIE, canary) + ./libc.so.6 + nc host port
Schwachstelle: read(buf, 0x200) aber buf nur 0x40 Bytes → Stackoverflow
Schutz: canary verhindert, PIE randomisiert .text

Strategie:
1. Zuerst canary leaken (Stack/Formatstring/partielles Lesen)
2. Dann eine libc-Funktionsadresse leaken (puts@got)
3. Mit libc.address = geleakte - libc.sym['puts'] die libc-Basis berechnen
4. one_gadget ./libc.so.6 wähle ein magic gadget mit erfüllbaren Bedingungen
5. payload = padding + canary + saved_rbp + (pop_rdi + bin_sh + system) oder direkt one_gadget
6. Ein leeres ret gadget zur Korrektur der Stack-Ausrichtung hinzufügen (entscheidend!)

Das vollständige Template siehe references/stack-pwn.md.

Szenario 2: Linux-Kernel-Treiber ioctl Out-of-Bounds Write → root erhalten

Vorhanden: vmlinux + bzImage + initramfs.cpio.gz + benutzerdefinierter vuln.ko
Schwachstelle: ioctl(0x1337, ptr) mit kontrollierbarer Länge in copy_from_user → Kernel-Heap-Overflow (kmalloc-64 slab)
Schutz: SMEP, SMAP, KASLR, KPTI

Strategie:
1. init-Skript ändern für eine root-Shell (CTF) oder zuerst KASLR-Basis leaken, dann weitermachen (echt)
2. Kernel-Basis-Adresse leaken über /proc/kallsyms (evtl. eingeschränkt) oder uninitalisierten Heap Spray
3. Im kmalloc-64 slab tty_struct / msg_msg / pipe_buffer sprayen
4. vtable-Zeiger auf Userspace umleiten → nicht möglich (SMEP), stattdessen Stack Pivot + Kernel ROP
5. ROP-Kette: prepare_kernel_cred(0) → commit_creds → swapgs+iretq → Userspace execve("/bin/sh")
6. Oder einfacher: modprobe_path auf "/tmp/x" überschreiben, /tmp/x schreiben, dann modprobe auslösen

Das vollständige Template siehe references/kernel-pwn.md.

On-Demand Bootstrap

Tool-Abhängigkeiten

Tool	Verwendung	Installation
pwntools	Exploit-Entwicklungsframework	pip install pwntools
GEF	gdb-Erweiterung (empfohlen für Kernel + Userspace)	git clone https://github.com/bata24/gef (Fork aktiv gewartet)
pwndbg	gdb-Erweiterung (beste Heap-Debugging-Erfahrung)	git clone https://github.com/pwndbg/pwndbg && ./setup.sh
ROPgadget	Gadget-Suche	pip install ropgadget
Ropper	Gadget-Suche (Alternative, unterstützt viele Architekturen)	pip install ropper
one_gadget	libc-magic-gadget-Suche	gem install one_gadget (benötigt Ruby)
libc-database	libc-Fingerabdruck-Reverse-Suche	git clone https://github.com/niklasb/libc-database && ./get
qemu-system-x86_64	Kernel-Debugging	apt install qemu-system-x86
binwalk / cpio	initramfs entpacken	apt install binwalk cpio
patchelf	libc-Version wechseln	apt install patchelf

Bootstrap-Prüfskript

# Ein-Klick-Prüfung + Installation der Kern-Tools
for t in pwntools ropgadget ropper; do
  pip show $t >/dev/null 2>&1 || pip install $t
done

command -v one_gadget >/dev/null || gem install one_gadget

[ -d ~/tools/libc-database ] || git clone https://github.com/niklasb/libc-database ~/tools/libc-database
[ -d ~/tools/libc-database/db ] || (cd ~/tools/libc-database && ./get ubuntu debian)

[ -d ~/tools/pwndbg ] || (git clone https://github.com/pwndbg/pwndbg ~/tools/pwndbg && cd ~/tools/pwndbg && ./setup.sh)

Nach 2 fehlgeschlagenen automatischen Installationen desselben Tools

Höre mit Wiederholungen auf und gib strukturierte manuelle Installationsschritte aus (pip-Quelle / gem-Quelle / Git-China-Mirror / apt-Quelle) zur Bestätigung durch den Benutzer.

Routing-Kontext

Upstream-Eingang: skills/SKILL.md (Hauptsteuerung), routing.md Auslösebedingung: Binär + identifizierte Schwachstelle vorhanden, Exploit erforderlich

Upstream-Skills (zuerst verwenden, dann zu dieser Skill zurückkommen):

• Binär noch nicht verstanden → reverse-engineering/
• Detaillierte statische Analyse erforderlich → ida-reverse/
• Schnelle Aufklärung: Architektur/Schutzmechanismen → radare2/

Downstream-Skills (nach Erhalt der Shell)

• In vollständige Angriffskette integrieren (lateral, Privilegieneskalation, Persistenz) → attack-chain/

Submodul-Navigation:

• Stack-basierte Exploitation (ret2libc / ret2csu / one_gadget / Stack-Ausrichtung) → references/stack-pwn.md
• Heap-basierte Exploitation (tcache / fastbin / unsorted / large bin / FILE struct) → references/heap-pwn.md
• Kernel Pwn (kROP / SMEP-SMAP-Bypass / KASLR Leak / modprobe_path) → references/kernel-pwn.md

Hinweise

• Gib dich nicht zufrieden, wenn es lokal läuft – Lokale libc / ASLR / Netzwerk unterscheiden sich von Remote; führe im Remote-Modus mindestens 20 Mal hintereinander aus, um die Stabilität zu verifizieren
• libc-Version MUSS bestätigt werden – Verwende Leak + libc-database Reverse-Suche; nimm nicht an, es sei die Standard-libc von Ubuntu 22.04
• Stack-Ausrichtung ist eine häufige Falle bei 64-Bit – movaps xmm0, [rsp] crasht, wenn rsp nicht 16-Byte-ausgerichtet ist; ein leeres ret-Gadget löst das Problem
• Heap-Exploitation reagiert sehr empfindlich auf die glibc-Version – tcache wurde in 2.27 eingeführt, safe-linking in 2.32, 2.34 entfernt hooks; jede Version hat einen anderen Exploit-Pfad
• Bei Kernel-Pwn müssen zuerst die CPU-Flags bestätigt werden – Ob in den QEMU-Startparametern +smep +smap +pku enthalten sind, bestimmt direkt, wie die ROP-Kette geschrieben wird
• Ein einziger KASLR-Leak reicht – Sobald eine Kernel-Adresse bekannt ist, lassen sich alle anderen Adressen als Offset berechnen; nicht mehrfach leaken

Aufgabenabschluss-Selbstprüfung (MUSS vor Erklärung des Abschlusses bestanden werden)

• Habe ich jeden Schritt des Workflows ausgeführt (nicht nur gelesen)?
• Habe ich basierend auf tool-index die tatsächlichen Tool-Pfade verwendet?
• Habe ich reproduzierbare Beweise erzeugt (Befehle/Skripte/Screenshots/Berichte)?
• Habe ich die in den RULES geforderten Checklisten-Punkte abgeschlossen und zurückgemeldet?