Маркер доступа в системе безопасности windows это

Обновлено: 08.07.2024

Какие же механизмы включаются, когда мы выбираем пункт меню «Безопасность» из диалогового окна свойств файла? В данной статье я постараюсь ответить на этот вопрос. В качестве примера возьмем технологии получения списка логических дисковых разделов, локальных разделяемых ресурсов, а также рассмотрим две удобные утилиты, одна из которых входит в поставку NT, а вторая - в Resource Kit.

В операционной системe NT существует понятие «защищенный объект» (securable object). Это объект, доступ к которому контролируется и ограничивается операционной системой. В семействе операционных систем производства Microsoft лишь NT и Windows 2000 обеспечивают подобный сервис. К таким объектам относятся: файлы и каталоги файловой системы NTFS; каналы (pipes); процессы и потоки (Process and threads); файлы, спроецированные в память (mapped files); маркеры доступа (access tokens); объекты управления окнами (Window-management objects); разделы реестра (registry keys); службы Win32 (services); принтеры (Printers); разделенные сетевые ресурсы (Network shares); объекты синхронизации процессов (Interprocess synchronization objects - events, mutexes, semaphores, waitable timers); задачи (Job objects).

В модели ограничения доступа Win32 существует два базовых понятия:

Access tokens - маркеры доступа (МД), содержащие информацию о пользователе;

Security descriptors - описатели защиты, содержащие информацию о правах тех или иных учетных записей на доступ к объекту.

При регистрации пользователя в системе после успешной проверки имени и пароля создается маркер доступа. Для каждого процесса, выполняемого далее в контексте этого пользователя, создается копия МД. Маркер доступа содержит множество идентификаторов защиты (security identifiers, SID), определяющих учетные записи пользователя и тех групп, в которые он входит. Кроме того, МД содержит список привилегий (privilege) - прав на доступ к тем или иным объектам, предоставляемых той или иной учетной записи. С помощью этой информации операционная система определяет возможности доступа пользователя к ресурсам.

При создании защищенного объекта ОС присваивает ему описатель защиты (security descriptor, SD) - той защиты, которая имеется у пользователя, создающего объект, или же той, что задана по умолчанию. Приложения Win32 могут использовать функции API как для получения, так и для изменения информации о доступе к объектам.

Security descriptor содержит информацию о владельце объекта, а также может включать следующие списки контроля доступа Access-Contol List (ACL):

Discretionary access-control list (DACL) - разграничительные списки контроля доступа, в которых содержатся пользователи и группы с соответствующими правами на доступ к объекту;

System access-control list (SACL) - системные списки контроля доступа, которые определяют, как осуществляется аудит попыток доступа к объекту.

Список контроля доступа содержит список записей контроля доступа (access-control entries, ACEs). Каждая запись содержит набор битовых флагов и идентификатор SID попечителя (trustee) - пользователя или группы, к которой эти права применены.

Остановимся на упомянутых объектах более подробно.

Security Descriptor

Эти объекты содержат информацию о безопасности, соотнесенную с тем или иным защищенным объектом. Физически этот объект представляет собой структуру SECURITY_DESCRIPTOR, описанную в файле Windows.h:

Структура SECURITY_DESCRIPTOR используется для доступа к информации о безопасности объектов. Но изменять поля непосредственно в данной структуре невозможно. Для этого необходимо использовать специальные функции (например, SetSecurityDescriptorOwner(…)). Кроме того, Win32 API предоставляет интерфейс для создания и инициализации описателя SD для новых объектов.

Access token

Access token (маркер доступа) - это объект операционной системы, который описывает контекст ограничения доступа к процессу или потоку. Он содержит привилегии, соответствующие учетной записи пользователя, ассоциированного с процессом или потоком. Маркер доступа создается после успешной идентификации пользователя в системе. После этого каждый процесс, который так или иначе запускается данным пользователем, сопровождается копией его маркера.

Идентификатор защиты SID

Уникальный параметр переменной длины, определяющий учетную запись (account) и хранящийся в базе данных системы безопасности Windows NT, - вот что такое SID. В начале каждого сеанса, как только пользователь идентифицирован в системе, его SID извлекается из БД и помещается в маркер доступа. Далее это значение используется операционной системой при всех действиях пользователя с защищенными объектами.

