Эскалация привилегий Linux: чеклист по SUID, cron и sudo для первых учебных машин

Эскалация привилегий Linux: чеклист по SUID, cron и sudo для первых учебных машин

Первая учебная машина, на которой я застрял на четыре часа, решалась одной командой: sudo -l показывала /usr/bin/find с NOPASSWD — а я всё это время компилировал kernel exploit под неподходящую версию ядра. Классика новичка: бросаться к сложному, пропуская очевидное. С тех пор на каждой машине я начинаю с одного и того же чеклиста — и до root добираюсь за десять-пятнадцать минут. Ниже — этот чеклист целиком, с пояснениями по каждому шагу: зачем проверка нужна, что искать глазами и когда вектор не сработает.

Требования к окружению

Работает если: у вас уже есть shell на целевой машине — reverse shell, SSH-сессия, web shell. Хватит любого непривилегированного пользователя (www-data, low-priv user). Целевая ОС — любой дистрибутив Linux. Подробнее — в нашем руководстве по linux для пентестера.

Что понадобится:

• Атакующая машина: Kali Linux или Parrot OS, 4 ГБ RAM минимум (8 ГБ рекомендуется, если крутите несколько VM одновременно)
• Целевая машина: любая учебная VM — TryHackMe, HackTheBox, VulnHub
• Стабильный интерактивный TTY: получается через python3 -c 'import pty;pty.spawn("/bin/bash")' или аналоги
• Сетевое соединение между машинами для передачи инструментов

Не работает если: вы ещё не получили начальный доступ. Повышение привилегий Linux — этап post-exploitation в цепочке атаки: initial access → foothold → privilege escalation → lateral movement. Без foothold эскалировать нечего.

Разведка системы: первые команды после shell

Прежде чем искать вектор эскалации привилегий Linux, надо ответить на три вопроса: кто мы, где мы и что за система. По MITRE ATT&CK это System Information Discovery (T1082) и System Owner/User Discovery (T1033).

Четыре команды, которые идут первыми:

• id — текущий пользователь, UID, GID, группы. Если UID=0, вы уже root (бывает и такое на совсем лёгких машинах). Если пользователь в группе docker, lxd или disk — это отдельные, хорошо задокументированные векторы эскалации
• uname -a — версия ядра и архитектура. Записываете на случай, если придётся искать kernel exploit как крайний вариант
• cat /etc/os-release — дистрибутив и версия. Пути к cron-файлам и поведение sudo различаются между Debian/Ubuntu, CentOS/RHEL и Alpine
• hostname — имя машины. На CTF-площадках часто намекает на вектор (видели машину с именем cron-lover? я — да)

Что искать глазами: нестандартные группы у текущего пользователя, старую версию ядра (ниже 4.x — повышает шансы на публичный exploit), необычное имя хоста. По данным IBM X-Force, рост атак с использованием действительных учётных данных составил 71% за 2024 год — на учебных машинах мисконфигурации встречаются ещё чаще.

Эскалация привилегий через sudo: что проверять первым

Команда sudo -l — это техника Sudo and Sudo Caching (T1548.003, Privilege Escalation по MITRE ATT&CK) и первый шаг в чеклисте. Логика простая: если админ разрешил текущему пользователю запускать хоть что-то через sudo, часто этот бинарник позволяет получить root-shell напрямую.

Выполняете sudo -l и смотрите на вывод. Три сценария:

Пароль не спрашивает, показывает список — самый удачный вариант. Ищите строки вида (root) NOPASSWD: /usr/bin/find или (ALL) NOPASSWD: /usr/bin/vim. Каждый бинарник из списка проверяйте на GTFOBins (gtfobins.github.io) — справочник Unix-бинарников, через которые можно получить shell, читать или записывать файлы.

Допустим, sudo -l показал /usr/bin/find с NOPASSWD. Открываете GTFOBins, находите find, выбираете функцию «Sudo» — сайт даёт готовую команду: sudo find . -exec /bin/sh \; -quit. Выполняете — получаете root shell. Бинарники, которые часто попадаются на учебных машинах: find, vim, less, man, awk, python3, perl, nmap (старые версии с интерактивным режимом), ftp, apache2. Не все из них имеют функцию «Sudo» на GTFOBins — всегда проверяйте конкретный бинарник и конкретную функцию (Sudo, SUID, Shell) на сайте, а не полагайтесь на общий список.

