Linux Privilege Escalation: Vektoren und Härtung für Verteidiger

Privilegienerweiterung ist der Moment, in dem ein begrenzter Zugang auf einem Linux-Host in vollständige Kontrolle umschlägt. Für ein Blue Team ist dies eine der folgenschwersten Phasen eines Einbruchs: Ein Angreifer, der als unprivilegiertes Dienstkonto landet und dann zu root wird, kann die Protokollierung deaktivieren, Persistenz installieren und sich seitlich durch die Umgebung bewegen. Dieser Artikel verfolgt einen Ansatz nach dem Prinzip Verstehen, um zu verteidigen. Wir beschreiben, wie Eskalation konzeptionell funktioniert, kartieren die Oberflächen, die Angreifer abtasten, und verbringen dann die meiste Zeit mit dem, was für Verteidiger zählt: der Telemetrie, die Eskalationsversuche sichtbar macht, und der Härtung, die die Gelegenheit von vornherein beseitigt.

Was Privilegienerweiterung wirklich bedeutet

Unter Linux wird Autorität über Benutzer- und Gruppenidentität, die effektive UID/GID eines Prozesses und einen Satz feingranularer Kernel-Capabilities ausgedrückt. Ein Prozess erbt in der Regel die Rechte des Kontos, das ihn gestartet hat. Privilegienerweiterung ist jede Technik, die Code mit mehr Autorität ausführen lässt, als ihm gewährt wurde. Es gibt zwei große Familien. Vertikale Eskalation führt von einem niedrig privilegierten Benutzer zu einem höheren, meist zu root. Horizontale Eskalation bewegt sich seitwärts zu einem anderen Benutzer derselben Privilegienstufe, um an Daten oder Sitzungen zu gelangen. Beides ist relevant, doch die vertikale Eskalation zu root fürchten Verteidiger am meisten, weil root die Regeln des Systems umschreiben kann, einschließlich der Kontrollen, die es fangen sollen.

Das entscheidende gedankliche Modell für einen Verteidiger lautet, dass Eskalation selten ein einzelner magischer Exploit ist. Fast immer handelt es sich um den Missbrauch eines legitimen Mechanismus, der zu lose konfiguriert wurde: ein Hilfsprogramm mit zu viel Macht, ein geplanter Auftrag, der als privilegierter Benutzer läuft, ein Dienstkonto, das seine eigene Konfiguration bearbeiten kann. Wer den Mechanismus versteht, kann seinen Missbrauch erkennen und die lose Konfiguration entfernen.

Wie Eskalation auf hoher Ebene funktioniert

Ein Angreifer, der auf einem Host gelandet ist, führt lokale Aufklärung durch, um zu ermitteln, was die aktuelle Identität erreichen kann. Er sucht nach Dateien, die er schreiben kann und die privilegierte Prozesse später lesen oder ausführen, nach Programmen, die mit erhöhter Autorität laufen, aber vom Angreifer beeinflusste Eingaben akzeptieren, und nach veralteter Software mit bekannten Schwächen. Die Eskalation selbst ist der Moment, in dem vom Angreifer kontrollierte Eingaben eine Vertrauensgrenze in einen privilegierten Kontext überschreiten. Konzeptionell ist jeder Vektor eine Variation eines Themas: eine niedrig privilegierte Eingabe erreicht einen hoch privilegierten Ausführungspfad. Ihre defensive Aufgabe besteht darin, diese Brücken zu finden und sie entweder zu entfernen oder genau zu überwachen.

Gängige Vektoren und die Angriffsfläche

Fehlkonfiguriertes sudo ist der häufigste Befund in realen Umgebungen. Wenn ein Konto bestimmte Befehle als root ausführen darf und einer dieser Befehle eine Shell starten, beliebige Dateien lesen oder in sensible Pfade schreiben kann, bricht die Grenze zusammen. Platzhalter in sudoers-Regeln und NOPASSWD-Einträge vergrößern die Fläche zusätzlich.

SUID- und SGID-Binärdateien laufen mit den Rechten des Dateieigentümers, unabhängig davon, wer sie startet. Ein legitimes SUID-root-Programm, das dazu gebracht werden kann, einen anderen Befehl auszuführen oder Dateien als root zu lesen und zu schreiben, wird zum Hebel. Die Sorge wächst, wenn eigene oder Drittanbieter-Binärdateien das SUID-Bit unnötig tragen.

Übermäßige Linux-Capabilities sind ein subtilerer Verwandter. Eine Binärdatei mit cap_setuid, cap_dac_override oder cap_sys_admin hält einen Teil der Root-Macht ohne SUID-Bit und wird bei einem Audit, das nur Dateimodi prüft, leicht übersehen.

Geplante Aufgaben wie Cron-Jobs, systemd-Timer und Init-Skripte laufen häufig als privilegierte Benutzer. Wenn ein von ihnen ausgeführtes Skript oder ein Verzeichnis auf dem Pfad zu diesem Skript von einem geringeren Benutzer beschreibbar ist, kann dieser beeinflussen, was root ausführt. Schwache Datei- und Dienstberechtigungen verallgemeinern dies: eine für alle beschreibbare Dienst-Unit, eine beim Start gelesene Konfigurationsdatei oder ein Bibliotheksverzeichnis im Suchpfad einer privilegierten Binärdatei sind allesamt Brücken von niedrig zu hoch.

PATH- und Umgebungsmanipulation nutzt privilegierte Skripte aus, die Hilfsprogramme über den Namen statt über den absoluten Pfad aufrufen; kann ein Angreifer den Suchpfad beeinflussen, wird das Hilfsprogramm zu seiner eigenen Binärdatei aufgelöst. Schließlich geben Kernel- und Dienstschwachstellen in ungepatchter Software direkte Eskalation, und Container- und Namespace-Fehlkonfigurationen, etwa ein als root laufender Container mit eingehängtem Host-Dateisystem oder Docker-Socket, erlauben den Ausbruch zum Host.

Erkennung: die Telemetrie, die Eskalation sichtbar macht

Die wertvollste Quelle ist das Linux-Audit-Framework auditd. Regeln, die execve, Änderungen an /etc/sudoers und /etc/sudoers.d/, Schreibvorgänge unter /etc/cron.* und /etc/systemd/ sowie die Syscalls setuid, setreuid und capset überwachen, verwandeln stille Eskalation in aufgezeichnete Ereignisse. Versehen Sie diese Regeln mit Schlüsseln, damit Ihr SIEM darauf alarmieren kann. Ein plötzlicher Schwall von Aufklärung — viele execve-Ereignisse für id, sudo -l, find / -perm und Lesevorgänge von /etc/passwd in Sekunden — ist bereits vor der Eskalation ein starkes Verhaltenssignal.

Der Kernel erzeugt einen Audit-Eintrag, wenn setuid Privilegien erhöht. Korrelieren Sie diesen Übergang zu root mit einer Baseline, welche Dienste dies legitim tun; ein unerwarteter Prozess, der den Sprung macht, verdient sofortige Untersuchung. sudo schreibt in das Authentifizierungsprotokoll, alarmieren Sie also auf Fehlschläge, auf die Nutzung des NOPASSWD-Pfads durch Konten, die ihn nicht haben sollten, und auf jeden als root ausgeführten Befehl, der anschließend einen Shell-Interpreter startet. Auf der EDR-Seite achten Sie auf verdächtige Eltern-Kind-Ketten, etwa einen Web- oder Datenbankprozess, der bash, sh, python oder nc startet, und auf ein nicht-interaktives Dienstkonto, das plötzlich ein interaktives TTY erhält.

Dateiintegritätsüberwachung schließt den Kreis. Alarmieren Sie, sobald das SUID- oder SGID-Bit auf einer Binärdatei erscheint, sobald sich Dateicapabilities ändern und sobald Cron-, systemd-Unit- oder Bibliotheksdateien außerhalb eines Änderungsfensters modifiziert werden. Versenden Sie all dies zentral, damit ein Angreifer mit root-Rechten, der lokale Protokolle löscht, die bereits erzeugten Beweise nicht auslöschen kann.