Существует несколько стандартных SID, применяемых для учетных записей:

NULL - S-1-0-0 - SID группы, в которую не входят пользователи. Используется лишь тогда, когда SID неизвестен;

World - S-1-1-0 - группа, включающая в себя всех пользователей;

Local - S-1-2-0 - пользователи, имеющие непосредственный, физический доступ к системе;

Creator Owner ID - S-1-3-0 - SID, которым заменяется SID пользователя, создавшего объект. Этот SID используется для унаследованных записей ACE (см. ниже);

Creator Group ID - S-1-3-1 - значение, заменяющее SID основной группы, к которой принадлежит пользователь, создавший объект. Этот SID, как и предыдущий, используется для унаследованных записей ACE.

Список управления доступом ACL

ACL представлен структурой, описанной в Windows.h:

Для Windows NT версий 3.5, 3.51, 4.0 определено максимальное число записей управления доступом, задаваемых списком управления доступом (см. статью Q166348 в базе знаний Microsoft). Оно равно 1820.

Запись управления доступом ACE

Система ограничения доступа Windows NT/2000 использует несколько типов записей ACE, которые перечислены в Таблице 1, содержащей, кроме того, и названия соответствующих этим типам структур данных.

Вполне вероятно, что в следующих версиях операционной системы появятся новые типы ACE, да и из приведенных в Таблице 1 некоторые поддерживаются только Windows 2000. Для того чтобы унифицировать процедуру анализа структур ACE, разработчики включили во все структуры _ACE одинаковую последовательность полей, которая отображается в структуре ACE_HEADER:

Первое поле AceType определяет тип структуры. Очевидно, что указатель на любую структуру _ACE можно преобразовать в указатель на ACE_HEAER, получить тип ACE, после чего этот указатель преобразовать в указатель на соответствующую полученному типу структуру данных. Замечу, что такой прием широко используется в различных API продуктов Microsoft.

На Листинге 1 показано, как получить список логических дисков. Для этого используется функция Win-API NetServerDiskEnum. Ее первый параметр определяет сетевое имя компьютера, список накопителей которого нас интересует. Если этот параметр NULL, то берется локальный компьютер. Список дисковых накопителей возвращается в параметре lpBuf. Он имеет вид последовательности из 3 байт. Каждая последовательность содержит букву - символ диска, двоеточие и разделитель NULL. Количество прочитанных накопителей возвращается в параметре dwReded, а общее количество дисков - в dwTotal. После обработки буфер lpBuf необходимо освободить вызовом функции NetApi-BufferFree(lpBuf).

В коде Листинга 1 вызывается написанная мной функция GetParti-tionTypeEx. Она получает параметры дискового накопителя, возвращает наименование файловой системы, на нем установленной, и проверяет, поддерживает ли файловая система контроль ограничения доступа (cм. Листинг 2).

В Win32 API для получения информации о дисковом разделе используется функция

Ее параметры описаны в Таблице 2. Чуть подробнее рассмотрим параметр lpFileSystemFlags. Это набор битовых флагов. Среди прочих определен флаг FS_PERSISTENT_ACLS. Наличие этого флага означает, что папки и файлы раздела являются охраняемыми объектами. Перед тем как получать списки ACE для того или иного объекта, неплохо убедиться, что файловая система их поддерживает. Теперь мы знаем, как это делается.

Список записей управления доступом для защищенных объектов

Итак, несложная операция просмотра всех объектов файловой системы и выяснения их свойств завершена. Пора обратиться к основному вопросу статьи - созданию механизма получения списков пользовательских прав на доступ к объектам. Как я уже отмечал выше, информация о правах доступа к объекту передается через DACL. Здесь рассматриваются лишь именованные объекты операционной системы, но функции работы с объектами, не имеющими уникального символьного идентификатора, например с потоками, ничем не отличаются от описанных ниже.

Чтобы получить структуру ACL для именованного объекта, нужно задействовать функцию GetNmedSe-curityInfo. Среди прочих значений она возвращает указатели на DACL и SACL. Нас интересует первый из них. Теперь у нас есть вся информация для создания списка ACE. Функция GetAce позволяет пройти по всему списку заголовков ACE_HEADER, соответствующих ACL. Этой функции передаются три параметра. Первый - указатель на ACL, второй - порядковый номер ACE, указатель на который возвращается в третьем параметре (cм. Листинг 3).