Спрашивает пароль — если пароль текущего пользователя известен (нашли в конфиге, подобрали), вводите. Нет пароля — вектор пока закрыт, переходите к SUID.

Выдаёт ошибку (sudo: no tty present или user is not in the sudoers file) — sudo недоступен. Двигаемся дальше.

LD_PRELOAD и переменные окружения в sudo

Отдельная ситуация: в выводе sudo -l строка env_keep+=LD_PRELOAD. Это значит, что при вызове sudo сохраняется переменная окружения LD_PRELOAD, которая задаёт shared-библиотеку для предварительной загрузки. Механика такая: вы компилируете .so-файл, который при инициализации вызывает setresuid(0,0,0) и запускает /bin/bash -p, а затем передаёте его через sudo LD_PRELOAD=/tmp/shell.so <разрешённый_бинарник>. Shell получается с правами root.

Схожий, но более узкий подход работает с LD_LIBRARY_PATH: помимо сохранения переменной в sudo-конфигурации, целевой бинарник должен динамически подгружать библиотеку по неабсолютному пути без RPATH/RUNPATH. На практике это встречается реже. Подробная механика с примерами C-кода описана в источниках Bordergate и InternalAllTheThings.

Работает если: env_keep содержит LD_PRELOAD или LD_LIBRARY_PATH, на системе есть gcc или можно загрузить скомпилированный .so с атакующей машины. Не работает если: sudo сконфигурирован с env_reset без сохранения этих переменных (поведение по умолчанию в современных дистрибутивах).

Когда sudo-вектор не работает

• Пользователь отсутствует в sudoers и пароль неизвестен
• sudo сконфигурирован с NOEXEC — запрещает exec/system изнутри бинарника
• На целевой машине sudo не установлен вовсе (минималистичные контейнеры на Alpine)
• Бинарник в sudo-списке не имеет записи на GTFOBins, не вызывает shell, не работает с файлами

Поиск SUID файлов Linux: отделяем стандартное от эксплуатируемого

SUID-бит (Set User ID) — специальный флаг на исполняемом файле, который заставляет его запускаться от имени владельца, а не вызывающего пользователя. Если владелец root, а бинарник позволяет выполнить произвольную команду — это прямой путь к root shell. Техника Setuid and Setgid (T1548.001, Privilege Escalation).

Поиск SUID файлов Linux выполняется командой find / -perm -4000 -type f 2>/dev/null. На типичной системе результатов десятки — задача не найти, а отфильтровать стандартные.

Стандартные SUID-бинарники (их присутствие нормально): passwd, mount, umount, ping, chfn, chsh, newgrp, gpasswd, sudo, su. Запомните этот список — всё, что не в нём, требует внимания. Для некоторых из «стандартных» (например, sudo для функции Shell, mount для Privilege Escalation) на GTFOBins тоже есть записи — проверяйте конкретную функцию в контексте. Даже passwd имеет запись на GTFOBins — не для SUID-эскалации, а для смены пароля root при наличии соответствующих прав.

Что должно насторожить: бинарники из /home/, /tmp/, /opt/ — самописные утилиты. Любой из стандартных инструментов (vim, find, bash, python) с SUID — немедленная проверка на GTFOBins. Неизвестный бинарник — исследуйте через strings <бинарник> | head -30, чтобы понять, какие команды он вызывает внутри.

PATH-подмена и shared object hijack в SUID-бинарниках

Если SUID-бинарник вызывает другую программу без абсолютного пути (например, curl вместо /usr/bin/curl) — это вектор для PATH-подмены. Создаёте в записываемой директории свой файл с нужным именем, добавляете эту директорию в начало PATH и запускаете SUID-бинарник — он выполнит ваш файл от имени root.

Shared object hijack работает похоже: если SUID-бинарник пытается загрузить .so-файл, которого нет или который принадлежит текущему пользователю, подставляете свой .so с payload. Для обнаружения таких зависимостей: strace <бинарник> 2>&1 | grep "open\|no such file" — ищите попытки загрузить несуществующие библиотеки.

Когда SUID-эскалация не сработает

