Was ist Privilege Escalation / Rechteausweitung?
Die meisten Computersysteme sind für die Verwendung mit mehreren Benutzern ausgelegt. Privilegien bedeuten, was ein Benutzer tun darf. Zu den allgemeinen Privilegien gehören das Anzeigen und Bearbeiten von Dateien oder das Ändern von Systemdateien. Privilege Escalation bedeutet, dass ein Benutzer Privilegien erhält, zu denen er nicht berechtigt ist. (Rechteausweitung) Diese Privilegien können verwendet werden, um Dateien zu löschen, private Informationen anzuzeigen oder unerwünschte Programme wie Viren zu installieren. Sie tritt in der Regel auf, wenn ein System einen Fehler hat, der es erlaubt, die Sicherheit zu umgehen, oder alternativ dazu fehlerhafte Design-Annahmen darüber hat, wie es verwendet werden soll.
Privilege Escalation oder Rechteausweitung ist der Akt des Ausnutzens eines Fehlers, eines Designfehlers oder eines Konfigurationsfehlers in einem Betriebssystem oder einer Software-Anwendung, um erhöhten Zugriff auf Ressourcen zu erhalten, die normalerweise vor einer Anwendung oder einem Benutzer geschützt sind. Das Ergebnis ist, dass eine Anwendung mit mehr Privilegien als vom Anwendungsentwickler oder Systemadministrator beabsichtigt, nicht autorisierte Aktionen durchführen kann.
Während Unternehmen statistisch gesehen wahrscheinlich mehr Windows-Clients haben, sind Angriffe auf Linux-Privilege Escalation eine erhebliche Bedrohung, die bei der Betrachtung der Informationssicherheitslage eines Unternehmens zu berücksichtigen ist. Bedenken Sie, dass die kritischste Infrastruktur eines Unternehmens, wie z. B. Webserver, Datenbanken, Firewalls usw., mit hoher Wahrscheinlichkeit mit einem Linux-Betriebssystem betrieben wird. Kompromisse bei diesen kritischen Geräten haben das Potenzial, den Betrieb einer Organisation ernsthaft zu stören, wenn nicht sogar ganz zu zerstören. Darüber hinaus werden das Internet der Dinge (Internet of Things, IoT) und eingebettete Systeme am Arbeitsplatz allgegenwärtig, wodurch sich die Zahl der potenziellen Ziele für böswillige Hacker erhöht. Angesichts der Verbreitung von Linux-Geräten am Arbeitsplatz ist es von größter Wichtigkeit, dass Organisationen diese Geräte abhärten und sichern.
Ziel
In diesem Blog werden wir im Detail darüber sprechen, welche Sicherheitsprobleme zu einem erfolgreichen Privilege Escalation-Angriff auf Linux-basierte Systeme führen könnten. Wir werden auch erörtern, wie ein Angreifer die möglichen bekannten Techniken nutzen kann, um seine Privilegien auf einem entfernten Host erfolgreich zu erhöhen, und wie wir unsere Systeme vor einem solchen Angriff schützen können. Am Ende würden wir anhand von Beispielen demonstrieren, wie wir Privilege Escalation auf verschiedenen Linux-Systemen unter verschiedenen Bedingungen erreicht haben.
Dieser Blog richtet sich insbesondere an Anfänger, um ihnen anhand von Beispielen die Grundlagen der Linux-Privilege Escalation näher zu bringen. Es ist kein Spickzettel für die Aufzählung mit Linux-Befehlen. Bei Privilege Escalation dreht sich alles um die korrekte Aufzählung. Es gibt mehrere Möglichkeiten, die gleichen Aufgaben, die ich in den Beispielen gezeigt habe, auszuführen. Wenn Sie ein Cheatsheet für die Aufzählung mit Linux-Befehlen wünschen, dann sollten Sie sich unbedingt den Beitrag von g0tmi1k hier ansehen – https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/
Berechtigungsmodell in Linux
Linux hat das Konzept von Eigentümern und Berechtigungen für Dateien von UNIX geerbt. Dateiberechtigungen sind eine Möglichkeit, wie das System vor böswilligen Manipulationen schützt. Auf einem UNIX-Webserver ist jeder einzelnen Datei und jedem einzelnen Ordner, der auf der Festplatte gespeichert ist, ein Satz von Berechtigungen zugeordnet, der festlegt, wer was mit der Datei tun darf.
In den beiden obigen Screenshots können wir sehen, dass die Datei ‘docker-compose.yml’ nur Lesezugriff durch den Besitzer hat, der ‘root’ ist. Wenn ein anderer Benutzer versucht, diese Datei zu lesen, kann er sie nicht lesen. Wir können den Fehler “Erlaubnis verweigert” sehen, wenn ich versucht habe, die Datei zu lesen, wenn ich kein Superuser bin.
Wir werden hier nicht auf Einzelheiten des Berechtigungsmodells eingehen, da dies ein weiteres großes Thema ist. Es geht nur darum, die grundlegende Tatsache zu verstehen, dass ein Benutzer nicht auf Dateien zugreifen kann (lesen/schreiben/ausführen), auf die er nicht zugreifen darf. Der Superuser (root) kann jedoch auf alle Dateien zugreifen, die auf dem System vorhanden sind. Um eine wichtige Konfiguration zu ändern oder einen weiteren Angriff durchzuführen, müssen wir zunächst auf jedem Linux-basierten System Root-Zugriff erhalten.
Warum müssen wir eine Privilege Escalation durchführen?
- Lesen/Schreiben jeder sensiblen Datei
- Leichter Fortbestand zwischen Neustarts
- Einfügen einer permanenten Hintertür
Techniken zur Privilege Escalation
Wir gehen davon aus, dass wir jetzt eine Shell auf dem entfernten System haben. Je nachdem, wie wir dorthin gelangt sind, haben wir wahrscheinlich keine “root”-Privilegien. Die unten erwähnten Techniken können verwendet werden, um “root”-Zugriff auf das System zu erhalten.
1. Kernel-Exploits
Kernel-Exploits sind Programme, die Kernel-Schwachstellen ausnutzen, um beliebigen Code mit erhöhten Rechten auszuführen. Erfolgreiche Kernel-Exploits geben Angreifern in der Regel Superuser-Zugriff auf Zielsysteme in Form einer Root-Kommandozeile. In vielen Fällen ist die Eskalation zu root auf einem Linux-System so einfach wie das Herunterladen eines Kernel-Exploits auf das Zieldateisystem, das Kompilieren des Exploits und die anschließende Ausführung.
Unter der Annahme, dass wir als unprivilegierter Benutzer Code ausführen können, ist dies der generische Arbeitsablauf eines Kernel-Exploits.
1. Den Kernel austricksen, damit er unsere Nutzlast im Kernel-Modus ausführt
2. Kernel-Daten manipulieren, z.B. Prozessprivilegien
3. Starten Sie eine Shell mit neuen Privilegien Get root!
Bedenken Sie, dass ein Gegner vier Bedingungen erfüllen muss, damit ein Kernel-Exploit-Angriff erfolgreich ist:
1. Ein verwundbarer Kernel
2. Ein passender Exploit
3. Die Fähigkeit, den Exploit auf das Ziel zu übertragen
4. Die Fähigkeit, den Exploit auf dem Ziel auszuführen
Der einfachste Weg, sich gegen Kernel-Exploits zu verteidigen, ist, den Kernel gepatcht und aktualisiert zu halten. Wenn keine Patches vorhanden sind, können Administratoren die Fähigkeit zur Übertragung und Ausführung des Exploits auf das Ziel stark beeinflussen. Angesichts dieser Überlegungen sind Kernel-Exploit-Angriffe nicht mehr durchführbar, wenn ein Administrator die Einführung und/oder Ausführung des Exploits auf das Linux-Dateisystem verhindern kann. Administratoren sollten sich daher darauf konzentrieren, Programme einzuschränken oder zu entfernen, die Dateiübertragungen ermöglichen, wie z. B. FTP, TFTP, SCP, wget und curl. Wenn diese Programme erforderlich sind, sollte ihre Verwendung auf bestimmte Benutzer, Verzeichnisse, Anwendungen (wie SCP) und bestimmte IP-Adressen oder Domänen beschränkt werden.
Der berüchtigte DirtyCow-Exploit – Linux-Kernel <= 3.19.0-73.8
In der Art und Weise, wie das Speichersubsystem des Linux-Kernels mit dem Copy-on-Write (COW)-Bruch der privaten Nur-Lese-Speicherzuordnungen umging, wurde eine Race-Condition gefunden. Ein unprivilegierter lokaler Benutzer konnte diesen Fehler ausnutzen, um Schreibzugriff auf ansonsten schreibgeschützte Speicherzuordnungen zu erhalten und so seine Privilegien auf dem System zu erhöhen. Es handelte sich um eine der schwerwiegendsten Privilege Escalation Schwachstellen, die je entdeckt wurde, und sie betraf fast alle großen Linux-Distributionen.
Ausnutzung einer verwundbaren Maschine über dirtycow
$ whoami – sagt uns, dass der aktuelle Benutzer John (Nicht-Root-Benutzer) ist
$ uname -a – gibt uns die Kernel-Version, von der wir wissen, dass sie für Dirtycow anfällig ist
> hat den Dirtycow-Exploit von hier heruntergeladen – https://www.exploit-db.com/exploits/40839/
> Kompiliert und ausgeführt. Es ersetzt den Benutzer ‘root’ durch einen neuen Benutzer ‘rash’, indem die Datei /etc/passwd editiert wird.
$ su rash – Ändert den aktuell angemeldeten Benutzer in den Benutzer ‘rash’, der root ist.
Sie können sich andere Varianten von Dirtycow-Exploits hier ansehen – https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
Es gibt eine Menge verschiedener lokaler Privilege Escalation Exploits, die für verschiedene Kernel und Betriebssysteme öffentlich verfügbar sind. Ob Sie mit einem Kernel-Exploit Root-Zugriff auf einen Linux-Host erhalten können, hängt davon ab, ob der Kernel verwundbar ist oder nicht. Kali Linux hat eine lokale Kopie von Exploit-db-Exploits, die die Suche nach lokalen Root-Exploits erleichtern. Ich würde jedoch nicht empfehlen, sich bei der Suche nach Linux-Kernel-Exploits vollständig auf diese Datenbank zu verlassen.
$ searchsploit Linux Kernel 2.6.24 – Sie zeigt uns alle verfügbaren Exploits für einen bestimmten Linux-Kernel, die bereits in Kali-Linux vorhanden sind.
Warum Sie es vermeiden sollten, einen lokalen Privilege Escalation Exploit an erster Stelle auszuführen?
Obwohl es sich sehr verlockend anfühlt, einfach einen Exploit zu starten und Root-Zugriff zu erhalten, sollten Sie dies immer als letzte Möglichkeit offen lassen.
1. Der entfernte Rechner könnte abstürzen, da viele der öffentlich verfügbaren Root-Exploits nicht sehr stabil sind.
2. Sie könnten Root-Zugriff erhalten und dann die Box zum Absturz bringen.
3. Der Exploit könnte Spuren/Logs hinterlassen, die Sie abfangen können.
Sie sollten immer die anderen Techniken ausprobieren, um Root zu bekommen, die wir weiter unten besprochen haben, bevor Sie direkt zur Ausführung eines lokalen Root-Exploits springen.
Gegenmaßnahmen
- Halten Sie den Kernel gepatcht und aktualisiert.
2. Ausnutzen von Diensten, die als root laufen
Wenn Sie einen Dienst ausnutzen, der als Root läuft, erhalten Sie Root!
Der berühmte EternalBlue- und SambaCry-Exploit, ein exploiteter smb-Dienst, der im Allgemeinen als Root läuft.
Mit nur einem Exploit kann ein Angreifer auch entfernte Codeausführung und Local Privilege Escalation erreichen.
Er wurde wegen seiner tödlichen Kombination stark zur weltweiten Verbreitung von Lösegeldforderungen genutzt.
Sie sollten immer prüfen, ob Webserver, Mailserver, Datenbankserver usw. als Root laufen. Viele Male lassen Web-Administratoren diese Dienste als root laufen und vergessen dabei die Sicherheitsprobleme, die dies verursachen könnte. Es könnte Dienste geben, die lokal laufen und nicht öffentlich zugänglich sind, die ebenfalls ausgenutzt werden können.
$ netstat -antup – Es zeigt Ihnen alle Ports, die offen sind und lauschen. Wir können für lokal laufende Dienste prüfen, ob sie ausgenutzt werden können oder nicht.
Ausnutzen einer verwundbaren Version von MySQL, die als Root läuft, um Root-Zugriff zu erhalten
Mit dem Exploit der MySQL UDF Dynamic Library können Sie beliebige Befehle von der mysql-Shell aus ausführen. Wenn mysql mit Root-Privilegien läuft, werden die Befehle als root ausgeführt.
$ ps -aux | grep root – Es zeigt uns die Dienste, die als root laufen.
> Wir können beliebige Befehle ausführen, indem wir die MySQL-Shell benutzen, die als root ausgeführt wird.
Einer der größten Fehler, den Webadministratoren machen, ist es, einen Webserver mit Root-Rechten laufen zu lassen. Eine Befehlsinjektionsschwachstelle in der Webanwendung kann einen Angreifer zur Root-Shell führen. Dies ist ein klassisches Beispiel dafür, warum man niemals einen Dienst als root ausführen sollte, es sei denn, dies ist wirklich erforderlich.
Binäre Exploits eines Root-eigenen Programms sind weit weniger gefährlich als ein Kernel-Exploit, denn selbst wenn der Dienst abstürzt, stürzt der Host-Rechner nicht ab und die Dienste werden wahrscheinlich automatisch neu gestartet.
Gegenmaßnahmen
- Führen Sie niemals einen Dienst als root aus, wenn dies nicht wirklich erforderlich ist, insbesondere Web-, Datenbank- und Dateiserver.
3. Ausnutzung von SUID-Ausführungsdateien
SUID, was für set user ID steht, ist eine Linux-Funktion, die es Benutzern ermöglicht, eine Datei mit den Rechten eines bestimmten Benutzers auszuführen. Beispielsweise erfordert der Linux-Befehl ping in der Regel root-Berechtigungen, um rohe Netzwerk-Sockets zu öffnen. Durch Markierung des ping-Programms als SUID mit dem Eigentümer als root wird ping mit Root-Rechten immer dann ausgeführt, wenn ein Benutzer mit geringen Rechten das Programm ausführt.
> -rwsr-xr-x-x- Das Zeichen ‘s’ anstelle von ‘x’ zeigt an, dass das SUID-Bit gesetzt ist.
SUID ist eine Funktion, die bei richtiger Verwendung die Sicherheit von Linux tatsächlich erhöht. Das Problem ist, dass Administratoren unwissentlich gefährliche SUID-Konfigurationen einführen können, wenn sie Anwendungen von Drittanbietern installieren oder logische Konfigurationsänderungen vornehmen.
Eine große Anzahl von Sysadmins versteht nicht, wo das SUID-Bit gesetzt werden soll und wo nicht. Das SUID-Bit sollte insbesondere bei keinem Datei-Editor gesetzt werden, da ein Angreifer alle auf dem System vorhandenen Dateien überschreiben kann.
Ausnutzung einer anfälligen SUID-Ausführungsdatei, um Root-Zugriff zu erhalten
$ find / -perm -u=s -type f 2>/dev/null – Es druckt die ausführbaren Dateien, bei denen das SUID-Bit gesetzt ist.
$ ls -la /usr/local/bin/nmap – Bestätigen wir, ob nmap das SUID-Bit gesetzt hat oder nicht.
> Nmap hat das SUID-Bit gesetzt. Häufig setzen Administratoren das SUID-Bit auf nmap, damit es zum effizienten Scannen des Netzwerks verwendet werden kann, da alle nmap-Scantechniken nicht funktionieren, wenn Sie es nicht mit Root-Rechten ausführen.
> Es gibt jedoch eine Funktionalität in älteren nmap-Versionen, mit der Sie nmap in einem interaktiven Modus laufen lassen können, der es Ihnen erlaubt, zur Shell zu wechseln. Wenn nmap das SUID-Bit gesetzt hat, läuft es mit Root-Privilegien und wir können über seinen interaktiven Modus Zugriff auf die ‘root’-Shell erhalten.
$ nmap -interaktiv – lässt nmap im interaktiven Modus laufen
$ !sh – Lässt Sie von der nmap-Shell auf die System-Shell entkommen
Gegenmaßnahmen
- Das SUID-Bit sollte nicht auf ein Programm gesetzt werden, mit dem Sie auf die Shell entkommen können.
- Sie sollten niemals das SUID-Bit bei einem Datei-Editor/Compiler/Interpreter setzen, da ein Angreifer leicht alle auf dem System vorhandenen Dateien lesen/überschreiben kann.
4. Ausnutzung von SUDO-Rechten/Benutzer
Wenn der Angreifer nicht direkt über andere Techniken Root-Zugriff erhalten kann, könnte er versuchen, jeden der Benutzer zu kompromittieren, die SUDO-Zugriff haben. Sobald er Zugriff auf einen der SUDO-Benutzer hat, kann er im Grunde genommen alle Befehle mit Root-Rechten ausführen.
Administratoren könnten den Benutzern nur erlauben, einige wenige Befehle über SUDO auszuführen und nicht alle, aber selbst mit dieser Konfiguration könnten sie unwissentlich Schwachstellen einführen, die zu Privilege Escalation führen können.
Ein klassisches Beispiel hierfür ist die Zuweisung von SUDO-Rechten an den Suchbefehl, damit ein anderer Benutzer nach bestimmten Dateien/Protokollen im System suchen kann. Während der Administrator möglicherweise nicht weiß, dass der Befehl “find” Parameter für die Befehlsausführung enthält, kann ein Angreifer Befehle mit Root-Rechten ausführen.
Ausnutzung falsch konfigurierter SUDO-Rechte, um Root-Zugriff zu erhalten
$ sudo -l – Zeigt die Befehle, die wir als SUDO ausführen dürfen
Wir können find, cat und python als SUDO laufen lassen. Alle diese Befehle werden als root ausgeführt, wenn sie mit SUDO ausgeführt werden. Wenn wir irgendwie durch einen dieser Befehle auf die Shell entkommen können, können wir Root-Zugriff erhalten.
$ sudo find /home -exec sh -i \; – der exec-Parameter des Befehls find kann für die Ausführung von beliebigem Code verwendet werden.
> Geben Sie niemals SUDO-Rechte an Compiler, Interpreter und Editoren der Programmiersprache.
> Diese Technik kann auch auf vi, more, less, perl, ruby, gdb und andere angewendet werden.
$ sudo python -c ‘import pty;pty.spawn(“/bin/bash”);’ – spawns eine Shell
Gegenmaßnahmen
- Geben Sie keinem Programm, das Sie auf die Shell entkommen lässt, Sudo-Rechte.
- Geben Sie niemals SUDO-Rechte an vi, more, less, nmap, perl, ruby, python, gdb und anderen.
5. Ausnutzung schlecht konfigurierter Cron-Jobs
Cron-Jobs können, wenn sie nicht richtig konfiguriert sind, ausgenutzt werden, um Root-Privilegien zu erhalten.
1. Gibt es Skripte oder Binärdateien in Cron-Jobs, die beschreibbar sind?
2. Können wir über die Cron-Datei selbst schreiben?
3. Ist das Verzeichnis cron.d beschreibbar?
Cron-Jobs laufen im Allgemeinen mit Root-Rechten. Wenn wir jedes Skript oder jede Binärdatei, die in den Cron-Jobs definiert sind, erfolgreich manipulieren können, dann können wir beliebigen Code mit Root-Privilegien ausführen.
Ausnutzung schlecht konfigurierter Cron-Jobs, um Root-Zugriff zu erhalten
$ ls -la /etc/cron.d – zeigt Cron-Jobs, die bereits in cron.d vorhanden sind
$ find / -perm -2 -type f 2>/dev/null – zeigt weltweit beschreibbare Dateien
$ ls -la /usr/local/sbin/cron-logrotate.sh – Bestätigen wir, ob die cron-logrotate.sh weltweit beschreibbar ist.
> cron-lograte.sh ist weltbeschreibbar und wird von logrotate cronjob ausgeführt. Jeder Befehl, den wir in cron-lograte.sh schreiben/anhängen, würde als ‘root’ ausgeführt werden.
> Wir schreiben eine C-Datei in das Verzeichnis /tmp und kompilieren sie.
> Die ausführbare Rootme-Datei wird eine Shell erzeugen.
$ ls -la rootme – Es sagt uns, dass es dem Benutzer ‘SHayslett’ gehört.
$ echo “chown root:root /tmp/rootme; chmod u+s /tmp/rootme;”>/usr/local/sbin/cron-logrotate.sh – Dies ändert den Eigentümer und die Gruppe der ausführbaren Datei als root. Es wird auch das SUID-Bit gesetzt.
$ ls -la rootme – Nach 5 Minuten wurde der Logrotate-Cronjob ausgeführt und cron-logrotate.sh wurde mit Root-Rechten ausgeführt.
$ ./rootme – erzeugt eine Root-Shell.
Gegenmaßnahmen
- Alle Skripte oder Binärdateien, die in Cron-Jobs definiert sind, sollten nicht schreibbar sein.
- cron-Datei sollte von niemandem außer root schreibbar sein.
- Das Verzeichnis cron.d sollte für niemanden außer root schreibbar sein.
6. Ausnutzen von Benutzern mit ‘.’ in ihrem PATH
Das Vorhandensein von ‘.’ in Ihrem PATH bedeutet, dass der Benutzer in der Lage ist, Binärdateien/Skripte aus dem aktuellen Verzeichnis auszuführen. Um zu vermeiden, dass diese beiden zusätzlichen Zeichen jedes Mal eingegeben werden müssen, fügt der Benutzer ‘.’ zu seinem PATH hinzu. Dies kann eine ausgezeichnete Methode für einen Angreifer sein, sein Privilege Escalation zu erweitern.
Nehmen wir an, Susan ist Administratorin und fügt in ihrem Pfad ‘.’ hinzu, so dass sie die 2 Zeichen nicht noch einmal schreiben muss.
Mit ‘.’ im Pfad – Programm
Ohne ‘.’ im Pfad – ./Programm
Dies geschieht, weil Linux zuerst im aktuellen Verzeichnis nach dem Programm sucht, wenn ‘.’ am Anfang im PATH hinzugefügt wird, und dann an anderer Stelle sucht.
> Ein anderer Benutzer ‘rashid’ wusste, dass susan ‘.’ in ihrem PATH hinzugefügt hat, weil sie faul ist
> rashid teilt susan mit, dass ‘ls’-Befehl in seinem Verzeichnis nicht funktioniert
> rashid fügt in seinem Verzeichnis einen Code hinzu, der die Datei sudoers ändert und ihn zum Administrator macht
> rashid speichert diesen Code in einer Datei mit dem Namen ‘ls’ und macht ihn ausführbar
> susan hat root-Rechte. Sie kommt und führt den Befehl ‘ls’ im Home-Verzeichnis von rashid aus
> Anstelle des ursprünglichen Befehls ‘ls’ wird der bösartige Code mit Root-Zugriff ausgeführt> In einer Datei, die als ‘ls’ gespeichert ist, wurde ein Code hinzugefügt, der “Hello world” ausgibt
$ PATH=.:${PATH} – fügt ‘.’ in die Variable PATH ein
$ ls – führt ./ls-Datei aus anstatt eine Übersicht (list) auszugeben
> Wenn nun ein Root-Benutzer den Code mit Root-Privileg ausführt, können wir beliebige Codeausführung mit Root-Privileg erreichen.