Список разделяемых ресурсов и прав для них

Последний вопрос, который я хочу подробно рассмотреть, касается получения списка локальных ресурсов общего доступа (shares) и прав доступа к ним. Процедура получения прав на объекты идентична описанной процедуре получения прав на доступ к файловым объектам. Поэтому реализующий ее код включен в код процедуры, представленной в Листинге 4, и отдельно не обсуждается. Это характерно для API системы безопасности, которая предоставляет обобщенный интерфейс ко всем защищенным объектам. Действительно, с точки зрения системы ограничения доступа Windows разделяемый ресурс - такой же именованный объект, как, например, и файл. Поэтому алгоритмы работы с ними одни и те же.

Список разделяемых ресурсов предоставляется функцией

Для получения SD ресурса используется функция

Для получения списка ACE используется поле shi502_security_descriptor, содержащее необходимый Security Descriptor.

Восстановление параметров безопасности

Результатом работы утилиты, которую можно загрузить по указанному адресу, является командный файл. Прекрасно, скажете вы, а что дальше? Вообще говоря, наш файл состоит из двух частей: в первой создаются и устанавливаются права доступа к разделяемым файлам и каталогам, а во второй выясняются параметры безопасности для объектов файловой системы. Для работы с разделяемыми ресурсами из командной строки в Microsoft WindowsNT (R) Resource Kit есть небольшая программа - RMTSHARE.EXE. Сценарий создан с использованием этой программы.

Параметры команды такие:

Для просмотра и установки параметров доступа к объектам NTFS используется утилита cacls.exe, входящая в WinNT.

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

/T - изменяет список записей управления доступом к объекту, а если это папка, то ко всем вложенным папкам.

/E - заменяет список записей управления доступом.

/C - позволяет продолжить работу в случае ошибки отказа в доступе.

/G user:perm - устанавливает для пользователя, определяемого параметром user, права на доступ к объекту, определяемые параметром perm:

N - нет; R - чтение; W - запись; C - изменение; F - полный контроль.

/R user - удаляет для указанного пользователя права на доступ к объекту.

/P user:perm - изменяет для указанного в параметре user пользователя права на доступ к объекту, которые описываются параметром perm и могут быть следующими:

N - нет; R - чтение; W - запись; C - изменение; F - полный контроль.

/D user - запрещает применять пользователю доступ к указанному объекту.

Утилита позволяет применять маски, например *.*, в именах файлов и папок, а также указывать в одной команде несколько пользователей. В Knowledge Base описан метод использования утилиты cacls.exe для изменения прав доступа не только пользователей, но и групп к объектам файловой системы. В этом случае синтаксис сохраняется, но имена групп берутся в кавычки (Q162786).

Active Directory и доступ к информации о безопасности

В Windows 2000 реализована новая служба качественно меняющая, кроме всего прочего, и механизмы работы с объектами файловой системы. Это Active Directory. Программный интерфейс к ней называется Active Directory Service Interfaces (ADSI). ADSI представляет собой набор COM-объектов, обеспечивающий программный интерфейс к функциям службы Active Directory. Базовые объекты системы безопасности (ACL, SID, ACE и т. д.) в ADSI те же, что и описанные выше. Существенные изменения коснулись лишь механизмов манипуляции с ними. Подробнее об ADSI я планирую рассказать в следующей статье.

Из этой статьи вы узнаете, что такое маркеры доступа, и из чего они состоят. А также я покажу, как запустить программу с изменённым маркером доступа.

Теория

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

Маркеры доступа затем используются монитором безопасности SRM (про него было написано здесь). Основываясь на маркерах доступа монитор решает какие объекты и к чему имеют доступ.

Маркер доступа включает в себя:

SID пользователя;
SID всех групп в которые входит пользователь;
массив привилегий, при этом привилегии бывают разные, например выключать компьютер, или сменить владельца у объекта;
уровень целостности;
ID сеанса;
состояние UAC.

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

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

Практика

Системная утилита Runas умеет запускать процессы от имени других пользователей. И соответственно с другими маркерами доступа.

С помощью следующей команды, вы можете запустить приложение “Блокнот” от имени какого-нибудь другого пользователя:

А теперь, давайте запустим две командные строки, одну от имени администратора а другую обычно. И посмотрим на их маркеры доступа в Process Explorer. Для этого откроем свойства запущенных процессов и перейдем на вкладку “Security“:

Слева обычный процесс, справа запущенный от имени администратора. Обратите внимание что второй процесс имеет больше привилегий.

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

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

Идентификаторы безопасности для групп, членом которых является пользователь , определяющий текущий сеанс входа в систему .
Список привилегий , хранящихся у пользователя или в группах пользователя.
Идентификатор безопасности владельца
Идентификатор безопасности для основной группы по умолчанию, используемый системой при создании пользователем защищаемого объекта без указания дескриптора безопасности
Источник маркера доступа
Является ли маркер основным маркером или токеном олицетворения
Необязательный список с максимальным идентификатором SID
Текущие уровни олицетворения
Другая статистика

Каждый процесс имеет основной маркер , описывающий контекст безопасности учетной записи пользователя, связанной с процессом. По умолчанию система использует основной маркер, когда поток процесса взаимодействует с защищаемым объектом. Более того, поток может олицетворять учетную запись клиента. Олицетворение позволяет потоку взаимодействовать с защищаемыми объектами с помощью контекста безопасности клиента. Поток, выполняющий олицетворение клиента, имеет как основной, так и олицетворенный токен.

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

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

Функция	Описание
аджусттокенграупс	Изменяет сведения о группе в маркере доступа.
AdjustTokenPrivileges	Включает или отключает привилегии в маркере доступа. Он не предоставляет новые права или не отзывает существующие.
чекктокенмембершип	Определяет, включен ли указанный идентификатор безопасности в указанном маркере доступа.
CreateRestrictedToken	Создает новый токен, который является ограниченной версией существующего токена. Маркер ограниченного доступа может иметь отключенные SID, удаленные права и список ограниченных идентификаторов безопасности.
Сбой duplicatetoken	Создает новый токен олицетворения, который дублирует существующий токен.
дупликатетокенекс	Создает новый основной маркер или маркер олицетворения, который дублирует существующий токен.
GetTokenInformation	Извлекает сведения о токене.
истокенрестриктед	Определяет, имеет ли маркер список идентификаторов SID.
OpenProcessToken	Извлекает маркер основного маркера доступа для процесса.
опенсреадтокен	Возвращает маркер для маркера доступа олицетворения для потока.
сетсреадтокен	Назначает или удаляет маркер олицетворения для потока.
сеттокенинформатион	Изменяет владельца маркера, основную группу или DACL по умолчанию.

Функции маркеров доступа используют следующие структуры для описания частей маркера доступа.

Основными требованиями к безопасности являются следующие 3 Эти требования были описаны в стандарте Министерства обороны США Trusted Computer System Evaluation Criteria (TCSEC) – критерии оценки доверенных компьютерных систем (1985 год), который известен как "Оранжевая книга". Система Windows NT3.5 SP3 получила сертификат уровня C2 этого стандарта (см. подробнее [Руссинович и др., 2008, стр. 510]) .

1. Обязательная идентификация и аутентификация.

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

В Windows за идентификацию и аутентификация пользователей отвечают процессы Winlogon.exe и Lsass.exe.

2. Управляемый доступ к объектам.

Пользователь -владелец объекта должен иметь возможность предоставлять доступ к объекту определенным пользователям и/или группам пользователей.

Безопасный доступ реализуется в Windows компонентом Security Reference Monitor ( SRM , монитор контроля безопасности) исполнительной системы Ntoskrnl.exe.

Система должна уметь отслеживать и записывать все события, связанные с доступом к объектам.

В Windows аудит поддерживается SRM и Lsass.exe.

4. Защита при повторном использовании объектов.

Если область памяти выделялась какому-либо пользователю, а затем была освобождена, то при последующем выделении этой области все данные в ней (даже зашифрованные) должны быть стерты.

В Windows освобожденная память очищается системным потоком обнуления страниц, работающим во время простоя системы (с нулевым приоритетом).

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

Организация управляемого доступа к объектам

Принцип организации доступа

