Как работают эксплойты по повышению привилегий в ОС Windows
Для будущих студентов курса «Пентест. Практика тестирования на проникновение» подготовили авторскую статью от нашего эксперта — Александра Колесникова.
Также приглашаем записаться на открытый вебинар по теме «Windows ad: сбор информации, эскалация привилегий. Эксплойты и уязвимости последних 5 лет.»
Тема получения безграничного доступа к системе очень интересна в контексте тестирования на проникновение. Получить доступ к системе и запустить команду — сегодня это только половина победы. Вторая половина достигается только в тот момент, когда удается обойти подсистемы песочниц и ограничений, которые есть в операционной системе.
Эта статья расскажет о некоторых особенностях эксплойтов для повышения привилегий в операционной системе Windows.
Privileges in Windows
Для понимания, как работает эскалаций привилегий, необходимо разобраться с разграничением доступа в операционной системе Windows. Описание системы разграничения доступа можно найти на официальном сайте. Согласно документации, разграничение доступа в ОС Windows строится на следующих понятиях:
У каждого из перечисленных объектов есть свой индивидуальный идентификатор SID. Вообще, этот идентификатор используется для обозначения любого объекта, с которым работает операционная система, и для него требуется контроль доступа, но нас интересует в первую очередь использование этого идентификатора в контексте пользователей, групп и их прав. Идентификатор используется для того, чтобы создать для пользователя токен доступа. Данный токен содержит информацию о том, какие права имеет пользователь и группы, в которые он входит. Токен будет использоваться для подтверждения или запрета действий над объектами операционной системы, называемыми “Securable Objects”. Токены доступа бывают:
Primary token — токен, которым наделяет пользователь процесс, когда запускает приложение.
Impersonation token — токен, который может работать от имени любого пользователя операционной системы. Также может применяться для клиент-серверного взаимодействия или для запуска потока процесса с другими привилегиями.
Отсюда становится ясно, что основная цель любой эскалации привилегий — это получение токена доступа, который создается привилегированными пользователями. В общем случае, в ОС Windows это стандартные пользователи, которые называются: “Administrator” и “System”. Именно их токены открывают двери к любой информации, которая есть в операционной системе.
Из официальной документации токен состоит из отдельных объектов:
Структура достаточно сложная и просто так скопировать или модифицировать ее не получится из-за того, что токен хранится в защищенном от модификации месте (как сказано в документации). Выясним, где она находится. Для этого запустим операционную систему Windows в отладочном режиме и исследуем все структуры, которые используются для работы процесса. Если обратиться снова к официальной документации, то начинать стоит со структуры EPROCESS.
Получается, что информация о токене процесса хранится в ядре и поэтому в документации это помечено как область, которую нельзя изменить. Теоретически это действительно так: обычные приложения, которые работают в 3-м кольце, не могут модифицировать то, что хранится в 0-м. Но если модифицировать из ядра структуру внутри ядра, то здесь нет никаких ограничений и противоречий. Обратимся к отладчику:
Жирным цветом выделен адрес структуры EPROCESS, чтобы изучить её более подробно вызовем команду отладчика:
Похоже, что и искать долго не придется, токен находится буквально сразу. В 64-битных операционных системах ссылка на него находится по смещению 0x208. Чтобы ее прочитать нужно маскировать адрес:
Это адрес, который необходимо маскировать полностью, кроме последнего байта:
Над адресом токена нужно вызвать одноименную команду и мы можем убедиться, что действительно, как указано в документации, токен содержит информацию, которая была заявлена:
Из рисунка видно, что все привилегии, которые содержит токен, располагаются в виде битовой маски и имеют названия, которые начинаются с префикса “Se”. Именно эти поля нам и нужно модифицировать, чтобы операционная система позволяла процессу читать что угодно в операционной системе. Определившись с целью, время поговорить об атаках на набор привилегий, уязвимостях и экспортах к ним.
LPE или что делать с токеном
Изменение привилегий в токене может быть весьма тривиальной задачей несмотря на то, что эти самые привилегии очень сложно структурированы. Основной атакой, которую применяют для эскалации привилегий — перезапись ссылки на токен, которая содержится в структуре EPROCESS. Иными словами токен не изменяется, меняется адрес, где лежит токен. Обычно этот адрес выбирается из системного процесса, который постоянно может присутствовать в операционной системе. Результатом такой операции становится процесс или отдельный поток, который может делать в ОС всё, что угодно. Ниже приведем пример кода, который позволяет произвести кражу токена:
Приведенный выше код позволяет скопировать токен для текущего процесса из системного процесса с идентификатором 4. Стоит отметить, что код должен быть запущен в контексте ядра операционной системы. Это означает, что он либо должен быть выполнен драйвером, либо шелкодом, который будет загружаться в память через уязвимость операционной системы.
Уязвимости и эксплойты
Операционная система Windows, как и любая другая сложная система, насчитывает миллионы строк кода. И, как в любом большом проекте, его размер не позволяет исключать ошибки и недочеты. На картинке ниже представлена статистика найденных в ОС уязвимостей последних 5 лет. В нее включены уязвимости для повышения привилегий:
Данные об уязвимостях взяты отсюда. Статистика показывает, что уязвимостей достаточно, чтобы можно было найти себе необходимую для повышения привилегий. Для исследования будем использовать готовые эксплойты. Попробуем восстановить последовательность действий, которые проводятся для достижения цели — эскалации привилегий. Список уязвимостей будет следующим:
CVE-2015-2546
Уязвимость в Win32k модуле операционной системы, повреждение памяти. Фрагмент эксплойта, который отвечает за изменение токена процесса:
Кажется, это тот самый код, который был представлен выше. В нем видоизменен подход к поиску токена, но основная идея та же — получить ссылку на токен из процесса с PID=4(System.exe).
CVE-2016-3309
Уязвимость в Win32k, снова проблема с повреждением памяти, взглянем на кусок кода, который используется для замены токена:
В этом случае автор использовал язык программирования C, так же была изменена часть поиска адреса токена, но снова методика замены токена — перезапись адреса из системного процесса.
CVE-017-0101
Уязвимость в user32 GDI объектах и снова повреждение памяти. Код замены токена:
Код скопирован из эксплойта 2016 года, похоже, что на этот период примитивы для проведения эскалаций привилегий еще пока что не митигировались в Windows.
CVE-2018-8120
Уязвимость в Win32k компоненте, в этот раз неверно обрабатывается nullpointer, код для замены токена:
Автор эксплойтов явно не спешит использовать что-то другое или хотя бы новое. Снова код, который ищет System.exe и использует его токен.
CVE-2019-1458
Уязвимость в Win32k, повреждение памяти, код замены токена:
Вот и первые изменения, автор больше не мог использовать код, который его выручал на протяжении 3х лет. Теперь токен заменяется через примитивы, которые использовались для эксплуатации уязвимостей в Windows 10 — метод Bitmap. По механике он делает тоже самое, но достигается это за счет использования объектов подсистемы Win32k.
CVE-2020-0796
Уязвимость в драйвере, который обрабатывает SMBv3 запросы. Проблема таилась в переполнении целочисленного типа, который отвечал за количество выделяемой памяти в ядре. Код замены токена:
Случай с этой уязвимостью — особенный. В первую очередь потому, что замена и перезапись токена осуществляется за 1 проход при получении неверно сформатированного запроса по SMBv3, поэтому в исходнике не происходит никаких дополнительных вычислений и действий по отношению к токену System.exe и процесса пользователя.
Вместо заключения
При тестировании на проникновение часто возникает необходимость использовать тот или иной публичный эксплойт на эскалацию привилегий. При этом не всегда можно найти подробное описание эксплойта и привести его в работоспособное состояние. Надеюсь, эта статья помогла вам увидеть шаблоны, которые применяются для написания эксплойтов, и теперь разбираться в них станет чуточку легче. К тому же, как показывает описание выше, способов на повышение привилегий не так много, а именно один — изменение ссылки на токен процесса. Все остальное это просто модификации способа как ссылку можно перезаписать.
Узнать подробнее о курсе «Пентест. Практика тестирования на проникновение».
Записаться на открытый вебинар по теме «Windows ad: сбор информации, эскалация привилегий. Эксплойты и уязвимости последних 5 лет.»
Статья Как повысить привилегии в Windows
Добрый день, Коллеги.
Сразу оговорюсь, я не претендую на полноценное авторство для данной статьи. Моя работа скорее была — скомпоновать техники и проверить их на практике, оставив только реально рабочие и полезные варианты.
В данной статье используются переводы с зарубежных форумов и статей, часть наших, часть писал и в том числе я сам. Просто делюсь своими архивчиками.
Сегодня мы поговорим о повышение привилегий Windows.
Повышение привилегий с BeRoot
Большинство способов поднятия привилегий связаны с ошибками в конфигурации установленного ПО, будь то путь к исполняемому файлу сервиса, не обрамленный кавычками и содержащий пробел (такая ситуация довольно интересно обрабатывается виндой), или же неверно выставленные права на директорию с приложением. Итак, что же BeRoot умеет находить? Для начала те самые пути с пробелами, не обрамленные кавычками:
C:\Program Files\SomeTest\binary.exe.
В данном случае Windows будет пытаться найти и запустить файл в следующем порядке:
Если посмотреть запись для этой службы в системном реестре, то можно увидеть ключ ImagePath значение которого:
C:\Program Files (x86)\Program Folder\A Subfolder\Executable.exe
Хотя должно быть:
“C:\Program Files (x86)\Program Folder\A Subfolder\Executable.exe”
Данный способ называется Неквотируемые пути служб (Unquoted Service Paths)
Далее, проверяются интересные директории, куда мы можем что-либо записать. Эти интересные директории составляются из путей до исполняемых файлов сервисов, запланированных заданий, ключей автозагрузки (HKLM).
Следующим этапом проверяется переменная окружения %PATH%, не содержит ли она директорий, доступных для записи. Если так, то на ОС от Vista до Windows Server 2016 можно будет выполнить DLL Hijacking
Примеры и Триксы
Для проверки прав на папку можно воспользоваться встроенной тулзой
icacls. Ниже показан результат проверки прав для C:\Program Files (x86)\Program Folder:
Как видим группа “Everyone” имеет полный доступ к этой папке. Значит,
мы можем записать любой файл в эту папку.
Описание некоторых флагов в выводе команды icacls:
F = Full Control (полный доступ)
CI = Container Inherit (наследование контейнерами)
OI = Object Inherit (только наследование)
Теперь создадим reverse shell пэйлоад, который запустится с правами SYSTEM.
Для этого можем воспользоваться MSFvenom:
При следующем старте службы A.exe должен запуститься с правами
SYSTEM. Давайте проверим – рестартанем уязвимую службу:
Как видим, теперь у нас появилась сессия Meterpreter’а с правами SYSTEM. Но почему же наша сессия оборвалась так быстро? Объяснить это можно — потому, что в системе Windows при старте службы она должна соединиться
с т. н. Менеджером Служб (Service Control Manager (SCM)). Если соединение не было установлено то Менеджер Служб завершит процесс. Поэтому нам необходимо мигрировать в другой процесс до того как
Менеджер Служб завершит работу нашего пэйлоада, также можно использовать автомигрирование. Хочу отметить, что в Metasploit есть уже готовый модуль для проверки и эксплуатации данной уязвимости на целевой машине:
Помимо только поиска уязвимых мест, BeRoot предоставляет возможность проэксплуатировать уязвимость MS16-075 (если она есть). Стандартный трюк с добавлением своего админа будет выглядеть следующим образом:
Повышение привилегий Windows. BeRoot нашел несколько доступных для записи директорий, указанных в переменной окружения PATH Также проверяются файлы, оставшиеся от Unattended Install, которые могут хранить данные админской учетки. Ну и на всякий случай проверяются такие экзотические вещи, как доступность сервиса для модификации, возможность создания нового сервиса, возможность создания ключа автозагрузки в HKLM, а также возможность записи в директорию, где хранятся запланированные задания.
В этом примере Vulnerable.exe содержит DLL hijacking уязвимость. Так как это демонстрация, то Vulnerable.exe является кодом, который подгружает длл без всяких проверок:
Если разбираться, что же такое DLL hijacking, то это хорошо расписано этой статье (Dynamic-Link Library Security (Windows)):
Когда приложение динамически подгружает динамическую библиотеку без указания полного пути (fully qualified path name) к библиотеке, то Windows пытается локализировать эту длл путем поиска в хорошо регламентированном списке директорий и в определенном порядке (детально это описано в Dynamic-Link Library Search Order). Если атакующему удается получить контроль над одной из директорий из списка поиска, то он может поместить вредоносную копию длл в эту директорию.
Это еще иногда называют preloading attackилиbinary planting attack. Если системе не удается найти легитимную длл до поиска в скомпрометированной директории, то будет загружена вредоносная длл. И если приложение выполняется с админскими правами, то атакующему удасться произвести локальное повышение привилегий (local privilege elevation).
Когда процесс пытается подгрузить длл, то система будет выполнять поиск длл в директориях в следующем порядке:
1. В директории из которой запущено приложение
2. В системных директориях
3. В системных директориях для 16-битных приложений
4. В директории Windows
5. В текущей директории
6. В директориях, указанных в переменной окружения %PATH%
Для эксплуатирования данной уязвимости нам необходимо проделать
следующие шаги:
— Проверить существует ли длл которую подгружает процесс в какой-то
директории на диске.
— Если такой длл нет, то необходимо поместить нашу вредоносную копию
длл в одну из директорий, перечисленных выше. Когда процесс будет
запущен он найдет и подгрузит нашу длл.
— Если длл существует в одной из перечисленных директорий, то
необходимо попробовать поместить нашу вредоносную длл в директорию с
более высоким приоритетом поиска чем та, в которой лежит обычная длл.
Давайте проверим есть ли hijackable.dll на целевой машине:
Поиск не дал результатов, но мы не можем быть уверены на 100% что такой длл нет на целевой машине, т.к. мы находимся в непривилегированной сессии и у нас нет прав на просмотр всех директорий на целевой машине.
Следующим шагом нам необходимо проверить наличие уязвимых разрешений. Обычно я проверяю установлен ли какой-нибудь софт в корне диска, например Python. Почему лучше проверять именно в корне диска? — Потому что, первое: если
каталок был создан софтом в корне диска, то у всех аутенцифицированных пользователей будут права на запись в этот каталог. И второе: софт типа Python, Ruby, Perl и др. добавляет путь в переменную среды %PATH%. А Windows как мы помним при поиске подгружаемой длл проверяет также директории, которые перечисленны в этой переменной.
И как видим: аутенцифицированные пользователи имеют права на модификацию. Осталось проверить есть ли каталог C:\Python27 в переменной среды %PATH%. Самый простой способ – это выполнить команду “python -h” в шелле. Если отобразится справка, то значит что этот путь есть в переменной среды %PATH%:
