Это первая статья цикла, который будет описывать методы исследования структур системы Windows и Active Directory. В статье попробуем изучить мини инфраструктуру AD и попытаемся понять как обнаруживаются логические уязвимости.
В сети достаточно много статей о том, что была найдена логическая уязвимость, которая позволяет выполнять повышение привилегий. Как происходит поиск и работа с такими уязвимостями?
Что такое AD и эскалация привилегий через ACL
Операционная система Windows с точки зрения разграничения привилегий использует списки доступа или так называемые ACL листы. Каждый такой лист содержит информацию о том какие привилегии есть у пользователя или какие привилегии требует объект в операционной системе, чтобы можно было с ним взаимодействовать (читать, изменять и т. д.). Если привилегии для одной операционной системы могут быть сохранены в структурах самой операционной системы, то в случае если используется целая инфраструктура на базе ОС Windows, то для сохранения данных о доступе к объектам приходится вести базу данных.
Своеобразная «база» данных используется набором сервисов, который называется Active Directory. Как эти данные хранятся и как их читать? Нужно установить на любой Windows Server роль AD Services и заглянуть в оснастку ADSI — специальный инструмент для просмотра данных об объектах в хранилище active Directory. Его интерфейс выглядит вот так:
Инструмент поставляется вместе с сервисами AD, поэтому ничего дополнительного устанавливать не нужно. Все данные, которые располагаются в базе типизированны и представляются в виде дерева, вложенные элементы являются элементарными объектами их характеристики и наименования задаются шаблонами, которые называются scheme, а объекты, которые находятся выше в дереве являются контейнерами. ADSI хоть и показывает объекты, с которыми чаще всего работает администратор и пользователь AD, но это не все данные базы. Остальные данные расположены по отдельным контейнерам доступ к которым можно обнаружить в других приложениях и структурах ОС. Мы же, чтобы максимально собрать данные в одном месте будем использовать ADExplorer.
Вообще академическое описание того из чего состоит AD есть на официальном сайте. Чтобы не цитировать официальную документацию и искать в чем смысл всех обобщенных схем, попробуем визуализировать то, что представляет собой на самом деле Windows Active Directory. Чтобы Active Directory работало, нужно, чтобы был как минимум один сервер Windows, так как на него и будут устанавливаться AD сервисы. В операционной системе это возможно за счет настройки ролей. Набор сервисов для работы Active Directory это просто набор системных приложений главной задачей которых стоит удобное использование ресурсов организации. Возьмем самый простой вариант AD, где пока что нет никаких пользователей и групп и визуализируем в приложении AdExplorer.
Как видно из рисунка, база содержит в самом начале фиксированное количество записей. Эти записи хранят необходимые для работы алгоритмов сервисов данные, а так же данные, которые могут вносить сами пользователи или система сервисов с течением своего существования.
В Active Directory одна из самых полезных возможностей это создание набора привилегий, которые могут позволять достаточно тонко контролировать доступ ко всем объектам, которые описаны в базе AD. Да, именно в базе, потому что здесь все данные о пользователях,сетях, машинах, группах и т. д. сохраняются в специальные схемы и контейнеры. Визуально можно представить эти данные вот так:
Пользователи и информация о стандартных группах, машинах:
Информация о конфигурации системы:
Информация по схемам - основной единице описания данных в AD:
Наличие привилегий или их отсутствие над контейнером или схемой в базе AD может приводить к проведению атак. Результатом таких атак может быть изменение характеристик объектов, которые располагаются в базе, либо нарушение разграничения доступа.
Кстати, помимо рассмотрения объектов, из картинок выше можно прочитать какие параметры есть у объектов и через них собирать фильтры для ldap запросов.
Нарушения доступа или изменение характеристик внутри AD
Общий термин для этой разновидности атак — «ACL Abuse». Самый, пожалуй, полный справочник по тому какие «Abuse» действия можно выполнять находится в readthedocs проекта bloodhound.
Как видно из методик, наличие «лишнего» ACL может сильно влиять на то, что может сделать пользователь в рамках Active Directory. Кстати, можно просматривать доступы к объектам, схемам и контейнерам прямо из AdExplorer:
Доступ к схеме выбранной группы:
Картинки показывают свойства объектов, которые представляют собой группу в AD. То есть чтобы создать группу в AD нужно чтобы была выбрана соответствующая scheme, у scheme в рамках AD будет свой автор и владелец так как он будет определять набор полей и первоначальные права доступа к объекту, который будет создаваться на основе scheme. Когда объект уже создается ему могут быть присвоены дополнительные права, которые могут принадлежать кому угодно в AD. Отсюда как раз и создается возможность найти такой набор scheme→объект, в которых будут разниться привилегии допустимые для всех пользователей AD или только пользователей, у которых прописано в наборе привилегий какие‑то определенные параметры.
Вся описанная выше процедура практически никогда не делается вручную и для этого либо существуют уже готовые scheme и пользователь через инструменты AD создает новые объекты, либо, если требуется новая scheme, то она поставляется вместе с программным обеспечением, которое и выполнит все необходимые преобразования. На этом месте уже можно себе представить, что система, которая будет существовать достаточно долгое время, будет периодически заполняться софтом, который требует особых параметров в scheme, и обновления, патчи, откаты самой ОС будут вносить идеальный хаос в наборы привилегий. Отсюда вопрос поиска уязвимости ставится с точки зрения того что хочет злоумышленник. И начинается поиск контейнера или scheme, которые удовлетворяют поставленной задаче.
Сбор данных о характеристиках объектов в AD конечно же не обязательно делать только с использованием ADExplorer, это можно делать так же посредством обращения, например в LDAP. Единственная сложность такого обращения будет заключаться в том, что нужно забрать из базы достаточное количество информации, чтобы ее можно было анализировать на наличие уязвимостей. Кстати, сбор большего числа данных для таких поисков производится сегодня через инструмент Bloodhound. Но стоит иметь в виду, что инструмент в стандартном виде позволяет смотреть только типичные и общеизвестные проблемы среди объектов AD.
Кстати об уязвимостях и объектах, на волне популярной сейчас атаки на использование сертификатов для аутентификации в AD. Можно заглянуть в раздел «Public Key Services» и посмотреть какие права доступа у пользователей к шаблонам:
Как видно из набора привилегий, даже являясь просто пользователем AD можно читать данные о самих шаблонах и их специальных параметрах. Среди которых находятся и данные, которые позволяют выпускать сертификаты для доступа к сервисам. Здесь, конечно придется немного полистать документацию и создать пару скриптов на Powershell. В итоге можно собирать данные по характеристикам шаблонов для этого можно использовать функции, которые приведены ниже:
$Object = [ADSI]"LDAP://CN=Administrator,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=LAB,DC=COM"
#$Object = [ADSI]"LDAP://CN=ClientAuth,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=LAB,DC=COM"
function Get-PKIDescription {
param([int]$flags)
$msPKICertificateNameFlag = @{
0x00000001= "ENROLLEE_SUPPLIES_SUBJECT"
0x00000002 = "ADD_EMAIL"
0x00000004 = "ADD_OBJ_GUID"
0x00000008 = "OLD_CERT_SUPPLIES_SUBJECT_AND_ALT_NAME"
0x00000100 = "ADD_DIRECTORY_PATH"
0x00010000 = "ENROLLEE_SUPPLIES_SUBJECT_ALT_NAME"
0x00400000 = "SUBJECT_ALT_REQUIRE_DOMAIN_DNS"
0x00800000 = "SUBJECT_ALT_REQUIRE_SPN"
0x01000000 = "SUBJECT_ALT_REQUIRE_DIRECTORY_GUID"
0x02000000 = "SUBJECT_ALT_REQUIRE_UPN"
0x04000000 = "SUBJECT_ALT_REQUIRE_EMAIL"
0x08000000 = "SUBJECT_ALT_REQUIRE_DNS"
0x10000000 = "SUBJECT_REQUIRE_DNS_AS_CN"
0x20000000 = "SUBJECT_REQUIRE_EMAIL"
0x40000000 = "SUBJECT_REQUIRE_COMMON_NAME"
0x80000000 = "SUBJECT_REQUIRE_DIRECTORY_PATH"
}
foreach($bits in $msPKICertificateNameFlag.Keys | Sort-Object){
if($flags -band $bits){
$msPKICertificateNameFlag[$bits]
}
}
}
function GetPKIEnrollFlagsDesc
{ param($flags)
$msPKIEnrollmentFlag = @{
0x00000000 = "NONE"
0x00000001 = "INCLUDE_SYMMETRIC_ALGORITHMS"
0x00000002 = "PEND_ALL_REQUESTS"
0x00000004 = "PUBLISH_TO_KRA_CONTAINER"
0x00000008 = "PUBLISH_TO_DS"
0x00000010 = "AUTO_ENROLLMENT_CHECK_USER_DS_CERTIFICATE"
0x00000020 = "AUTO_ENROLLMENT"
0x80 = "CT_FLAG_DOMAIN_AUTHENTICATION_NOT_REQUIRED"
0x00000040 = "PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT"
0x00000100 = "USER_INTERACTION_REQUIRED"
0x200 = "ADD_TEMPLATE_NAME"
0x00000400 = "REMOVE_INVALID_CERTIFICATE_FROM_PERSONAL_STORE"
0x00000800 = "ALLOW_ENROLL_ON_BEHALF_OF"
0x00001000 = "ADD_OCSP_NOCHECK"
0x00002000 = "ENABLE_KEY_REUSE_ON_NT_TOKEN_KEYSET_STORAGE_FULL"
0x00004000 = "NOREVOCATIONINFOINISSUEDCERTS"
0x00008000 = "INCLUDE_BASIC_CONSTRAINTS_FOR_EE_CERTS"
0x00010000 = "ALLOW_PREVIOUS_APPROVAL_KEYBASEDRENEWAL_VALIDATE_REENROLLMENT"
0x00020000 = "ISSUANCE_POLICIES_FROM_REQUEST"
0x00040000 = "SKIP_AUTO_RENEWAL"
0x00080000 = "NO_SECURITY_EXTENSION"
}
foreach($bits in $msPKIEnrollmentFlag.Keys | Sort-Object){
if($flags -band $bits){
$msPKIEnrollmentFlag[$bits]
}
}
}
Get-PKIDescription([int]$Object.'msPKI-Certificate-Name-Flag'.Value)
GetPKIEnrollFlagsDesc([int]$Object.'msPKI-Enrollment-Flag'.Value)
Таким образом можно самостоятельно изучать структуры AD и подходы к атакам на инфраструктуру.
На этом все. В конце статьи хочу пригласить вас на свой бесплатный урок, где рассмотрим принципы работы привилегий в операционной системе и инструменты для их исследования.
Комментарии (5)
anzay911
00.00.0000 00:00Перед публикацией стоило бы закинуть в спеллчекер. Многовато синтаксических.
olegtsss
Не понятно, что делает приведенный вами скрипт?