Minderung und Härtung: zuerst geringste Rechte

Jede Härtungsentscheidung folgt dem Prinzip der geringsten Rechte. Prüfen Sie sudoers und entfernen Sie pauschale Rechte: gewähren Sie bestimmte Befehle bestimmten Benutzern, vermeiden Sie NOPASSWD, außer eine eng begrenzte Automatisierung erfordert es, und erlauben Sie niemals Befehle, die eine Shell öffnen oder beliebige Dateien lesen können, es sei denn, dies ist die bewusste Absicht. Bevorzugen Sie sudo mit Argumenteinschränkungen gegenüber einer interaktiven Root-Shell. Überprüfen Sie diese Regeln planmäßig, da sie sich im Laufe der Zeit als nie entfernte Ausnahmen ansammeln.

Betreiben Sie Dienste als dedizierte, unprivilegierte Konten, eines pro Dienst, damit die Kompromittierung einer Webanwendung dem Angreifer keine Shell verschafft, der ein anderer Dienst vertraut. Nutzen Sie systemd-Sandboxing-Direktiven — NoNewPrivileges=yes, ProtectSystem=strict, PrivateTmp=yes und ein restriktives CapabilityBoundingSet — um einzuschränken, was ein kompromittierter Dienst tun kann, noch bevor Eskalation ins Spiel kommt.

Härtung von Dateisystem, SUID und Capabilities

Inventarisieren Sie jede SUID- und SGID-Binärdatei in Ihrer Flotte und begründen Sie jede einzelne. Entfernen Sie das Bit von allem, was es nicht braucht, und behandeln Sie eine unerwartete SUID-Binärdatei als Vorfall. Hängen Sie Dateisysteme mit benutzerbeschreibbaren oder temporären Daten — /tmp, /var/tmp, /dev/shm und Home-Partitionen — mit nosuid, nodev und wo möglich noexec ein, damit eine platzierte SUID-Datei ihr Privileg schlicht nicht trägt. Prüfen Sie Dateicapabilities mit Werkzeugen, die sie über den Baum auflisten, und ziehen Sie Capabilities SUID nur vor, wenn Sie sie eng begrenzen können.

Sperren Sie die Berechtigungen für alles, was ein privilegierter Prozess konsumiert: Cron-Verzeichnisse, systemd-Unit-Dateien, Dienstkonfigurationen und die Verzeichnisse im Bibliotheks- und Ausführungssuchpfad jeder privilegierten Binärdatei dürfen nicht von geringeren Benutzern beschreibbar sein. Rufen Sie in privilegierten Skripten Hilfsprogramme stets über den absoluten Pfad auf und setzen Sie die Umgebung zurück, damit PATH-Manipulation nichts greifen kann.

Kernel, Patching und verpflichtende Zugriffskontrolle

Zeitnahes Patchen beseitigt die Kernel- und Dienstschwachstellen, die direkte Eskalation ermöglichen; verfolgen Sie Ihre Exposition anhand einer Schwachstellenquelle und priorisieren Sie alles mit einer öffentlichen Local-Privilege-Escalation-Lücke. Über das Patchen hinaus schichten Sie verpflichtende Zugriffskontrolle ein. SELinux im Enforcing-Modus oder ein gut abgestimmtes AppArmor-Profil beschränkt einen Prozess auf das, was seine Rolle erfordert, sodass selbst eine erfolgreiche Eskalation zu root innerhalb einer beschränkten Domäne das System nicht frei umschreiben kann. Kombinieren Sie dies mit Kernel-Härtung wie kernel.yama.ptrace_scope, eingeschränktem dmesg-Zugriff und deaktivierten ungenutzten Kernelmodulen, um ganze Technikklassen zu entfernen.

Häufige Fallstricke, die Verteidiger vermeiden sollten

