README - sudo-chwoot.sh

Beschreibung

Dieses Skript ist ein Proof of Concept (PoC), der eine Technik zur Privilegieneskalation demonstriert, die eine theoretische Schwachstelle in 'sudo' ausnutzt (z. B. CVE-2025-32463).

Der PoC zwingt 'sudo', eine manipulierte .so-Bibliothek zu laden, indem er die '-R'-Funktion (chroot) und eine benutzerdefinierte Konfiguration der Datei nsswitch.conf ausnutzt.

Achtung: Dieses Skript dient ausschließlich Forschungs- und Testzwecken in kontrollierten Umgebungen. Es darf nicht auf Produktionssystemen oder auf Maschinen ausgeführt werden, die man nicht besitzt oder verwaltet.

Ziel

• Eine temporäre Umgebung mit einer benutzerdefinierten NSS-Konfiguration erstellen.
• Eine .so-Bibliothek in eine chroot-Struktur injizieren.
• 'sudo -R' verwenden, um das Laden der Bibliothek zu erzwingen und die Ausführung eines Befehls mit erhöhten Privilegien zu erreichen.

Wichtigste Änderungen

Die wichtigste Änderung gegenüber dem Originalskript ist die Integration der .so-Bibliothek direkt in das Skript im base64-Format.

Vorher: Die .so-Bibliothek musste als externe Datei im Dateisystem vorhanden sein und wurde kopiert mit: cp "$SCRIPT_DIR/woot1337.so.2" libnss_/woot1337.so.2

Jetzt: Die .so-Bibliothek ist im Skript im Textformat (base64) enthalten und wird zum Zeitpunkt der Ausführung dynamisch in das temporäre Dateisystem geschrieben, mit:

    cat << 'EOF' | base64 -d > libnss_/woot1337.so.2
    (base64-Inhalt hier)
    EOF

Struktur des temporären Dateisystems

Das Skript erstellt eine Struktur wie diese:

/tmp/sudowoot.stage.xxxxxx/ ├── woot/ │ └── etc/ │ ├── nsswitch.conf (manipulierte Konfiguration) │ └── group (Kopie von /etc/group) └── libnss_/ └── woot1337.so.2 (aus base64 dekodierte .so-Bibliothek)

Schritt-für-Schritt-Ablauf

1. Das Skript erstellt mit mktemp ein temporäres Verzeichnis.
2. Es legt den auszuführenden Befehl fest (Standard: /bin/bash oder die übergebenen Argumente).
3. Es erstellt die Verzeichnisstruktur woot/etc und libnss_.
4. Es schreibt eine nsswitch.conf-Datei, die das Laden eines benutzerdefinierten NSS-Moduls erzwingt: passwd: /woot1337
5. Es kopiert die Datei /etc/group in woot/etc.
6. Es dekodiert die .so-Bibliothek aus base64 und schreibt sie.
7. Es führt 'sudo -R woot $CMD' aus, das den angegebenen Befehl im Kontext des chroot startet, und dabei die veränderte NSS-Konfiguration und die .so-Bibliothek lädt.
8. Es entfernt das temporäre Verzeichnis.

Ausführung

Um das Skript ausführbar zu machen:

chmod +x sudo-chwoot.sh

Standardausführung:

./sudo-chwoot.sh
    - Startet eine Root-Shell (wenn der Exploit erfolgreich ist)

Ausführung mit Befehl:

./sudo-chwoot.sh id
    - Führt 'id' als Root aus (wenn der Exploit erfolgreich ist)

So generieren Sie den Base64-Payload

Um eine benutzerdefinierte .so-Bibliothek in das Skript zu integrieren, konvertieren Sie sie zunächst in base64:

base64 woot1337.so.2 > woot1337.so.2.b64

Kopieren Sie anschließend den Inhalt der .b64-Datei in das Skript in den Abschnitt:

cat << 'EOF' | base64 -d > libnss_/woot1337.so.2
(hier base64-Inhalt einfügen)
EOF

Sicherheitshinweise

Die Verwendung von .so-Bibliotheken, die dynamisch über NSS und chroot geladen werden, kann die Ausführung von beliebigem Code mit erhöhten Privilegien verursachen. Diese Art von Exploit sollte nur in Testumgebungen verwendet werden und niemals auf realen Systemen ohne ausdrückliche Genehmigung.

Haftungsausschluss

Dieses Skript wird ausschließlich zu Bildungs- und Forschungszwecken bereitgestellt. Der Autor übernimmt keinerlei Verantwortung für die missbräuchliche Verwendung des Codes oder für etwaige verursachte Schäden. Nur in Laborumgebungen verwenden, mit Bewusstsein und Genehmigung.