Дескриптор безопасности windows это

Из этой статьи вы узнаете про ещё один компонент безопасности операционной системы Windows, а именно про дескрипторы безопасности.

Дескрипторы безопасности

Выше мы смотрели на механизмы которые позволяют точно идентифицировать объекты. И эти объекты, после идентификации, могут выполнять какие-то действия в системе. Если провести аналогию с реальным миром, то SID и Уровень целостности должны быть записаны в вашем паспорте (маркере доступа). Вы пытаетесь зайти на какой-то секретный объект и охранник проверяет ваш паспорт (маркер доступа) и свой список (дескриптор безопасности) тех кто может заходить на этот объект. Получается, маркеры доступа должны быть у тех, кто хочет что-то сделать. А дескрипторы безопасности нужны тем объектам с которыми хотят что-то сделать.

Дескриптор безопасности — это информация, связанная с объектом, которая определяет, кто и какие действия с объектом может выполнять.

В дескриптор безопасности входят:

• Номер версии модели монитора безопасности SRM.
• Дополнительные флаги.
• SID владельца объекта.
• Избирательный список управления доступом — DACL. Это список, кто и какой доступ имеет к объекту.
• Системный список управления доступом — SACL. Это список операций которые должны регистрироваться в журнале аудита безопасности.

ACL состоит из субъектов доступа (кто может обращаться к объекту) и набора прав для каждого субъекта (писать, читать, исполнять). DACL — указывает какой доступ имеет определенный субъект к этому объекту. SACL — указывает какие события нужно заносить в журнал аудита безопасности.

Практика

Давайте посмотрим дескриптор безопасности какого-нибудь процесса. Заметьте, дескриптор безопасности процесса определяет кто может что-то сделать с этим процессом, а не то что может сделать сам процесс. Посмотреть на дескриптор безопасности можно из Process Explorer. Я выбираю любой процесс svhost (процесс какой-то службы), открываю его свойства. Затем перехожу на вкладку «Securuty» и внизу нажимаю кнопку «Permision«:

Картинка с сайта: sysadminium.ru

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

Если погрузиться дальше, нажимаем кнопку «Дополнительно«, далее два раза щелкаем по группе «Администраторы«, и в открывшемся окне нажимаем ссылку «Отображение дополнительных разрешений«. Вы увидите такую ACE запись (записи в ACL называются ACE):

Картинка с сайта: sysadminium.ru

То есть Администраторы могут запрашивать информацию о процессе.

Вот еще некоторые сведения о DACL:

• Владельцы объекта имеют возможность редактировать DACL записи. То есть могут дать себе полные права, или дать права к этому файлу другому пользователю.
• Запрещающие правила ACL всегда имеют приоритет над разрешающими.

Если открыть свойства файла или папки, перейти на вкладку «Безопасность«, а затем нажать кнопку «Дополнительно«. И перейти на вкладку «Действующие права доступа«, то можно выбрать пользователя и проверить его права доступа к этому файлу или каталогу:

Картинка с сайта: sysadminium.ru

Динамическое управление доступом (DAC)

В дополнение к перечисленному выше стоит упомянуть ещё одну технологию — динамическое управление доступом.

Механизм избирательного управления доступом, описанный выше был еще с первой версии Windows NT. Но начиная с Windows 8 и Server 2012 появилось динамическое управление доступом (DAC). Оно рассчитано на домен.

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

Картинка с сайта: sysadminium.ru

Дополнительно к этому на файлы и каталоги стало возможно навешивать различные теги.

Благодаря расширению маркера доступа и тегам, DAC позволяет настраивать гибкие правила. Например, можно настроить такое поведение, чтобы сотрудник из Москвы мог прочитать файлы только с определённым тегом.

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

Вот ещё примеры действий, которые можно совершить используя DAC:

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

Конфигурация DAC определяется в Active Directory и распространяется через групповые политики. Для этого был расширен протокол Kerberos. Подробнее про DAC может посмотреть в этом видео.

Вернуться к оглавлению

Если понравилась статья, подпишись на мой канал в VK или Telegram.

Дескриптор защиты

Объекты, к которым могут получать доступ процессы, имеют специальный атрибут – дескриптор защиты (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).

Картинка с сайта: intuit.ru

Рис.
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.

Картинка с сайта: intuit.ru

Рис.
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).

Картинка с сайта: intuit.ru

Рис.
13.5.
Оснастка «Локальная политика безопасности»

Следует отметить, что в оснастке не различаются права учетных записей и привилегии, но это легко можно сделать самостоятельно: право учетной записи всегда содержит слово «вход» (например, «Вход в качестве пакетного задания»).

Резюме

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

Следующая лекция посвящена вопросам взаимодействия Windows с внешними устройствами.

Контрольные вопросы

1. Какие требования к безопасности предъявляются к Windows?
2. Что такое идентификатор защиты (SID)? Как его узнать?
3. Что такое дескриптор защиты (security descriptor)? Где он хранится?
4. Что такое маркер доступа (access token)? Где он хранится?
5. Опишите схему получения доступа процесса к объекту.
6. Что такое права и привилегии учетных записей? Чем они отличаются?

Overview#

Security Descriptor (NT-Sec-Desc or nTSecurityDescriptor) is component of the Access Control Model-Microsoft Windows that contains security information specified when it is created, or default security information if none is specified.Security Descriptor is on every Securable object and is pre-defined for the Object type or it can be modified ONLY after creation.

