Linux privilege escalation SUID SGID: гайд для CTF

На одной из первых машин Hack The Box, которую я решал сам, путь от user-шелла до root занял 40 минут. 35 из них я бездарно потратил на поиск ядерных эксплойтов, пока прямо перед глазами лежал бинарник find с установленным SUID-битом. Одна команда с GTFOBins, один запуск — root. Проблема была не в сложности эксплуатации, а в том, что я не понимал, что искать и почему это работает. Разберём механику специальных битов Linux — SUID, SGID, sticky bit — от базовых концепций до конкретных сценариев эскалации привилегий в CTF и лабораторных средах.

Права доступа Linux для начинающих: база перед атакой

Прежде чем ломать — нужно понимать, как устроена защита. В Linux каждый файл и директория имеют три группы прав: владелец (user), группа (group), остальные (others). Каждая группа получает комбинацию из трёх разрешений: чтение (r = 4), запись (w = 2), исполнение (x = 1). Подробнее — в нашем руководстве по linux для пентестера.

Когда в выводе ls -la видишь строку вроде -rwxr-xr-x, читай слева направо: владелец может всё (rwx = 7), группа — читать и исполнять (r-x = 5), остальные — тоже (r-x = 5). В числовом формате — 755. Команда chmod 755 file устанавливает именно эти linux файловые permissions.

Но стандартных rwx для понимания privesc-векторов мало. Есть четвёртый, старший разряд в числовой записи chmod права доступа — он отвечает за специальные биты: SUID (4), SGID (2) и sticky bit (1). Запись chmod 4755 file означает: SUID включён (4), владелец rwx (7), группа r-x (5), остальные r-x (5). Именно эти специальные биты превращают обычный бинарник в вектор атаки при кривой конфигурации.

Файл /etc/passwd читается всеми (права 644), а /etc/shadow с хешами паролей — только root. Эта разница — фундамент безопасности Linux, и каждый вектор privesc по сути обходит этот фундамент тем или иным способом.

SUID бит Linux — когда программа получает чужие права

SUID (Set User ID) — механизм, при котором программа запускается не с правами того, кто её вызвал, а с правами владельца файла. Аналогия: вам — обычному сотруднику — дали ключ-карту директора, но она действует только пока вы внутри одного конкретного кабинета. Вошли — полномочия директора. Вышли — снова обычный сотрудник.

Классический легитимный пример — /usr/bin/passwd. Программа должна менять файл /etc/shadow, который читается только root. Без SUID обычный пользователь не смог бы сменить собственный пароль. С SUID — программа запускается от имени root, вносит изменение и завершается. Всё безопасно, потому что passwd делает одну конкретную операцию.

Проблема появляется, когда админ ставит SUID на бинарник, способный выполнять произвольные команды. find, vim, python, bash — каждый из них при наличии SUID-бита становится прямой дорогой к root shell escalation. В терминологии MITRE ATT&CK злоупотребление SUID/SGID классифицируется как техника Setuid and Setgid (T1548.001, Privilege Escalation). Атакующий находит misconfigured binaries exploitation и использует штатные возможности программы для повышения привилегий.

Как SUID выглядит в системе и ловушка с заглавной S

Установить SUID можно двумя способами: символьным chmod u+s file или числовым chmod 4755 file. В числовой записи четвёрка в старшем разряде — это SUID. После установки в выводе ls -la позиция x у владельца заменяется на s:

• -rwsr-xr-x — SUID установлен, исполнение разрешено (строчная s). Бинарник запустится от имени владельца.
• -rwSr-xr-x — SUID установлен, но исполнение НЕ разрешено (заглавная S). Файл невозможно запустить, эксплуатация через SUID исключена.

Различие между s и S — ловушка, на которую я сам попался дважды. Заглавная S значит, что кто-то поставил SUID без права на исполнение — обычно ошибка конфигурации, а не вектор атаки. Не тратьте на такие файлы время при разведке.

SGID права доступа — групповой аналог SUID

SGID (Set Group ID) работает аналогично SUID, но для группы-владельца. Когда SGID установлен на исполняемом файле, процесс запускается с правами группы-владельца файла, а не с группой запустившего пользователя.