Принцип организации управляемого безопасного доступа к объектам выглядит следующим образом. У каждого пользователя в системе имеется свой маркер доступа (access token), в котором указан уникальный идентификатор пользователя. Процессы, создаваемые пользователем, наследуют его маркер.

С другой стороны, все объекты в системе имеют структуру данных, которая называется дескриптор защиты (security descriptor). В эту структуру входит список идентификаторов пользователей, которые могут (или не могут) получить доступ к объекту, а также вид доступа (только чтение, чтение и запись, полный доступ и т.д.).

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

Рассмотрим структуры данных и функции, отвечающие за реализацию этого принципа в ядре Windows.

Идентификаторы защиты

Для однозначного определения пользователя в системе используются идентификаторы защиты (SID – Security Identifier). Кроме пользователей, SID имеется у групп пользователей, компьютеров, доменов 4 Домен (в Windows) – группа компьютеров, управляемых централизованно, информация о которых хранится в общей базе данных (Active Directory) и членов доменов.

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

В WRK структура SID описывается в файле public\sdk\inc\ntseapi.h (строка 251). SID состоит из следующих частей:

номер версии – поле Revision (1 байт);
код агента идентификатора (identifier authority) – поле IdentifierAuthority (6 байт);
коды субагентов (subauthority values) – поле SubAuthority (от 1 до 15 кодов по 4 байта каждый). Количество кодов субагентов хранится в поле SubAuthorityCount.

В текстовом виде SID записывается следующим образом:

На рис.13.1 последний код субагента называется относительным идентификатором (relative identifier, RID), поскольку все учетные записи пользователей на компьютере могут иметь одинаковые коды, кроме RID. RID, который равен 500, обозначает локального администратора.

Маркер доступа

Идентификаторы безопасности пользователей хранятся в маркерах доступа (access token). Во время входа пользователя в систему процесс Lsass.exe создает для него маркер доступа, который назначается первому пользовательскому процессу UserInit.exe, остальные процессы, запущенные пользователем, наследуют этот маркер (рис.13.2). Маркер доступа процесса хранится в поле Token структуры EPROCESS (см. лекцию 6 "Процессы и потоки").

Маркер доступа представлен структурой TOKEN , описанной в файле base\ntos\se\tokenp.h (строка 235) и имеющей следующие основные поля:

Остальные статьи цикла:

Ранее я писал о рисках раскрытия парольных хэшей на скомпрометированной машине. Оказывается, существует и другой способ воспользоваться учетными данными на Windows-хосте, который очень походит на кражу хэшей с последующим их использованием в атаках передачи хэша. Этот способ эксплуатирует маркеры доступа Windows, которые в концепции чем-то напоминают неперсистентные куки. Они располагаются в памяти и, по существу, предоставляют функционал единой точки входа (single sign on), позволяющий любому процессу или потоку, связанному с пользователем, легко обращаться к атрибутам безопасности этого пользователя (в том числе видеть его привилегии и членство в группах).

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

Что такое маркеры доступа?

По словам Microsoft, в Windows до версии Vista (версии начиная с Vista также используют "фильтрованный" маркер для контроля учетных записей UAC, который, по сути, является первичным маркером без административных прав) существует два типа маркеров доступа:

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

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

Чтобы увидеть, как можно использовать имперсонализацию, рассмотрим FTP-сервер, с которым вы соединяетесь под авторизованной учетной записью. Авторизованная учетная запись, вероятно, имеет права на загрузку и скачивание файлов только из определенных директорий. FTP-сервер узнает ваши права через имперсонализацию. Когда процесс FTP-сервера занят обслуживанием ваших запросов, он на короткое время выполняется под управлением вашего имперсонализирующего маркера, что дает ему "врожденное" знание ваших привилегий, то есть, того, к каким файлам и папкам вы имеете доступ. Когда он завершает обработку вашего запроса, то возвращается к своей работе под управлением своего первичного маркера или имперсонализирующего маркера другого пользователя.

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

