Sudo-Missbrauch erkennen: Rechteausweitung über sudoers und sudo-Caching

Sudo-Missbrauch erkennen heißt, die schmale Grenze zwischen legitimer Administration und Rechteausweitung sichtbar zu machen. sudo ist auf jedem Linux-Server im Einsatz, und genau diese Allgegenwärtigkeit macht es für einen Angreifer attraktiv: Statt eines Exploits reicht oft eine zu großzügige Regel in der sudoers-Datei, um von einem normalen Konto zu root zu kommen. Nach dem ersten Zugriff über eine Unix-Shell prüft ein Angreifer als Erstes, was er per sudo darf. Dieser Beitrag aus der Serie "Angriff erkennen" zeigt aus Verteidigersicht, wo sudo-Missbrauch Spuren hinterlässt, mit Logquellen, drei Sigma-Regeln, der Härtung, einer Checkliste und dem Test. Die Telemetrie-Grundlagen stehen unter Linux-Sicherheitsmonitoring.

Was der Angreifer tut

Der Weg über sudo hat wenige, wiederkehrende Varianten. Bewusst auf der Ebene des Prinzips, nicht als Anleitung:

• Fehlkonfiguration ausnutzen. Eine sudoers-Regel erlaubt dem Konto mehr als nötig - ein NOPASSWD ohne Passwortabfrage, ein zu breites Befehlsrecht oder ein Programm, das sich zu einer Shell ausbrechen lässt. Der Angreifer prüft das mit sudo -l und nutzt die passende Regel.
• Root-Shell öffnen. Darf das Konto eine Shell oder ein ausbruchsfähiges Programm per sudo starten, genügt ein sudo -i, sudo su oder ein GTFOBins-Aufruf, um als root weiterzuarbeiten.
• sudo-Caching missbrauchen. Nach einer erfolgreichen sudo-Eingabe merkt sich sudo die Berechtigung für einige Minuten. Wer in diesem Fenster Zugriff auf die Sitzung des Nutzers hat, nutzt die zwischengespeicherte Berechtigung ohne eigenes Passwort.
• sudoers selbst erweitern. Hat der Angreifer einmal root, legt er eine eigene Regel in /etc/sudoers.d/ an, oft mit NOPASSWD, und sichert sich so eine bequeme, dauerhafte Rechteausweitung.

Der gemeinsame Nenner ist entweder eine geänderte sudoers-Regel oder ein sudo-Aufruf, der eine Root-Shell öffnet. Beides steht im Log.

Welche Logquellen die Technik zeigt

• sudo-Logs in journald (die wichtigste Quelle). Jeder sudo-Aufruf wird protokolliert: sudo: <user> : TTY=... ; PWD=... ; USER=root ; COMMAND=<pfad>. Auch Fehlversuche sind hier zu sehen, etwa user NOT in sudoers oder incorrect password attempts - wertvoll, um Probieren an einer Fehlkonfiguration zu erkennen.
• auditd. Ein Datei-Watch auf die sudoers macht jede Regeländerung sichtbar, etwa -w /etc/sudoers -p wa -k sudoers und -w /etc/sudoers.d/ -p wa -k sudoers. Der execve-Datensatz zeigt zusätzlich den sudo- und visudo-Aufruf mit Konto und Kommandozeile.
• Sysmon for Linux. Event 1 (Prozesserstellung) zeigt den sudo-Aufruf und das als root gestartete Kind, Event 11 das Anlegen einer neuen Datei in /etc/sudoers.d/.
• Korrelation. Am aussagekräftigsten ist die Kette: erst sudo -l zur Aufklärung, dann der sudo-Aufruf, der eine Shell öffnet, dann die root-Aktivität - alles auf demselben System in kurzer Folge.

Das Muster im Log

sudo selbst ist Alltag, deshalb zählen Kontext und Abweichung. Eine Änderung an der sudoers-Datei außerhalb eines Wartungsfensters ist fast immer prüfwürdig, besonders wenn sie ein NOPASSWD oder ein neues Konto einträgt. Ein sudo, das direkt eine Shell öffnet, ist bei Administratoren normal, bei einem Dienst- oder Anwendungskonto dagegen ein starkes Signal. Verdächtig ist auch ein Konto, das zum ersten Mal überhaupt sudo nutzt, oder eine Häufung von NOT in sudoers-Meldungen, die auf das Abtasten einer Fehlkonfiguration hindeutet. Wer die sudoers-Änderung, die Enumeration und den Shell-Aufruf zusammenbringt, trennt die Administration vom Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli validiert und nutzen die Linux-Logquellen file_event und process_creation. Die erste fängt die sudoers-Änderung, die zweite den sudo-Aufruf einer Shell, die dritte die Enumeration per sudo -l. Die Übersetzung ins SIEM steht unter Sigma-Regeln.

1. Änderung an der sudoers-Konfiguration (T1548.003). Jede Schreiboperation an /etc/sudoers oder /etc/sudoers.d/ ist ein Prüffall.

title: Aenderung an der sudoers-Konfiguration
id: b14af2d4-9554-4177-ba06-e5b7267388fb
status: experimental
description: Erkennt das Anlegen oder Aendern von /etc/sudoers oder einer Datei in
  /etc/sudoers.d/. Angreifer tragen dort erweiterte Rechte ein, etwa eine
  NOPASSWD-Regel oder ein ALL=(ALL)-Recht fuer ihr Konto, und verschaffen sich so
  eine dauerhafte Rechteausweitung (Sudo and Sudo Caching).
references:
  - https://attack.mitre.org/techniques/T1548/003/
author: blue-team.net
tags:
  - attack.privilege-escalation
  - attack.t1548.003
logsource:
  product: linux
  category: file_event
detection:
  selection:
    TargetFilename|contains:
      - '/etc/sudoers'
  condition: selection
falsepositives:
  - Administrative Pflege der sudoers und Paketinstallationen - bekannte Wartungsfenster abgleichen
level: high

2. sudo startet eine interaktive Shell (T1548.003). sudo -i, sudo -s, sudo su oder sudo bash als direkter Weg zur Root-Shell.

title: sudo startet eine interaktive Shell
id: 075bd7c1-e188-417e-9b1c-1d96a737d32a
status: experimental
description: Erkennt den Aufruf von sudo, der direkt eine interaktive Shell oeffnet
  (sudo -i, sudo -s, sudo su oder sudo bash). Nach einer passenden sudoers-Regel ist
  das der direkte Weg zu einer Root-Shell. Legitime Administration nutzt dasselbe
  Muster, daher zusammen mit Konto und Kontext bewerten.
references:
  - https://attack.mitre.org/techniques/T1548/003/
author: blue-team.net
tags:
  - attack.privilege-escalation
  - attack.t1548.003
logsource:
  product: linux
  category: process_creation
detection:
  selection_img:
    Image|endswith: '/sudo'
  selection_cmd:
    CommandLine|contains:
      - ' -i'
      - ' -s'
      - ' su'
      - '/bash'
      - '/sh'
  condition: selection_img and selection_cmd
falsepositives:
  - Administratoren, die regulaer eine Root-Shell oeffnen - bekannte Konten als Baseline ausnehmen
level: medium

3. Enumeration der sudo-Rechte per sudo -l (T1548.003). Der Recon-Schritt, der die nutzbare Fehlkonfiguration findet.

title: Enumeration der sudo-Rechte per sudo -l
id: 25ecd551-a387-4fd4-9134-0a8143c17b20
status: experimental
description: Erkennt den Aufruf sudo -l, mit dem die erlaubten sudo-Befehle eines
  Kontos aufgelistet werden. Das ist der typische Aufklaerungsschritt vor dem
  Missbrauch einer sudo-Fehlkonfiguration. Einzeln harmlos, in Verbindung mit einem
  frischen Shell-Zugriff aber ein fruehes Warnsignal.
references:
  - https://attack.mitre.org/techniques/T1548/003/
author: blue-team.net
tags:
  - attack.privilege-escalation
  - attack.t1548.003
logsource:
  product: linux
  category: process_creation
detection:
  selection_img:
    Image|endswith: '/sudo'
  selection_cmd:
    CommandLine|contains: ' -l'
  condition: selection_img and selection_cmd
