Повышение привилегий: как возникает и как закрыть

Атакующий редко попадает сразу под root — он попадает «куда-то», а дальше ищет, как подняться выше.

Повышение привилегий (privilege escalation) — получение прав более высокого уровня, чем были выданы изначально: из обычного пользователя в администратора, из контейнера на хост, из веб-приложения в системную учётную запись.

Первичный доступ почти всегда низкоприлегированный: украденный пароль рядового сотрудника, RCE в веб-приложении под пользователем www-data, гостевой аккаунт. Сам по себе он мало что даёт. Ценность появляется, когда атакующий поднимается до администратора или системной учётки — тогда открывается доступ к чужим данным, секретам и соседним машинам. Для защитника это значит главное: граница «обычный пользователь → администратор» должна быть настоящей стеной, а не формальностью, и любые попытки её перейти должны быть видны.

Зачем это знать защитнику

Если вы понимаете, по каким «лестницам» обычно поднимаются, вы знаете, какие из них надо убрать или поставить под камеру. Повышение привилегий — это почти всегда следствие чьей-то ошибки в конфигурации или забытого обновления, а не магия. Значит, это управляемый риск: его можно систематически уменьшать харднингом и закрывать мониторингом.

Откуда берутся «лестницы наверх»

Концептуально источников немного, и все они — про лишнее доверие или устаревший код.

Источник	Суть проблемы	Что закрывает защитник
Мисконфигурация прав	файлам, сервисам, задачам выданы слишком широкие права; запись туда, откуда исполняется код от имени админа	аудит прав, ужесточение ACL, least privilege
Опасные привилегии	учётке выданы возможности, эквивалентные администраторским (например, право запускать что угодно от рута)	ревизия sudo-политик и системных привилегий
Устаревшее ПО	в ядре или сервисе есть известная уязвимость, для которой давно вышел патч	патч-менеджмент, инвентаризация версий
Секреты «в открытую»	пароли и токены в скриптах, истории команд, переменных окружения, конфигах	секрет-менеджер, чистка артефактов

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

Как выглядит разведка в лаборатории

В учебном стенде (своя ВМ, DVWA, TryHackMe) первичная энумерация — это безобидные команды чтения состояния системы:

id                     # кто я и в каких группах
sudo -l                # что мне разрешено запускать через sudo
uname -a               # версия ядра — сверить с известными уязвимостями
find / -perm -4000 2>/dev/null   # бинарники с битом SUID

Эти же команды — инструмент защитника: тем же find вы сами находите подозрительные SUID-бинарники и записываемые сервисные файлы раньше атакующего. Разница только в намерении и в наличии разрешения на работу с системой.

Linux и Windows: разные двери, один принцип

Конкретные «лестницы» зависят от ОС, но логика общая. В Linux классические источники — лишние SUID-биты, слишком щедрые sudo-правила, записываемые cron-скрипты и старое ядро. В Windows — службы, чей бинарник или путь можно подменить, неаккуратные права на ключи реестра, токены и привилегии вроде SeImpersonatePrivilege у сервисных учёток. В обоих мирах суть одна: где-то выдано доверие или права, которые не должны были быть выданы. Поэтому и защита переносится между платформами без изменений — меняется лишь, что именно аудировать.

Маленький детект как пример мышления

Допустим, у вас есть эталонный список SUID-бинарников «чистой» системы. Тогда обнаружение нового — это элементарное сравнение множеств; вот та же идея на Python, которую легко прокрутить в голове:

baseline = {"/usr/bin/passwd", "/usr/bin/sudo", "/bin/mount"}
current  = {"/usr/bin/passwd", "/usr/bin/sudo", "/bin/mount", "/tmp/.x"}
suspicious = current - baseline
for path in sorted(suspicious):
    print("Новый SUID-файл:", path)

Вывод:

Новый SUID-файл: /tmp/.x

Появление SUID-бита у файла в /tmp — почти всегда тревога. Сам приём «зафиксируй эталон, сравни с текущим» — универсальный фундамент детектирования, и к нему мы вернёмся в уроке про закрепление.

Как это работает под капотом

Большинство сценариев повышения сводятся к одному принципу: код, который вы контролируете, исполняется в контексте, который вы контролировать не должны. Пример концепции: если сервис от имени администратора периодически запускает скрипт, а на этот скрипт у обычного пользователя есть право записи, то пользователь может подменить содержимое — и при следующем запуске его код выполнится с правами администратора. Ничего «хакерского» в механизме нет: это прямое следствие неверно выставленных прав на файл.

Аналогично с устаревшим ПО: уязвимость в ядре или setuid-программе позволяет процессу выйти за рамки своих прав из-за ошибки в самом коде. Защита здесь не в «обнаружении хакера», а в том, чтобы уязвимого кода в системе просто не было — то есть в обновлениях.

Как защититься

Оборона строится слоями, от снижения вероятности до обнаружения:

Принцип наименьших привилегий. Каждой учётке и сервису — ровно те права, что нужны для работы. Сервисы запускают под отдельными непривилегированными пользователями, а не под root. Регулярно ревизуйте sudo-правила и членство в админских группах.
Харднинг конфигурации. Уберите лишние SUID-биты, закройте на запись каталоги, из которых что-то исполняется, не храните секреты в скриптах и переменных окружения. Полезны бенчмарки CIS как чек-лист.
Патч-менеджмент. Ведите инвентаризацию версий ОС и сервисов, оперативно ставьте обновления безопасности. Большинство «эксплойтов локального повышения» работают только на непропатченных системах.
Мониторинг и аудит. Включите аудит вызовов (на Linux — auditd, в Windows — расширенный аудит и Sysmon). Тревожные сигналы: всплеск sudo-ошибок, запуск редко используемых системных утилит, появление новых SUID-файлов, чтение чувствительных файлов из необычного процесса.
Принцип «предполагай компрометацию». Стройте детектирование так, будто низкоприлегированный доступ у атакующего уже есть. Тогда ваша задача — не дать ему подняться и быстро это заметить.

Юридическое напоминание: исследовать повышение привилегий допустимо только на своих системах, в учебных лабораториях или в рамках легального пентеста с письменным разрешением владельца. Несанкционированный доступ к чужим системам наказуем (УК РФ ст. 272).

Итоги

Повышение привилегий — переход через границу прав; почти всегда следствие мисконфига, лишних привилегий или устаревшего ПО.
Механизм прозаичен: подконтрольный атакующему код исполняется в чужом, более привилегированном контексте.
Защита — least privilege, харднинг, патчинг и аудит; та же энумерация, что использует атакующий, помогает защитнику найти дыры первым.
Стройте детект, предполагая, что низкоприлегированный доступ уже получен.