Установка: chmod g+s file или chmod 2755 file. В выводе ls -la позиция x в триплете группы заменяется на s: -rwxr-sr-x. Уязвимые SGID-бинарники дают атакующему не root, а членство в целевой группе — и если эта группа имеет доступ к чувствительным файлам (например, группа shadow может читать /etc/shadow), это полноценный вектор эскалации.

SGID на директориях — совсем другое поведение

На директориях SGID ведёт себя принципиально иначе: все новые файлы, созданные внутри SGID-директории, наследуют группу директории, а не основную группу создателя. Используется для командных каталогов, где нескольким пользователям нужен общий групповой доступ.

Для эскалации привилегий CTF SGID на директориях менее интересен как прямой вектор. Но в реальных пентестах бывает так: SGID-директория содержит конфиг с паролями, доступный только определённой группе — и получение членства в этой группе через SGID-бинарник открывает доступ к креденшелам. Цепочка из двух шагов вместо одного.

Sticky bit Linux — защита общих директорий

Sticky bit — наименее «атакующий» из трёх специальных битов, но понимать его нужно для полной картины pwn linux permissions. Устанавливается на директориях: chmod +t dir или chmod 1777 dir.

Эффект: в директории со sticky bit пользователь может удалять только свои файлы, даже если у директории стоят права 777 (полный доступ для всех). Каноничный пример — /tmp. Без sticky bit любой пользователь мог бы удалять чужие файлы из /tmp, ломая кучу системных процессов.

В выводе ls -ld /tmp sticky bit обозначается буквой t в позиции x для others: drwxrwxrwt. Заглавная T — sticky bit есть, но execute для others отсутствует (аналогично заглавной S для SUID).

Для эскалации привилегий sticky bit сам по себе не вектор. Но вот что критично для практики: если файловая система смонтирована с опцией nosuid, то SUID/SGID биты на файлах внутри неё ядро просто проигнорирует. Это стандартная практика для /tmp, /dev/shm, /run. Новички регулярно на этом спотыкаются: копируют бинарник в /tmp, ставят SUID через chmod u+s — и ничего не работает, потому что раздел смонтирован с nosuid. Проверяйте: grep nosuid /proc/mounts.

Поиск SUID файлов Linux — разведка перед эксплуатацией

Разведка — фундамент любого привилегированного доступа. По MITRE ATT&CK обнаружение файлов и директорий — техника File and Directory Discovery (T1083, Discovery). На практике всё сводится к нескольким командам.

Ручной поиск SUID через find

Базовая команда — выучите наизусть:

# Поиск файлов с SUID-битом
find / -perm -4000 -type f 2>/dev/null

# Поиск файлов с SGID-битом
find / -perm -2000 -type f 2>/dev/null

# Оба типа одновременно
find / -perm -u=s -o -perm -g=s -type f 2>/dev/null

Разберём по частям: / — поиск от корня. -perm -4000 — файлы с установленным SUID (4 в старшем разряде). -type f — только обычные файлы, не директории и не симлинки. 2>/dev/null — перенаправление ошибок «Permission denied» в пустоту, чтобы не засорять вывод.

На типичной Ubuntu 22.04 вывод покажет десяток-два стандартных бинарников: /usr/bin/passwd, /usr/bin/su, /usr/bin/sudo, /usr/bin/mount, /usr/bin/umount. Все легитимны и ожидаемы. Интерес представляют бинарники, которых в этом списке быть не должно: find, vim, python3, bash, cp, nano, docker.

Приём для CTF: чтобы отсечь стандартные бинарники и найти только добавленные позже, используйте find / -xdev -perm -4000 -newer /bin/bash 2>/dev/null. Флаг -newer покажет файлы, модифицированные позже /bin/bash — то есть добавленные после установки системы. Флаг -xdev не даёт переходить на другие файловые системы.

Автоматизация: LinPEAS и сканеры привилегий

Ручной поиск — база, но на CTF время дорого. LinPEAS (Linux Privilege Escalation Awesome Script) автоматически проверяет десятки векторов привилегий, включая SUID/SGID. Скачиваете скрипт, выполняете chmod +x linpeas.sh && ./linpeas.sh. LinPEAS подсвечивает потенциально уязвимые SUID бинарники красным и жёлтым, давая мгновенную приоритезацию.

