Как локальная версия MS Exchange компрометирует Active Directory и что организации могут сделать, чтобы предотвратить это.
В SpectreOps мы рекомендуем нашим клиентам установить границу безопасности вокруг их наиболее важных активов (т. е. нулевого уровня ) Active Directory (AD). Мы помогаем им находить и устранять пути атак, пересекающие границу безопасности, с помощью BloodHound Enterprise . Одной из наиболее распространенных проблем, с которыми мы и наши клиенты сталкиваемся, является локальная версия Microsoft Exchange (Exchange).
Если вы скомпрометируете Exchange в AD, вам почти гарантирован путь атаки к полному контролю над доменом из-за обширных разрешений AD, которыми обладает Exchange. Так было уже много лет; Microsoft сократила многие разрешения, но проблема осталась.
В этом сообщении блога мы рассмотрим, какие разрешения имеет Exchange в AD, которыми злоумышленник может злоупотребить, чтобы скомпрометировать домен; какое влияние оказывает другая модель разрешений Exchange на компрометацию разрешений AD; и что организации могут сделать, чтобы уменьшить разрешения, чтобы взлом Exchange не обеспечил путь атаки к полному контролю над доменом.
Однако Microsoft со временем сократила разрешения Exchange, так что злоумышленник, взломавший сервер Exchange, сегодня не имеет прямого пути атаки для компрометации домена. Microsoft исправила разрешение WriteDACL для объекта домена с помощью накопительного обновления для Exchange в 2019 году (описано здесь ). Более того, то же обновление « возвращает все среды к общему сокращенному профилю разрешений каталога », что означает, что обновление удалило старые ненужные разрешения. Позже в том же году Microsoft представила два запретительных разрешения для группы DnsAdmins , чтобы предотвратить возможность компрометации домена группами Exchange с помощью атаки, описанной Шэй Бером здесь: Функция, а не ошибка: компрометация DNSAdmin для DC в одной строке .
Означает ли это, что сегодня Exchange безвреден? Не в последнюю очередь.
Разрешения Exchange Windows имеют следующие компрометирующие разрешения:
По пользователям (без отключения наследования ACL)
Операторы учетных записей
Администраторы
Администраторы
Операторы резервного копирования Администраторы
домена
Контроллеры домена (группа)
Администраторы предприятия
Администраторы корпоративных ключей (отсутствуют в документации MS)
Ключевые администраторы (отсутствуют в документации MS)
KRBTGT
Операторы печати
Контроллеры домена только для чтения Администраторы схемы
репликатора Операторы сервера
Имейте в виду, что AdminSDHolder также защищает членов вышеуказанных групп, включая вложенные члены, но не членов объектов-компьютеров. Защита AdminSDHolder работает только потому, что для объекта AdminSDHolder отключено наследование ACL. Защита станет неэффективной, если вы включите наследование ACL для объекта.
Группа разрешений Windows Exchange по умолчанию включает серверы Exchange среды AD в качестве членов группы доверенной подсистемы Exchange . Обе группы и серверы обмена находятся под контролем третьей группы Exchange под названием « Управление организацией» :
В группу управления организацией будут входить пользователи-администраторы Exchange; это означает, что компрометация серверов Exchange или пользователя-администратора Exchange предоставляет привилегии группы разрешений Windows Exchange.
Разрешения группы разрешений Windows Exchange по умолчанию не позволяют вам скомпрометировать домен, поскольку члены администраторов домена и другие привилегированные пользователи защищены AdminSDHolder и не находятся под контролем разрешений Windows Exchange. Однако AdminSDHolder не защищает всех пользователей и группы нулевого уровня, а разрешения Exchange Windows, скорее всего, в любом случае будут иметь путь атаки на домен. Например, вы можете скомпрометировать любую учетную запись службы с включенным наследованием ACL по умолчанию. Типичным примером учетной записи службы нулевого уровня является учетная запись службы Microsoft Entra Connect (ранее известная как Azure AD Connect) (т. е. учетная запись соединителя AD DS , обычно называемая MSOL_nnnnnnnnnnnn). Эта учетная запись имеет очень привилегированные права в большинстве конфигураций. Например, для работы функции синхронизации хэша паролей он должен иметь разрешения GetChanges и GetChangesAll для объекта домена, как описывает Microsoft здесь . Эти разрешения позволяют провести атаку DCSync, которая ставит под угрозу весь домен AD. Вы можете защитить учетную запись службы от унаследованных разрешений, выполнив шаг «Ограничить разрешения для учетной записи соединителя AD DS» в настройке Microsoft Entra Connect, но я лично видел много сред, где это не было сделано и где существует путь атаки со стороны Обменяйте группу разрешений Windows на домен через учетную запись соединителя AD DS:
Также важно помнить, что злоумышленнику может не потребоваться компрометация домена для достижения своих целей. Предположим, что в качестве целей у них есть одна или несколько критически важных для бизнеса систем. В этом случае им, вероятно, не потребуется компрометировать администраторов домена, чтобы добраться до этих целей, и группа Exchange Windows Permissions, скорее всего, будет иметь путь атаки на системы с ее расширенными разрешениями.
Вышеупомянутые разрешения Exchange действительны для Exchange, настроенного в модели общих разрешений по умолчанию. Что делать, если вы настроили Exchange с более строгой моделью разрешений? В следующем разделе мы ответим на этот вопрос, углубившись в разрешения AD, предоставляемые в трех моделях разрешений Exchange.
Microsoft задокументировала разрешения AD Exchange в справочнике по разрешениям развертывания Exchange 2013 , но, насколько мне известно, аналогичной документации для Exchange 2016 и Exchange 2019, к сожалению, не существует. Поэтому, чтобы проверить разрешения AD Exchange в различных моделях, я установил Exchange Server 2019 в модели общих разрешений по умолчанию в своей лаборатории, изменил ее на модель разделенных разрешений RBAC и изменил ее на модель разделенных разрешений AD. Между каждым шагом я запускал SharpHound и сценарий PowerShell, чтобы составить список всех ненаследованных записей контроля доступа (ACE) объектов AD в контексте именования домена (NC), NC конфигурации и схеме (включая дескриптор безопасности по умолчанию), используя Get-AllADACLs.ps1 . Это позволило мне использовать Get-ACLDiff.ps1 для просмотра и сравнения разрешений AD различных моделей.
Прежде чем мы углубимся в разрешения AD различных моделей, важно иметь базовое представление о ролях Exchange и RBAC .
Административные роли Exchange существуют в AD как универсальные группы безопасности:
Сюда входит группа «Управление организацией», которая является наиболее привилегированной ролью Exchange. Мы не будем рассказывать о том, что может делать каждая из групп ролей Exchange, поскольку в этой статье мы сосредоточимся на том, что может сделать злоумышленник, если он скомпрометирует Exchange, а не только на ограниченную роль Exchange.
Вы можете увидеть все разрешения AD, добавленные к существующим объектам AD моей лаборатории AD, когда я установил Exchange Server 2019, здесь: Exchange-AD-ACL-testing/01 Exchange установленный diff .
Из документации модели мы можем прочитать, что «разделение RBAC» относится к разделению разрешений в Exchange RBAC, а не в AD. Это объясняет, почему мы не видим больше изменений в AD. Итак, честно говоря, я предполагаю, что это может быть не совсем та же картина, поскольку режим разделения RBAC дает вам больше возможностей для делегирования ограниченного контроля в Exchange RBAC. Однако с точки зрения злоумышленника, имеющего контроль над сервером/администратором Exchange, все выглядит так же.
Вы можете увидеть полный список разрешений AD, удаленных в моей лаборатории AD (на объектах AD, не относящихся к Exchange) после настройки модели разделенных разрешений AD, по адресу Exchange-AD-ACL-testing/02 AD Split Deployed diff .
Группам Exchange по-прежнему предоставляется несколько разрешений AD, даже при использовании модели разделенных разрешений AD. В следующем разделе мы подробнее рассмотрим некоторые из них.
ObjectDN: DC=external,DC=local
InheritedObject:
Object: Personal-Information
ActiveDirectoryRights: WriteProperty
InheritanceType: All
ObjectType: 77b5b886-944a-11d1-aebd-0000f80367c1
InheritedObjectType: 00000000-0000-0000-0000-00
0000000000 ObjectFlags: ObjectAceTypePresent
AccessControlType: Разрешить
IdentityReference: EXTERNAL\Exchange Доверенная подсистема
IsInherited: False
InheritanceFlags: ContainerInherit
PropagationFlags: Нет
ObjectDN: CN=AdminSDHolder,CN=System,DC=external,DC=local
InheritedObject:
Object: Личная информация
ActiveDirectoryRights: WriteProperty
InheritanceType: All
ObjectType: 77b5b886-944a-11d1-aebd-0000f80367c1
InheritedObjectType: 00000000-000 0-0000-0000 -000000000000
ObjectFlags: ObjectAceTypePresent
AccessControlType: Allow
IdentityReference: EXTERNAL\Exchange Доверенная подсистема
IsInherited: False
InheritanceFlags: ContainerInherit
PropagationFlags: Нет
Это означает, что группа может записывать атрибуты этого набора свойств на всех объектах AD, к которым применяется этот набор свойств. Документация Microsoft для набора свойств «Личная информация» определяет атрибуты, являющиеся частью набора свойств для разных версий Windows. Атрибут msDS-AllowedToActOnBehalfOfOtherIdentityявляется частью набора свойств последней версии Windows, указанного в документации. Энтузиасты безопасности AD (такие как я) знают, что доступ на запись к этому атрибуту на компьютере позволяет злоумышленнику скомпрометировать хост компьютера с помощью атаки RBCD . Похоже, что доверенная подсистема Exchange может скомпрометировать любой хост в среде AD. Я протестировал атаку, но при попытке записи в msDS-AllowedToActOnBehalfOfOtherIdentityатрибут получил ошибку «доступ запрещен».
Более мудрые энтузиасты безопасности AD (другими словами, не я) будут знать, что атрибут msDS-AllowedToActOnBehalfOfOtherIdentityпереместился в User-Account-Restrictions набор свойств, как объяснил Дирк-Ян Моллема в своем сообщении в блоге «Злоупотребление забытыми разрешениями на компьютерные объекты в Active Directory ». Документация Microsoft доступна только до Windows Server 2012 и выше msDS-AllowedToActOnBehalfOfOtherIdentity, поэтому вы не можете увидеть текущий набор свойств атрибута.
Чтобы избавить других от такого же разочарования, я создал сценарий PowerShell для распечатки всех наборов свойств среды AD с именем Get-PropertySets.ps1 . Сценарий также включает выходные данные моей лабораторной среды в виде блока комментариев, поэтому вам не обязательно его запускать.
Дополнительная информация ( примечания
) cn) Компания (компания) Отдел (отдел) Описание (description) Отображаемое имя-печать (displayNamePrintable) Подразделение (подразделение) Адреса электронной почты (почта) Имя (givenName) Инициалы (инициалы) Legacy-Exchange-DN ( HeritageExchangeDN) Менеджер (менеджер) ms-DS-Allowed-To-Delegate-To (msDS-AllowedToDelegateTo) ms-DS-Auxiliary-Classes (msDS-Auxiliary-Classes) ms-DS-Approx-Immed-Subordinates (msDS-Approx- Immed-Subordinates) ms-DS-Phonetic-FirstName (msDS-PhoneticFirstName) ms-DS-Phonetic-LastName (msDS-PhoneticLastName) ms-DS-Phonetic-Department (msDS-PhoneticDepartment) ms-DS-Phonetic- Название компании (msDS-PhoneticCompanyName) ms-DS-Phonetic-Display-Name (msDS-PhoneticDisplayName) ms-DS-HAB-Seniority-Index (msDS-HABSeniorityIndex) ms-DS-Source-Object-DN (msDS-SourceObjectDN) Obj-Dist-Name (distinguishedName) Object-Category (objectCategory) Object-Class (objectClass) Object-Guid (objectGUID) Имя-организации (o) Имя-подразделения организации (ou) Другой-Почтовый ящик (otherMailbox) Прокси-адреса ( proxyAddresses) RDN (name) Отчеты (directReports) Имя-участника-службы (servicePrincipalName) Показать-в-адресной книге (showInAddressBook) Фамилия (sn) Системные-флаги (systemFlags) Text-Country (co) Text-Encoded-OR- Адрес (textEncodedORAddress) Имя-участника-пользователя (userPrincipalName)
Мы рассмотрим те, которые показались мне интересными.
Однако, как объясняется в статье Жеро, Microsoft добавила специальные запрещающие элементы управления доступом, чтобы заблокировать доступ на запись к атрибуту SPN:
ObjectDN: DC=external,DC=local
InheritedObject:
Object: Имя-участника-службы
ActiveDirectoryRights: WriteProperty
InheritanceType: Все
ObjectType: f3a64788-5306-11d1-a9c5-0000f80367c1
InheritedObjectType: 00000000-0000-0000-0000 -000000000000
ObjectFlags: ObjectAceTypePresent
AccessControlType : Запретить
IdentityReference : EXTERNAL\Exchange Доверенная подсистема
IsInherited : False
InheritanceFlags : ContainerInherit
PropagationFlags : Нет
ObjectDN: CN=AdminSDHolder,CN=System,DC=external,DC=local
InheritedObject:
Object: Имя-участника-службы
ActiveDirectoryRights: WriteProperty
InheritanceType: Все
ObjectType: f3a64788-5306-11d1-a9c5-0000f80367c1
InheritedObjectType: 00000000- 00 :00-00:00 -0000-000000000000
ObjectFlags: ObjectAceTypePresent
AccessControlType: Deny
IdentityReference: EXTERNAL\Exchange Доверенная подсистема
IsInherited: False
InheritanceFlags: ContainerInherit
PropagationFlags: Нет
Запретить ACE означает, что атака предотвращена.
Ключевые требования для атаки зависят от того, выбирает ли злоумышленник аутентификацию Kerberos (PKINIT) или Schannel. Требования аутентификации Kerberos:
«Сопоставления», которые вы можете добавить в атрибут, представляют собой строки, соответствующие определенному шаблону. Чтобы сопоставить внешнего пользователя Kerberos с UPN [email protected] с данным пользователем, вам необходимо добавить следующую строку сопоставления: Kerberos:[email protected]. Сопоставление сертификатов X.509 дает вам возможность использовать различные значения свойств сертификата:
Эти сопоставления сертификатов X.509 известны как явные сопоставления сертификатов , поскольку вы явно определяете сопоставление вместо того, чтобы позволить контроллеру домена неявно находить соответствующего участника на основе UPN или значения SAM-Account-Name.
Alt-Security-IdentitiesПрежде чем вы начнете слишком волноваться, отметим, что в объекте домена и AdminSDHolder есть два запрета на запись в ACE, предназначенные для доверенной подсистемы Exchange:
ObjectDN: DC=external,DC=local
InheritedObject: Компьютер
Объект: Alt-Security-Identities
ActiveDirectoryRights: WriteProperty
InheritanceType: Все
ObjectType: 00fbf30c-91fe-11d1-aebc-0000f80367c1
InheritedObjectType: bf967a86-0de6-11d0-a285- 00aa003049e2
ObjectFlags: ObjectAceTypePresent , InheritedObjectAceTypePresent
AccessControlType: Deny
IdentityReference: EXTERNAL\Exchange Доверенная подсистема
IsInherited: False
InheritanceFlags: ContainerInherit
PropagationFlags: None
ObjectDN: CN=AdminSDHolder,CN=System,DC=external,DC=local
InheritedObject: Компьютер
Объект: Alt-Security-Identities
ActiveDirectoryRights: WriteProperty
InheritanceType: Все
ObjectType: 00fbf30c-91fe-11d1-aebc-0000f80367c1
InheritedObjectType: bf967a86- 0de6- 11d0-a285-00aa003049e2
ObjectFlags: ObjectAceTypePresent, InheritedObjectAceTypePresent
AccessControlType: Deny
IdentityReference: EXTERNAL\Exchange Доверенная подсистема
IsInherited: False
InheritanceFlags: ContainerInherit
PropagationFlags: Нет
Однако интересно то, что они применяются только к текущему объекту и компьютерным объектам-потомкам. Это означает, что доверенные подсистемы Exchange по-прежнему могут писать Alt-Security-Identitiesвсем пользователям с включенным наследованием ACL (например, не защищенным AdminSDHolder). Давайте посмотрим, что это позволит нам сделать.
Явное сопоставление Kerberos
Похоже, что до патча No PAC можно было злоупотреблять явным сопоставлением Kerberos . Чарли Кларк демонстрирует в своем блоге CVE-2021–42287/CVE-2021–42278 Weaponisation , как злоумышленник в одном домене с разрешением на запись Alt-Security-Identitiesцелевого пользователя в другом домене позволяет злоумышленнику скомпрометировать целевого пользователя, выполнив следующие шаги:
Исправление «No PAC» сделало невозможным получение TGT без PAC из центра распространения ключей Kerberos AD (KDC). Я попытался выполнить атаку в исправленной среде, где у TGT был PAC, и это не сработало, однако я предполагаю, что можно осуществить атаку из области KDC, отличной от Windows, с входящим доверием из домена AD целевого пользователя, поскольку оттуда должна быть возможность получить TGT без PAC.
Явное сопоставление сертификата X.509
Явное сопоставление сертификата — это ссылка на сертификат. Любой, у кого сертификат соответствует ссылке явного сопоставления сертификатов принципала, может использовать свой сертификат для аутентификации в качестве принципала. Таким образом, злоумышленник может злоупотребить доступом для записи к Alt-Security-Identitiesатрибуту пользователя AD, чтобы добавить явное сопоставление сертификатов со ссылкой на сертификат, которым владеет злоумышленник, а затем использовать этот сертификат для аутентификации в качестве этого пользователя.
Этот метод злоупотребления был впервые задокументирован в 2019 году, когда Жеро де Друа описал, как злоумышленник, скомпрометировавший локальный Exchange, может выполнить атаку, на этой странице GitHub: Набор свойств Public-Information включает Alt-Security-Identities, позволяет сопоставлять сертификаты x509. привилегированным пользователям . Кроме того, Жан Марсо продемонстрировал атаку в сообщении блога Microsoft ADCS — злоупотребление PKI в среде Active Directory в разделе « Эксплойт ACL на пользовательских объектах (1) ». Недавно я также изучил технику злоупотребления и опубликовал сообщение в блоге здесь: ADCS ESC14 Abuse Technique .
Злоумышленник может выполнить атаку, выполнив следующие действия:
Это означает, что злоумышленник, обладающий контролем над администратором Exchange или сервером Exchange, может скомпрометировать любого пользователя AD с включенным наследованием ACL, даже если вы настроили Exchange в модели разделения разрешений AD.
Злоумышленник, который не может зарегистрировать какие-либо сертификаты в среде, может даже иметь возможность выполнить атаку. Ханс-Йоахим Кноблох объяснил в ветке LinkedIn , что KDC не требует, чтобы контроллер домена доверял эмитенту сертификата для аутентификации NT при выполнении явного сопоставления сертификатов X509IssuerSubject , X509IssuerSerialNumber , X509SKI или X509SHA1PublicKey . Microsoft визуализировала это поведение в виде блок-схемы в документации по логике обработки сертификатов , и Ханс обсудил это в очень интересном сообщении в блоге здесь: Nilpferde, NDES und Goldene Zertifikate als Schlüssel zum AD . Это означает, что злоумышленник потенциально может использовать сертификат одного из многих общедоступных корневых центров сертификации, которым DC по умолчанию доверяют при атаке, что устраняет необходимость в правах регистрации в среде AD.
Если вам нужен локальный Exchange, вместо этого вы можете ограничить разрешения AD Exchange. Трудно придумать общий минимальный набор разрешений AD для групп Exchange AD, поскольку использование Exchange варьируется в разных организациях; однако должна быть возможность определить, для каких пользователей и групп Exchange вообще не нужны никакие разрешения. Exchange не должны требоваться разрешения для большинства, если не для всех, учетных записей служб, пользователей-администраторов и групп администраторов. В некоторых организациях у администраторов есть почтовые ящики. Вам следует избегать этого, внедряя отдельные учетные записи для администраторов , чтобы не подвергать администраторов атакам по электронной почте, таким как фишинг. Сотрудник с ролью, требующей привилегированного доступа (администратора), должен получить отдельную учетную запись администратора без почтового ящика для привилегированного доступа в дополнение к своей обычной рабочей учетной записи с почтовым ящиком.
Существует несколько способов запретить применение разрешений Exchange AD объекта домена к заданному набору объектов:
Да, я использовал тот же мем в своем предыдущем посте в блоге. Я действительно это имею в виду!
Приведенные выше рекомендации действительны для Exchange, настроенного с любой моделью разрешений.
Если вы настроите Exchange на модель разделения AD, Exchange не будет иметь таких же компрометирующих разрешений, как две другие модели разрешений. Поэтому я настоятельно рекомендую рассмотреть модель разделения AD . У меня ограниченные знания о работе администратора Exchange, и я не знаю, насколько сложно администраторам Exchange адаптироваться к модели разделения AD, но я слышал, что это требует усилий. Я рекомендую ознакомиться с раздельными разрешениями Switch to Active Directory от Microsoft и этой публикацией в блоге TEAL , в которой объясняется, как настроить некоторые разрешения, которые вам могут понадобиться: Разделение разрешений Exchange — разрешения и процессы AD .
Если вы решите не использовать модель разделения AD, подумайте, можете ли вы уменьшить любое из трех компрометирующих разрешений, описанных в разделе « Что может Exchange сделать сегодня, BloodHound?» раздел. Например, Exchange может не обязательно иметь возможность сбрасывать пароли обычных пользователей, даже если у них есть почтовый ящик.
Уменьшить разрешение группы «Доверенные подсистемы Exchange» на запись для Alt-Security-Identitiesатрибута пользователей сложно, поскольку разрешение предоставляется через доступ на запись к Public-Informationнабору свойств. Чтобы избежать запрета ACE, вы можете заменить доступ на запись к набору свойств доступом на запись к отдельным атрибутам в наборе свойств; однако это значительно увеличит количество ACE для большого набора свойств, такого как Public-Information. Атрибуты могут принадлежать только одному набору свойств, поэтому создание пользовательского набора свойств, содержащего подмножество исходного набора свойств, невозможно, если вы не удалите атрибуты из исходного. Поэтому лучшим решением, на мой взгляд, является изменение существующего запрета записи в Alt-Security-IdentitiesACE для доверенной подсистемы Exchange на объекте домена, чтобы он поражал объекты всех классов, а не только компьютеры. Вы можете использовать этот сценарий PowerShell, чтобы проверить, у каких пользователей установлен атрибут, чтобы получить представление об использовании атрибута в организации перед внесением изменений: Get-AltSecIDMapping.ps1 .
Наконец, вам также следует проверить, какие разрешения AD, отличные от стандартных, Exchange получил за эти годы. Exchange обычно имеет компрометирующие разрешения, настроенные непосредственно для пользователей, компьютеров и групп, созданных Exchange в AD. Вы можете использовать этот запрос Cypher в BloodHound, чтобы найти исходящие границы ACL, созданные из ненаследованных элементов управления доступом из групп Exchange, в объекты AD за пределами подразделений и контейнеров Exchange:
СОВПАДЕНИЕ p = (g:Group)-[r]->(x)
ГДЕ g.distinguishedname СОДЕРЖИТ «MICROSOFT EXCHANGE»
, А НЕ x.distinguishedname СОДЕРЖИТ «MICROSOFT EXCHANGE»
И r.isinherited = ЛОЖНЫЙ
ВОЗВРАТ p LIMIT 100
Обязательно привлекайте администраторов Exchange к процессу уменьшения разрешений AD Exchange, поскольку они могут помочь вам определить, какие разрешения необходимы, и проверить, что все работает должным образом после применения изменений. Я также рекомендую вам документировать разрешения до и после изменения и подготовить способ восстановления удаленных разрешений в случае, если что-то сломается (например, с помощью сценария).
Если вам вообще не хочется уменьшать разрешения AD Exchange, вам следует рассматривать группы Exchange AD «Разрешения Windows Exchange» и «Доверенная подсистема Exchange» как нулевой уровень; однако я не советую этого делать. Серверы Exchange нулевого уровня увеличивают поверхность атаки нулевого уровня, а это означает, что вам следует ограничивать доступ к серверам Exchange так же, как вы это делаете с контроллерами домена.
Разрешения AD Exchange можно ограничить. Вы можете изменить Exchange, чтобы он использовал модель разделения AD и тем самым устранить компрометирующие разрешения AD Exchange, за исключением разрешения ESC14, которое можно исправить отдельным усилием. Модель разделения AD или нет, вы также можете ограничить круг пользователей и групп, которым Exchange имеет разрешения; например, переместив разрешение из объекта домена в подразделения, содержащие пользователей и группы, где Exchange действительно необходимы разрешения.
В SpectreOps мы рекомендуем нашим клиентам установить границу безопасности вокруг их наиболее важных активов (т. е. нулевого уровня ) Active Directory (AD). Мы помогаем им находить и устранять пути атак, пересекающие границу безопасности, с помощью BloodHound Enterprise . Одной из наиболее распространенных проблем, с которыми мы и наши клиенты сталкиваемся, является локальная версия Microsoft Exchange (Exchange).
Если вы скомпрометируете Exchange в AD, вам почти гарантирован путь атаки к полному контролю над доменом из-за обширных разрешений AD, которыми обладает Exchange. Так было уже много лет; Microsoft сократила многие разрешения, но проблема осталась.
В этом сообщении блога мы рассмотрим, какие разрешения имеет Exchange в AD, которыми злоумышленник может злоупотребить, чтобы скомпрометировать домен; какое влияние оказывает другая модель разрешений Exchange на компрометацию разрешений AD; и что организации могут сделать, чтобы уменьшить разрешения, чтобы взлом Exchange не обеспечил путь атаки к полному контролю над доменом.
Благодарности
Большое спасибо следующим людям за их работу, которую я использовал в этом сообщении в блоге:- Жеро де Друа за репозиторий GitHub, документирующий атаки Exchange AD: Exchange-AD-Privesc
- Шей Бер за описание того, как DnsAdmins может скомпрометировать контроллеры домена: Функция, а не ошибка: компрометация DNSAdmin для контроллера домена в одной строке.
- Дирк-Ян Моллема за описание наборов свойств AD: злоупотребление забытыми разрешениями на компьютерные объекты в Active Directory.
- Оливеру Ляку за описание методов злоупотребления ESC9 и ESC10: Certipy 4.0: ESC9 и ESC10, графический интерфейс BloodHound, новые методы аутентификации и запроса — и многое другое!
- Чарли Кларку за описание того, как можно злоупотреблять явным сопоставлением Kerberos: CVE-2021–42287/CVE-2021–42278.
- Жану Марсо за описание того, как можно злоупотреблять явным сопоставлением сертификатов: Microsoft ADCS — злоупотребление PKI в среде Active Directory.
- Ханс-Йоахим Кноблох за описание того, как можно злоупотреблять явным сопоставлением сертификатов: Hippos, NDES и золотые сертификаты как ключи к AD
- Али Таджран за описание того, как удалить разрешения Exchange в AD: Как удалить Exchange из Active Directory
- TEAL для описания настройки соответствующих разрешений Exchange в AD: Разделение разрешений Exchange — разрешения и процессы AD
Обмен путями атак в прошлом
При установке Exchange создается набор групп Exchange AD для пользователей-администраторов Exchange и серверов Exchange и предоставляется этим группам множество разрешений в AD. Традиционно этот набор разрешений был очень обширным и включал разрешения, позволяющие Exchange получить полный контроль над средой AD. Например, группа Exchange Windows Permissions по умолчанию имела разрешение WriteDACL для объекта домена, что позволяло группе предоставлять разрешения DCSync и тем самым ставило под угрозу домен.Однако Microsoft со временем сократила разрешения Exchange, так что злоумышленник, взломавший сервер Exchange, сегодня не имеет прямого пути атаки для компрометации домена. Microsoft исправила разрешение WriteDACL для объекта домена с помощью накопительного обновления для Exchange в 2019 году (описано здесь ). Более того, то же обновление « возвращает все среды к общему сокращенному профилю разрешений каталога », что означает, что обновление удалило старые ненужные разрешения. Позже в том же году Microsoft представила два запретительных разрешения для группы DnsAdmins , чтобы предотвратить возможность компрометации домена группами Exchange с помощью атаки, описанной Шэй Бером здесь: Функция, а не ошибка: компрометация DNSAdmin для DC в одной строке .
Означает ли это, что сегодня Exchange безвреден? Не в последнюю очередь.
Что может сделать Exchange сегодня, BloodHound?
Я установил Exchange Server 2019 в своей лаборатории AD с моделью общих разрешений по умолчанию (подробнее о различных моделях разрешений см. в следующем разделе). Запуск BloodHound показывает, что группа разрешений Windows Exchange по-прежнему имеет достаточные привилегии в AD:Разрешения Exchange Windows имеют следующие компрометирующие разрешения:
По пользователям (без отключения наследования ACL)
- WriteDACL : разрешение на добавление любых разрешений, включая полный доступ.
- ForceChangePassword : разрешение на сброс пароля пользователя.
- AddMember : разрешение на добавление участников в группу.
Операторы учетных записей
Администраторы
Администраторы
Операторы резервного копирования Администраторы
домена
Контроллеры домена (группа)
Администраторы предприятия
Администраторы корпоративных ключей (отсутствуют в документации MS)
Ключевые администраторы (отсутствуют в документации MS)
KRBTGT
Операторы печати
Контроллеры домена только для чтения Администраторы схемы
репликатора Операторы сервера
Имейте в виду, что AdminSDHolder также защищает членов вышеуказанных групп, включая вложенные члены, но не членов объектов-компьютеров. Защита AdminSDHolder работает только потому, что для объекта AdminSDHolder отключено наследование ACL. Защита станет неэффективной, если вы включите наследование ACL для объекта.
Группа разрешений Windows Exchange по умолчанию включает серверы Exchange среды AD в качестве членов группы доверенной подсистемы Exchange . Обе группы и серверы обмена находятся под контролем третьей группы Exchange под названием « Управление организацией» :
В группу управления организацией будут входить пользователи-администраторы Exchange; это означает, что компрометация серверов Exchange или пользователя-администратора Exchange предоставляет привилегии группы разрешений Windows Exchange.
Разрешения группы разрешений Windows Exchange по умолчанию не позволяют вам скомпрометировать домен, поскольку члены администраторов домена и другие привилегированные пользователи защищены AdminSDHolder и не находятся под контролем разрешений Windows Exchange. Однако AdminSDHolder не защищает всех пользователей и группы нулевого уровня, а разрешения Exchange Windows, скорее всего, в любом случае будут иметь путь атаки на домен. Например, вы можете скомпрометировать любую учетную запись службы с включенным наследованием ACL по умолчанию. Типичным примером учетной записи службы нулевого уровня является учетная запись службы Microsoft Entra Connect (ранее известная как Azure AD Connect) (т. е. учетная запись соединителя AD DS , обычно называемая MSOL_nnnnnnnnnnnn). Эта учетная запись имеет очень привилегированные права в большинстве конфигураций. Например, для работы функции синхронизации хэша паролей он должен иметь разрешения GetChanges и GetChangesAll для объекта домена, как описывает Microsoft здесь . Эти разрешения позволяют провести атаку DCSync, которая ставит под угрозу весь домен AD. Вы можете защитить учетную запись службы от унаследованных разрешений, выполнив шаг «Ограничить разрешения для учетной записи соединителя AD DS» в настройке Microsoft Entra Connect, но я лично видел много сред, где это не было сделано и где существует путь атаки со стороны Обменяйте группу разрешений Windows на домен через учетную запись соединителя AD DS:
Также важно помнить, что злоумышленнику может не потребоваться компрометация домена для достижения своих целей. Предположим, что в качестве целей у них есть одна или несколько критически важных для бизнеса систем. В этом случае им, вероятно, не потребуется компрометировать администраторов домена, чтобы добраться до этих целей, и группа Exchange Windows Permissions, скорее всего, будет иметь путь атаки на системы с ее расширенными разрешениями.
Вышеупомянутые разрешения Exchange действительны для Exchange, настроенного в модели общих разрешений по умолчанию. Что делать, если вы настроили Exchange с более строгой моделью разрешений? В следующем разделе мы ответим на этот вопрос, углубившись в разрешения AD, предоставляемые в трех моделях разрешений Exchange.
Модели обмена и разрешения в AD
Вы можете настроить Exchange с использованием трех различных моделей разрешений:- Модель общих разрешений (по умолчанию)
- Модель разделения разрешений управления доступом на основе ролей (RBAC)
- Модель разделения разрешений AD
Microsoft задокументировала разрешения AD Exchange в справочнике по разрешениям развертывания Exchange 2013 , но, насколько мне известно, аналогичной документации для Exchange 2016 и Exchange 2019, к сожалению, не существует. Поэтому, чтобы проверить разрешения AD Exchange в различных моделях, я установил Exchange Server 2019 в модели общих разрешений по умолчанию в своей лаборатории, изменил ее на модель разделенных разрешений RBAC и изменил ее на модель разделенных разрешений AD. Между каждым шагом я запускал SharpHound и сценарий PowerShell, чтобы составить список всех ненаследованных записей контроля доступа (ACE) объектов AD в контексте именования домена (NC), NC конфигурации и схеме (включая дескриптор безопасности по умолчанию), используя Get-AllADACLs.ps1 . Это позволило мне использовать Get-ACLDiff.ps1 для просмотра и сравнения разрешений AD различных моделей.
Прежде чем мы углубимся в разрешения AD различных моделей, важно иметь базовое представление о ролях Exchange и RBAC .
Обмен ролями и RBAC
Exchange имеет собственную систему авторизации RBAC. Когда пользователь пытается выполнить действие в командной консоли Exchange или в интерфейсе центра администрирования Exchange, Exchange проверяет, есть ли у пользователя роль Exchange , которая позволяет ему выполнять действие в соответствии с моделью RBAC. Если RBAC авторизует пользователя, он может выполнить действие независимо от своих разрешений AD. Это действие выполняет Exchange, поэтому AD разрешит это действие только в том случае, если объект-компьютер сервера Exchange имеет необходимые разрешения в AD. Сервер Exchange имеет свои разрешения через группу «Доверенная подсистема Exchange» и группу «Разрешения Windows Exchange», которые мы видели в предыдущем разделе.Административные роли Exchange существуют в AD как универсальные группы безопасности:
Сюда входит группа «Управление организацией», которая является наиболее привилегированной ролью Exchange. Мы не будем рассказывать о том, что может делать каждая из групп ролей Exchange, поскольку в этой статье мы сосредоточимся на том, что может сделать злоумышленник, если он скомпрометирует Exchange, а не только на ограниченную роль Exchange.
Модель общих разрешений Exchange
Модель общих разрешений является моделью по умолчанию. Доверенные разрешения Exchange, разрешения Exchange Windows и некоторые группы ролей Exchange имеют разрешения в AD с этой моделью; однако большинство разрешений являются бескомпромиссными, например, доступ на чтение и запись к атрибутам, специфичным для Exchange. Разрешения, которые приводят к исходящим ребрам BloodHound к объектам, не принадлежащим Exchange, описаны в разделе « Что может сегодня делать Exchange, BloodHound?» раздел .Вы можете увидеть все разрешения AD, добавленные к существующим объектам AD моей лаборатории AD, когда я установил Exchange Server 2019, здесь: Exchange-AD-ACL-testing/01 Exchange установленный diff .
Модель разделения разрешений Exchange RBAC
Модель разделения RBAC — любимая у Microsoft: (из документации Microsoft )Это звучит многообещающе, но когда я изменил свое развертывание Exchange на эту модель, я обнаружил, что ни один ACE в домене NC не был добавлен или удален за пределами организационного подразделения (OU) групп безопасности Microsoft Exchange и контейнера системных объектов Microsoft Exchange . Аналогично в Конфигурационном NC были изменения только в контейнере Microsoft Exchange . Таким образом, пути атаки в рамках модели общих разрешений от сервера/администратора Exchange к пользователям и группам также действительны в модели разделения RBAC.
Из документации модели мы можем прочитать, что «разделение RBAC» относится к разделению разрешений в Exchange RBAC, а не в AD. Это объясняет, почему мы не видим больше изменений в AD. Итак, честно говоря, я предполагаю, что это может быть не совсем та же картина, поскольку режим разделения RBAC дает вам больше возможностей для делегирования ограниченного контроля в Exchange RBAC. Однако с точки зрения злоумышленника, имеющего контроль над сервером/администратором Exchange, все выглядит так же.
Модель разделения разрешений AD
Microsoft пишет вот что о модели разделения AD:Это верно. Группа разрешений Exchange Windows сильно меняется с появлением модели разделения AD:
- Группа сейчас пуста; группа доверенных разрешений Exchange больше не является членом
- Входящие разрешения для группы ограничены привилегированными группами по умолчанию (т. е. администраторами домена, администраторами предприятия и т. д.), что означает, что доверенная подсистема Exchange и управление организацией потеряли свои разрешения для группы.
- Все элементы управления доступом, назначенные группе, исчезли, за исключением одного запрещающего элемента управления доступом в домене.
Вы можете увидеть полный список разрешений AD, удаленных в моей лаборатории AD (на объектах AD, не относящихся к Exchange) после настройки модели разделенных разрешений AD, по адресу Exchange-AD-ACL-testing/02 AD Split Deployed diff .
Группам Exchange по-прежнему предоставляется несколько разрешений AD, даже при использовании модели разделенных разрешений AD. В следующем разделе мы подробнее рассмотрим некоторые из них.
Более пристальный взгляд на разрешения Exchange AD
Группы Exchange имеют несколько разрешений для объектов AD, не относящихся к Exchange, даже если вы развертываете модель разделения Exchange AD. Ни одно из этих разрешений не приводит к преимуществам BloodHound, но некоторые из них все еще весьма актуальны.Запись набора свойств личной информации
Группа доверенной подсистемы Exchange имеет разрешение на запись в Personal-Informationнабор свойств AdminSDHolder и в объект домена с включенным наследованием ACL:ObjectDN: DC=external,DC=local
InheritedObject:
Object: Personal-Information
ActiveDirectoryRights: WriteProperty
InheritanceType: All
ObjectType: 77b5b886-944a-11d1-aebd-0000f80367c1
InheritedObjectType: 00000000-0000-0000-0000-00
0000000000 ObjectFlags: ObjectAceTypePresent
AccessControlType: Разрешить
IdentityReference: EXTERNAL\Exchange Доверенная подсистема
IsInherited: False
InheritanceFlags: ContainerInherit
PropagationFlags: Нет
ObjectDN: CN=AdminSDHolder,CN=System,DC=external,DC=local
InheritedObject:
Object: Личная информация
ActiveDirectoryRights: WriteProperty
InheritanceType: All
ObjectType: 77b5b886-944a-11d1-aebd-0000f80367c1
InheritedObjectType: 00000000-000 0-0000-0000 -000000000000
ObjectFlags: ObjectAceTypePresent
AccessControlType: Allow
IdentityReference: EXTERNAL\Exchange Доверенная подсистема
IsInherited: False
InheritanceFlags: ContainerInherit
PropagationFlags: Нет
Это означает, что группа может записывать атрибуты этого набора свойств на всех объектах AD, к которым применяется этот набор свойств. Документация Microsoft для набора свойств «Личная информация» определяет атрибуты, являющиеся частью набора свойств для разных версий Windows. Атрибут msDS-AllowedToActOnBehalfOfOtherIdentityявляется частью набора свойств последней версии Windows, указанного в документации. Энтузиасты безопасности AD (такие как я) знают, что доступ на запись к этому атрибуту на компьютере позволяет злоумышленнику скомпрометировать хост компьютера с помощью атаки RBCD . Похоже, что доверенная подсистема Exchange может скомпрометировать любой хост в среде AD. Я протестировал атаку, но при попытке записи в msDS-AllowedToActOnBehalfOfOtherIdentityатрибут получил ошибку «доступ запрещен».
Более мудрые энтузиасты безопасности AD (другими словами, не я) будут знать, что атрибут msDS-AllowedToActOnBehalfOfOtherIdentityпереместился в User-Account-Restrictions набор свойств, как объяснил Дирк-Ян Моллема в своем сообщении в блоге «Злоупотребление забытыми разрешениями на компьютерные объекты в Active Directory ». Документация Microsoft доступна только до Windows Server 2012 и выше msDS-AllowedToActOnBehalfOfOtherIdentity, поэтому вы не можете увидеть текущий набор свойств атрибута.
Чтобы избавить других от такого же разочарования, я создал сценарий PowerShell для распечатки всех наборов свойств среды AD с именем Get-PropertySets.ps1 . Сценарий также включает выходные данные моей лабораторной среды в виде блока комментариев, поэтому вам не обязательно его запускать.
Запись набора свойств общедоступной информации
Группа доверенной подсистемы Exchange имеет разрешение на запись в Public-Informationнабор свойств в AdminSDHolder и в объект домена с включенным наследованием ACL, как и в случае с Personal-Informationнабором свойств. Набор Public-Informationсвойств содержит следующие атрибуты:Дополнительная информация ( примечания
) cn) Компания (компания) Отдел (отдел) Описание (description) Отображаемое имя-печать (displayNamePrintable) Подразделение (подразделение) Адреса электронной почты (почта) Имя (givenName) Инициалы (инициалы) Legacy-Exchange-DN ( HeritageExchangeDN) Менеджер (менеджер) ms-DS-Allowed-To-Delegate-To (msDS-AllowedToDelegateTo) ms-DS-Auxiliary-Classes (msDS-Auxiliary-Classes) ms-DS-Approx-Immed-Subordinates (msDS-Approx- Immed-Subordinates) ms-DS-Phonetic-FirstName (msDS-PhoneticFirstName) ms-DS-Phonetic-LastName (msDS-PhoneticLastName) ms-DS-Phonetic-Department (msDS-PhoneticDepartment) ms-DS-Phonetic- Название компании (msDS-PhoneticCompanyName) ms-DS-Phonetic-Display-Name (msDS-PhoneticDisplayName) ms-DS-HAB-Seniority-Index (msDS-HABSeniorityIndex) ms-DS-Source-Object-DN (msDS-SourceObjectDN) Obj-Dist-Name (distinguishedName) Object-Category (objectCategory) Object-Class (objectClass) Object-Guid (objectGUID) Имя-организации (o) Имя-подразделения организации (ou) Другой-Почтовый ящик (otherMailbox) Прокси-адреса ( proxyAddresses) RDN (name) Отчеты (directReports) Имя-участника-службы (servicePrincipalName) Показать-в-адресной книге (showInAddressBook) Фамилия (sn) Системные-флаги (systemFlags) Text-Country (co) Text-Encoded-OR- Адрес (textEncodedORAddress) Имя-участника-пользователя (userPrincipalName)
Мы рассмотрим те, которые показались мне интересными.
Напишите имя-участника-службы
Из списка в предыдущем разделе Service-Principal-Nameвыделяется атрибут (SPN). Доступ на запись к этому атрибуту позволяет выполнять целевой Kerberoasting . Жеро де Друа описал эту атаку здесь: Write Public-Information ACE приводит к Kerberoasting из групп безопасности Exchange .Однако, как объясняется в статье Жеро, Microsoft добавила специальные запрещающие элементы управления доступом, чтобы заблокировать доступ на запись к атрибуту SPN:
ObjectDN: DC=external,DC=local
InheritedObject:
Object: Имя-участника-службы
ActiveDirectoryRights: WriteProperty
InheritanceType: Все
ObjectType: f3a64788-5306-11d1-a9c5-0000f80367c1
InheritedObjectType: 00000000-0000-0000-0000 -000000000000
ObjectFlags: ObjectAceTypePresent
AccessControlType : Запретить
IdentityReference : EXTERNAL\Exchange Доверенная подсистема
IsInherited : False
InheritanceFlags : ContainerInherit
PropagationFlags : Нет
ObjectDN: CN=AdminSDHolder,CN=System,DC=external,DC=local
InheritedObject:
Object: Имя-участника-службы
ActiveDirectoryRights: WriteProperty
InheritanceType: Все
ObjectType: f3a64788-5306-11d1-a9c5-0000f80367c1
InheritedObjectType: 00000000- 00 :00-00:00 -0000-000000000000
ObjectFlags: ObjectAceTypePresent
AccessControlType: Deny
IdentityReference: EXTERNAL\Exchange Доверенная подсистема
IsInherited: False
InheritanceFlags: ContainerInherit
PropagationFlags: Нет
Запретить ACE означает, что атака предотвращена.
Напишите имя-участника-пользователя
Атрибут User-Principal-Name(UPN) более интересен. Оливер Ляк продемонстрировал в блоге ESC9 и ESC10 , как злоумышленник может злоупотребить доступом на запись к этому атрибуту контролируемого пользователя или компьютера, чтобы поставить под угрозу любого пользователя или компьютер в лесу AD. Атаки на ESC9 и ESC10 со злоупотреблением UPN выглядят следующим образом:- Перезаписать UPN участника, контролируемого злоумышленником (т. е. жертвы), чтобы он был атрибутом SAM-Account-Nameцелевого пользователя или [email protected]целевого компьютера.
- Зарегистрируйте сертификат, который позволяет выполнять аутентификацию (клиента) в качестве жертвы.
- Измените UPN жертвы на что-то другое, чтобы оно не совпадало с UPN в сертификате.
- Аутентифицироваться как целевой субъект
Ключевые требования для атаки зависят от того, выбирает ли злоумышленник аутентификацию Kerberos (PKINIT) или Schannel. Требования аутентификации Kerberos:
- Контроллер домена (DC) допускает слабое сопоставление сертификатов для Kerberos, что означает, что StrongCertificateBindingEnforcementзначение ключа реестра DC установлено равным 0 или 1 (не 2)
. - Значение по умолчанию — 1.
- Значение 0 интерпретируется как 1 (т. е. режим совместимости). ) с апреля 2023 г., как описано здесь
. Строгое сопоставление сертификатов будет введено в действие к 11 февраля 2025 г. - Сертификат не включает расширение SID, которое требует, чтобы шаблон сертификата содержал флаг CT_FLAG_NO_SECURITY_EXTENSIONв msPKI-Enrollment-Flagатрибуте (отсутствует по умолчанию).
- Контроллер домена допускает сопоставление сертификатов UPN (слабых) для Schannel, что означает, что CertificateMappingMethodsзначение ключа реестра DC содержит флаг UPN (т. е. 0x04) (отсутствует по умолчанию).
Напишите Alt-Security-Identities
Набор Public-Informationсвойств также включает в себя Alt-Security-Identitiesследующее описание Microsoft: « Содержит сопоставления сертификатов X.509 или внешних учетных записей пользователей Kerberos с этим пользователем в целях аутентификации». Более подробное описание можно найти в разделе «Атрибуты безопасности пользователя» и KB5014754 — Изменения аутентификации на основе сертификатов на контроллерах домена Windows .«Сопоставления», которые вы можете добавить в атрибут, представляют собой строки, соответствующие определенному шаблону. Чтобы сопоставить внешнего пользователя Kerberos с UPN [email protected] с данным пользователем, вам необходимо добавить следующую строку сопоставления: Kerberos:[email protected]. Сопоставление сертификатов X.509 дает вам возможность использовать различные значения свойств сертификата:
Эти сопоставления сертификатов X.509 известны как явные сопоставления сертификатов , поскольку вы явно определяете сопоставление вместо того, чтобы позволить контроллеру домена неявно находить соответствующего участника на основе UPN или значения SAM-Account-Name.
Alt-Security-IdentitiesПрежде чем вы начнете слишком волноваться, отметим, что в объекте домена и AdminSDHolder есть два запрета на запись в ACE, предназначенные для доверенной подсистемы Exchange:
ObjectDN: DC=external,DC=local
InheritedObject: Компьютер
Объект: Alt-Security-Identities
ActiveDirectoryRights: WriteProperty
InheritanceType: Все
ObjectType: 00fbf30c-91fe-11d1-aebc-0000f80367c1
InheritedObjectType: bf967a86-0de6-11d0-a285- 00aa003049e2
ObjectFlags: ObjectAceTypePresent , InheritedObjectAceTypePresent
AccessControlType: Deny
IdentityReference: EXTERNAL\Exchange Доверенная подсистема
IsInherited: False
InheritanceFlags: ContainerInherit
PropagationFlags: None
ObjectDN: CN=AdminSDHolder,CN=System,DC=external,DC=local
InheritedObject: Компьютер
Объект: Alt-Security-Identities
ActiveDirectoryRights: WriteProperty
InheritanceType: Все
ObjectType: 00fbf30c-91fe-11d1-aebc-0000f80367c1
InheritedObjectType: bf967a86- 0de6- 11d0-a285-00aa003049e2
ObjectFlags: ObjectAceTypePresent, InheritedObjectAceTypePresent
AccessControlType: Deny
IdentityReference: EXTERNAL\Exchange Доверенная подсистема
IsInherited: False
InheritanceFlags: ContainerInherit
PropagationFlags: Нет
Однако интересно то, что они применяются только к текущему объекту и компьютерным объектам-потомкам. Это означает, что доверенные подсистемы Exchange по-прежнему могут писать Alt-Security-Identitiesвсем пользователям с включенным наследованием ACL (например, не защищенным AdminSDHolder). Давайте посмотрим, что это позволит нам сделать.
Явное сопоставление Kerberos
Похоже, что до патча No PAC можно было злоупотреблять явным сопоставлением Kerberos . Чарли Кларк демонстрирует в своем блоге CVE-2021–42287/CVE-2021–42278 Weaponisation , как злоумышленник в одном домене с разрешением на запись Alt-Security-Identitiesцелевого пользователя в другом домене позволяет злоумышленнику скомпрометировать целевого пользователя, выполнив следующие шаги:
- Добавьте строку сопоставления « Kerberos:[email protected]» к Alt-Security-Identitiesатрибуту целевого пользователя с UPN пользователя-злоумышленника.
- Запросите билет предоставления билета Kerberos (TGT) без сертификата атрибута привилегий (PAC) в качестве пользователя-злоумышленника из его локального домена.
- Используйте TGT для запроса межобластного TGT в домен целевого пользователя.
- Используйте межобластной TGT для запроса билета на обслуживание для домена целевого пользователя.
Исправление «No PAC» сделало невозможным получение TGT без PAC из центра распространения ключей Kerberos AD (KDC). Я попытался выполнить атаку в исправленной среде, где у TGT был PAC, и это не сработало, однако я предполагаю, что можно осуществить атаку из области KDC, отличной от Windows, с входящим доверием из домена AD целевого пользователя, поскольку оттуда должна быть возможность получить TGT без PAC.
Явное сопоставление сертификата X.509
Явное сопоставление сертификата — это ссылка на сертификат. Любой, у кого сертификат соответствует ссылке явного сопоставления сертификатов принципала, может использовать свой сертификат для аутентификации в качестве принципала. Таким образом, злоумышленник может злоупотребить доступом для записи к Alt-Security-Identitiesатрибуту пользователя AD, чтобы добавить явное сопоставление сертификатов со ссылкой на сертификат, которым владеет злоумышленник, а затем использовать этот сертификат для аутентификации в качестве этого пользователя.
Этот метод злоупотребления был впервые задокументирован в 2019 году, когда Жеро де Друа описал, как злоумышленник, скомпрометировавший локальный Exchange, может выполнить атаку, на этой странице GitHub: Набор свойств Public-Information включает Alt-Security-Identities, позволяет сопоставлять сертификаты x509. привилегированным пользователям . Кроме того, Жан Марсо продемонстрировал атаку в сообщении блога Microsoft ADCS — злоупотребление PKI в среде Active Directory в разделе « Эксплойт ACL на пользовательских объектах (1) ». Недавно я также изучил технику злоупотребления и опубликовал сообщение в блоге здесь: ADCS ESC14 Abuse Technique .
Злоумышленник может выполнить атаку, выполнив следующие действия:
- Зарегистрируйте сертификат в шаблоне сертификата, который допускает аутентификацию (клиента).
- Добавьте (сильное) явное сопоставление сертификатов на основе сертификата в Alt-Security-Identitiesатрибуте целевого участника.
- Аутентификация в качестве целевого участника с помощью сертификата
Это означает, что злоумышленник, обладающий контролем над администратором Exchange или сервером Exchange, может скомпрометировать любого пользователя AD с включенным наследованием ACL, даже если вы настроили Exchange в модели разделения разрешений AD.
Злоумышленник, который не может зарегистрировать какие-либо сертификаты в среде, может даже иметь возможность выполнить атаку. Ханс-Йоахим Кноблох объяснил в ветке LinkedIn , что KDC не требует, чтобы контроллер домена доверял эмитенту сертификата для аутентификации NT при выполнении явного сопоставления сертификатов X509IssuerSubject , X509IssuerSerialNumber , X509SKI или X509SHA1PublicKey . Microsoft визуализировала это поведение в виде блок-схемы в документации по логике обработки сертификатов , и Ханс обсудил это в очень интересном сообщении в блоге здесь: Nilpferde, NDES und Goldene Zertifikate als Schlüssel zum AD . Это означает, что злоумышленник потенциально может использовать сертификат одного из многих общедоступных корневых центров сертификации, которым DC по умолчанию доверяют при атаке, что устраняет необходимость в правах регистрации в среде AD.
Уменьшите разрешения Exchange в AD
Если вы (как организация) больше не используете локальную версию Exchange (например, вы используете только Exchange Online, а не гибридную версию), вам следует избавиться от локальной версии Exchange. Microsoft предоставила некоторые рекомендации по выводу из эксплуатации серверов Exchange: Как и когда выводить из эксплуатации локальные серверы Exchange в гибридном развертывании . После вывода из эксплуатации серверов Exchange необходимо вручную очистить группы AD Exchange. Подробное руководство предоставлено Али Таджраном здесь: Как удалить Exchange из Active Directory .Если вам нужен локальный Exchange, вместо этого вы можете ограничить разрешения AD Exchange. Трудно придумать общий минимальный набор разрешений AD для групп Exchange AD, поскольку использование Exchange варьируется в разных организациях; однако должна быть возможность определить, для каких пользователей и групп Exchange вообще не нужны никакие разрешения. Exchange не должны требоваться разрешения для большинства, если не для всех, учетных записей служб, пользователей-администраторов и групп администраторов. В некоторых организациях у администраторов есть почтовые ящики. Вам следует избегать этого, внедряя отдельные учетные записи для администраторов , чтобы не подвергать администраторов атакам по электронной почте, таким как фишинг. Сотрудник с ролью, требующей привилегированного доступа (администратора), должен получить отдельную учетную запись администратора без почтового ящика для привилегированного доступа в дополнение к своей обычной рабочей учетной записи с почтовым ящиком.
Существует несколько способов запретить применение разрешений Exchange AD объекта домена к заданному набору объектов:
- Переместите элементы управления доступом Exchange в нужные подразделения (рекомендуется).
Вы можете переместить все разрешения AD, которые группы Exchange имеют на объекте домена AD, в подразделения, в которых у вас есть группы и пользователи, относящиеся к Exchange. На практике вам необходимо добавить элементы управления доступом в подразделения, а затем удалить их из объекта домена. Вы должны убедиться на дочерних пользователях и компьютерах, что их списки ACL одинаковы и что приоритет ACL (описанный здесь ) не привел к изменению. - Блокировка наследования ACL в подразделениях администратора.
При реализации многоуровневого управления AD обычной практикой является создание подразделения нулевого уровня с отключенным наследованием, так что разрешения, настроенные для объекта домена AD, не будут применяться к объектам нулевого уровня. Эта концепция также работает для защиты объектов AD от разрешений Exchange. Недостаток блокировки наследования заключается в том, что становится сложнее определить, где в среде применяются разрешения. - Внедрить запрещающие ACE (не рекомендуется).
Вы можете реализовать запретные ACE в подразделениях администратора, чтобы заблокировать разрешения, предоставленные группам Exchange. Приоритет ACL непрост, особенно потому, что явные разрешения ACE имеют приоритет над унаследованными запретами. Чтобы сделать списки ACL максимально простыми, я рекомендую избегать запрета ACE.
Да, я использовал тот же мем в своем предыдущем посте в блоге. Я действительно это имею в виду!
Приведенные выше рекомендации действительны для Exchange, настроенного с любой моделью разрешений.
Если вы настроите Exchange на модель разделения AD, Exchange не будет иметь таких же компрометирующих разрешений, как две другие модели разрешений. Поэтому я настоятельно рекомендую рассмотреть модель разделения AD . У меня ограниченные знания о работе администратора Exchange, и я не знаю, насколько сложно администраторам Exchange адаптироваться к модели разделения AD, но я слышал, что это требует усилий. Я рекомендую ознакомиться с раздельными разрешениями Switch to Active Directory от Microsoft и этой публикацией в блоге TEAL , в которой объясняется, как настроить некоторые разрешения, которые вам могут понадобиться: Разделение разрешений Exchange — разрешения и процессы AD .
Если вы решите не использовать модель разделения AD, подумайте, можете ли вы уменьшить любое из трех компрометирующих разрешений, описанных в разделе « Что может Exchange сделать сегодня, BloodHound?» раздел. Например, Exchange может не обязательно иметь возможность сбрасывать пароли обычных пользователей, даже если у них есть почтовый ящик.
Уменьшить разрешение группы «Доверенные подсистемы Exchange» на запись для Alt-Security-Identitiesатрибута пользователей сложно, поскольку разрешение предоставляется через доступ на запись к Public-Informationнабору свойств. Чтобы избежать запрета ACE, вы можете заменить доступ на запись к набору свойств доступом на запись к отдельным атрибутам в наборе свойств; однако это значительно увеличит количество ACE для большого набора свойств, такого как Public-Information. Атрибуты могут принадлежать только одному набору свойств, поэтому создание пользовательского набора свойств, содержащего подмножество исходного набора свойств, невозможно, если вы не удалите атрибуты из исходного. Поэтому лучшим решением, на мой взгляд, является изменение существующего запрета записи в Alt-Security-IdentitiesACE для доверенной подсистемы Exchange на объекте домена, чтобы он поражал объекты всех классов, а не только компьютеры. Вы можете использовать этот сценарий PowerShell, чтобы проверить, у каких пользователей установлен атрибут, чтобы получить представление об использовании атрибута в организации перед внесением изменений: Get-AltSecIDMapping.ps1 .
Наконец, вам также следует проверить, какие разрешения AD, отличные от стандартных, Exchange получил за эти годы. Exchange обычно имеет компрометирующие разрешения, настроенные непосредственно для пользователей, компьютеров и групп, созданных Exchange в AD. Вы можете использовать этот запрос Cypher в BloodHound, чтобы найти исходящие границы ACL, созданные из ненаследованных элементов управления доступом из групп Exchange, в объекты AD за пределами подразделений и контейнеров Exchange:
СОВПАДЕНИЕ p = (g:Group)-[r]->(x)
ГДЕ g.distinguishedname СОДЕРЖИТ «MICROSOFT EXCHANGE»
, А НЕ x.distinguishedname СОДЕРЖИТ «MICROSOFT EXCHANGE»
И r.isinherited = ЛОЖНЫЙ
ВОЗВРАТ p LIMIT 100
Обязательно привлекайте администраторов Exchange к процессу уменьшения разрешений AD Exchange, поскольку они могут помочь вам определить, какие разрешения необходимы, и проверить, что все работает должным образом после применения изменений. Я также рекомендую вам документировать разрешения до и после изменения и подготовить способ восстановления удаленных разрешений в случае, если что-то сломается (например, с помощью сценария).
Если вам вообще не хочется уменьшать разрешения AD Exchange, вам следует рассматривать группы Exchange AD «Разрешения Windows Exchange» и «Доверенная подсистема Exchange» как нулевой уровень; однако я не советую этого делать. Серверы Exchange нулевого уровня увеличивают поверхность атаки нулевого уровня, а это означает, что вам следует ограничивать доступ к серверам Exchange так же, как вы это делаете с контроллерами домена.
Заключение
В этом сообщении блога были рассмотрены компрометирующие разрешения AD Microsoft Exchange, и мы оценили модели разрешений Exchange (т. е. общие, разделение RBAC и разделение AD). Мы обнаружили, что общая модель и модель разделения RBAC позволяют злоумышленнику, скомпрометировавшему администратора Exchange или сервер Exchange, добавить себя в любую группу AD и скомпрометировать (захватить) любого пользователя AD, если отключенное наследование ACL не защищает целевую группу или пользователя. Более того, мы обнаружили, что администратор Exchange может скомпрометировать одних и тех же пользователей, используя явное злоупотребление сопоставлением сертификатов (ESC14), и что такая атака возможна даже в более строгой модели разделения AD.Разрешения AD Exchange можно ограничить. Вы можете изменить Exchange, чтобы он использовал модель разделения AD и тем самым устранить компрометирующие разрешения AD Exchange, за исключением разрешения ESC14, которое можно исправить отдельным усилием. Модель разделения AD или нет, вы также можете ограничить круг пользователей и групп, которым Exchange имеет разрешения; например, переместив разрешение из объекта домена в подразделения, содержащие пользователей и группы, где Exchange действительно необходимы разрешения.