Linux Privilege Escalation
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lass uns beginnen, einige Kenntnisse über das laufende OS zu gewinnen.
Wenn Sie Schreibberechtigungen für einen Ordner innerhalb der PATH
-Variablen haben, könnten Sie in der Lage sein, einige Bibliotheken oder Binärdateien zu übernehmen:
Interessante Informationen, Passwörter oder API-Schlüssel in den Umgebungsvariablen?
Überprüfen Sie die Kernel-Version und ob es einen Exploit gibt, der verwendet werden kann, um die Berechtigungen zu erhöhen.
Sie können eine gute Liste verwundbarer Kernel und einige bereits kompilierte Exploits hier finden: https://github.com/lucyoa/kernel-exploits und exploitdb sploits. Andere Seiten, auf denen Sie einige kompilierte Exploits finden können: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack
Um alle verwundbaren Kernel-Versionen von dieser Website zu extrahieren, können Sie Folgendes tun:
Tools, die bei der Suche nach Kernel-Exploits helfen könnten, sind:
linux-exploit-suggester.sh linux-exploit-suggester2.pl linuxprivchecker.py (ausführen IM Opfer, überprüft nur Exploits für Kernel 2.x)
Immer die Kernel-Version in Google suchen, vielleicht ist Ihre Kernel-Version in einem bestimmten Kernel-Exploit aufgeführt und dann sind Sie sich sicher, dass dieser Exploit gültig ist.
Linux Privilege Escalation - Linux Kernel <= 3.19.0-73.8
Basierend auf den anfälligen sudo-Versionen, die erscheinen in:
You can check if the sudo version is vulnerable using this grep. Sie können überprüfen, ob die sudo-Version anfällig ist, indem Sie dieses grep verwenden.
Von @sickrov
Überprüfen Sie smasher2 box of HTB für ein Beispiel, wie diese Schwachstelle ausgenutzt werden könnte.
Wenn Sie sich in einem Docker-Container befinden, können Sie versuchen, daraus zu entkommen:
Docker SecurityÜberprüfen Sie was gemountet und ungemountet ist, wo und warum. Wenn etwas ungemountet ist, könnten Sie versuchen, es zu mounten und nach privaten Informationen zu suchen.
Zähle nützliche Binaries auf
Auch überprüfen, ob irgendein Compiler installiert ist. Dies ist nützlich, wenn Sie einen Kernel-Exploit verwenden müssen, da es empfohlen wird, ihn auf der Maschine zu kompilieren, auf der Sie ihn verwenden möchten (oder auf einer ähnlichen).
Überprüfen Sie die Version der installierten Pakete und Dienste. Möglicherweise gibt es eine alte Nagios-Version (zum Beispiel), die ausgenutzt werden könnte, um Privilegien zu eskalieren… Es wird empfohlen, die Version der verdächtigeren installierten Software manuell zu überprüfen.
Wenn Sie SSH-Zugriff auf die Maschine haben, können Sie auch openVAS verwenden, um nach veralteter und anfälliger Software zu suchen, die auf der Maschine installiert ist.
Beachten Sie, dass diese Befehle viele Informationen anzeigen, die größtenteils nutzlos sein werden. Daher wird empfohlen, einige Anwendungen wie OpenVAS oder ähnliche zu verwenden, die überprüfen, ob eine installierte Softwareversion anfällig für bekannte Exploits ist.
Werfen Sie einen Blick darauf, welche Prozesse ausgeführt werden, und überprüfen Sie, ob ein Prozess mehr Berechtigungen hat, als er sollte (vielleicht ein Tomcat, der von root ausgeführt wird?)
Immer nach möglichen [electron/cef/chromium Debuggern] suchen, die ausgeführt werden, da Sie diese möglicherweise missbrauchen können, um Privilegien zu eskalieren. Linpeas erkennt diese, indem es den --inspect
Parameter in der Befehlszeile des Prozesses überprüft.
Überprüfen Sie auch Ihre Berechtigungen über die Binärdateien der Prozesse, vielleicht können Sie jemanden überschreiben.
Sie können Tools wie pspy verwenden, um Prozesse zu überwachen. Dies kann sehr nützlich sein, um anfällige Prozesse zu identifizieren, die häufig ausgeführt werden oder wenn eine Reihe von Anforderungen erfüllt sind.
Einige Dienste eines Servers speichern Anmeldeinformationen im Klartext im Speicher. Normalerweise benötigen Sie Root-Rechte, um den Speicher von Prozessen zu lesen, die anderen Benutzern gehören, daher ist dies normalerweise nützlicher, wenn Sie bereits Root sind und mehr Anmeldeinformationen entdecken möchten. Denken Sie jedoch daran, dass Sie als regulärer Benutzer den Speicher der Prozesse, die Sie besitzen, lesen können.
Beachten Sie, dass die meisten Maschinen heutzutage ptrace standardmäßig nicht zulassen, was bedeutet, dass Sie keine anderen Prozesse, die Ihrem unprivilegierten Benutzer gehören, dumpen können.
Die Datei /proc/sys/kernel/yama/ptrace_scope steuert die Zugänglichkeit von ptrace:
kernel.yama.ptrace_scope = 0: Alle Prozesse können debuggt werden, solange sie die gleiche UID haben. Dies ist die klassische Art, wie ptracing funktionierte.
kernel.yama.ptrace_scope = 1: Nur ein übergeordneter Prozess kann debuggt werden.
kernel.yama.ptrace_scope = 2: Nur Admin kann ptrace verwenden, da es die CAP_SYS_PTRACE Fähigkeit erfordert.
kernel.yama.ptrace_scope = 3: Es dürfen keine Prozesse mit ptrace verfolgt werden. Ein Neustart ist erforderlich, um das ptracing wieder zu aktivieren, sobald es festgelegt ist.
Wenn Sie Zugriff auf den Speicher eines FTP-Dienstes (zum Beispiel) haben, könnten Sie den Heap abrufen und darin nach Anmeldeinformationen suchen.
Für eine gegebene Prozess-ID zeigt maps, wie der Speicher innerhalb des virtuellen Adressraums dieses Prozesses abgebildet ist; es zeigt auch die Berechtigungen jeder abgebildeten Region. Die mem Pseudo-Datei stellt den Speicher der Prozesse selbst zur Verfügung. Aus der maps-Datei wissen wir, welche Speicherregionen lesbar sind und ihre Offsets. Wir verwenden diese Informationen, um in die mem-Datei zu suchen und alle lesbaren Regionen in eine Datei zu dumpen.
/dev/mem
bietet Zugriff auf den physischen Speicher des Systems, nicht auf den virtuellen Speicher. Der virtuelle Adressraum des Kernels kann über /dev/kmem zugegriffen werden.
Typischerweise ist /dev/mem
nur für root und die kmem-Gruppe lesbar.
ProcDump ist eine Linux-Neuinterpretation des klassischen ProcDump-Tools aus der Sysinternals-Suite von Tools für Windows. Erhalten Sie es unter https://github.com/Sysinternals/ProcDump-for-Linux
Um den Speicher eines Prozesses zu dumpen, können Sie Folgendes verwenden:
https://github.com/hajzer/bash-memory-dump (root) - _Sie können die Root-Anforderungen manuell entfernen und den von Ihnen besessenen Prozess dumpen
Skript A.5 von https://www.delaat.net/rp/2016-2017/p97/report.pdf (Root ist erforderlich)
Wenn Sie feststellen, dass der Authenticator-Prozess läuft:
Sie können den Prozess dumpen (siehe vorherige Abschnitte, um verschiedene Möglichkeiten zum Dumpen des Speichers eines Prozesses zu finden) und nach Anmeldeinformationen im Speicher suchen:
Das Tool https://github.com/huntergregal/mimipenguin wird Klartext-Anmeldeinformationen aus dem Speicher stehlen und aus einigen bekannten Dateien. Es erfordert Root-Rechte, um ordnungsgemäß zu funktionieren.
GDM-Passwort (Kali Desktop, Debian Desktop)
gdm-password
Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop)
gnome-keyring-daemon
LightDM (Ubuntu Desktop)
lightdm
VSFTPd (Aktive FTP-Verbindungen)
vsftpd
Apache2 (Aktive HTTP-Basic-Auth-Sitzungen)
apache2
OpenSSH (Aktive SSH-Sitzungen - Sudo-Nutzung)
sshd:
Überprüfen Sie, ob ein geplanter Job anfällig ist. Vielleicht können Sie einen Vorteil aus einem von root ausgeführten Skript ziehen (Wildcard-Schwachstelle? Kann Dateien ändern, die root verwendet? Symlinks verwenden? Bestimmte Dateien im Verzeichnis erstellen, das root verwendet?).
Zum Beispiel finden Sie im /etc/crontab den PATH: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
(Beachten Sie, dass der Benutzer "user" Schreibrechte über /home/user hat)
Wenn der Root-Benutzer in diesem Crontab versucht, einen Befehl oder ein Skript auszuführen, ohne den Pfad festzulegen. Zum Beispiel: * * * * root overwrite.sh Dann können Sie eine Root-Shell erhalten, indem Sie:
Wenn ein Skript, das von root ausgeführt wird, ein „*“ innerhalb eines Befehls hat, könnten Sie dies ausnutzen, um unerwartete Dinge zu verursachen (wie privesc). Beispiel:
Wenn das Wildcard von einem Pfad wie /some/path/* vorgegangen wird, ist es nicht anfällig (sogar ./* ist es nicht).
Lesen Sie die folgende Seite für weitere Tricks zur Ausnutzung von Wildcards:
Wildcards Spare tricksWenn Sie ein Cron-Skript, das von root ausgeführt wird, ändern können, können Sie sehr einfach eine Shell erhalten:
Wenn das von root ausgeführte Skript ein Verzeichnis verwendet, auf das Sie vollen Zugriff haben, könnte es nützlich sein, diesen Ordner zu löschen und einen Symlink-Ordner zu einem anderen zu erstellen, der ein von Ihnen kontrolliertes Skript bereitstellt.
Sie können die Prozesse überwachen, um nach Prozessen zu suchen, die alle 1, 2 oder 5 Minuten ausgeführt werden. Vielleicht können Sie dies ausnutzen und die Berechtigungen erhöhen.
Zum Beispiel, um alle 0,1 Sekunden während 1 Minute zu überwachen, nach weniger ausgeführten Befehlen zu sortieren und die Befehle zu löschen, die am häufigsten ausgeführt wurden, können Sie Folgendes tun:
Sie können auch pspy (dies wird jeden Prozess überwachen und auflisten, der gestartet wird).
Es ist möglich, einen Cronjob zu erstellen, indem man einen Wagenrücklauf nach einem Kommentar einfügt (ohne Zeilenumbruchzeichen), und der Cronjob wird funktionieren. Beispiel (beachten Sie das Wagenrücklaufzeichen):
Überprüfen Sie, ob Sie eine .service
-Datei schreiben können. Wenn ja, könnten Sie sie ändern, sodass sie Ihre Hintertür ausführt, wenn der Dienst gestartet, neu gestartet oder gestoppt wird (vielleicht müssen Sie warten, bis die Maschine neu gestartet wird).
Erstellen Sie beispielsweise Ihre Hintertür innerhalb der .service-Datei mit ExecStart=/tmp/script.sh
Behalten Sie im Hinterkopf, dass Sie, wenn Sie Schreibberechtigungen für von Diensten ausgeführte Binärdateien haben, diese durch Hintertüren ändern können, sodass beim erneuten Ausführen der Dienste die Hintertüren ausgeführt werden.
Sie können den von systemd verwendeten PATH mit:
Wenn Sie feststellen, dass Sie in einem der Ordner des Pfades schreiben können, könnten Sie in der Lage sein, Privilegien zu eskalieren. Sie müssen nach relativen Pfaden, die in Dienstkonfigurations dateien verwendet werden, suchen, wie:
Dann erstellen Sie ein ausführbares Programm mit dem gleichen Namen wie der relative Pfad-Binärdatei im systemd PATH-Ordner, in den Sie schreiben können, und wenn der Dienst aufgefordert wird, die verwundbare Aktion (Start, Stop, Reload) auszuführen, wird Ihr Backdoor ausgeführt (nicht privilegierte Benutzer können normalerweise keine Dienste starten/stoppen, aber überprüfen Sie, ob Sie sudo -l
verwenden können).
Erfahren Sie mehr über Dienste mit man systemd.service
.
Timer sind systemd-Einheitendateien, deren Name mit **.timer**
endet und die **.service**
-Dateien oder Ereignisse steuern. Timer können als Alternative zu cron verwendet werden, da sie integrierte Unterstützung für Kalenderzeitereignisse und monotone Zeitereignisse haben und asynchron ausgeführt werden können.
Sie können alle Timer mit auflisten:
Wenn Sie einen Timer ändern können, können Sie ihn dazu bringen, einige Instanzen von systemd.unit (wie eine .service
oder eine .target
) auszuführen.
In der Dokumentation können Sie lesen, was die Einheit ist:
Die Einheit, die aktiviert werden soll, wenn dieser Timer abläuft. Das Argument ist ein Einheitsname, dessen Suffix nicht ".timer" ist. Wenn nicht angegeben, wird dieser Wert standardmäßig auf einen Dienst gesetzt, der denselben Namen wie die Timer-Einheit hat, mit Ausnahme des Suffixes. (Siehe oben.) Es wird empfohlen, dass der aktivierte Einheitsname und der Einheitsname der Timer-Einheit identisch benannt sind, mit Ausnahme des Suffixes.
Daher müssten Sie, um diese Berechtigung auszunutzen:
Eine systemd-Einheit (wie eine .service
) finden, die eine beschreibbare Binärdatei ausführt
Eine systemd-Einheit finden, die einen relativen Pfad ausführt und über schreibbare Berechtigungen über den systemd PATH verfügt (um diese ausführbare Datei zu impersonifizieren)
Erfahren Sie mehr über Timer mit man systemd.timer
.
Um einen Timer zu aktivieren, benötigen Sie Root-Rechte und müssen Folgendes ausführen:
Note the timer is activated by creating a symlink to it on /etc/systemd/system/<WantedBy_section>.wants/<name>.timer
Unix Domain Sockets (UDS) ermöglichen die Prozesskommunikation auf derselben oder verschiedenen Maschinen innerhalb von Client-Server-Modellen. Sie nutzen standardmäßige Unix-Beschreibungsdateien für die intercomputerliche Kommunikation und werden über .socket
-Dateien eingerichtet.
Sockets können mit .socket
-Dateien konfiguriert werden.
Erfahren Sie mehr über Sockets mit man systemd.socket
. In dieser Datei können mehrere interessante Parameter konfiguriert werden:
ListenStream
, ListenDatagram
, ListenSequentialPacket
, ListenFIFO
, ListenSpecial
, ListenNetlink
, ListenMessageQueue
, ListenUSBFunction
: Diese Optionen sind unterschiedlich, aber eine Zusammenfassung wird verwendet, um anzuzeigen, wo es auf den Socket hören wird (der Pfad der AF_UNIX-Socket-Datei, die IPv4/6 und/oder Portnummer, auf die gehört werden soll, usw.)
Accept
: Nimmt ein boolesches Argument. Wenn true, wird eine Service-Instanz für jede eingehende Verbindung erstellt und nur der Verbindungs-Socket wird an sie übergeben. Wenn false, werden alle hörenden Sockets selbst an die gestartete Service-Einheit übergeben, und es wird nur eine Service-Einheit für alle Verbindungen erstellt. Dieser Wert wird für Datagram-Sockets und FIFOs ignoriert, bei denen eine einzelne Service-Einheit bedingungslos den gesamten eingehenden Verkehr verarbeitet. Standardmäßig false. Aus Leistungsgründen wird empfohlen, neue Daemons nur so zu schreiben, dass sie für Accept=no
geeignet sind.
ExecStartPre
, ExecStartPost
: Nimmt eine oder mehrere Befehlszeilen, die vor oder nach dem Erstellen und Binden der hörenden Sockets/FIFOs ausgeführt werden. Das erste Token der Befehlszeile muss ein absoluter Dateiname sein, gefolgt von Argumenten für den Prozess.
ExecStopPre
, ExecStopPost
: Zusätzliche Befehle, die vor oder nach dem Schließen und Entfernen der hörenden Sockets/FIFOs ausgeführt werden.
Service
: Gibt den Namen der Service-Einheit an, die bei eingehendem Verkehr aktiviert werden soll. Diese Einstellung ist nur für Sockets mit Accept=no zulässig. Sie wird standardmäßig auf den Service gesetzt, der denselben Namen wie der Socket trägt (mit dem ersetzten Suffix). In den meisten Fällen sollte es nicht notwendig sein, diese Option zu verwenden.
Wenn Sie eine beschreibbare .socket
-Datei finden, können Sie am Anfang des [Socket]
-Abschnitts etwas hinzufügen wie: ExecStartPre=/home/kali/sys/backdoor
und die Hintertür wird ausgeführt, bevor der Socket erstellt wird. Daher müssen Sie wahrscheinlich warten, bis die Maschine neu gestartet wird.
&#xNAN;Note that the system must be using that socket file configuration or the backdoor won't be executed
Wenn Sie irgendeinen beschreibbaren Socket identifizieren (jetzt sprechen wir über Unix-Sockets und nicht über die Konfigurations-.socket-Dateien), dann können Sie mit diesem Socket kommunizieren und möglicherweise eine Schwachstelle ausnutzen.
Exploitation Beispiel:
Socket Command InjectionBeachten Sie, dass es einige Sockets geben kann, die auf HTTP-Anfragen hören (ich spreche nicht von .socket-Dateien, sondern von den Dateien, die als Unix-Sockets fungieren). Sie können dies überprüfen mit:
Wenn der Socket mit einer HTTP-Anfrage antwortet, können Sie mit ihm kommunizieren und möglicherweise eine Schwachstelle ausnutzen.
Der Docker-Socket, der häufig unter /var/run/docker.sock
zu finden ist, ist eine kritische Datei, die gesichert werden sollte. Standardmäßig ist er für den root
-Benutzer und Mitglieder der docker
-Gruppe schreibbar. Schreibzugriff auf diesen Socket kann zu einer Privilegieneskalation führen. Hier ist eine Übersicht, wie dies geschehen kann und alternative Methoden, falls die Docker-CLI nicht verfügbar ist.
Wenn Sie Schreibzugriff auf den Docker-Socket haben, können Sie die Privilegien mit den folgenden Befehlen eskalieren:
Diese Befehle ermöglichen es Ihnen, einen Container mit Root-Zugriff auf das Dateisystem des Hosts auszuführen.
In Fällen, in denen die Docker-CLI nicht verfügbar ist, kann der Docker-Socket weiterhin mit der Docker-API und curl
-Befehlen manipuliert werden.
Docker-Images auflisten: Holen Sie sich die Liste der verfügbaren Images.
Einen Container erstellen: Senden Sie eine Anfrage, um einen Container zu erstellen, der das Root-Verzeichnis des Host-Systems einbindet.
Starten Sie den neu erstellten Container:
An den Container anhängen: Verwenden Sie socat
, um eine Verbindung zum Container herzustellen, die die Ausführung von Befehlen innerhalb des Containers ermöglicht.
Nachdem die socat
-Verbindung eingerichtet ist, können Sie Befehle direkt im Container mit Root-Zugriff auf das Dateisystem des Hosts ausführen.
Beachten Sie, dass Sie, wenn Sie Schreibberechtigungen über den Docker-Socket haben, weil Sie innerhalb der Gruppe docker
sind, mehr Möglichkeiten zur Eskalation von Rechten haben. Wenn die Docker-API an einem Port lauscht, können Sie sie möglicherweise ebenfalls kompromittieren.
Überprüfen Sie weitere Möglichkeiten, aus Docker auszubrechen oder es zu missbrauchen, um Privilegien zu eskalieren in:
Docker SecurityWenn Sie feststellen, dass Sie den ctr
-Befehl verwenden können, lesen Sie die folgende Seite, da Sie ihn möglicherweise missbrauchen können, um Privilegien zu eskalieren:
Wenn Sie feststellen, dass Sie den runc
-Befehl verwenden können, lesen Sie die folgende Seite, da Sie ihn möglicherweise missbrauchen können, um Privilegien zu eskalieren:
D-Bus ist ein ausgeklügeltes Inter-Process Communication (IPC) System, das es Anwendungen ermöglicht, effizient zu interagieren und Daten auszutauschen. Es wurde mit dem modernen Linux-System im Hinterkopf entwickelt und bietet ein robustes Framework für verschiedene Formen der Anwendungskommunikation.
Das System ist vielseitig und unterstützt grundlegendes IPC, das den Datenaustausch zwischen Prozessen verbessert, ähnlich wie erweiterte UNIX-Domänensockets. Darüber hinaus hilft es beim Broadcasten von Ereignissen oder Signalen, was eine nahtlose Integration zwischen Systemkomponenten fördert. Zum Beispiel kann ein Signal von einem Bluetooth-Daemon über einen eingehenden Anruf einen Musikplayer dazu bringen, sich stummzuschalten, was die Benutzererfahrung verbessert. Darüber hinaus unterstützt D-Bus ein Remote-Objektsystem, das Serviceanfragen und Methodenaufrufe zwischen Anwendungen vereinfacht und Prozesse optimiert, die traditionell komplex waren.
D-Bus arbeitet nach einem Erlauben/Verweigern-Modell, das die Nachrichtenberechtigungen (Methodenaufrufe, Signalübertragungen usw.) basierend auf der kumulativen Wirkung übereinstimmender Richtlinienregeln verwaltet. Diese Richtlinien spezifizieren Interaktionen mit dem Bus und können möglicherweise eine Privilegieneskalation durch die Ausnutzung dieser Berechtigungen ermöglichen.
Ein Beispiel für eine solche Richtlinie in /etc/dbus-1/system.d/wpa_supplicant.conf
wird bereitgestellt, die die Berechtigungen für den Root-Benutzer beschreibt, um Nachrichten von fi.w1.wpa_supplicant1
zu besitzen, zu senden und zu empfangen.
Richtlinien ohne einen angegebenen Benutzer oder eine Gruppe gelten universell, während "Standard"-Kontextrichtlinien für alle gelten, die nicht von anderen spezifischen Richtlinien abgedeckt sind.
Erfahren Sie hier, wie Sie eine D-Bus-Kommunikation auflisten und ausnutzen können:
D-Bus Enumeration & Command Injection Privilege EscalationEs ist immer interessant, das Netzwerk aufzulisten und die Position der Maschine herauszufinden.
Überprüfen Sie immer die Netzwerkdienste, die auf der Maschine laufen, mit der Sie zuvor nicht interagieren konnten, bevor Sie darauf zugreifen:
Überprüfen Sie, ob Sie den Datenverkehr sniffen können. Wenn ja, könnten Sie in der Lage sein, einige Anmeldeinformationen zu erfassen.
Überprüfen Sie wer Sie sind, welche Berechtigungen Sie haben, welche Benutzer im System sind, welche sich anmelden können und welche Root-Berechtigungen haben:
Einige Linux-Versionen waren von einem Fehler betroffen, der es Benutzern mit UID > INT_MAX ermöglicht, Privilegien zu eskalieren. Weitere Informationen: hier, hier und hier.
Nutze es aus mit: systemd-run -t /bin/bash
Überprüfe, ob du Mitglied einer Gruppe bist, die dir Root-Rechte gewähren könnte:
Interesting Groups - Linux PrivescÜberprüfe, ob sich etwas Interessantes in der Zwischenablage befindet (wenn möglich)
Wenn Sie ein Passwort der Umgebung kennen, versuchen Sie sich als jeder Benutzer mit dem Passwort anzumelden.
Wenn es Ihnen nichts ausmacht, viel Lärm zu machen und die su
- und timeout
-Binaries auf dem Computer vorhanden sind, können Sie versuchen, Benutzer mit su-bruteforce zu brute-forcen.
Linpeas mit dem Parameter -a
versucht ebenfalls, Benutzer zu brute-forcen.
Wenn Sie feststellen, dass Sie in einen Ordner des $PATH schreiben können, könnten Sie in der Lage sein, Privilegien zu eskalieren, indem Sie eine Hintertür im beschreibbaren Ordner mit dem Namen eines Befehls erstellen, der von einem anderen Benutzer (idealerweise root) ausgeführt wird und der nicht aus einem Ordner geladen wird, der vor Ihrem beschreibbaren Ordner im $PATH liegt.
Es könnte Ihnen erlaubt sein, einige Befehle mit sudo auszuführen oder sie könnten das suid-Bit haben. Überprüfen Sie dies mit:
Einige unerwartete Befehle ermöglichen es Ihnen, Dateien zu lesen und/oder zu schreiben oder sogar einen Befehl auszuführen. Zum Beispiel:
Die Sudo-Konfiguration könnte es einem Benutzer ermöglichen, einen Befehl mit den Rechten eines anderen Benutzers auszuführen, ohne das Passwort zu kennen.
In diesem Beispiel kann der Benutzer demo
vim
als root
ausführen, es ist jetzt trivial, eine Shell zu erhalten, indem man einen SSH-Schlüssel in das Root-Verzeichnis hinzufügt oder sh
aufruft.
Diese Direktive ermöglicht es dem Benutzer, eine Umgebungsvariable beim Ausführen von etwas festzulegen:
Dieses Beispiel, basierend auf der HTB-Maschine Admirer, war anfällig für PYTHONPATH-Hijacking, um eine beliebige Python-Bibliothek zu laden, während das Skript als Root ausgeführt wurde:
Springen Sie, um andere Dateien zu lesen oder verwenden Sie Symlinks. Zum Beispiel in der sudoers-Datei: hacker10 ALL= (root) /bin/less /var/log/*
Wenn ein Wildcard verwendet wird (*), ist es noch einfacher:
Gegenmaßnahmen: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/
Wenn die sudo-Berechtigung für einen einzelnen Befehl ohne Angabe des Pfades gewährt wird: hacker10 ALL= (root) less, kannst du dies ausnutzen, indem du die PATH-Variable änderst.
Diese Technik kann auch verwendet werden, wenn eine suid-Binärdatei einen anderen Befehl ausführt, ohne den Pfad dazu anzugeben (überprüfen Sie immer mit strings den Inhalt einer seltsamen SUID-Binärdatei).
Payload-Beispiele zur Ausführung.
Wenn die suid-Binärdatei einen anderen Befehl unter Angabe des Pfades ausführt, können Sie versuchen, eine Funktion zu exportieren, die den Namen des Befehls trägt, den die SUID-Datei aufruft.
Wenn eine SUID-Binärdatei beispielsweise /usr/sbin/service apache2 start aufruft, müssen Sie versuchen, die Funktion zu erstellen und zu exportieren:
Dann, wenn Sie die SUID-Binärdatei aufrufen, wird diese Funktion ausgeführt
Die LD_PRELOAD-Umgebungsvariable wird verwendet, um eine oder mehrere gemeinsam genutzte Bibliotheken (.so-Dateien) anzugeben, die vom Loader vor allen anderen, einschließlich der Standard-C-Bibliothek (libc.so
), geladen werden sollen. Dieser Prozess wird als Vorladen einer Bibliothek bezeichnet.
Um jedoch die Systemsicherheit aufrechtzuerhalten und zu verhindern, dass diese Funktion ausgenutzt wird, insbesondere bei suid/sgid-Ausführungen, setzt das System bestimmte Bedingungen durch:
Der Loader ignoriert LD_PRELOAD für Ausführungen, bei denen die echte Benutzer-ID (ruid) nicht mit der effektiven Benutzer-ID (euid) übereinstimmt.
Für Ausführungen mit suid/sgid werden nur Bibliotheken in Standardpfaden, die ebenfalls suid/sgid sind, vorab geladen.
Eine Privilegieneskalation kann auftreten, wenn Sie die Möglichkeit haben, Befehle mit sudo
auszuführen und die Ausgabe von sudo -l
die Aussage env_keep+=LD_PRELOAD enthält. Diese Konfiguration ermöglicht es, dass die LD_PRELOAD-Umgebungsvariable bestehen bleibt und auch erkannt wird, wenn Befehle mit sudo
ausgeführt werden, was potenziell zur Ausführung beliebigen Codes mit erhöhten Rechten führen kann.
Speichern als /tmp/pe.c
Dann kompiliere es mit:
Schließlich, Privilegien eskalieren durch Ausführen
Ein ähnlicher Privilegienausstieg kann missbraucht werden, wenn der Angreifer die LD_LIBRARY_PATH-Umgebungsvariable kontrolliert, da er den Pfad kontrolliert, in dem nach Bibliotheken gesucht wird.
Wenn man auf eine Binärdatei mit SUID-Berechtigungen stößt, die ungewöhnlich erscheint, ist es eine gute Praxis zu überprüfen, ob sie .so-Dateien ordnungsgemäß lädt. Dies kann überprüft werden, indem man den folgenden Befehl ausführt:
Zum Beispiel deutet das Auftreten eines Fehlers wie "open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)" auf ein potenzielles Exploitationsrisiko hin.
Um dies auszunutzen, würde man fortfahren, indem man eine C-Datei erstellt, sagen wir "/path/to/.config/libcalc.c", die den folgenden Code enthält:
Dieser Code, einmal kompiliert und ausgeführt, zielt darauf ab, die Berechtigungen zu erhöhen, indem er die Dateiberechtigungen manipuliert und eine Shell mit erhöhten Berechtigungen ausführt.
Kompilieren Sie die obige C-Datei in eine Shared Object (.so) Datei mit:
Schließlich sollte das Ausführen der betroffenen SUID-Binärdatei den Exploit auslösen, was zu einer potenziellen Kompromittierung des Systems führen kann.
Jetzt, da wir eine SUID-Binärdatei gefunden haben, die eine Bibliothek aus einem Ordner lädt, in den wir schreiben können, lassen Sie uns die Bibliothek in diesem Ordner mit dem erforderlichen Namen erstellen:
Wenn Sie einen Fehler wie erhalten
das bedeutet, dass die von Ihnen generierte Bibliothek eine Funktion namens a_function_name
haben muss.
GTFOBins ist eine kuratierte Liste von Unix-Binärdateien, die von einem Angreifer ausgenutzt werden können, um lokale Sicherheitsbeschränkungen zu umgehen. GTFOArgs ist dasselbe, aber für Fälle, in denen Sie nur Argumente in einen Befehl injizieren können.
Das Projekt sammelt legitime Funktionen von Unix-Binärdateien, die missbraucht werden können, um aus eingeschränkten Shells auszubrechen, Privilegien zu eskalieren oder aufrechtzuerhalten, Dateien zu übertragen, Bind- und Reverse-Shells zu erzeugen und andere Aufgaben nach der Ausnutzung zu erleichtern.
gdb -nx -ex '!sh' -ex quit sudo mysql -e '! /bin/sh' strace -o /dev/null /bin/sh sudo awk 'BEGIN {system("/bin/sh")}'
Wenn Sie auf sudo -l
zugreifen können, können Sie das Tool FallOfSudo verwenden, um zu überprüfen, ob es eine Möglichkeit findet, eine sudo-Regel auszunutzen.
In Fällen, in denen Sie sudo-Zugriff haben, aber nicht das Passwort, können Sie Privilegien eskalieren, indem Sie auf die Ausführung eines sudo-Befehls warten und dann das Sitzungstoken übernehmen.
Anforderungen zur Eskalation von Privilegien:
Sie haben bereits eine Shell als Benutzer "sampleuser"
"sampleuser" hat sudo
verwendet, um etwas in den letzten 15 Minuten auszuführen (standardmäßig ist das die Dauer des sudo-Tokens, das es uns ermöglicht, sudo
zu verwenden, ohne ein Passwort einzugeben)
cat /proc/sys/kernel/yama/ptrace_scope
ist 0
gdb
ist zugänglich (Sie sollten in der Lage sein, es hochzuladen)
(Sie können ptrace_scope
vorübergehend mit echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
aktivieren oder dauerhaft /etc/sysctl.d/10-ptrace.conf
ändern und kernel.yama.ptrace_scope = 0
setzen)
Wenn alle diese Anforderungen erfüllt sind, können Sie Privilegien eskalieren mit: https://github.com/nongiach/sudo_inject
Der erste Exploit (exploit.sh
) erstellt die Binärdatei activate_sudo_token
in /tmp. Sie können es verwenden, um das sudo-Token in Ihrer Sitzung zu aktivieren (Sie erhalten nicht automatisch eine Root-Shell, führen Sie sudo su
aus):
Der zweite Exploit (exploit_v2.sh
) erstellt eine sh-Shell in /tmp, die von root mit setuid besessen wird
Der dritte Exploit (exploit_v3.sh
) wird eine sudoers-Datei erstellen, die sudo-Token ewig macht und allen Benutzern erlaubt, sudo zu verwenden
Wenn Sie Schreibberechtigungen im Ordner oder auf einer der darin erstellten Dateien haben, können Sie die Binärdatei write_sudo_token verwenden, um ein sudo-Token für einen Benutzer und PID zu erstellen. Zum Beispiel, wenn Sie die Datei /var/run/sudo/ts/sampleuser überschreiben können und Sie eine Shell als dieser Benutzer mit PID 1234 haben, können Sie sudo-Rechte erhalten, ohne das Passwort wissen zu müssen, indem Sie:
Die Datei /etc/sudoers
und die Dateien in /etc/sudoers.d
konfigurieren, wer sudo
verwenden kann und wie. Diese Dateien können standardmäßig nur von Benutzer root und Gruppe root gelesen werden.
Wenn Sie diese Datei lesen können, könnten Sie in der Lage sein, einige interessante Informationen zu erhalten, und wenn Sie irgendeine Datei schreiben können, werden Sie in der Lage sein, die Berechtigungen zu eskalieren.
Wenn du schreiben kannst, kannst du diese Berechtigung missbrauchen.
Eine weitere Möglichkeit, diese Berechtigungen auszunutzen:
Es gibt einige Alternativen zur sudo
-Binärdatei, wie doas
für OpenBSD. Vergessen Sie nicht, die Konfiguration unter /etc/doas.conf
zu überprüfen.
Wenn Sie wissen, dass ein Benutzer normalerweise eine Maschine verbindet und sudo
verwendet, um Privilegien zu eskalieren, und Sie haben eine Shell im Kontext dieses Benutzers, können Sie eine neue sudo ausführbare Datei erstellen, die Ihren Code als root und dann den Befehl des Benutzers ausführt. Dann ändern Sie den $PATH des Benutzerkontexts (zum Beispiel, indem Sie den neuen Pfad in .bash_profile hinzufügen), sodass, wenn der Benutzer sudo ausführt, Ihre sudo ausführbare Datei ausgeführt wird.
Beachten Sie, dass Sie, wenn der Benutzer eine andere Shell (nicht bash) verwendet, andere Dateien ändern müssen, um den neuen Pfad hinzuzufügen. Zum Beispiel sudo-piggyback ändert ~/.bashrc
, ~/.zshrc
, ~/.bash_profile
. Sie können ein weiteres Beispiel in bashdoor.py finden.
Oder etwas wie ausführen:
Die Datei /etc/ld.so.conf
gibt an, woher die geladenen Konfigurationsdateien stammen. Typischerweise enthält diese Datei den folgenden Pfad: include /etc/ld.so.conf.d/*.conf
Das bedeutet, dass die Konfigurationsdateien aus /etc/ld.so.conf.d/*.conf
gelesen werden. Diese Konfigurationsdateien verweisen auf andere Ordner, in denen Bibliotheken gesucht werden. Zum Beispiel ist der Inhalt von /etc/ld.so.conf.d/libc.conf
/usr/local/lib
. Das bedeutet, dass das System nach Bibliotheken im Verzeichnis /usr/local/lib
suchen wird.
Wenn aus irgendeinem Grund ein Benutzer Schreibberechtigungen für einen der angegebenen Pfade hat: /etc/ld.so.conf
, /etc/ld.so.conf.d/
, jede Datei innerhalb von /etc/ld.so.conf.d/
oder jeden Ordner innerhalb der Konfigurationsdatei in /etc/ld.so.conf.d/*.conf
, könnte er in der Lage sein, Privilegien zu eskalieren.
Schau dir an, wie man diese Fehlkonfiguration ausnutzen kann auf der folgenden Seite:
Durch das Kopieren der lib in /var/tmp/flag15/
wird sie von dem Programm an diesem Ort verwendet, wie im RPATH
-Variable angegeben.
Dann erstellen Sie eine bösartige Bibliothek in /var/tmp
mit gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6
Linux-Fähigkeiten bieten eine Teilmenge der verfügbaren Root-Rechte für einen Prozess. Dies zerlegt effektiv die Root-Rechte in kleinere und unterscheidbare Einheiten. Jede dieser Einheiten kann dann unabhängig an Prozesse vergeben werden. Auf diese Weise wird die vollständige Menge an Rechten reduziert, was die Risiken einer Ausnutzung verringert. Lesen Sie die folgende Seite, um mehr über Fähigkeiten und deren Missbrauch zu erfahren:
Linux CapabilitiesIn einem Verzeichnis impliziert das Bit für "ausführen", dass der betroffene Benutzer in den Ordner "cd" wechseln kann. Das "lesen"-Bit impliziert, dass der Benutzer die Dateien auflisten kann, und das "schreiben"-Bit impliziert, dass der Benutzer löschen und neue Dateien erstellen kann.
Access Control Lists (ACLs) stellen die sekundäre Ebene der diskretionären Berechtigungen dar, die in der Lage sind, die traditionellen ugo/rwx-Berechtigungen zu überschreiben. Diese Berechtigungen verbessern die Kontrolle über den Zugriff auf Dateien oder Verzeichnisse, indem sie bestimmten Benutzern, die nicht die Eigentümer oder Teil der Gruppe sind, Rechte gewähren oder verweigern. Diese Ebene der Granularität sorgt für eine präzisere Zugriffsverwaltung. Weitere Details finden Sie hier.
Geben Sie dem Benutzer "kali" Lese- und Schreibberechtigungen für eine Datei:
Holen Sie Dateien mit spezifischen ACLs vom System:
In alten Versionen können Sie Shell-Sitzungen eines anderen Benutzers (root) übernehmen. In neueren Versionen können Sie sich nur mit den Screen-Sitzungen Ihres eigenen Benutzers verbinden. Sie könnten jedoch interessante Informationen innerhalb der Sitzung finden.
Liste der Screen-Sitzungen
An eine Sitzung anhängen
Dies war ein Problem mit alten tmux-Versionen. Ich konnte eine von root erstellte tmux (v2.1) Sitzung als nicht privilegierter Benutzer nicht hijacken.
Liste der tmux-Sitzungen
An eine Sitzung anhängen
Check Valentine box from HTB for an example.
Alle SSL- und SSH-Schlüssel, die auf Debian-basierten Systemen (Ubuntu, Kubuntu usw.) zwischen September 2006 und dem 13. Mai 2008 generiert wurden, können von diesem Fehler betroffen sein. Dieser Fehler tritt auf, wenn ein neuer SSH-Schlüssel in diesen Betriebssystemen erstellt wird, da nur 32.768 Variationen möglich waren. Das bedeutet, dass alle Möglichkeiten berechnet werden können und wenn Sie den SSH-Öffentlichen Schlüssel haben, können Sie nach dem entsprechenden privaten Schlüssel suchen. Die berechneten Möglichkeiten finden Sie hier: https://github.com/g0tmi1k/debian-ssh
PasswordAuthentication: Gibt an, ob die Passwortauthentifizierung erlaubt ist. Der Standardwert ist no
.
PubkeyAuthentication: Gibt an, ob die Authentifizierung mit öffentlichem Schlüssel erlaubt ist. Der Standardwert ist yes
.
PermitEmptyPasswords: Wenn die Passwortauthentifizierung erlaubt ist, gibt es an, ob der Server die Anmeldung zu Konten mit leeren Passwortzeichenfolgen erlaubt. Der Standardwert ist no
.
Gibt an, ob root sich über SSH anmelden kann, der Standardwert ist no
. Mögliche Werte:
yes
: root kann sich mit Passwort und privatem Schlüssel anmelden
without-password
oder prohibit-password
: root kann sich nur mit einem privaten Schlüssel anmelden
forced-commands-only
: Root kann sich nur mit privatem Schlüssel anmelden und wenn die Befehlsoptionen angegeben sind
no
: nein
Gibt Dateien an, die die öffentlichen Schlüssel enthalten, die für die Benutzerauthentifizierung verwendet werden können. Sie kann Tokens wie %h
enthalten, die durch das Home-Verzeichnis ersetzt werden. Sie können absolute Pfade angeben (beginnend mit /
) oder relative Pfade vom Home-Verzeichnis des Benutzers. Zum Beispiel:
Diese Konfiguration zeigt an, dass, wenn Sie versuchen, sich mit dem privaten Schlüssel des Benutzers "testusername" anzumelden, ssh den öffentlichen Schlüssel Ihres Schlüssels mit den in /home/testusername/.ssh/authorized_keys
und /home/testusername/access
befindlichen vergleichen wird.
SSH-Agent-Weiterleitung ermöglicht es Ihnen, Ihre lokalen SSH-Schlüssel zu verwenden, anstatt Schlüssel (ohne Passphrasen!) auf Ihrem Server zu lassen. So können Sie via ssh zu einem Host springen und von dort zu einem anderen Host springen, indem Sie den Schlüssel verwenden, der sich auf Ihrem ursprünglichen Host befindet.
Sie müssen diese Option in $HOME/.ssh.config
wie folgt festlegen:
Beachten Sie, dass wenn Host
*
ist, jedes Mal, wenn der Benutzer zu einer anderen Maschine wechselt, dieser Host Zugriff auf die Schlüssel haben kann (was ein Sicherheitsproblem darstellt).
Die Datei /etc/ssh_config
kann diese Optionen überschreiben und diese Konfiguration erlauben oder verweigern.
Die Datei /etc/sshd_config
kann das Weiterleiten des ssh-agent mit dem Schlüsselwort AllowAgentForwarding
erlauben oder verweigern (Standard ist erlauben).
Wenn Sie feststellen, dass der Forward Agent in einer Umgebung konfiguriert ist, lesen Sie die folgende Seite, da Sie möglicherweise in der Lage sind, dies auszunutzen, um Privilegien zu eskalieren:
SSH Forward Agent exploitationDie Datei /etc/profile
und die Dateien unter /etc/profile.d/
sind Skripte, die ausgeführt werden, wenn ein Benutzer eine neue Shell startet. Daher, wenn Sie eine von ihnen schreiben oder ändern können, können Sie Privilegien eskalieren.
Wenn ein seltsames Profil-Skript gefunden wird, sollten Sie es auf sensible Details überprüfen.
Je nach Betriebssystem können die Dateien /etc/passwd
und /etc/shadow
einen anderen Namen haben oder es kann eine Sicherungskopie vorhanden sein. Daher wird empfohlen, alle zu finden und zu überprüfen, ob Sie sie lesen können, um zu sehen, ob sich Hashes in den Dateien befinden:
In einigen Fällen können Sie Passwort-Hashes in der Datei /etc/passwd
(oder einer entsprechenden Datei) finden.
Zuerst generieren Sie ein Passwort mit einem der folgenden Befehle.
Dann fügen Sie den Benutzer hacker
hinzu und fügen Sie das generierte Passwort hinzu.
E.g: hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash
Sie können jetzt den Befehl su
mit hacker:hacker
verwenden.
Alternativ können Sie die folgenden Zeilen verwenden, um einen Dummy-Benutzer ohne Passwort hinzuzufügen. WARNUNG: Sie könnten die aktuelle Sicherheit der Maschine beeinträchtigen.
HINWEIS: Auf BSD-Plattformen befindet sich /etc/passwd
in /etc/pwd.db
und /etc/master.passwd
, außerdem wird /etc/shadow
in /etc/spwd.db
umbenannt.
Sie sollten überprüfen, ob Sie in einige sensible Dateien schreiben können. Zum Beispiel, können Sie in eine Dienstkonfigurationsdatei schreiben?
Zum Beispiel, wenn die Maschine einen tomcat-Server ausführt und Sie die Tomcat-Dienstkonfigurationsdatei in /etc/systemd/ ändern können, dann können Sie die Zeilen ändern:
Ihr Backdoor wird beim nächsten Start von tomcat ausgeführt.
Die folgenden Ordner können Backups oder interessante Informationen enthalten: /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root (Wahrscheinlich können Sie den letzten nicht lesen, aber versuchen Sie es)
Lesen Sie den Code von linPEAS, er sucht nach mehreren möglichen Dateien, die Passwörter enthalten könnten. Ein weiteres interessantes Tool, das Sie dafür verwenden können, ist: LaZagne, das eine Open-Source-Anwendung ist, um viele Passwörter abzurufen, die auf einem lokalen Computer für Windows, Linux und Mac gespeichert sind.
Wenn Sie Protokolle lesen können, könnten Sie interessante/vertrauliche Informationen darin finden. Je seltsamer das Protokoll ist, desto interessanter wird es sein (wahrscheinlich). Außerdem könnten einige "schlecht" konfigurierte (backdoored?) Audit-Protokolle es Ihnen ermöglichen, Passwörter in Audit-Protokollen aufzuzeichnen, wie in diesem Beitrag erklärt: https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/.
Um Protokolle zu lesen, wird die Gruppe adm sehr hilfreich sein.
Sie sollten auch nach Dateien suchen, die das Wort "password" in ihrem Namen oder im Inhalt enthalten, und auch nach IPs und E-Mails in Protokollen oder Hashes Regexps suchen. Ich werde hier nicht auflisten, wie man all dies macht, aber wenn Sie interessiert sind, können Sie die letzten Überprüfungen, die linpeas durchführt, überprüfen.
Wenn Sie wissen, woher ein Python-Skript ausgeführt wird und Sie in diesen Ordner schreiben können oder Python-Bibliotheken modifizieren können, können Sie die OS-Bibliothek modifizieren und einen Backdoor einfügen (wenn Sie schreiben können, wo das Python-Skript ausgeführt wird, kopieren und fügen Sie die os.py-Bibliothek ein).
Um die Bibliothek zu backdooren, fügen Sie einfach am Ende der os.py-Bibliothek die folgende Zeile hinzu (ändern Sie IP und PORT):
Eine Schwachstelle in logrotate
ermöglicht es Benutzern mit Schreibberechtigungen für eine Protokolldatei oder deren übergeordnete Verzeichnisse, potenziell erhöhte Berechtigungen zu erlangen. Dies liegt daran, dass logrotate
, das oft als root ausgeführt wird, manipuliert werden kann, um beliebige Dateien auszuführen, insbesondere in Verzeichnissen wie /etc/bash_completion.d/. Es ist wichtig, die Berechtigungen nicht nur in /var/log zu überprüfen, sondern auch in jedem Verzeichnis, in dem die Protokollrotation angewendet wird.
Diese Schwachstelle betrifft logrotate
Version 3.18.0
und älter
Detailliertere Informationen über die Schwachstelle finden Sie auf dieser Seite: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.
Sie können diese Schwachstelle mit logrotten ausnutzen.
Diese Schwachstelle ist sehr ähnlich zu CVE-2016-1247 (nginx-Logs), also überprüfen Sie immer, ob Sie Protokolle ändern können, wer diese Protokolle verwaltet und ob Sie die Berechtigungen erhöhen können, indem Sie die Protokolle durch Symlinks ersetzen.
Schwachstellenreferenz: https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f
Wenn ein Benutzer aus irgendeinem Grund in der Lage ist, ein ifcf-<whatever>
-Skript in /etc/sysconfig/network-scripts zu schreiben oder ein vorhandenes anzupassen, dann ist Ihr System pwned.
Netzwerkskripte, ifcg-eth0 zum Beispiel, werden für Netzwerkverbindungen verwendet. Sie sehen genau wie .INI-Dateien aus. Sie werden jedoch ~sourced~ auf Linux durch den Network Manager (dispatcher.d).
In meinem Fall wird das NAME=
-Attribut in diesen Netzwerkskripten nicht korrekt behandelt. Wenn Sie weißen/leer Raum im Namen haben, versucht das System, den Teil nach dem weißen/leer Raum auszuführen. Das bedeutet, dass alles nach dem ersten Leerzeichen als root ausgeführt wird.
Zum Beispiel: /etc/sysconfig/network-scripts/ifcfg-1337
Das Verzeichnis /etc/init.d
ist die Heimat von Skripten für System V init (SysVinit), dem klassischen Linux-Dienstverwaltungssystem. Es enthält Skripte zum Starten
, Stoppen
, Neustarten
und manchmal Neuladen
von Diensten. Diese können direkt oder über symbolische Links in /etc/rc?.d/
ausgeführt werden. Ein alternativer Pfad in Redhat-Systemen ist /etc/rc.d/init.d
.
Andererseits ist /etc/init
mit Upstart verbunden, einer neueren Dienstverwaltung, die von Ubuntu eingeführt wurde und Konfigurationsdateien für Aufgaben der Dienstverwaltung verwendet. Trotz des Übergangs zu Upstart werden SysVinit-Skripte weiterhin zusammen mit Upstart-Konfigurationen aufgrund einer Kompatibilitätsschicht in Upstart verwendet.
systemd tritt als modernes Initialisierungs- und Dienstverwaltungssystem auf und bietet erweiterte Funktionen wie das Starten von Daemons nach Bedarf, Automount-Verwaltung und Systemzustands-Snapshots. Es organisiert Dateien in /usr/lib/systemd/
für Verteilungspakete und /etc/systemd/system/
für Administratoränderungen, was den Prozess der Systemadministration optimiert.
Statische Impacket-Binärdateien
LinEnum: https://github.com/rebootuser/LinEnum(-t Option) Enumy: https://github.com/luke-goddard/enumy Unix Privesc Check: http://pentestmonkey.net/tools/audit/unix-privesc-check Linux Priv Checker: www.securitysift.com/download/linuxprivchecker.py BeeRoot: https://github.com/AlessandroZ/BeRoot/tree/master/Linux Kernelpop: Enumeriert Kernel-Schwachstellen in Linux und MAC https://github.com/spencerdodd/kernelpop Mestaploit: multi/recon/local_exploit_suggester Linux Exploit Suggester: https://github.com/mzet-/linux-exploit-suggester EvilAbigail (physischer Zugriff): https://github.com/GDSSecurity/EvilAbigail Zusammenstellung weiterer Skripte: https://github.com/1N3/PrivEsc
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)