Security Descriptor structure is a compact binary representation for the security associated with a Securable object such as a Microsoft Active Directory or Microsoft Windows as on a File System.

Security Descriptor is not, however, convenient for use in tools that operate primarily on text strings. Therefore, a text-based form of the Security Descriptor is available for situations when a Security Descriptor must be carried by a text method. This format is the Security Descriptor Description Language (SDDL)

Security Descriptor components#

A security descriptor includes information that specifies the following components of an object’s security:

• OWNER_SECURITY_INFORMATION (OSI) 0x1 which is the Security Identifier (SID)
• GROUP_SECURITY_INFORMATION (GSI) 0x2 which is the PrimaryGroupID SID
• DACL_SECURITY_INFORMATION (DSI) 0x4 which is the Discretionary Access Control List (DACL)
• SACL_SECURITY_INFORMATION (SSI) 0x8 which is the System Access Control List (SACL)
• Qualifiers for the preceding items

An ACL contains a list of Access Control Entry (ACEs). Each Access Control Entry specifies a set of access permissions and contains a Security Identifier (SID) that identifies a trustee for whom the permissions are allowed, denied, or audited. A trustee can be a user account, group account, or logon session.

Security Descriptor maybe modified or read using LDAP by making use of the LDAP_SERVER_SD_FLAGS_OID SupportedControl!! More Information
There might be more information for this subject on one of the following:

• Access Control Entry
• Access Control List
• Access Control Model-Microsoft Windows
• DACL_SECURITY_INFORMATION
• Discretionary Access Control List
• GROUP_SECURITY_INFORMATION
• LDAP_SERVER_SD_FLAGS_OID
• MS Access Mask
• NT-Sec-Desc
• OWNER_SECURITY_INFORMATION
• Relative IDentifier
• SACL_SECURITY_INFORMATION
• SECURITY_IMPERSONATION_LEVEL
• SchemaIDGUID
• Securable object
• Security Descriptor Description Language
• Security Reference Monitor
• System Access Control List

• [#1] — 6.1.3.2 SD Flags Control — based on information obtained 2019-02-28-

Время на прочтение9 мин

Количество просмотров8.8K

Картинка с сайта: habr.com

Давным-давно, когда трава была зеленее, а интернет безопаснее, в ИТ родилась инициатива 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.

Картинка с сайта: habr.com

Для доступа к инфраструктуре 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.

Картинка с сайта: habr.com

Протокол DCOM также предоставляет возможность запросить для соединения WMI определенный уровень аутентификации (проверки подлинности) и конфиденциальности:

Отсутствует (None). Проверка подлинности отсутствует.

По умолчанию (Default). Для выбора уровня проверки подлинности используются стандартные настройки безопасности. Рекомендуется использовать именно этот уровень, так как к клиенту будет применен уровень проверки подлинности, который задается сервером.

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

Вызовов(Call). Клиент проходит проверку подлинности в начале каждого вызова, во время приема запросов сервером. При этом заголовки пакетов подписываются, однако сами данные (содержимое пакетов), передаваемые между клиентом и сервером, не подписываются и не шифруются.

Пакет (Pkt). Проверке подлинности подвергаются все пакеты данных, которые поступают серверу от клиентов. Как и при проверке подлинности на уровне вызовов, заголовки пакетов подписываются, но не шифруются. Сами пакеты не подписываются и не шифруются.

Целостности пакетов (Pktlntegrity). Все пакеты данных проходят проверку подлинности и целостности. Проверяется, что содержимое пакета не было изменено во время передачи от клиента серверу. При этом данные подписываются, но не шифруются.

Привилегии (PktPrivacy). Все пакеты данных проходят проверку подлинности и целостности, при этом данные подписываются и шифруются, что обеспечивает конфиденциальность передаваемых данных.

Администраторам Windows хорошо известны настройки безопасности системы, доступные в консоли безопасности системы и групповых политиках домена и раздел «User Right Assignments» (привилегии пользователей). Ряд действий с операционной системой можно проделать только при наличии у пользователя или группы, куда он входит, той или иной привилегии. К таким действиям, например, относятся: перезагрузка системы (завершение её работы), восстановление состояния системы из резервной копии или смена системного времени.

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

Резюме

Что предлагается сделать для обеспечения безопасности WMI-подключений:

1. Изменить уровень имперсонации для критичных сервисов (Скриншот 2).
2. Настроить разрешения wmimgmt.msc (Скриншот 1).
3. Изменить репозиторий по умолчанию. Это может нарушить сценарий шаблонных атак.

Картинка с сайта: habr.com

4. Изменить группы лиц с возможностями удаленного запуска и активации WMI через утилиту DCOMCNFG

Картинка с сайта: habr.com

5. Чтобы запустить WMI пользователь должен быть членом группы administrators либо DCOM users. Также должна быть доступна служба remote registry.

6. Настроить файервол – входящие подключения к DCOM идут по 135 TCP-порту и (имеют?) динамический диапазон RPC.

Картинка с сайта: habr.com

В заключение хочу сказать следующее: WMI дает скорость, мощь и легкость запуска команд на удаленных хостах, а SQL based-семантика команд делает его легким для освоения.

В интернете очень много информации о взломах и WMI-атаках, ведь они вписываются в нынешний атакующий тренд – использование нативных инструментов взлома системы – наряду с telnet NTP и DNS. Наша задача — этот тренд уловить и найти методы противодействия уже заложенные в систему.

Автор: Галиулин Тимур GTRch