"Данные уровни влияют на то, что вы можете сделать с имперсонализирующим маркером, получив его. Анонимный характеризуется своим названием – мы можем представлять вас только как анонимного пользователя. Уровень идентификации – это когда процесс может получить ваш маркер для проверки учетных данных, но не может производить никаких действий над маркером. Уровень имперсонализации означает, что процесс может выполнять действия от имени другого пользователя… Имперсонализация ограничена только локальными для данного компьютера задачами… Процесс не может 'запустить задачу' или 'запросить объект', которые располагаются вне его системы… Делегация находится на шаг впереди имперсонализации: процесс может вызывать ресурсы и выполнять задачи на других компьютерах. …делегирование – это возможность, предоставляемая протоколом аутентификации Керберос, и часто называемая аутентификацией 'двойного прыжка' (double hop) – наши учетные данные перепрыгивают с одного компьютера на другой, освобождая нас от необходимости заходить на каждый из этих компьютеров отдельно."

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

Когда появляются эти маркеры доступа?

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

Маркеры уровня делегирования появляются при интерактивных входах, в том числе, входах с консоли, через RunAs, PsExec с опцией "-u" и при входах на удаленный рабочий стол RDP/VNC-вида. Я уже говорил о значительном риске раскрытия парольных хешей при интерактивном входе, поэтому нам определенно нужно избегать этого типа входа в систему под нашим привилегированным аккаунтом домена.

Маркеры уровня делегирования также могут появляться в результате сетевых входов в определенные сервисы, например, SharePoint. SharePoint, который часто использует веб-сервер как фронтенд и SQL-Server как бэкенд, является превосходным примером того, насколько полезным может быть делегирование. Она позволяет веб-серверу (фронтенду) после того, как клиент соединился с ним и прошел аутентификацию, соединяться с SQL-сервером от имени этого аутентифицированного клиента. Многозвенные решения такого типа – это обычный сценарий использования делегирования. Отметим также, что Шифрующая Файловая Система (EFS) Microsoft использует делегирование для шифрования и расшифрования файлов от имени пользователя.

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

Вот снимок экрана, показывающий, где в Active Directory можно включить делегирование для определенной учетной записи пользователя:

А вот снимок экрана, показывающий, как в Active Directory можно включить делегирование для определенной учетной записи компьютера (всплывающее окно показалось после того, как я выбрал "Trust computer for delegation"):

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

Необходимые условия кражи маркеров безопасности

Итак, мы знаем, что должно произойти, чтобы маркеры уровня делегирования и имперсонализации были созданы и стали доступными для использования. Но что должно случиться, чтобы можно было ими завладеть и эксплуатировать их? Код атакующего должен быть запущен от имени пользователя, имеющего привилегию имперсонализации (SeImpersonatePrivilege). По умолчанию в Windows XP данным правом обладают администраторы, а также члены встроенной группы SERVICE:

Обычно на момент кражи маркеров доступа атакующий уже поднял привилегии до уровня Adminstrator/SYSTEM, так что данное условие редко представляет проблему.

Кража маркеров в действии

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

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

Для просмотра и кражи маркеров доступа я собираюсь использовать утилиту incognito, созданную Люком Дженнингсом. Точнее, в данных тестах я собираюсь использовать модуль Метасплоита incognito (также созданный Дженнингсом), поскольку я обнаружил, что он является более совместимым, чем приложение incognito. Статья Дженнингса "Security Implications of Windows Access Tokens — A Penetration Tester's Guide" – это прекрасный источник, позволяющий разобраться в данной проблеме и описывающий то, как работает incognito.

В нашем сценарии имеется потенциально скомпрометированная машина Windows XP SP2 с именем "USER-XP-PC". У нас также есть сотрудник службы реагирования на инциденты безопасности "MSAD2-RESPONDER1", которому нужно со своей машины "IR-XP-PC" соединиться со скомпрометированной машиной для анализа последней. В прошлой своей статье я тестировал утилиты NET USE, WMIC и PsExec. В данной же статье я сфокусируюсь только на PsExec, поскольку лишь она оказалась уязвимой по умолчанию к краже маркеров доступа уровня делегирования, если предположить, что скомпрометированный компьютер является доверенным для делегирования. Для WMIC делегирование можно включить путем указания ключа /IMPLEVEL.

Итак, давайте начнем!