Der erste Fallstrick besteht darin, Härtung als einmaliges Projekt zu behandeln. Sudo-Regeln, SUID-Inventare und Cron-Jobs driften, wenn sich Systeme ändern; ohne regelmäßiges Re-Audit wächst die Fläche still nach. Der zweite ist, nur auf bekannte Exploit-Signaturen zu überwachen und Verhalten zu ignorieren — Eskalation über Fehlkonfiguration erzeugt gar keine Exploit-Signatur, nur anomale Prozessabstammung und Privilegienübergänge. Der dritte ist, Protokolle nur lokal zu halten, die ein Angreifer mit root-Rechten löscht; zentralisieren Sie Telemetrie, damit sie eine Host-Kompromittierung überlebt. Der vierte ist, Container zu vergessen: ein Container, der als root läuft, --privileged erhält oder den Docker-Socket einhängt, gewährt faktisch Host-root, wenden Sie also dieselbe Disziplin der geringsten Rechte innerhalb der Images an.

Praktische Härtungscheckliste

Nutzen Sie dies als wiederkehrende Prüfung. Geringste Rechte: sudoers prüfen, pauschale und NOPASSWD-Regeln entfernen, jeden Dienst als eigenes unprivilegiertes Konto betreiben. Dateisystem: SUID/SGID inventarisieren und minimieren, beschreibbare Partitionen nosuid,nodev,noexec einhängen, Berechtigungen auf Cron-, systemd- und Konfigpfaden verschärfen. Capabilities: Dateicapabilities prüfen und unnötige entfernen. Kernel: im Takt patchen, SELinux oder AppArmor im Enforcing-Modus aktivieren, Kernel-Härtungs-sysctls anwenden. Erkennung: auditd-Regeln für setuid, sudoers, cron und capset ausrollen; Prozessabstammung im EDR überwachen; Dateiintegritätsüberwachung auf privilegierten Pfaden aktivieren; alle Protokolle in einen zentralen Speicher senden, den der Host nicht erreicht. Container: als Nicht-Root betreiben, Capabilities entfernen, den Docker-Socket nie in nicht vertrauenswürdige Workloads einhängen.

Häufig gestellte Fragen

Ist das Entfernen von SUID-Binärdateien sicher? Einige Systembinärdateien brauchen das Bit wirklich, etwa passwd. Der sichere Weg besteht darin, jede SUID-Datei zu inventarisieren, sie einem begründeten Bedarf zuzuordnen, das Bit von allem Unbegründeten zu entfernen und zuerst in einer Staging-Umgebung zu testen. Eine unerklärliche SUID-Binärdatei ist weit eher von einem Angreifer platziert als legitim.

Bin ich vor Privilegienerweiterung sicher, wenn ich alles in Containern betreibe? Nein. Container sind eine Grenze, keine Garantie. Ein als root laufender Container mit übermäßigen Capabilities oder eingehängtem Host-Socket ist oft ein direkter Weg zu Host-root. Behandeln Sie Container-Konfiguration mit derselben Strenge der geringsten Rechte wie Hosts und überwachen Sie Eskalation auch innerhalb von Containern.

Fazit

Linux-Privilegienerweiterung ist meist keine Frage exotischer Exploits; sie ist die vorhersehbare Folge angehäufter loser Konfiguration — eine zu breite Sudo-Regel, ein verirrtes SUID-Bit, ein beschreibbarer Cron-Pfad, ein ungepatchter Kernel. Das ist eine gute Nachricht für Verteidiger, denn es bedeutet, dass die Fläche aufzählbar und die Korrekturen konkret sind. Kombinieren Sie disziplinierte geringste Rechte, Dateisystem- und Capability-Härtung, zeitnahes Patchen und verpflichtende Zugriffskontrolle, um die Gelegenheit zu beseitigen, und schichten Sie dann auditd, EDR-Prozessabstammungsüberwachung und zentralisierte Dateiintegritätsüberwachung ein, um den Rest zu fangen. Regelmäßig statt einmalig geprüft, macht diese defensive Haltung aus Eskalation statt einer stillen Unvermeidlichkeit ein lautes, fangbares Ereignis.