Из этой статьи вы узнаете про ещё один компонент безопасности операционной системы Windows, а именно про дескрипторы безопасности.
Дескрипторы безопасности
Выше мы смотрели на механизмы которые позволяют точно идентифицировать объекты. И эти объекты, после идентификации, могут выполнять какие-то действия в системе. Если провести аналогию с реальным миром, то SID и Уровень целостности должны быть записаны в вашем паспорте (маркере доступа). Вы пытаетесь зайти на какой-то секретный объект и охранник проверяет ваш паспорт (маркер доступа) и свой список (дескриптор безопасности) тех кто может заходить на этот объект. Получается, маркеры доступа должны быть у тех, кто хочет что-то сделать. А дескрипторы безопасности нужны тем объектам с которыми хотят что-то сделать.
Дескриптор безопасности — это информация, связанная с объектом, которая определяет, кто и какие действия с объектом может выполнять.
В дескриптор безопасности входят:
- Номер версии модели монитора безопасности SRM.
- Дополнительные флаги.
- SID владельца объекта.
- Избирательный список управления доступом — DACL. Это список, кто и какой доступ имеет к объекту.
- Системный список управления доступом — SACL. Это список операций которые должны регистрироваться в журнале аудита безопасности.
ACL состоит из субъектов доступа (кто может обращаться к объекту) и набора прав для каждого субъекта (писать, читать, исполнять). DACL — указывает какой доступ имеет определенный субъект к этому объекту. SACL — указывает какие события нужно заносить в журнал аудита безопасности.
Практика
Давайте посмотрим дескриптор безопасности какого-нибудь процесса. Заметьте, дескриптор безопасности процесса определяет кто может что-то сделать с этим процессом, а не то что может сделать сам процесс. Посмотреть на дескриптор безопасности можно из Process Explorer. Я выбираю любой процесс svhost (процесс какой-то службы), открываю его свойства. Затем перехожу на вкладку «Securuty» и внизу нажимаю кнопку «Permision«:
В примере выше к этому процессу имеют доступ только локальные администраторы. При этом читать и писать в процесс они не могут, но имеют «Особые разрешения«.
Если погрузиться дальше, нажимаем кнопку «Дополнительно«, далее два раза щелкаем по группе «Администраторы«, и в открывшемся окне нажимаем ссылку «Отображение дополнительных разрешений«. Вы увидите такую ACE запись (записи в ACL называются ACE):
То есть Администраторы могут запрашивать информацию о процессе.
Вот еще некоторые сведения о DACL:
- Владельцы объекта имеют возможность редактировать DACL записи. То есть могут дать себе полные права, или дать права к этому файлу другому пользователю.
- Запрещающие правила ACL всегда имеют приоритет над разрешающими.
Если открыть свойства файла или папки, перейти на вкладку «Безопасность«, а затем нажать кнопку «Дополнительно«. И перейти на вкладку «Действующие права доступа«, то можно выбрать пользователя и проверить его права доступа к этому файлу или каталогу:
Динамическое управление доступом (DAC)
В дополнение к перечисленному выше стоит упомянуть ещё одну технологию — динамическое управление доступом.
Механизм избирательного управления доступом, описанный выше был еще с первой версии Windows NT. Но начиная с Windows 8 и Server 2012 появилось динамическое управление доступом (DAC). Оно рассчитано на домен.
Суть в том что в маркер доступа стало возможно добавлять различные атрибуты учетных записей домена. Например город в котором работает сотрудник.
Дополнительно к этому на файлы и каталоги стало возможно навешивать различные теги.
Благодаря расширению маркера доступа и тегам, DAC позволяет настраивать гибкие правила. Например, можно настроить такое поведение, чтобы сотрудник из Москвы мог прочитать файлы только с определённым тегом.
DAC не заменяет DACL, а лишь дополняет его. Так что если DACL запрещало доступ к файлу, то с помощью DAC открыть доступ мы не сможем. Получится лишь ограничить доступ ещё сильнее, оставив доступ только у тех, кому он действительно нужен.
Вот ещё примеры действий, которые можно совершить используя DAC:
- дать доступ пользователю к файлу только с определенного компьютера, при этом с других компьютеров у него не будет доступа;
- открыть доступ к файлу сотруднику, если у него соответствующая должность;
- дать доступ пользователю из определённого города, к файлу с определённым тегом.
Конфигурация DAC определяется в Active Directory и распространяется через групповые политики. Для этого был расширен протокол Kerberos. Подробнее про DAC может посмотреть в этом видео.
Вернуться к оглавлению
Если понравилась статья, подпишись на мой канал в VK или Telegram.
Security descriptors are data structures of security information for securable Windows objects, that is objects that can be identified by a unique name. Security descriptors can be associated with any named objects, including files, folders, shares, registry keys, processes, threads, named pipes, services, job objects and other resources.[1]
Security descriptors contain discretionary access control lists (DACLs) that contain access control entries (ACEs) that grant and deny access to trustees such as users or groups. They also contain a system access control list (SACLs) that control auditing of object access.[2][3] ACEs may be explicitly applied to an object or inherited from a parent object. The order of ACEs in an ACL is important, with access denied ACEs appearing higher in the order than ACEs that grant access. Security descriptors also contain the object owner.
Mandatory Integrity Control is implemented through a new type of ACE on a security descriptor.[4]
Files and folder permissions can be edited by various tools including Windows Explorer, WMI, command line tools like Cacls, XCacls, ICacls, SubInACL,[5] the freeware Win32 console FILEACL,[6][7] the free software utility SetACL, and other utilities. To edit a security descriptor, a user needs WRITE_DAC permissions to the object,[8] a permission that is usually delegated by default to administrators and the object’s owner.
The following table summarizes NTFS permissions and their roles (in individual rows.) The table exposes the following information:[9][10][11]
- Permission code: Each access control entry (ACE) specifies its permission with binary code. There are 14 codes (12 in older systems.)
- Meaning: Each permission code has a meaning, depending on whether it is applied to a file or a folder. For example, code 0x01 on a file indicates the permission to read the file, while on a folder indicates the permission to list the content of the folder. Knowing the meaning alone, however, is useless. An ACE must also specify to whom the permission applies, and whether that permission is granted or denied.
- Included in: In addition to individual permissions, an ACE can specify special permissions known as «generic access rights.» These special permissions are equivalents of a number individual permissions. For example, GENERIC_READ (or GR) is the equivalent of «Read data», «Read attributes», «Read extended attributes», «Read permissions», and «Synchronize». Because it makes sense to ask for these five at the same time, requesting «GENERIC_READ» is more convenient.
- Alias: The two Windows command-line utilities (icacls and cacls) have their own aliases for these permissions.
| Permission code |
Meaning | Included in | Alias | ||||||
|---|---|---|---|---|---|---|---|---|---|
| For files | For folders | R[a] | E[b] | W[c] | A[d] | M[e] | In icacls | In cacls | |
| 0x01 | Read data | List folder contents | Yes | Yes | Yes | Yes | RD | FILE_READ_DATA | |
| 0x80 | Read attributes | Yes | Yes | Yes | Yes | RA | FILE_READ_ATTRIBUTES | ||
| 0x08 | Read extended attributes | Yes | Yes | Yes | Yes | REA | FILE_READ_EA | ||
| 0x20 | Execute file | Traverse folder | Yes | Yes | Yes | X | FILE_EXECUTE | ||
| 0x20000 | Read permissions | Yes | Yes | Yes | Yes | Yes | RC | READ_CONTROL | |
| 0x100000 | Synchronize | Yes | Yes | Yes | Yes | Yes | S | SYNCHRONIZE | |
| 0x02 | Write data | Create files | Yes | Yes | Yes | WD | FILE_WRITE_DATA | ||
| 0x04 | Append data | Create folders | Yes | Yes | Yes | AD | FILE_APPEND_D | ||
| 0x100 | Write attributes | Yes | Yes | Yes | WA | FILE_WRITE_ATTRIBUTES | |||
| 0x10 | Write extended attributes | Yes | Yes | Yes | WEA | FILE_WRITE_EA | |||
| 0x10000 | Delete (or rename[12]) | Yes | Yes | DE | DELETE | ||||
| 0x40000 | Change permissions | Yes | WDAC | WRITE_DAC | |||||
| 0x80000 | Take ownership | Yes | WO | WRITE_OWNER | |||||
| 0x40 | Delete subfolders and files | Yes | DC | FILE_DELETE_CHILD |
Most of these permissions are self-explanatory, except the following:
- Renaming a file requires the «Delete» permission.[12]
- File Explorer doesn’t show «Synchronize» and always sets it. Multi-threaded apps like File Explorer and Windows Command Prompt need the «Synchronize» permission to be able to work with files and folders.[13]
- ^ GENERIC_READ, known as «Read» in File Explorer
- ^ GENERIC_EXECUTE, known as «Read & Execute» in File Explorer
- ^ GENERIC_WRITE, known as «Write» in File Explorer
- ^ GENERIC_ALL, known as «Full Control» in File Explorer
- ^ Known as «Modify» in File Explorer
- Access control § Computer security
- Information technology security audit
- Authorization
- Computer security
- Information security
- Token (Windows NT architecture)
- Windows SID
- SDDL
- ^ «Securable Objects». Microsoft. 2008-04-24. Retrieved 2008-07-16.
- ^ «What Are Security Descriptors and Access Control Lists?». Microsoft. Archived from the original on 2008-05-05. Retrieved 2008-07-16.
- ^ «DACLs and ACEs». Microsoft. 2008-04-24. Retrieved 2008-07-16.
- ^ https://msdn.microsoft.com/en-us/library/bb625957.aspx What is the Windows Integrity Mechanism?
- ^ SubInACL home page
- ^ FILEACL home page Archived 2012-08-29 at the Wayback Machine
- ^ «FILEACL v3.0.1.6». Microsoft. 2004-03-23. Archived from the original on April 16, 2008. Retrieved 2008-07-25.
- ^ «ACCESS_MASK Data Type». Microsoft. 2008-04-24. Retrieved 2008-07-23.
- ^ «How Permissions Work». Microsoft. 2013-06-21. Retrieved 2017-11-24.
- ^ Richard Civil (8 September 2016). «How IT works NTFS Permissions, Part 2». Microsoft. Retrieved 2017-11-24.
- ^ Richard Civil (30 August 2016). «How IT works NTFS Permissions». Microsoft. Retrieved 2017-11-24.
- ^ a b Chen, Raymond (22 October 2021). «Renaming a file is a multi-step process, only one of which is changing the name of the file». The Old New Thing. Microsoft.
Opening with DELETE permission grants permission to rename the file. The required permission is DELETE because the old name is being deleted.
- ^ Chen, Raymond (18 November 2019). «I set the same ACL with the GUI and with icacls, yet the results are different». The Old New Thing. Microsoft.
- CACLS command description on SS64.com
- SetACL SourceForge page
Дескриптор защиты
Объекты, к которым могут получать доступ процессы, имеют специальный атрибут – дескриптор защиты (security descriptor), содержащий информацию обо всех пользователях, которым разрешен или запрещен доступ к объекту.
Структура данных SECURITY_DESCRIPTOR, представляющая дескриптор защиты, описана в файле public\sdk\inc\ntseapi.h (строка 1173) и включает следующие основные поля:
- Owner – SID владельца;
- Dacl – список управления избирательным доступом;
- Sacl – системный список управления доступом.
Списки управления доступом (ACL, Access-Control List) в системе представлены заголовком (ACL Header) и последовательностью элементов списка (ACE, Access-Control Entry) (рис.13.3).
Рис.
13.3.
Внутреннее представление списка управления доступом ACL
Заголовок списка описывается структурой ACL (файл public\sdk\inc\ntseapi.h, строка 658), в которой хранятся количество элементов списка ACL (поле AceCount) и общий размер списка без заголовка (поле AclSize).
Элементы ACE имеют заголовок (ACE Header), описываемый структурой ACE_HEADER (тот же файл, строка 687), маску доступа и идентификатор безопасности SID. В заголовке указывается тип ACE (поле AceType); множество значений этого поля приведены в строках 699–728. Основными являются ACCESS_ALLOWED_ACE_TYPE (доступ разрешен) и ACCESS_DENIED_ACE_TYPE (доступ запрещен).
Маска доступа (Access Mask) описывает разнообразные виды доступа к объектам (строки 72–166). В маске выделяются стандартные права доступа (Standard Access Rights), применимые к большинству объектов, и специфичные для объектов права доступа (Object-Specific Access Rights).
Стандартными являются следующие права доступа:
- DELETE – право на удаление объекта;
- READ_CONTROL – право на просмотр информации о дескрипторе защиты объекта;
- SYNCHRONIZE – право на использование объекта для синхронизации;
- WRITE_DAC – право на изменение списка DACL;
- WRITE_OWNER – право на смену владельца объекта.
Списки управления доступом бывают двух видов: DACL и SACL. Список управления избирательным доступом (DACL, Discretionary Access-Control List) определяет пользователей, которые могут получать доступ к объекту, а также указывает тип доступа. В системном списке управления доступом (SACL, System Access-control List) перечислены пользователи и операции, которые должны учитываться в журнале аудита безопасности (security audit log).
Схема получения доступа процесса к объекту показана на рис.13.4.
Рис.
13.4.
Схема получения доступа процесса к объекту
За проверку возможности доступа процесса к объекту отвечает функция SeAccessCheck (файл base\ntos\se\accessck.c, строка 3391). На вход функции поступают следующие параметры:
- дескриптор защиты объекта (SecurityDescriptor);
- маркер доступа процесса (элемент структуры SubjectSecurityContext);
- маска запрашиваемого доступа (DesiredAccess);
- маска ранее предоставленного доступа (PreviouslyGrantedAccess);
- режим работы процессора (AccessMode);
Функция возвращает TRUE, если процессу возможно предоставить доступ к объекту, а также маску предоставленного доступа (GrantedAccess). Если доступ запрещен, функция возвращает FALSE.
Функция SeAccessCheck осуществляет следующие действия:
- Сначала анализируется режим работы процессора – если это режим ядра, доступ предоставляется без дальнейшего анализа (строки 3396–3416).
- В случае пользовательского режима проверяется дескриптор защиты: если он отсутствует (SecurityDescriptor == NULL), в доступе отказывается (строки 3423–3428).
- Если маска запрашиваемого доступа равна нулю (DesiredAccess == 0), возвращается маска ранее предоставленного доступа (строки 3442–3454).
- Если запрашивается доступ на изменение списка DACL (WRITE_DAC) или на чтение информации в дескрипторе защиты (READ_CONTROL), то при помощи функции SepTokenIsOwner проверяется, не является ли процесс владельцем объекта, к которому требуется получить доступ (строки 3477–3483). Если является, то ему предоставляются указанные права (3485–3492), а если запрашиваются только эти права, то функция успешно возвращает требуемую маску доступа (строки 3498–3506).
- Вызывается функция SepAccessCheck (определенная в том же файле, строка 1809), которая просматривает список DACL объекта в поисках соответствия идентификаторов безопасности SID в маркере доступа процесса. В том случае, если список DACL пустой, процессу предоставляется доступ (строка 3510–3527).
Права и привилегии
Кроме операций с объектами система должна контролировать множество других действий пользователей, например, вход в систему, включение/выключение компьютера, изменение системного времени, загрузка драйверов и т.д.
Для управления такими действиями, не связанными с доступом к конкретным объектам, система использует два механизма – права учетных записей и привилегии.
Право учетной записи (account right) – разрешение или запрет на определенный вид входа в систему.
Различают следующие виды входа:
- интерактивный (локальный) вход;
- вход из сети;
- вход через службу удаленных рабочих столов (ранее называлось – «через службу терминалов»);
- вход в качестве службы;
- вход в качестве пакетного задания.
Проверка прав учетных записей осуществляется не в ядре, а в процессах Winlogon.exe и Lsass.exe.
Привилегия (privilege) – разрешение или запрет определенных действий в системе, например, включение/выключение компьютера или загрузка драйверов. Привилегии хранятся в поле Privileges структуры маркера доступа TOKEN (см. выше).
Список всех привилегий в системе можно посмотреть в оснастке MMC «Локальная политика безопасности» (Local Security Policy), раздел «Локальные политики» – «Назначение прав пользователей» (Local Policies – User Rights Assignment) (см. рис.13.5). Вызывается оснастка через Панель управления – Администрирование. (Control Panel – Administrative Tools).
Рис.
13.5.
Оснастка «Локальная политика безопасности»
Следует отметить, что в оснастке не различаются права учетных записей и привилегии, но это легко можно сделать самостоятельно: право учетной записи всегда содержит слово «вход» (например, «Вход в качестве пакетного задания»).
Резюме
В лекции описываются требования к безопасности, предъявляемые к операционным системам Windows, и то, каким образом эти требования реализуются. Рассматривается схема проверки прав доступа процесса к объекту, которая заключается в сравнении параметров маркера доступа процесса и дескриптора защиты объекта. Также приводится информация о правах и привилегиях учетных записей.
Следующая лекция посвящена вопросам взаимодействия Windows с внешними устройствами.
Контрольные вопросы
- Какие требования к безопасности предъявляются к Windows?
- Что такое идентификатор защиты (SID)? Как его узнать?
- Что такое дескриптор защиты (security descriptor)? Где он хранится?
- Что такое маркер доступа (access token)? Где он хранится?
- Опишите схему получения доступа процесса к объекту.
- Что такое права и привилегии учетных записей? Чем они отличаются?
Дескрипторы
безопасности в Windows.
Дескрипторы
безопасности используются в Windows
для защиты и аудита ресурсов. Дескриптор
безопасности содержит владельца,
основную группу, дискреционный список
контроля доступа и системный список
контроля доступа.
Владелец
и основная группа.
Поля
владельца и основной группы содержат
идентификаторы безопасности. Владелец
— это принципал безопасности, владеющий
объектом. Владелец ресурса располагает
полным доступом к объекту, включая
возможность добавления и удаления
разрешений доступа в дескрипторе
безопасности.
Основная
группа содержится в дескрипторе
безопасности лишь для обеспечения
совместимости с подсистемой POSIX.
Система Windows не использует
эту часть дескриптора безопасности,
если не применяются утилиты, которые
оперируют с POSIX. По умолчанию
принципал безопасности, создавший
объект, записывает в дескриптор
безопасности свою основную группу.
Основной группой Windows по
умолчанию является группа Domain
Users.
Основная
группа подразумевает членство в группе.
При входе пользователя операционная
система вставляет SID этой
группы в маркер пользователя. Атрибут
memberOf
не перечисляет основную группу, а лишь
включает явно назначенное членство в
группах.
Дискреционные
и системные списки контроля доступа.
Списки
контроля доступа ACL состоят
из двух частей. Первая часть списка
контроля доступа представляет именованные
контрольные флаги. Эти параметры
контролируют применение разрешений в
списке ACL и правил
наследования. Вторая часть списка
контроля доступа представляет собственно
сам список. Этот список контроля доступа
содержит одну или несколько записей
управления доступом АСЕ. Флаги управления
доступом определяют, каким образом
Windows применяет записи
управления доступом внутри списка ACL.
Изначально Windows использует
защищенные и автоматические флаги.
Защищенные флаги запрещают модификацию
списка контроля доступа путем наследования.
Этот флаг является эквивалентом флажка
Allow inheritable
permissions from
parent to
propagate to this
object (Разрешение наследуемых
разрешений доступа). Флаг автоматически
разрешает записям управления доступом
в списках ACL наследовать
разрешения доступа от родительских
объектов дочерним.
Записи
управления доступом.
Списки
управления доступом содержат одну или
несколько записей контроля доступа. В
Windows записи управления
доступом разбиты на два типа: Allow
(Разрешить) и Deny (Запретить).
Каждый тип АСЕ располагает объектом
подтипа и необъектными подтипами. Записи
управления доступом Allow
и Deny назначают уровень
доступа, обеспечиваемый подсистемой
авторизации на основе права, запрашиваемого
принципалом безопасности. Записи
управления доступом к объектам являются
исключающими для объектов в AD
DS, поскольку они обеспечивают
дополнительные поля для наследования
объектов. Для большинства остальных
ресурсов, как, например, ресурсов файловой
системы и реестра, Windows
использует необъектные записи управления
доступом. Необъектные записи АСЕ
обеспечивают наследование контейнеров,
то есть объект в контейнере наследует
запись контроля доступом контейнера.
Этот принцип аналогичен наследованию
разрешений доступа файлами от родительских
папок. Каждый тип записи управления
доступом располагает полем Rights
и полем Trustee. Поля с правами
обычно заполняются предварительно
определенными числами, представляющими
действия, которые может выполнять
принципал безопасности. Рассмотрим
пример с пользователем, запрашивающим
чтение или запись файла. В этом случае
чтение и запись являются двумя отдельными
правами доступа. Поле доверия Trustee
представляет идентификатор безопасности,
разрешающий или запрещающий указанное
право. В качестве примера можно привести
пользователя или группу, которой
разрешено либо запрещено выполнять
действие, указанное в поле Right.
Маркеры доступа.
Связующим
звеном между SID-идентификатором
принципала безопасности и списком ACL
является маркер доступа. Когда Windows
выполняет проверку подлинности
пользователя с помощью Kerberos,
пользователю в процессе входа на
локальном компьютере присваивается
маркер доступа. Этот маркер включает
основной SID пользователя,
SID-идентификаторы всех
групп, которым принадлежит пользователь,
а также привилегии и права пользователя.
Примечание.
Маркер доступа также может включать в
атрибуте SIDHistory
дополнительные SID-идентификаторы.
Эти SID-идентификаторы
могут заполняться при перемещении
учетных записей пользователей из одного
домена в другой.Маркер доступа используется
подсистемой безопасности каждый раз
при попытке пользователя получить
доступ к ресурсу. Когда пользователь
пытается получить доступ к локальному
ресурсу, этот маркер предоставляется
клиентской рабочей станцией всем потокам
и приложениям, которые запрашивают
данные безопасности перед разрешением
доступа к ресурсу. Этот маркер доступа
никогда не передается по сети на другие
компьютеры. Вместо этого на каждом
сервере, где пользователь пытается
получить доступ к ресурсу, создается
локальный маркер доступа. Например,
когда пользователь пытается получить
доступ к почтовому ящику на сервере, то
на этом сервере создается маркер доступа.
В данном случае подсистема безопасности
на сервере будет сравнивать
SID-идентификаторы в маркере
доступа с разрешениями, предоставленными
в ACL-списке почтового
ящика. Если предоставленные для SID
разрешения позволяют доступ, пользователь
сможет открыть почтовый ящик.
Проверка
подлинности.
Для работы процессов
подсистемы безопасности, включая
использование SID и ACL,
нужно обеспечить способ получения
пользователями доступа к сети. По сути,
пользователи должны иметь возможность
указывать свои данные для извлечения
маркера доступа из контроллера домена.
Этот процесс называется проверкой
подлинности.
Проверка
подлинности выполняется в исходном
клиентском входе на компьютер, являющийся
членом домена AD DS.
Шаги проверки подлинности зависят от
операционной системы, с помощью которой
клиент входит в сеть.
В
случае успешной проверки подлинности
пользователю предоставляется доступ
в сеть. Если пользователь вошел в домен
и все необходимые ему ресурсы находятся
в одном лесе, пользователю только один
раз будет предложено пройти проверку
подлинности. Пока пользователь остается
в системе, все разрешения, получаемые
им в сети, основаны на начальной проверке
подлинности. Хотя учетная запись
пользователя проходит проверку
подлинности каждый раз при получении
пользователем доступа к ресурсам на
сервере, где пользователь не проходил
проверку подлинности, эта аутентификация
прозрачна для пользователя.
Время на прочтение9 мин
Количество просмотров8.8K
Давным-давно, когда трава была зеленее, а интернет безопаснее, в ИТ родилась инициатива Web Based Enterprise Management (WBEM). Первоначально спонсируемая в 1996 году такими компаниями как Cisco Systems, Intel и Microsoft, она получила широкое распространение и реализацию на различных платформах: от MAC OS до Redhat. WBEM четко документирован, основан на стандартах Интернета и представляет собой иной подход к управлению системами, отличный, например, от SNMP протокола.
Адаптация WBEM для Windows получила название WMI (Windows management interface) и впервые была представлена в Windows XP. Нам известно, что системы обновляются быстрее, чем их компоненты и многие уязвимости, бывшие ранее удобным инструментом управления, кочуют из версии в версию. В этой статье я хочу описать как выполняются задачи WMI и как избежать потенциальных рисков.
В силу своей мощности, WMI позволяет с помощью специальных утилит или сценариев производить различные потенциально опасные действия на ПК, в том числе, остановку критичных для работы служб и даже выключение компьютера. Например, так:
(Get-WmiObject Win32_OperatingSystem -EnableAllPrivileges).Win32Shutdown(5)
(GWMI -Class Win32_Service -Filter «name=’WinRM’» -ComputerName Server).StopService()
Кроме того, на удаленной машине эти действия выполнить так же просто, как на локальной — достаточно написать имя нужной машины в пути к WMI-объекту.
Пространство имен WMI – это раздел репозитория WMI, который призван группировать классы и объекты WMI по назначению, плюс, определять атрибуты безопасности при доступе к классам и объектам в каждом таком контейнере. Все пространства имен начинаются с корня, который в WMI обозначается ключевым словом root. После имени корня через косую черту указывается пространство имен. Пространства имен могут быть вложенными. Большинство интересных классов и объектов размещается в пространстве имен root/CIMv2.
Одно из существующих в Windows пространств имен WMI может быть выбрано по умолчанию. Это означает, что если вы попытаетесь подключиться к этому хосту, не указав пространство имен, то вы автоматически будете подключены к выбранному по умолчанию. В стандартной инсталляции Windows по умолчанию выбрано пространство root\cimv2.
Технология WMI предназначена для администраторов Windows, и вся система безопасности в WMI устроена так, чтобы с помощью сценариев WMI пользователь мог на заданном ПК выполнить лишь те действия, на которые ему даны разрешения/привилегии. Это так называемые привилегии по умолчанию. Так реализуется безопасность WMI на уровне операционной системы: если пользователю на уровне операционной системы не дана привилегия перезагружать компьютер, то и с помощью WMI он и не сможет этого сделать.
Дополнительные политики безопасности в WMI реализованы на уровне пространств имен протокола Distributed СОМ (DCOM) – распределенной объектной модели компонентов. Чтобы более подробно рассмотреть эти типы безопасности WMI, кратко напомню основные общие понятия, связанные с безопасностью в Windows. А основана эта безопасность на именах пользователей и их паролях.
О разрешениях WMI
Когда в Windows создается пользователь, его системной учетной записи присваивается уникальный идентификатор безопасности (Security IDentifier или SID). На основе SID для пользователя формируется маркер доступа (Access Token), в который также добавляется список групп, членом которых является пользователь и список привилегий, которыми он обладает (например, остановка служб или выключение компьютера). Этот маркер доступа присваивается также всем процессам, которые запускает пользователь. В это время каждый объект операционной системы, доступ к которому определяет система безопасности – файл, либо процесс, либо служба или что-то ещё, имеет дескриптор безопасности (Security Descriptor, SD). В этом дескрипторе, в свою очередь, хранится список контроля доступа (Access Control List, ACL) для этого объекта.
Итак, при обращении пользователя или запущенного им процесса к объекту происходит сравнение маркера доступа данного пользователя со списком контроля доступа. В зависимости от результатов выдается или отклоняется разрешение/привилегия на выполнение запрашиваемых действий над объектом.
На уровне пространств имен механизм безопасности WMI соответствует общей модели безопасности Windows. Каждое пространство имен может иметь собственный дескриптор безопасности, на котором хранится список контроля доступа (ACL).
Каждая запись списка контроля доступа (Access Control Entry, АСE) содержит информацию о том, какие разрешения имеет определенный пользователь при выполнении различных операций в этом пространстве имен.
А вот и список разрешений при работе с пространством имен:
Выполнение методов (Execute Methods). Позволяет вызывать методы классов из определенного пространства имен. Будет ли метод выполнен или произойдет отказ, зависит от того, имеет ли пользователь разрешение на выполнение этой операции в системе.
Полная запись (Full Write). Разрешает создавать и модифицировать подпространства имен, системные классы и экземпляры классов.
Частичная запись (Partial Write). Открывает возможность создавать и модифицировать любые статические классы и экземпляры несистемных классов.
Запись поставщика (Provider Write). Позволяет записывать в репозиторий CIM классы провайдеров WMI и экземпляры этих классов.
Включить учетную запись (Enable Account). Предоставляет право чтения пространства имен WMI. Пользователи с этим разрешением, могут запускать на локальном компьютере сценарии, которые читают данные WMI.
Включить удаленно (Remote Enable). Разрешает пользователям получить доступ к пространству имен WMI на удаленном компьютере. По умолчанию этим разрешением обладают только администраторы, обычные пользователи не могут получать данные WMI с удаленных машин.
Прочесть безопасность (Read Security). Дает право читать дескриптор безопасности для пространства имен WMI без возможности его модификации.
Изменение правил безопасности (Edit Security). Позволяет изменять дескриптор безопасности для пространства имен WMI.
Все эти записи списка контроля доступа хранятся в репозитории WMI. Разрешения WMI для конкретного пространства имен применяются ко всем подпространствам имен и классам, которые определены в этом пространстве (наследуются ими). Собственные же разрешения безопасности для отдельного класса WMI определить нельзя.
О настройке по умолчанию
В Windows группа администраторов обладает всеми разрешениями из таблицы выше, а для остальных пользователей включена учетная запись (Enable Account), разрешено вызывать методы (Execute Methods) и записывать в CIM экземпляры классов провайдеров (Provider Write).
Администратор может изменить разрешения для определенных пользователей с помощью утилиты для настройки параметров WMI (оснастка wmimgmt.msc консоли управления ММС).
Скриншот 1.
Для доступа к инфраструктуре WMI на удаленном компьютере используется вышеуказанный протокол DCOM. Пользователь запускает сценарий или подключается к WMI с помощью специальных утилит и выступает в качестве клиента, а объект WMI, к которому идет обращение, является сервером. Чтобы определить, какой маркер доступа будет применяться при работе с WMI на удаленном компьютере, используются стандартные уровни имперсонации протокола DCOM.
Об имперсонации или Impersonation Levels
По-русски звучит несколько коряво. Что такое имперсонация и зачем она нужна? Это метод, при котором для подключения к ресурсу процесс или система должны использовать не свой контекст безопасности, а учетные данные другого субъекта безопасности.
Представьте – некая служба, запущенная в контексте безопасности LocalSystem, должна выполнить действие от лица другой учетной записи (например, от лица текущего зарегистрированного на компьютере пользователя). В этом случае службе необходимо создать специальный маркер доступа (Access Token), описывающий контекст безопасности той учетной записи, под которой мы хотим выполнить указанное действие.
Для того чтобы создать такой маркер доступа, службе необходимо знать учетные данные этого пользователя, а если этот процесс происходит на локальной машине, получить копию маркера доступа ранее зарегистрированного локально пользователя.
Еще для этого контекст безопасности службы должен обладать привилегией создания маркеров доступа.
Бывает более сложный вариант имперсонации – делегирование. Этот вариант необходим тогда, когда подключение к конечному ресурсу выполняется не самим субъектом безопасности (в примере выше – службой от лица пользователя), а через посредника (например, промежуточный сервер).
Представьте: пользователь подключается не напрямую к базе данных, а через веб-приложение на третьем сервере. Для осуществления такого подключения веб-приложение должно получить от субъекта безопасности (нашей службы) маркер доступа с правом делегирования – это позволит веб-приложению использовать маркер доступа субъекта безопасности уже при подключении к базе данных.
В случае с WMI делегирование может выглядеть так: мы, работая на станции администратора, подключаемся по WMI к некому серверу и запускаем на нем процесс с помощью метода Execute класса Win32_Process. Этот процесс не что иное, как другой скрипт WMI, который подключается к ещё одному хосту в сети для того, чтобы совершить какие-то действия. Если мы не воспользуемся делегированием, то на конечной машине скрипт будет запущен в контексте безопасности учетной записи промежуточного сервера, что далеко не всегда желаемо. С другой стороны, подобная ситуация с делегированием в реальной жизни случается достаточно редко.
Об уровнях Impersonation Levels
Анонимный доступ (Anonymous). Объект-сервер не имеет права получить информацию о пользователе или процессе, который обращается к данному объекту (иными словами, объект не может олицетворить клиента). Этот уровень олицетворения в WMI не используется.
Идентификация (Identify). Объект-сервер может запросить маркер доступа, связанный с клиентом, но не может произвести олицетворение.
В сценариях WMI этот уровень олицетворения используется редко, в этом случае нельзя запускать сценарии WMI на удаленных машинах.
Олицетворение (Impersonate). Объект-сервер может пользоваться всеми правами и привилегиями, которыми обладает клиент. В сценариях WMI рекомендуется использовать именно этот уровень олицетворения, ибо в таком случае сценарий WMI на удаленной машине сможет выполнять все действия, которые разрешено осуществлять пользователю, запустившему этот сценарий.
Делегирование (Delegate). Объект на сервере, к которому обращается клиент, может обратиться от имени клиента к другому объекту на другом сервере. Делегирование позволяет сценарию использовать на удаленной машине маркер доступа запустившего его пользователя. Тот же маркер используется для доступа к объектам WMI на других рабочих станциях. Применение данного уровня олицетворения связано с потенциальным риском, делегирование в сценариях WMI следует применять только в случае особой необходимости.
Выбираемый по умолчанию уровень олицетворения зависит от версии WMI на целевом компьютере. В версиях WMI ниже 1.5 по умолчанию используется уровень Идентификация (Identify), в версии WMI 1.5 и выше —Олицетворение (Impersonate). При необходимости можно изменить уровень олицетворения по умолчанию — для этого необходимо записать наименование нужного уровня (например, impersonate или Delegate) в ключ реестра
HKEY_LOCAL_MACHINE\Software\Microsoft\Wbem\Scripting\Default Impersonation Level.
Скриншот 2.
Протокол DCOM также предоставляет возможность запросить для соединения WMI определенный уровень аутентификации (проверки подлинности) и конфиденциальности:
Отсутствует (None). Проверка подлинности отсутствует.
По умолчанию (Default). Для выбора уровня проверки подлинности используются стандартные настройки безопасности. Рекомендуется использовать именно этот уровень, так как к клиенту будет применен уровень проверки подлинности, который задается сервером.
Подключений (Connect). Клиент проходит проверку подлинности только во время подключения к серверу. После того как соединение установлено, никаких дополнительных проверок не производится.
Вызовов(Call). Клиент проходит проверку подлинности в начале каждого вызова, во время приема запросов сервером. При этом заголовки пакетов подписываются, однако сами данные (содержимое пакетов), передаваемые между клиентом и сервером, не подписываются и не шифруются.
Пакет (Pkt). Проверке подлинности подвергаются все пакеты данных, которые поступают серверу от клиентов. Как и при проверке подлинности на уровне вызовов, заголовки пакетов подписываются, но не шифруются. Сами пакеты не подписываются и не шифруются.
Целостности пакетов (Pktlntegrity). Все пакеты данных проходят проверку подлинности и целостности. Проверяется, что содержимое пакета не было изменено во время передачи от клиента серверу. При этом данные подписываются, но не шифруются.
Привилегии (PktPrivacy). Все пакеты данных проходят проверку подлинности и целостности, при этом данные подписываются и шифруются, что обеспечивает конфиденциальность передаваемых данных.
Администраторам Windows хорошо известны настройки безопасности системы, доступные в консоли безопасности системы и групповых политиках домена и раздел «User Right Assignments» (привилегии пользователей). Ряд действий с операционной системой можно проделать только при наличии у пользователя или группы, куда он входит, той или иной привилегии. К таким действиям, например, относятся: перезагрузка системы (завершение её работы), восстановление состояния системы из резервной копии или смена системного времени.
Поскольку с использованием WMI можно выполнить все эти действия, разработчики WMI заложили дополнительный механизм защиты: даже если учетная запись пользователя обладает привилегиями, необходимыми для действия с системой, он все равно не сможет выполнить это действие, пока явно не активирует привилегию перед выполнением действия. В частности, если администратор запустит скрипт WMI, запрашивающий перезагрузку системы, этого все равно не произойдет, пока в скрипте не будет явно активирована эта привилегия.
Резюме
Что предлагается сделать для обеспечения безопасности WMI-подключений:
- Изменить уровень имперсонации для критичных сервисов (Скриншот 2).
- Настроить разрешения wmimgmt.msc (Скриншот 1).
- Изменить репозиторий по умолчанию. Это может нарушить сценарий шаблонных атак.
4. Изменить группы лиц с возможностями удаленного запуска и активации WMI через утилиту DCOMCNFG
5. Чтобы запустить WMI пользователь должен быть членом группы administrators либо DCOM users. Также должна быть доступна служба remote registry.
6. Настроить файервол – входящие подключения к DCOM идут по 135 TCP-порту и (имеют?) динамический диапазон RPC.
В заключение хочу сказать следующее: WMI дает скорость, мощь и легкость запуска команд на удаленных хостах, а SQL based-семантика команд делает его легким для освоения.
В интернете очень много информации о взломах и WMI-атаках, ведь они вписываются в нынешний атакующий тренд – использование нативных инструментов взлома системы – наряду с telnet NTP и DNS. Наша задача — этот тренд уловить и найти методы противодействия уже заложенные в систему.
Автор: Галиулин Тимур GTRch