• Все SUID-бинарники стандартные и обновлённые, без записей на GTFOBins
• На разделе установлен флаг nosuid (проверяется через mount | grep nosuid)
• AppArmor или SELinux в enforcing-режиме ограничивают выполнение — SUID-бит установлен, но policy блокирует escape
• Бинарник статический, не загружает внешние библиотеки и не вызывает команды через system()

Уязвимые cron-задачи Linux: от crontab до wildcard-инъекций

Cron-задачи (T1053.003 — Cron, тактики Execution, Persistence и Privilege Escalation по MITRE ATT&CK) — скрипты, выполняемые по расписанию. Если задача запускается от root и ссылается на записываемый файл — это прямой вектор эскалации привилегий через cron.

Где искать: cat /etc/crontab для системного crontab, ls -la /etc/cron.d/ для дополнительных конфигов, ls -la /etc/cron.daily/ /etc/cron.hourly/ для периодических задач. В каждой найденной строке вида * * * * * root /path/to/script.sh проверяете права на скрипт: ls -la /path/to/script.sh. Файл записываемый для вашего пользователя — заменяете содержимое на reverse shell или команду chmod u+s /bin/bash, ждёте выполнения по расписанию.

Отдельный вектор — wildcard-инъекции. Если cron-задача использует tar с wildcardом (tar czf /backup/archive.tar.gz *), создание файлов с именами, совпадающими с флагами tar, превращает имена файлов в аргументы команды:

echo "" > "--checkpoint=1"
echo "" > "--checkpoint-action=exec=sh privesc.sh"

Файл privesc.sh содержит команду для получения привилегий. Когда tar обработает *, эти «имена файлов» станут аргументами, и скрипт выполнится от root. Выглядит как грязный хак, но на CTF-машинах встречается регулярно. Подробный разбор техники — в InternalAllTheThings (SwissKyRepo).

Обнаружение скрытых задач через pspy

Не все cron-задачи видны в /etc/crontab. Часть настроена через crontab -e и хранится в /var/spool/cron/crontabs/. Есть ещё systemd timers (systemctl list-timers --all), которые работают по аналогии с cron, но в другом формате.

Инструмент pspy решает эту проблему: он мониторит создание процессов в реальном времени, не требуя root-прав. Запускаете ./pspy64 (или pspy32 для 32-bit систем — архитектуру вы уже знаете из uname -a) и наблюдаете: через минуту-две увидите все периодические задачи, включая те, что не отображаются в стандартных cron-конфигах. Я обычно запускаю pspy в отдельном терминале и иду проверять другие векторы — к моменту, когда дойду до cron, результаты уже готовы.

Когда cron-вектор не работает

• Все cron-скрипты принадлежат root с правами 755 или жёстче — записать в них нельзя
• Crontab использует абсолютные пути к бинарникам (нет PATH-манипуляции)
• Задачи запускаются без wildcard и в окружении с ограниченным PATH
• SELinux/AppArmor блокирует модификацию файлов, указанных в cron

Capabilities и утечки паролей: два дополнительных вектора

Linux Capabilities — гранулярная система прав, более тонкая чем SUID. Бинарник может иметь capability cap_setuid+ep, что функционально эквивалентно SUID-биту, но не отображается при стандартном поиске через find -perm -4000. Поиск: getcap -r / 2>/dev/null. Если видите /usr/bin/python3 = cap_setuid+ep — одна команда python3 -c 'import os; os.setuid(0); os.system("/bin/bash")' даёт root. Из интересных capabilities для повышения привилегий: cap_setuid, cap_setgid, cap_dac_override (обход проверок прав), cap_sys_admin.

Утечки паролей в файлах — техника Credentials In Files (T1552.001, Credential Access). Админы оставляют пароли в конфигах, истории команд и бэкапах. Что проверять: cat ~/.bash_history на предмет паролей, введённых в командной строке (да, люди реально пишут mysql -u root -pSuperSecret123), grep -rli "password" /home /var/www /etc 2>/dev/null для поиска в конфигурационных файлах, find / -name "id_rsa" 2>/dev/null для забытых SSH-ключей. Если /etc/shadow доступен на чтение (типичная Security Misconfiguration по OWASP A05:2021), хэши можно прогнать через John The Ripper или hashcat.

LinPEAS чеклист: когда запускать и что искать в выводе

LinPEAS (Linux Privilege Escalation Awesome Script) автоматизирует все проверки выше и десятки дополнительных. Но запускать его первым — ошибка новичка. Вывод LinPEAS — тысячи строк. Без понимания что искать, цветные блоки текста превращаются в шум. Пройдите чеклист руками, поймите логику каждой проверки — и тогда автоматизация станет верификацией, а не костылём.

# Загрузка и запуск LinPEAS
curl -L "https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh" -o linpeas.sh
chmod +x linpeas.sh
./linpeas.sh -a   # все проверки — глубже, но дольше
./linpeas.sh -s   # быстрый режим, ничего не пишет на диск

В выводе LinPEAS ориентируйтесь на цветовую маркировку: красные строки с восклицательным знаком — высоковероятные векторы эскалации, жёлтые — находки, требующие ручной проверки.

Смежные инструменты для полноты картины:

• linux-smart-enumeration (lse.sh) — лаконичнее LinPEAS, три уровня детализации (-l0 минимум, -l2 максимум). Удобен для быстрой первичной проверки
• pspy — мониторинг процессов без root, незаменим для обнаружения скрытых cron-задач и systemd timers
• linux-exploit-suggester — подбор kernel exploit по версии ядра. Используйте как последнюю опцию: kernel exploit нестабильны (целевая система может упасть, как отмечает Payatu) и оставляют следы

Итоговый чеклист пентестера Linux

1. id, uname -a, cat /etc/os-release — определить контекст
2. sudo -l — проверить sudo-права, сверить каждый бинарник с GTFOBins
3. find / -perm -4000 -type f 2>/dev/null — найти SUID-бинарники, отфильтровать стандартные
4. cat /etc/crontab, ls -la /etc/cron.*, запустить pspy — обнаружить cron-задачи
5. getcap -r / 2>/dev/null — проверить capabilities
6. grep -rli "password" /home /var/www /etc 2>/dev/null — поиск утечек паролей
7. find / -name "id_rsa" 2>/dev/null — забытые SSH-ключи
8. Запустить LinPEAS / lse.sh — поймать пропущенное
9. Kernel exploit — только если шаги 2-8 не дали результата

Каждый шаг — от нескольких секунд до пары минут. Полный цикл ручной проверки на учебной машине занимает 10-15 минут.

Порядок в чеклисте не случаен: sudo — самый быстрый и вероятный вектор на учебных машинах уровня easy-medium. SUID — второй по частоте. Cron требует ожидания выполнения задачи, поэтому идёт третьим: запустили pspy, переключились на другие проверки, вернулись к результатам. Kernel exploit стоит последним, потому что он наименее надёжен и потенциально деструктивен — CVE-2010-3904 (RDS Protocol, CWE-1284, CVSS 7.8 HIGH) добавлена в CISA KEV в 2023 году как активно эксплуатируемая (SSVC: Act — патчить немедленно; required action: продукт EOL, при обнаружении — вывести из эксплуатации). Несмотря на возраст CVE 2010 года, угроза остаётся актуальной для необновлённых систем. На учебных машинах ядра чаще обновлены, и этот вектор срабатывает редко.

Большинство новичков, которые проходят учебные машины уровня easy, не до конца понимают, что произошло. Скопировали команду из writeup, получили root, двинулись дальше. На OSCP такой подход ломается: writeup нет, каждая машина требует осознанного выбора вектора. Этот чеклист — не набор команд для бездумного копирования, а последовательность рассуждений: сначала проверить самое вероятное (sudo), затем менее очевидное (SUID), потом скрытое (cron, capabilities). Когда эта логика встроится в голову, LinPEAS станет инструментом верификации, а не костылём.

Инструмент бесполезен без понимания, почему /usr/bin/python3 с cap_setuid+ep опаснее, чем /usr/bin/passwd с SUID-битом. Кто понял логику — решает машины за десять минут. Кто заучил команды — застревает, когда вывод LinPEAS пуст, а вектор спрятан в systemd timer или в .bash_history соседнего пользователя. Если только начинаешь путь в offensive security и хочешь пройти базу системно — на IB Basics это закрывается за пару месяцев без академического тона.

🚀 Хочешь закрепить на практике? CTF-задачи и лабы ждут на HackerLab.