Linux Privilege Escalation Verhindern
Linux Privilege Escalation verhindern – Server absichern
Was ist Privilege Escalation?
Privilege Escalation ist der Prozess, bei dem ein Benutzer mit niedrigen Rechten seine Berechtigungen auf höhere Stufen erhöht (z.B. vom normalen Benutzer zu root). Es gibt zwei Arten:
Horizontale Privilege Escalation
Ein Benutzer erweitert seine Rechte auf die Rechte eines anderen gleichberechtigten Benutzers. Beispiel: Ein normaler Benutzer dringt in einen anderen normalen Benutzer ein.
Vertikale Privilege Escalation (Vertikal/zu Root)
Ein normaler Benutzer erlangt root-Zugriff. Dies ist die kritischere Form und der Fokus dieser Anleitung.
Häufige Privilege Escalation Angriffsvektoren
1. SUID-Binaries
SUID (Set User ID) Bit ermöglicht es Dateien, mit der UID des Owners zu laufen, nicht des Benutzers. Ein fehlerhaftes SUID-Binary könnte von einem Angreifer missbraucht werden.
SUID-Binaries finden:
find / -perm -4000 -type f 2>/dev/null
Beispiel verdächtiger SUID-Binaries:
-rwsr-xr-x 1 root root 59640 Jul 14 2023 /usr/bin/passwd -rwsr-xr-x 1 root root 88464 Jul 14 2023 /usr/bin/sudo -rwsr-xr-x 1 root root 44808 Mar 23 2023 /usr/bin/mount
Dies sind legitim. Unerwartete SUID-Binaries sind verdächtig:
find / -perm -4000 -type f 2>/dev/null | grep -v -E "^(/usr/|/bin/|/sbin/)" # Zeigt verdächtige Orte
2. Sudo-Misconfigurations
Die /etc/sudoers Datei regelt, welche Benutzer welche Befehle mit root-Rechten ausführen dürfen. Fehler hier sind kritisch.
Aktuelle sudo-Regeln überprüfen:
sudo -l # Beispiel-Ausgabe: # User testuser may run the following commands: # (root) NOPASSWD: /usr/bin/apt-get # (root) /bin/nano /etc/hosts
Häufiger Fehler: NOPASSWD ohne Passwort
# GEFÄHRLICH! Jeder kann diesen Befehl als root ausführen: testuser ALL=(root) NOPASSWD: /bin/bash
Auch gefährlich: Wildcards in sudo-Regeln
# Ein Angreifer könnte /usr/bin/apt-get-exploit erstellen: testuser ALL=(root) /usr/bin/apt-get*
3. Schreibbare /etc/passwd oder /etc/shadow
Wenn ein normaler Benutzer diese kritischen Dateien ändern kann, kann er sein eigenes Passwort zu root setzen.
Überprüfen:
ls -l /etc/passwd /etc/shadow # Sollte sein: # -rw-r--r-- 1 root root 1234 Apr 5 10:00 /etc/passwd # -rw-r----- 1 root shadow 567 Apr 5 10:00 /etc/shadow
Falls falsch:
sudo chmod 644 /etc/passwd sudo chmod 640 /etc/shadow
4. Cron-Job Hijacking
Ein root-Cron-Job, der ein Skript mit schreibbaren Berechtigungen ausführt, kann von einem Angreifer modifiziert werden.
Beispiel eines anfälligen Cron-Jobs:
cat /etc/cron.d/backup # 0 2 * * * root /home/admin/backup.sh <-- Nicht executable für Others, aber...
Wenn /home/admin/backup.sh weltlesbar/schreibbar ist:
ls -l /home/admin/backup.sh # Wenn: -rwxrwxrwx (777), kann jeder ihn modifizieren!
Cron-Verzeichnis-Permissions überprüfen:
ls -ld /etc/cron.* /var/spool/cron/ # Sollte sein: drwxr-xr-x oder restriktiver
5. PATH-Injection
Wenn ein Benutzer den PATH manipuliert, kann er gefälschte Binaries vor den echten laden.
Beispiel-Angriff:
# Angreifer erstellt ein gefälschtes ls: mkdir -p /tmp/bin cat > /tmp/bin/ls << 'EOF' #!/bin/bash /bin/bash EOF chmod +x /tmp/bin/ls # Dann setzt er PATH: export PATH=/tmp/bin:$PATH # Wenn ein Shell-Skript das aufruft, erhält der Angreifer eine Shell!
6. Schwache Dateiberechtigungen
Wenn wichtige Konfigurationsdateien weltlesbar sind oder das Verzeichnis schreibbar ist:
find / -path /proc -prune -o -path /sys -prune -o -perm -002 -type f 2>/dev/null # Zeigt alle Dateien, die "Other" schreiben darf (sehr gefährlich!)
7. Kernel-Exploits
Alte Kernel-Versionen mit bekannten Privilege Escalation CVEs. Dies ist kritisch:
uname -r # Vergleichen Sie mit: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Schwachstellen überprüfen – Praktische Schritte
Schritt 1: SUID-Binaries auditieren
#!/bin/bash
# SUID-Audit-Skript
echo "=== SUID-Binaries Audit ==="
find / -perm -4000 -type f 2>/dev/null | while read binary; do
owner=$(stat -c '%U' "$binary")
if [ "$owner" != "root" ]; then
echo "WARNING: Nicht-root SUID binary: $binary (Owner: $owner)"
fi
done
# Whiteliste gewöhnlicher SUID-Binaries
EXPECTED_SUID="/usr/bin/sudo
/usr/bin/passwd
/usr/bin/mount
/usr/bin/umount
/usr/bin/ping"
echo "=== Unerwartete SUID-Binaries ==="
find / -perm -4000 -type f 2>/dev/null | while read binary; do
if ! echo "$EXPECTED_SUID" | grep -q "^$binary$"; then
echo "Unexpected: $binary"
fi
done
Schritt 2: sudo-Konfiguration auditieren
sudo -l # Zeigt Ihre eigenen Berechtigungen # Als Admin für alle Benutzer überprüfen: sudo visudo # Konfiguration überprüfen # oder sudo grep -r "NOPASSWD" /etc/sudoers.d/
Schritt 3: Datei-Permissions überprüfen
#!/bin/bash
# Kritische Dateien Permissions Check
echo "=== Kritische System-Dateien ==="
for file in /etc/passwd /etc/shadow /etc/sudoers /etc/crontab; do
echo "$file:"
ls -l "$file"
done
echo ""
echo "=== World-writable Dateien (GEFÄHRLICH!) ==="
find / -path /proc -prune -o -path /sys -prune -o -perm -002 -type f -print 2>/dev/null | head -20
Schritt 4: Cron-Jobs auditieren
#!/bin/bash
# Cron-Job Security Check
echo "=== System Cron-Jobs ==="
cat /etc/crontab
ls -la /etc/cron.d/
echo ""
echo "=== Cron-Permissions ==="
ls -ld /etc/cron.* /var/spool/cron/
echo ""
echo "=== Benutzer mit Cron-Jobs ==="
for user in $(cut -f1 -d: /etc/passwd); do
crontab -u "$user" -l 2>/dev/null | head -5 && echo "User: $user"
done
Hardening-Maßnahmen
1. sudo korrekt konfigurieren
Verwenden Sie immer visudo, nie direkt nano zum Bearbeiten:
sudo visudo # Syntax wird validiert, falsche Konfiguration wird verweigert
Sicherheitsrichtlinien für /etc/sudoers:
# FALSCH – Zu permissiv: testuser ALL=(ALL) ALL # BESSER – Spezifische Befehle: testuser ALL=(root) /usr/bin/systemctl restart nginx testuser ALL=(root) /usr/bin/apt-get update # MIT Password-Schutz (nicht NOPASSWD!): testuser ALL=(root) /usr/bin/systemctl restart nginx # FÜR MEHRERE BENUTZER in einer Gruppe: %admin ALL=(ALL) ALL # Aber Password verpflichtend!
Sichere sudoers-Beispiel:
# /etc/sudoers.d/admin (sudo visudo -f /etc/sudoers.d/admin) # Admin-Gruppe kann jede root-Aktion machen, benötigt aber Passwort: %admin ALL=(ALL) ALL # Sicherungs-Benutzer darf nur Backup-Skript ausführen: backup ALL=(root) /usr/local/bin/daily-backup.sh # Webserver darf nur Dienst neu starten: www-data ALL=(root) /usr/bin/systemctl reload nginx # NIEMALS verwenden für normale Benutzer: # user ALL=(root) NOPASSWD: /bin/bash
2. SUID-Binaries einschränken
Entfernen Sie SUID-Bit von Binaries, die es nicht brauchen:
# Finden Sie alle SUID-Binaries: sudo find / -perm -4000 -type f 2>/dev/null > /tmp/suid-list.txt # Überprüfen Sie jedes einzeln, dann entfernen Sie verdächtige: sudo chmod u-s /pfad/zur/binary
Beispiel – ping braucht nicht SUID unter modernen Systemen:
sudo chmod u-s /bin/ping # Nur Benutzer mit CAP_NET_RAW brauchen ping
3. Cron-Job Sicherheit
Sichere Cron-Job Best Practices:
# FALSCH – Skript weltlesbar/schreibbar: 0 2 * * * root /home/admin/backup.sh # (mit chmod 777 /home/admin/backup.sh) # RICHTIG: 0 2 * * * root /usr/local/bin/backup.sh # mit chmod 755 /usr/local/bin/backup.sh und Eigentümer: root
Kontrollieren Sie Verzeichnisberechtigungen:
sudo chmod 755 /etc/cron.d sudo chmod 755 /etc/cron.daily sudo chmod 755 /etc/cron.weekly sudo chmod 755 /etc/cron.monthly sudo chmod 1777 /var/spool/cron # Sticky-Bit nötig für Benutzer-Crontabs
4. umask richtig setzen
umask bestimmt die Standardberechtigungen neuer Dateien. Ein lockerer umask ist ein Sicherheitsrisiko:
umask # Standard ist 0022 (also 644 für Dateien, 755 für Verzeichnisse) # In /etc/profile oder ~/.bashrc für Benutzer: umask 0077 # Nur Owner darf lesen/schreiben (600 für Dateien)
5. Kernel-Exploits verhindern
Kernel aktuell halten:
sudo apt update && sudo apt upgrade # Oder yum auf RHEL-Systemen uname -r # Aktuelle Version überprüfen
Kernel-Parameter via sysctl hardenen:
sudo nano /etc/sysctl.d/99-hardening.conf
Fügen Sie hinzu:
# Kernel-Exploit-Mitigation kernel.unprivileged_userns_clone=0 # User namespaces nur für root kernel.unprivileged_bpf_disabled=1 # BPF nur für root kernel.kptr_restrict=2 # Kernel-Pointer verstecken kernel.dmesg_restrict=1 # dmesg nur für root # Anderes Hardening: kernel.panic=10 # System reboot nach Panic kernel.ctrl-alt-del=0 # Ctrl-Alt-Del deaktivieren
Anwenden:
sudo sysctl -p /etc/sysctl.d/99-hardening.conf
6. Audit mit LinPEAS
LinPEAS ist ein Automated Local Privilege Escalation Checker – sehr hilfreich zum Testen:
# Auf Test-Systemen: curl -L https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh | bash # oder herunterlade und lokal ausführen: wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh chmod +x linpeas.sh ./linpeas.sh 2>/dev/null | tee /tmp/linpeas-report.txt
LinPEAS findet potenzielle Privilege Escalation-Wege. Nutzen Sie das Report, um Ihre Systeme zu hardenen.
7. /proc und Kernel-Sicherheit
Beschränken Sie Zugriff auf sensitive /proc-Dateien:
# In /etc/sysctl.d/99-hardening.conf: kernel.perf_event_paranoid=3 # Perf nur für root kernel.yama.ptrace_scope=2 # ptrace nur für Parent/Child-Prozesse kernel.kexec_load_disabled=1 # Kexec deaktivieren
Privilege Escalation Hardening – Checkliste
| Überprüfung | Status | Befehl |
|---|---|---|
| Nur legitime SUID-Binaries | Ja ☐ Nein ☐ | find / -perm -4000 2>/dev/null |
| Keine NOPASSWD in sudoers (außer Scripts) | Ja ☐ Nein ☐ | sudo visudo |
| /etc/passwd ist 644, /etc/shadow ist 640 | Ja ☐ Nein ☐ | ls -l /etc/passwd /etc/shadow |
| Cron-Dateien nicht weltschreibbar | Ja ☐ Nein ☐ | ls -ld /etc/cron.* |
| Keine world-writable Dateien | Ja ☐ Nein ☐ | find / -perm -002 -type f 2>/dev/null |
| Kernel aktuell | Ja ☐ Nein ☐ | uname -r |
| Kernel-Hardening sysctl angewendet | Ja ☐ Nein ☐ | sysctl kernel.unprivileged_userns_clone |
| LinPEAS durchlaufen und behoben | Ja ☐ Nein ☐ | ./linpeas.sh |
Zusammenfassung
Privilege Escalation ist ein Mehrschritt-Problem, das durch mehrere Schwachstellen gelöst werden muss:
- Kontrollieren Sie SUID-Binaries und entfernen Sie unnötige Bits
- Sichern Sie sudo-Konfiguration mit spezifischen Befehlen
- Hardenen Sie Dateiberechtigungen und Cron-Jobs
- Aktivieren Sie Kernel-Hardening via sysctl
- Halten Sie Kernel und Pakete aktuell
- Testen Sie regelmäßig mit LinPEAS