🔒 How to hack a system —
local privilege escalation and prevention

🧭 Eine einfache Kill Chain – vom lokalen User zum Root

Typische Schritte sind:

1. Discovery & Scanning (lokal):
   Der Mitarbeitende inventarisiert ohne Administratorrechte die installierten
   Pakete (z. B. via dpkg-query) und prüft sie automatisiert gegen
   offizielle Schwachstellendatenbanken.
2. Research & Weaponization (extern):
   Für gefundene CVEs werden PoCs/Exploits recherchiert. Viele davon sind frei zugänglich.
3. Exploitation (lokal):
   Der Exploit wird auf dem Zielsystem ohne zusätzliche Rechte ausgeführt – zielt aber auf eine Schwachstelle,
   die es erlaubt, die Privilegien zu erhöhen.
4. Impact & Persistence:
   Nach erfolgreicher Eskalation folgen z. B. das Anlegen persistenter Zugänge, das Auslesen sensibler Daten oder laterale Bewegungen.

Wichtiger Hinweis: Das ist eine defensive Darstellung aus Forschung & Härtung. Keine Anleitung zum Missbrauch.
Tests bitte ausschließlich in isolierten, autorisierten Umgebungen durchführen.

1. 🔍 Discovery & Scanning (lokal)

Ich beginne das Experiment ganz bewusst mit minimalen Rechten: ein frisch
erstellter, normaler Benutzeraccount ohne Mitgliedschaft in administrativen
Gruppen, keine sudo-Rechte und keine zusätzlichen Tools. Die Umgebung ist eine
isolierte VM mit Ubuntu MATE (x86_64) in VirtualBox, ein aktueller
generischer Linux-Kernel, standardmäßige Paketquellen und ein Desktop, damit
ich die Ergebnisse bequem als Dateien auf dem Schreibtisch ablegen kann.

Das System ist absichtlich „realistisch-chaotisch“ gehalten: einige Pakete sind
frisch, andere stammen aus Basis-Images oder wurden bereits früher aktualisiert.
Genau so entstehen in der Praxis die Versionen-Mischungen, die später
sicherheitsrelevant sind.

🖥️ Das Test-System

Genau an diesem Punkt verschafft man sich zuerst einen Überblick: Welche Software
ist überhaupt installiert? Welche Versionen laufen? Welche davon sind potenziell angreifbar?
In der „Discovery“-Phase geht es nicht um Tricks, sondern um sauberes Bestandsmanagement –
einmal die Realität des Systems erfassen, bevor man irgendetwas bewertet oder gar ausprobiert.

Ein normaler Benutzer kann dafür mehr als genug sehen: Paketnamen, Versionsstände,
Basisinfos zum Betriebssystem und Hinweise auf lokal vorhandene Werkzeuge.

🔁 Automatisierung

Damit das reproduzierbar und nicht fehleranfällig ist, habe ich diesen Schritt automatisiert:
Ein kleines Skript, das ohne Adminrechte läuft, liest die installierten Pakete samt Versionsnummern aus,
gleicht sie gegen eine offizielle Schwachstellen-Datenbank ab und reichert gefundene CVE-Einträge mit Schweregraden an.
Das Ganze produziert einen klaren Report, den man archivieren, vergleichen oder direkt in ein SIEM einspeisen kann.

🧩 Was das Skript in dieser Phase konkret macht

• Inventar erfassen: Per dpkg-query werden Paketname und Versionsstand ausgelesen – rein lesend, ohne Änderungen am System.
  Zusätzlich wird die OS-Version (z. B. „Ubuntu MATE 25.04“) für die Kopfzeile notiert.
• Schwachstellen abgleichen: Für jedes Paket/Version-Paar fragt das Skript die OSV-API (Open Source Vulnerabilities) im Batch-Modus ab.
  OSV liefert zu bekannten Paketständen die passenden CVE-IDs zurück – also die „Katalognummern“ der Schwachstellen.
• Kritikalität bestimmen: Zu jeder CVE zieht das Skript die CVSS-Bewertung aus der NVD (CVE-API 2.0).
  Falls dort (zeitweise) nichts vorliegt, dient CIRCL als Fallback. So bekommt jede gefundene Schwachstelle eine klar verständliche Einstufung wie
  critical, high, medium oder low.
• Ergebnis aufbereiten: Am Ende entsteht ein Report im Format
  Name | Version | CVE | Kritikalität – gut lesbar als Text und zusätzlich als CSV für weitere Auswertungen.

Diese Vorgehensweise hat drei Vorteile: Sie ist minimalinvasiv (keine Installation, keine Rechte),
offiziell fundiert (OSV/NVD statt Foren-Rätselraten) und skalierbar (in Sekunden wiederholbar, auch auf anderen Hosts).

📝 Was dabei herauskam – und warum das relevant ist

🔎 Ergebnis meines Schwachstellen-Scans

In unserem konkreten Lauf fiel eine Schwachstelle in sudo auf: Eine installierte
(bzw. lokal ausführbare) Version entsprach einem bekannten, noch nicht gepatchten Stand, für den
öffentlich dokumentierte Privilege-Escalation-CVEs existieren. Genau das ist sicherheitsfachlich
der kritische Moment: Ein rein lokaler Benutzer mit minimalen Rechten weiß nun zielgenau,
welche Komponente verwundbar ist – und kann im nächsten Schritt nach passenden Exploits suchen.

Im folgenden Kapitel zeige ich deshalb, wie man (ausschließlich im Labor, auf der VM) für die
identifizierte sudo-Schwachstelle einen Proof-of-Concept bzw. Exploit recherchiert und ausführt –
mit dem Ziel, Root-Rechte zu erlangen. Das demonstriert, wie kurz der Weg vom sichtbar ungepatchten
Paket zur erfolgreichen Privilegieneskalation tatsächlich ist – und warum durchgehendes Patching sowie
eine Überwachung per SIEM (die sowohl den lokalen Scan als auch den anschließenden Exploit-Download sehen kann)
in Unternehmen unverzichtbar sind.

2. 🧾 Research & Weaponization (extern)

In Phase 2 wird die gefundene Schwachstelle systematisch analysiert, auf öffentlich
verfügbare Exploits geprüft und — falls vorhanden — für eine mögliche Weaponization bewertet.
Für CVE-2025-32463 (Local Privilege Escalation in sudo durch fehlerhafte chroot-Handhabung)
lässt sich das folgendermaßen zusammenfassen:

🔧 Technische Vertiefung (high-level)

Die Schwachstelle liegt in der Art und wie sudo die chroot-Funktionalität und zugehörige Pfad-/Rechteprüfungen implementiert.
Unter bestimmten Konfigurationen oder bei manipulierten Eingaben kann ein lokaler, nicht-privilegierter Benutzer Code oder Dateisystemreferenzen so einbringen,
dass nach Ausführung durch sudo Privilegien auf root eskaliert werden. Die fehlerhafte Validierung von Pfaden und Zuständen
innerhalb des chroot-Kontexts ist der Kern des Problems. (Das ist bewusst abstrakt gehalten — keine Exploit-Schritte.)

⚠️ Exploit-Verfügbarkeit und Aufwand

Öffentlich dokumentierte Proof-of-Concepts und Repositorien (z. B. Repos, die die Schwachstelle benennen)
sind bereits erschienen. Durch einfache Recherche (Repository-Namen, CVE-ID oder Suchbegriffe wie
„CVE-2025-32463 sudo chroot exploit“) ist ein praktischer PoC schnell auffindbar. Das bedeutet:
Ein Angreifer mit Basiswissen und Zugriff auf eine verwundbare Maschine kann relativ zügig einen vorhandenen
Exploit nutzen — es handelt sich also nicht notwendigerweise um eine nur theoretische Lücke.

3. 🛠️ Exploitation (lokal)

In dieser Phase wird der bereits recherchierte Proof-of-Concept (PoC) auf dem Zielsystem
eingesetzt, um die Schwachstelle tatsächlich auszunutzen und Privilegien zu eskalieren.
Im Fall von CVE-2025-32463 (sudo chroot-Fehler) lässt sich das Vorgehen auf einem System wie folgt beschreiben:

🎯 Ziel und Anspruch

Das Ziel der Exploitation ist es, vom Status eines lokalen, nicht-privilegierten Benutzers
aus eine Root-Privilegien-Kontext zu erreichen, indem eine Fehlfunktion in der chroot-Behandlung
von sudo ausgenutzt wird. Die Exploitation verlangt keinen Netzwerkzugang — ein lokaler
Account auf dem betroffenen System reicht aus.

Voraussetzungen

• Eine verwundbare sudo-Version (laut Bekanntgabe typischerweise innerhalb eines bestimmten Versionsfensters).
• Lokaler Zugang zum System unter einem Nicht-Root-Benutzerkonto.
• Die Systemkonfiguration und -zustände, die die fehlerhafte Pfad-/Rechtebehandlung innerhalb eines chroot-Kontexts ermöglichen, müssen erfüllt sein
  (konkrete Details dazu sind aus Sicherheitsgründen nicht angegeben).

Bei der Untersuchung zeigte sich schnell, wie ernst die Lage ist: ein in der Wildnis verfügbarer
Proof-of-Concept ließ sich in einer kontrollierten Testumgebung ausführen und führte dort tatsächlich
zur Erhöhung von Rechten auf root. Ein Screenshot dokumentiert dieses Ergebnis — das heißt
nicht nur, dass die Theorie stimmt, sondern dass die Schwachstelle praktisch ausnutzbar ist, wenn die
betroffenen Bedingungen erfüllt sind. Das macht die Lücke zu einem akuten Problem für alle Betreiber
von Systemen mit verwundbaren sudo-Versionen.