falsepositives:
  - Skripte und Werkzeuge, die die eigenen sudo-Rechte pruefen
level: low

Härtung

• sudoers minimal halten. Keine pauschalen ALL-Rechte, NOPASSWD nur wo zwingend nötig, und keine Befehle erlauben, die sich zu einer Shell ausbrechen lassen (Editoren, Interpreter, Pager). Jede Regel auf das notwendige Minimum fassen.
• Änderungen kontrollieren. sudoers nur über visudo pflegen, Änderungen per Review und Konfigurationsmanagement ausrollen und /etc/sudoers.d/ sauber halten. Eine Baseline der erlaubten Regeln macht jede Abweichung sichtbar.
• Caching begrenzen. Für sensible Konten das Zeitfenster per timestamp_timeout=0 abschalten, damit eine zwischengespeicherte Berechtigung nicht missbraucht werden kann, und use_pty setzen.
• Vollständig protokollieren. sudo-Logs zentral sammeln und, wo nötig, die Ein- und Ausgabeprotokollierung (I/O logging) aktivieren, damit auch der Inhalt einer Root-Sitzung nachvollziehbar ist.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einer isolierten VM mit auditd-Dateiwatches, zentralen sudo-Logs und Sysmon for Linux:

• Für Regel 1 eine Testdatei in /etc/sudoers.d/ mit einer NOPASSWD-Regel anlegen (danach wieder entfernen). Der auditd-PATH-Datensatz und Sysmon for Linux Event 11 müssen die Änderung zeigen.
• Für Regel 2 ein sudo -i oder sudo su - ausführen und prüfen, dass der sudo-Log-Eintrag mit USER=root und die Prozess-Regel greifen.
• Für Regel 3 ein sudo -l absetzen und den Treffer prüfen.
• Breiter wird der Test mit den Fällen zu T1548.003 aus Atomic Red Team.

Fehlalarme und Tuning

• Administratoren. sudo -i und sudo -s sind für Admins Alltag. Deren Konten als Baseline hinterlegen und den Fokus auf untypische Konten legen, statt die Regel zu entschärfen.
• Paketinstallationen. Manche Pakete legen eine eigene Datei in /etc/sudoers.d/ an. Diese Änderungen fallen in Wartungsfenster und lassen sich über den Paketmanager zuordnen.
• Konfigurationsmanagement. Ansible und Puppet verwalten sudoers oft zentral. Deren Konten und Läufe gehören in die Baseline.
• Kontext entscheidet. sudo aus einem Dienst- oder Anwendungskonto, ein erstmaliger sudo-Gebrauch eines Kontos oder eine Häufung von Fehlversuchen wiegen schwerer als die gewohnte Admin-Sitzung.

Analysten-Checkliste

• Wurde /etc/sudoers oder /etc/sudoers.d/ geändert? Inhalt prüfen: NOPASSWD, ALL, neues Konto oder neuer Befehl?
• Öffnet sudo eine Shell oder ein ausbruchsfähiges Programm, und unter welchem Konto?
• Gab es davor ein sudo -l zur Enumeration?
• Ist das Konto normalerweise sudo-berechtigt, oder nutzt es sudo zum ersten Mal?
• Häufen sich NOT-in-sudoers- oder Fehlversuch-Meldungen vorher?
• Welcher vorangehende Shell-Zugriff führt zu dem Ereignis?

Fazit

sudo-Missbrauch ist selten ein Exploit und fast immer eine Frage der Konfiguration: eine zu großzügige Regel, ein ausbruchsfähiger Befehl, ein zu langes Caching-Fenster. Das macht die Erkennung dankbar, weil jede dieser Schwächen im Log sichtbar wird - in den sudo-Einträgen von journald, in der sudoers-Änderung in auditd und im sudo-Aufruf in Sysmon for Linux. Wer diese Quellen erfasst, die sudoers minimal hält und jede Änderung gegen eine Baseline prüft, schließt einen der häufigsten Wege nach oben. Der verwandte Weg über Dateirechte steht unter SUID/SGID-Missbrauch, der Zugang davor meist über eine Unix-Shell. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Privilege Escalation.