Гайд От DA до EA с помощью ESC5

[DeCoded]

<статья переведена с английского языка, так что заранее прошу прощения за возможные дефекты перевода>
8–11 минут

Существует новый практичный способ повышения с администратора домена до администратора предприятия.

ESC5​

Вы слышали об ESC1 и ESC8. Но как насчет ESC5? ESC5 также известен как “Контроль доступа к уязвимым объектам PKI”. В техническом документе Уилла Шредера и Ли Кристенсена при обсуждении ESC5 упоминаются три класса объектов:

• Объект компьютера AD сервера CA (т. Е. компрометация через S4U2self или S4U2proxy)
• Сервер RPC / DCOM сервера CA
• Любой дочерний объект AD или контейнер в контейнере (например, контейнер шаблонов сертификатов, контейнер центров сертификации, объект theNTAuthCertificates, контейнер служб регистрации и т.д.)

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

Иерархия LDAP ADCS​

ADCS хранит информацию о центрах сертификации и шаблонах сертификатов в LDAP. Вы можете увидеть эти объекты, открыв ADSI и подключившись к контексту именования конфигурации. Затем перейдите вниз:

Конфигурация > Службы > Службы открытых ключей

Вот график этой иерархии, включающий объекты, которыми мы собираемся злоупотреблять:

В контейнере “Шаблоны сертификатов” хранятся шаблоны, которые могут быть опубликованы в центре сертификации ADCS. Когда вы видите это диалоговое окно, оно буквально просто перечисляет объекты шаблона, которые находятся в этом контейнере:

В контейнере “Службы регистрации” хранится один объект pKIEnrollmentService для каждого центра сертификации. В этих объектах перечислены шаблоны, которые были “опубликованы” в CA в их свойстве “certificateTemplates”:

Это два объекта LDAP, которыми вам нужно управлять для выполнения шаблона сертификата ESC5 — one и объекта pKIEnrollmentService. Для целей этого блога мы предполагаем, что объект pKIEnrollmentService связан с центром сертификации, которому доверено выполнять аутентификацию домена, и что ему доверяют либо как корневому центру сертификации, либо по цепочке до корневого центра сертификации.

Прежде чем я покажу вам, как проводить атаку, мне нужно заложить еще кое-какой фундамент.

Любопытный случай с контекстом именования конфигурации​

Контекст именования конфигурации (NC) - это место, где Active Directory хранит данные конфигурации для всего леса, которые должны быть реплицированы по всему лесу AD. Отличительным именем для NC является CN=Configuration,DC=example,DC=local, где DC=example,DC=local - DN корневого домена леса.

Как вы могли себе представить, если объект в конфигурации изменен в корне леса, это изменение реплицируется на все домены в лесу.

Но чего вы, возможно, не знаете, так это того, что верно и обратное: если объект в конфигурации изменяется в дочернем домене, это изменение реплицируется вплоть до корня леса. Это потому, что каждый доступный для записи контроллер домена в лесу имеет доступную для записи копию контекста именования конфигурации леса.

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

Вот лаборатория, в которой у меня есть корневой домен леса под названием ForestRoot.local и дочерний домен под названием ChildDomain.Корень леса.Местные новости:

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

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

Теперь давайте посмотрим на дескриптор безопасности для этого объекта:

Как администратор домена в дочернем домене, я не имею никакого контроля над этим объектом. Вы можете видеть, что кнопка для добавления ACE здесь выделена серым цветом. Но вы также можете заметить, что СИСТЕМНЫЙ участник имеет полный контроль над этим объектом.

Я закрою MMC и снова открою его, но на этот раз с помощью PsExec для запуска MMC в качестве СИСТЕМНОГО пользователя:

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

Теперь мы можем добавить ACEs. Я добавлю ACE к этому объекту, предоставляя Бобу — пользователю в дочернем домене — полный контроль над этим контейнером:

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

ACE реплицировался до корня леса из дочернего домена.

Собираем все это вместе​