Warum ist das so gefährlich? Root-Rechte geben einem Angreifer faktisch die komplette Kontrolle über ein System:
Zugriff auf vertrauliche Daten, Manipulation oder Zerstörung von Dateien, Abschaltung oder Umgehung von Schutzmechanismen
und die Möglichkeit, dauerhaft versteckte Zugangspfade einzurichten. Einmal erlangt, lassen sich Logs und Spuren verändern,
Backups kompromittieren und weitere Systeme im Netzwerk attackieren — die Folgen reichen also weit über den
ursprünglich kompromittierten Host hinaus. Besonders bedrohlich ist zudem, dass funktionierende PoCs öffentlich verfügbar sind;
das senkt die Hürde für Angreifer erheblich und erlaubt eine einfache Automatisierung von Angriffen gegen viele Systeme gleichzeitig.

4. ⚠️ Impact & Persistence

Wenn eine lokale Schwachstelle wie CVE-2025-32463 erfolgreich ausgenutzt wird, endet die Story nicht mit
dem bloßen „Ich habe Root“. Die eigentliche Gefahr liegt in den Auswirkungen und in der Fähigkeit eines Angreifers,
seinen Zugriff zu verankern — also Persistence herzustellen — sodass die Kompromittierung lange bestehen bleibt,
unentdeckt bleibt und sich weiter auswirkt.

Root-Rechte öffnen die Tür zu allem: vertrauliche Daten, Systemkonfigurationen, Netzwerkzugänge und Credentials sind
plötzlich frei verfügbar. Ein Angreifer kann Prozesse manipulieren, Dienste neu konfigurieren, Backups verändern oder
gänzlich löschen — und damit die Wiederherstellung extrem erschweren.

🔒 Persistence bedeutet in der Praxis:

• Dauerhaft eingerichtete Dienste oder veränderte Startskripte
• Hinterlegte SSH-Keys oder subtile Änderungen an Authentifizierungsmechanismen
• Manipulation oder Löschung von Logs und Prüf-/Überwachungsdaten

Dadurch steigt die Zeit bis zur Entdeckung dramatisch, und die Kosten für Aufklärung und Wiederherstellung explodieren.
Aus Sicht eines Unternehmens heißt das: ein einzelner erfolgreicher LPE (Local Privilege Escalation) kann schnell zur
kompletten, langfristigen Kompromittierung einer Umgebung werden.

Deshalb ist Patchen so wichtig — und zwar nicht als lästige Pflicht, sondern als zentrale, proaktive Verteidigungsmaßnahme.
Patches schließen bekannte Einfallstore, reduzieren die Angriffsfläche und verhindern, dass öffentlich verfügbare PoCs oder
automatisierte Scans Erfolg haben. Je länger bekannte Schwachstellen ungepatcht bleiben, desto größer die Wahrscheinlichkeit,
dass ein Angreifer (oder ein automatisiertes Botnetz) genau diese Lücke ausnutzt. Regelmäßiges, planbares Patch-Management minimiert dieses Risiko,
verkürzt die Fenster, in denen Systeme verwundbar sind, und ist häufig deutlich kostengünstiger als die Nachbearbeitung eines Vorfalls.

🛰️ Monitoring & SIEM: Wie man das Risiko reduziert

Hier kommt Monitoring und ein integriertes SIEM ins Spiel: Nur wer weiß, welche Softwareversionen wo laufen und wer
verdächtige Aktivitäten zeitnah erkennt, kann schnell reagieren. Meine Open-Source-SIEM-Architektur auf Basis von
Wazuh, speziell zugeschnitten auf KMU und kostengünstig ausgelegt, adressiert genau diese Bedürfnisse.

Neben der klassischen Log-Korrelation und Verhaltensanalyse bietet der Wazuh-Agent auch Inventarisierung und Bewertung der
installierten Software. Das erlaubt automatisierte Workflows, die regelmäßig prüfen, welche Systeme welche Versionen verwenden,
welche Patches fehlen und welche Priorität die jeweiligen Updates haben. So lässt sich ein effizientes Patch-Lifecycle aufbauen:

1. Erkennung →
2. Priorisierung →
3. Rollout →
4. Validierung

Ein solcher Workflow reduziert nicht nur manuellen Aufwand, sondern ermöglicht auch nachvollziehbare Audits und schnelle Reaktion
im Verdachtsfall. Wenn ein System bereits kompromittiert wurde, hilft die Kombination aus Inventarisierung, Integritätsprüfungen
und Log-Korrelation dabei, das Ausmaß zu begrenzen, Indikatoren für Kompromittierung zu identifizieren und geeignete Sofortmaßnahmen
zu koordinieren (Isolation, Forensik-Snapshot, Credential-Rotation, Neuinstallation falls nötig).

Für KMU ist das besonders wertvoll, weil begrenzte Ressourcen gezielt dort eingesetzt werden können, wo das Risiko am größten ist.

🤝 Angebot: Beratung & Unterstützung

Wenn Sie möchten, berate ich gern beim Aufsetzen oder Optimieren eines solchen, kosteneffizienten
Patch- und Monitoring-Workflows mit Wazuh — von der Agent-Rollout-Strategie über die Erstellung von Regeln
zur Erkennung ungewöhnlicher sudo-Aktivitäten bis hin zur Integration in Ticket- und Update-Prozesse.

Zusammen lässt sich so das Risiko von lokalen Eskalationen deutlich senken und die Erholungszeit nach einem Vorfall massiv reduzieren.