Здесь наш сотрудник посредством PsExec заходит с его машины (IR-XP-PC) на удаленную скомпрометированную машину USER-XP-PC:
Атакующий запустил сессию Metasploit Meterpreter на удаленной машине USER-XP-PC. На этот момент он может полностью контролировать USER-XP-PC с консоли Metasploit своей машины, на которой установлена ОС BackTrack Linux. Здесь мы видим попытку атакующего украсть маркер уровня делегирования пользователя MSAD2-RESPONDER1.
Теперь давайте посмотрим, что может сделать атакующий, когда действует от имени MSAD2-RESPONDER1. Вот продолжение сессии, показанной на предыдущем снимке:

Результаты показывают очень эффективный метод повышения привилегий с уровня стандартной учетной записи домена до уровня привилегированной доменной записи (в данном случае – администратора домена) и получения доступа к файлу резервной копии контроллера домена. Ксаба Барта в документе "Active Directory Offline Hash Dump and Forensic Analysis" указал, что файлы резервных копий часто содержат NTDIS.DIT и файлы реестра, необходимые для извлечения доменных хэшей. В более реалистичном сценарии (и, возможно, более простом) атакующий попытается заполучить упомянутые файлы с сервера резервных копий, используя учетную запись администратора резервных копий. В любом случае, мы видим, что кража маркеров уровня делегирования привилегированной учетной записи домена может иметь очень серьезные последствия.

Защита маркеров доступа

Теперь давайте посмотрим, что можно сделать для решения данной проблемы. К счастью, Microsoft предоставляет нам простой и эффективный способ защиты наших привилегированных учетных записей. Практически для всех привилегированных учетных записей домена вам следует включить опцию "Account is sensitive and cannot be delegated" в свойствах учетной записи:

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

Давайте проведем тесты и посмотрим, все ли работает так, как ожидалось. Проверим, что получится после применения к учетной записи MSAD2-RESPONDER1 показанных выше настроек и перезагрузки тестовых машин.

Наш сотрудник службы безопасности опять заходит через PsExec со своей машины IR-XP-PC на удаленную скомпрометированную машину USER-XP-PC:
Атакующий снова запускает сессию Metasploit Meterpreter, чтобы получить контроль над скомпрометированной машиной. Все последующие команды запускаются на скомпрометированном хосте USER-XP-PC с машины атакующего (ОС BackTrack Linux):
Все выглядит так же, как в прошлый раз, но давайте посмотрим, можем ли мы теперь соединиться с контроллером домена как раньше, когда опция "Account is sensitive and cannot be delegated" была отключена.
Не получается! Так что же произошло? Давайте посмотрим на логи контроллера домена, MSAD2-DC-2K3:

Мы видим попытку сетевого входа (Event ID 540) в 7:11:31 PM с рабочей станции USER-XP-PC. Это удачная попытка сетевого входа, но от имени анонимного пользователя, а не от имени MSAD2-RESPONDER1. Так происходит потому, что без маркера уровня делегирования в соединениях с удаленными рабочими станциями отсутствуют учетные данные. Эти соединения являются анонимными входами, которые хоть и аутентифицируются, но не авторизуются доменным контроллером. Другими словами, относительно наших ожиданий попытка входа оказалась неудачной.

Заключение

Мы получили важный результат. Включение опции "Account is sensitive and cannot be delegated" означает, что мы можем предотвратить ситуацию, когда маркеры доступа уровня делегирования станут доступны атакующему. В противном случае для атакующего существует явная возможность украсть маркер уровня делегирования, чтобы перемещаться по всей сети, а это может быть столь же опустошительным, как и компрометация хэшей привилегированной учетной записи.

Хотя данная опция исключает возможность украсть маркер уровня делегирования, маркер уровня имперсонализации все еще остается доступным атакующему. Как упоминалось ранее, это открывает уязвимость к локальному повышению привилегий на скомпрометированной машине. В нашем сценарии, однако, это не имеет большого значения, поскольку машина вероятнее всего уже была полностью скомпрометированна атакующим. Даже если машина еще не была полностью скомпрометирована, мы установили, что для эффективного анализа машины нам понадобятся права администратора. Поскольку любая учетная запись администратора (локальная или доменная) одинаково уязвима к локальному повышению привилегий, использование учетной записи администратора домена вместо аккаунта локального администратора не вносит дополнительного риска.

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

Читайте также: