Auf einem Linux-Host finden Sie eine für alle beschreibbare Datei, die root gehört und das SUID-Bit gesetzt hat. Was ist das Risiko und Ihre Maßnahme?
Kurzantwort
Eine SUID-root-Binärdatei läuft mit Root-Rechten, und wenn sie für alle beschreibbar ist, kann ein Angreifer sie ersetzen oder verändern, um beliebigen Code als root auszuführen — ein klassischer Pfad zur lokalen Rechteausweitung. Entfernen Sie das SUID-Bit, korrigieren Sie Eigentümer und Berechtigungen und untersuchen Sie, wie die Fehlkonfiguration entstanden ist, da sie auf eine Kompromittierung hindeuten kann. Das Verschlüsseln der Datei lässt den ausführbaren Pfad intakt, und das Umbenennen verschiebt das Problem nur, ohne die Ausweitung zu beseitigen. Keine dieser Optionen behebt die Ursache.
Eine SUID-Binärdatei (Set User ID) läuft mit den Rechten ihres Eigentümers, nicht des Benutzers, der sie gestartet hat. Wenn der Eigentümer root ist, läuft jeder Code, den diese Binärdatei ausführt, als root. Das ist für eine kleine, sorgfältig geprüfte Auswahl an Systemwerkzeugen akzeptabel. Es wird katastrophal, sobald die Datei zusätzlich für alle beschreibbar ist.
Warum dies eine Rechteausweitung ist
Wenn eine Datei -rwsrwxrwx root root ist, kann jeder lokale Benutzer ihren Inhalt überschreiben. Ein Angreifer ersetzt die Binärdatei einfach (oder bearbeitet sie, falls es ein Skript ist) durch eine Nutzlast seiner Wahl — eine Shell, einen Befehl, der einen SSH-Schlüssel zu ~/.ssh/authorized_keys hinzufügt, oder eine Rückverbindung. Beim nächsten Aufruf mit gesetztem SUID-Bit wird diese Nutzlast als root ausgeführt. Der Angreifer ist von einer unprivilegierten Shell zur vollständigen Root-Kontrolle gelangt, ohne einen einzigen Speicherbeschädigungsfehler auszunutzen. Dies ist eine der zuverlässigsten Primitiven zur lokalen Rechteausweitung unter Linux.
Die richtige Maßnahme
- Entfernen Sie das SUID-Bit (
chmod u-s), sofern es nicht wirklich benötigt wird. - Korrigieren Sie Eigentümer und Berechtigungen, damit die Datei nicht für Gruppe oder andere beschreibbar ist (
chmod o-w,g-w). - Untersuchen Sie die Ursache. Eine root gehörende, für alle beschreibbare SUID-Datei entsteht selten zufällig. Prüfen Sie die Paketintegrität, kürzliche Änderungen und ob ein Angreifer sie als Hintertür oder Persistenzmechanismus erstellt hat. Behandeln Sie sie als möglichen Kompromittierungsindikator, nicht nur als Hygieneproblem.
Warum die Ablenker scheitern
- „Kein Risiko" ist schlicht falsch — dies ist ein Lehrbuchpfad zur Ausweitung und offenbart eine gefährliche Urteilslücke.
- Das Verschlüsseln der Datei verhindert nicht, dass sie als SUID-root läuft, und ein Angreifer kann sie weiterhin ersetzen; Sie haben nichts gelöst.
- Das Umbenennen lässt dieselbe beschreibbare SUID-Binärdatei unter neuem Namen auf der Festplatte zurück, weiterhin für die Ausweitung nutzbar.
Was der Interviewer prüft
Ob Sie wirklich verstehen, wie SUID funktioniert, „für alle beschreibbar + SUID-root" mit der Ausführung beliebigen Codes als root verbinden können und instinktiv vom Beheben der Datei zur Frage ihrer Herkunft übergehen — der Incident-Response-Reflex, der einen erfahrenen Ingenieur von einem Anfänger unterscheidet.
Wahrscheinliche Anschlussfragen
- Wie würden Sie alle SUID/SGID-Binärdateien auf einem Host auflisten, und welche sind zu erwarten?
- Wenn diese Binärdatei nicht beschreibbar, aber ein bekannter GTFOBins-Eintrag wäre, wie würde sich die Ausweitung unterscheiden?
- Welche Protokollierungs- oder Integritätskontrollen hätten die Berechtigungsänderung früher erkannt?