Есть и специализированный инструмент — suid3num. Он категоризирует найденные SUID-файлы на стандартные (ожидаемые для дистрибутива) и нестандартные (потенциально уязвимые), плюс автоматически проверяет их по базе GTFOBins. Инструмент группирует бинарники в категории «default», «not default» и «custom» — сильно ускоряет анализ.

А вот что ни один автоматический сканер не покрывает — кастомные бинарники. На CTF часто попадаются скомпилированные программы без названий из GTFOBins. Тут помогает только ручной анализ: strings binary_name покажет строковые константы, ltrace ./binary_name — вызовы библиотечных функций. Если в выводе strings видите вызов вроде system("tar") или system("ls") без абсолютного пути — это почти гарантированный вектор через PATH hijacking.

GTFOBins примеры — каталог уязвимых SUID бинарников

GTFOBins (gtfobins.github.io) — справочник стандартных Unix-утилит, которые можно использовать для обхода ограничений безопасности. Для каждого бинарника указаны техники эксплуатации в разных контекстах: SUID, sudo, capabilities, чтение/запись файлов.

Алгоритм работы с GTFOBins на CTF — пять шагов:

1. Нашли нестандартный SUID-бинарник через find.
2. Открываете GTFOBins, ищете бинарник по имени.
3. Переходите в раздел SUID на его странице.
4. Копируете команду, адаптируете путь под конкретную машину.
5. Получаете root shell.

Бинарники, которые чаще всего встречаются в лабах и CTF:

find — один из самых популярных. Если у find стоит SUID, достаточно выполнить find . -exec /bin/sh -p \; -quit. Параметр -exec запускает произвольную команду, -p сохраняет effective UID, -quit завершает find после первого совпадения. Результат — root-шелл.

bash — если на /bin/bash стоит SUID (в реальности это безумие, но в CTF бывает), команда bash -p запустит шелл с правами владельца. Флаг -p отключает сброс привилегий, который bash делает по умолчанию — без него SUID на bash бесполезен.

python3 — с SUID позволяет выполнить python3 -c 'import os; os.execl("/bin/sh", "sh", "-p")'. Интерпретатор запускается от root, порождает шелл с сохранёнными привилегиями.

vim/nano — текстовые редакторы с SUID дают возможность редактировать любой файл от root. Через vim можно открыть /etc/passwd или /etc/sudoers и добавить пользователя с UID 0 или запись NOPASSWD для sudo.

cp — тут три метода эксплуатации SUID: копирование подменённого /etc/passwd, клонирование SUID-бита на другой бинарник и модификация /etc/sudoers. Каждый рабочий, когда утилита копирования имеет misconfigured SUID.

Полный список бинарников с техниками SUID-эксплуатации на GTFOBins содержит десятки позиций: от aa-exec и arp до awk, gdb и docker. Не нужно запоминать все — нужно запомнить, где искать.

Эскалация привилегий CTF — пошаговые сценарии

Теория без практики мертва. Три сценария, покрывающих основные паттерны SUID-эксплуатации.

Сценарий 1: прямой SUID на стандартном бинарнике

Ситуация: получен user-шелл, разведка через find / -perm -4000 -type f 2>/dev/null показывает в списке /usr/bin/find с правами -rwsr-xr-x 1 root root.

Что это значит: find исполняется от имени root (SUID-бит установлен, владелец — root). У find есть параметр -exec, выполняющий произвольную команду для каждого найденного файла.

Эксплуатация: find . -exec /bin/sh -p \; -quit. Проверка: id в открывшемся шелле покажет uid=0(root). Время от обнаружения до root — 10 секунд.

На GTFOBins страница find в разделе SUID содержит ту же команду — подтверждение вектора.

Сценарий 2: PATH hijacking через кастомный бинарник

Ситуация: при разведке найден нестандартный бинарник /opt/backup с правами -rwsr-xr-x 1 root root. Команда strings /opt/backup показывает вызов system("tar czf /tmp/backup.tar.gz /home").