Как минимум, нам нужны следующие возможности для выполнения ESC5 при злоупотреблении контролем над объектами PKI в LDAP:

1. Возможность добавлять новые шаблоны в контейнер шаблонов сертификатов.
2. Доступ на запись к объекту pKIEnrollmentService, связанному с корневым центром сертификации леса или подключенному к нему по цепочке и связанному с центром сертификации, которому доверена аутентификация NT.

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

У нас нет полного контроля над объектом pKIEnrollmentService, но мы можем предоставить себе этот контроль, поскольку у этого объекта включено наследование разрешений:

Но у шаблонов по умолчанию отключено наследование разрешений, и мы не можем контролировать их как администратор домена в дочернем домене:

Давайте посмотрим на дескриптор безопасности для самого контейнера шаблонов сертификатов:

Мы будем использовать PsExec для запуска mmc в качестве СИСТЕМНОГО пользователя на дочернем DC:

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

Чтобы воспользоваться этой привилегией, я открою certsrv.msc как СИСТЕМНЫЙ пользователь, затем продублирую существующий шаблон:

Это откроет свойства для нашего нового шаблона, где я настрою шаблон, чтобы мы могли выполнить ESC1 с помощью:

1. Предоставление прав на регистрацию участнику, которого мы контролируем в дочернем домене.
2. Включение аутентификации клиента в политики приложений.
3. Разрешение SANS в запросах сертификатов.
4. Не позволяет получить одобрение менеджера или авторизованные подписи.

Новый шаблон записывается в нашу локальную копию контекста именования конфигурации предприятия, а затем реплицируется в контекст именования конфигурации контроллера корневого домена леса:

Теперь шаблон должен быть опубликован в CA. Мы можем сделать это как СИСТЕМНЫЙ пользователь дочернего DC, злоупотребив нашим полным контролем над этим объектом:

Сертификаты “публикуются” в CA, когда они перечислены в свойстве certificateTemplates этого объекта. Все, что нам нужно сделать, чтобы “опубликовать” шаблон в CA, - это добавить шаблон в этот список:

Если мы запустим certsrv.msc на контроллере корневого домена леса и проверим “Шаблоны сертификатов” для нашего центра сертификации, мы действительно сможем увидеть, что этот новый шаблон evil теперь “опубликован” и готов к использованию:

Теперь все готово для выполнения ESC1 и превращения DA в дочернем элементе в EA в корне леса.

Мы используем Certify для получения сертификата, указывая наш шаблон evil и администратора предприятия, за которого мы хотим выдавать себя:

Мы преобразуем сертификат в PFX с помощью openssl:

Мы помещаем PFX в дочерний домен DC через канал RDP, затем используем Rubeus, чтобы получить TGT для корпоративного администратора, продемонстрировав, что мы не являемся локальными администраторами в корневом домене леса:

Мы можем доказать, что наш TGT действителен с помощью wmic:

Думайте в графиках​

Я визуальный человек. Если вы похожи на меня, то представление этого пути атаки в терминах графика поможет вам понять все движущиеся фигуры.

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

Теперь мы добавляем дочерний домен, который имеет двустороннее доверие к корневому домену леса:

Дочерний домен имеет свой собственный домен-локальную копию контекста именования конфигурации корневого домена леса:

Изменения, внесенные в домен-локальные объекты в дочернем домене реплицируются до соответствующих им объектов в корневом домене леса:

СИСТЕМНЫЙ пользователь на контроллере домена дочернего домена имеет полный контроль над некоторыми объектами в домене-локальной копией контекста именования конфигурации корневого домена леса:

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

Центр сертификации является корневым центром сертификации для корневого домена forest, а корневой домен forest содержит своих пользователей, таких как пользователь ForestRootDA:

Красными краями выделен фактический путь, пройденный от контроллера домена дочернего домена до администратора корневого домена леса:

Заключение и будущая работа​

В этом сообщении показано, как злоумышленник может использовать ESC5, за которым следует ESC1, чтобы превратить DA в дочернем домене в EA в корне леса.

---