В чём дыра: бинарник вызывает tar без абсолютного пути (не /usr/bin/tar, а просто tar). Система ищет tar по переменной окружения PATH, перебирая директории слева направо. Подставляем свой поддельный tar в директорию, которая в PATH стоит раньше /usr/bin — и бинарник выполнит нашу подмену с правами root.

# Создаём поддельный tar, запускающий шелл
echo '#!/bin/sh' > /tmp/tar
echo '/bin/sh -p' >> /tmp/tar
chmod +x /tmp/tar

# Подставляем /tmp первым в PATH
export PATH=/tmp:$PATH

# Запускаем SUID-бинарник
/opt/backup

Результат: вместо tar вызывается наш скрипт, который открывает шелл с root-привилегиями. В терминах MITRE ATT&CK это пересечение техник Setuid and Setgid (T1548.001) и манипуляции с окружением выполнения.

Аналогичный фокус работает с любым system() без абсолютного пути. На одном CTF SUID-бинарник welcome вызывал файл greetings по относительному пути — атакующий заменил его симлинком на /bin/sh и получил root.

Сценарий 3: SUID на текстовом редакторе

Ситуация: разведка показывает /usr/bin/vim.tiny с SUID root.

Логика: vim с правами root может редактировать любой файл в системе. Два основных вектора:

Через /etc/sudoers: открываете vim.tiny /etc/sudoers, добавляете строку username ALL=(ALL) NOPASSWD: ALL, сохраняете через :wq!. После этого sudo su даёт root без пароля.

Через /etc/passwd: генерируете хеш пароля через openssl passwd -6 -salt xyz yourpassword, затем в vim добавляете в /etc/passwd строку с UID 0 — новый пользователь с правами root. Вариант: заменить хеш root в /etc/shadow через find с -exec sed, если find имеет SUID.

Оба варианта требуют понимания формата системных файлов. Каждое поле в /etc/passwd разделено двоеточием — третье поле (UID) определяет уровень привилегий. UID 0 — root.

Linux privesc чек-лист для CTF и лабов

Систематический подход экономит время. Порядок действий после получения user-шелла, выстроенный по вероятности срабатывания в CTF:

1. id и whoami. Проверьте группы: членство в docker, lxd или disk — самостоятельные векторы эскалации, не связанные с SUID.

2. sudo -l — какие команды можно выполнять через sudo без пароля? Часто самый быстрый вектор, быстрее SUID.

3. find / -perm -4000 -type f 2>/dev/null и отдельно -perm -2000. Сравнивайте с дефолтным набором, выделяйте нестандартные.

4. cat /etc/crontab и ls -la /etc/cron.d/. Ищите скрипты, запускаемые root, но доступные на запись текущему пользователю.

5. getcap -r / 2>/dev/null. Linux capabilities — более гранулярная альтернатива SUID (capabilities linux security). Бинарник с cap_setuid+ep эквивалентен SUID root с точки зрения privesc.

6. find /etc -writable -type f 2>/dev/null. Если /etc/passwd доступен на запись — root без эксплойтов и без SUID.

7. uname -a. Старые ядра имеют публичные эксплойты эскалации привилегий.

8. LinPEAS объединяет пункты 1-7 и добавляет десятки дополнительных проверок. Запускайте, если ручная разведка не дала результатов за 5-10 минут.

Каждый пункт — потенциальный вектор. В CTF обычно заложен один-два. На реальном пентесте может быть несколько параллельных цепочек.

Частые ошибки новичков при работе с SUID

Разберу промахи, на которых я терял время сам и вижу, как теряют другие.

Путаница SUID с sudo. SUID — бит на файле, программа запускается от владельца файла автоматически при любом запуске. Sudo — отдельный механизм, проверяющий /etc/sudoers и явно разрешающий конкретным пользователям выполнять конкретные команды от root. Два независимых механизма. SUID не требует пароля и не проверяет sudoers. Sudo не требует SUID на целевом бинарнике. MITRE ATT&CK разделяет их: SUID — T1548.001, sudo — T1548.003 (Sudo and Sudo Caching).

Не проверяют владельца бинарника. SUID-бит не равен «root». Если бинарник принадлежит пользователю www-data и имеет SUID — запуск даст права www-data, не root. Всегда смотрите третий столбец в ls -la: -rwsr-xr-x 1 root root — тут root root означает владельца root и группу root. Без этой проверки тратите время на бинарники, которые дадут бесполезные привилегии.

Копируют бинарник и теряют SUID. При копировании через cp бит SUID сбрасывается — защитный механизм ядра. Если нужно перенести SUID-бинарник, используйте cp --preserve=mode или работайте с оригиналом на месте. Аналогично SUID сбрасывается при изменении содержимого файла.

Игнорируют nosuid-разделы. Разделы с nosuid полностью игнорируют SUID/SGID биты. Стандартная практика для /tmp, /dev/shm, /run. Проверить: mount | grep nosuid или cat /proc/mounts | grep nosuid. Создали SUID-шелл в /tmp и он не работает? Первое, что проверяйте.

Забывают флаг -p у bash. Bash по умолчанию сбрасывает effective UID до real UID при запуске. Без -p (privileged mode) SUID на bash бесполезен — получите шелл с правами обычного пользователя. Сознательный защитный механизм bash, и он ловит новичков практически гарантированно.

Не используют GTFOBins. Находят SUID на awk, less или aspell — и теряют полчаса, не зная, что делать. На GTFOBins для каждого из них есть готовая команда с инструкцией. Не запоминайте всё — запомните адрес справочника.

Защита от SUID-эксплуатации: перспектива blue team

Понимание защиты помогает и атакующему — видеть, что может заблокировать вектор.

Первая мера: регулярный аудит SUID/SGID файлов. Правило Elastic детектирует процессы с effective UID 0 при real UID != 0 — прямой маркер SUID-эксплуатации. EQL-запрос проверяет условие: process.user.id == "0" and process.real_user.id != "0". Мониторинг таких событий через EDR или SIEM — базовая мера для blue team.

Минимизация SUID-поверхности: убрать бит с программ, которым он объективно не нужен, через chmod u-s /path/to/binary. Альтернатива — замена SUID на Linux capabilities. Вместо SUID на ping можно установить setcap cap_net_raw+ep /usr/bin/ping — программа получит только право на raw-сокеты, а не полные привилегии root. Capabilities — более гранулярный механизм, постепенно вытесняющий SUID в современных дистрибутивах.

Монтирование tmpfs-разделов (/tmp, /dev/shm) с опциями nosuid,noexec,nodev перекрывает создание и запуск SUID-шеллов во временных директориях. DISA STIG для Ubuntu 22.04 требует регулярного аудита файлов со специальными битами и минимизации их количества — каждый лишний SUID-бинарник расширяет поверхность атаки.

По данным CrowdStrike Global Threat Report 2025, 79% атак обходятся без malware (hands-on-keyboard / living off the land). Эксплуатация SUID-бинарников — классический пример living off the land: атакующий не загружает ничего, а использует то, что уже установлено в системе. Именно поэтому аудит специальных битов — не факультативная задача.

Половина CTF-задач на Linux privesc сводится к одному: SUID на бинарнике, который не должен его иметь. Не сложно. Не требует знания эксплойт-разработки, реверс-инжиниринга или криптографии. find / -perm -4000, GTFOBins, готовая команда — три шага до root. И именно поэтому считаю, что начинающим стоит не застревать на SUID-задачах, а использовать их как трамплин. Первые пять-десять машин — учимся находить SUID, понимать механику, набиваем руку. Но если через двадцать решённых машин единственный вектор, который вы уверенно находите — misconfigured SUID — это тупик. Capabilities, cron-задачи, writable PATH, docker escape — каждый из них встречается в реальных пентестах не реже SUID, а цепочки из нескольких шагов (writable cron вызывает скрипт → скрипт использует relative path → PATH контролируется через .bashrc) требуют совсем другого уровня мышления. SUID — входная точка, не потолок. Освойте, прогоните через десяток лабов, автоматизируйте разведку — и двигайтесь дальше. Если хочется пройти базу от прав доступа до первых задач системно, а не по случайным статьям — IB Basics на codeby.school закрывает этот трек за пару месяцев без академической воды.

🚀 Хочешь закрепить на практике? Реши задачи по теме на HackerLab — категория «pentest-machines».