ESC1,ESC6,ESC9

[Tak10]

Добрый день. Пытаюсь разобраться с уязвимыми настройками шаблонов сертификатов и самого CA, известными как ESC... Возникло несколько вопросов, буду признателен если кто поможет прояснить ситуацию.
1)Сценарий ESC9 основан на двух ключевых условиях:

• Первое условие это отсутствии в шаблоне сертификата расширения szOID_NTDS_CA_SECURITY_EX. Как я понял если в атрибуте msPKI-Enrollment-Flag установлен флаг CT_FLAG_NO_SECURITY_EXTENSION то это значит szOID_NTDS_CA_SECURITY_EX не применяется(проверить можно за счет побитового И между значением атрибута и значением флага). szOID_NTDS_CA_SECURITY_EX впервые появилось в патче от мая 22го года и смысл его работы в том что CA по умолчанию включает в выдаваемый сертификат SID учетной записи запросившей этот сертификат. Если это расширение отключено то KDC вынужден использовать слабые механизмы сопоставления при выдаче билетов. Тоесть при отсутствии в сертификате sid, для сопоставления этого сертификата с учетной записью AD, KDC будет использовать например UPN из сертификата и сопоставлять его с атрибутом UPN учетных записей в AD.
• Второе условие это то что конфигурация KDC, допускает слабое сопоставление. Тоесть в KDC должна быть активна возможность сопоставления сертификата по UPN или DNS. Как я понимаю за это отвечает ключ реестра HKLM\SYSTEM\CurrentControlSet\Services\KdcStrongCertificateBindingEnforcement на контроллере домена. Если значение этого ключа установлено в 0 то слабое сопоставление используется по умолчанию. Если значение этого ключа установлено в 1(по умолчанию с мая 22го года по февраль 25го) то по умолчанию KDC будет пытатся использовать sid для сопоставления, а при его отсутсвии будет использовать слабое сопоставление, например по upn. Если значение ключа 2(по умолчанию с февраля 25го года), то KDC будет использовать только сопоставление по sid, а при его отсутствии просто не выдаст билет.

Есть и другие условия необходимые для этой атаки(права на enroll, отсутствие необходимости ручного одобрения запросов администратором, отсутствие в необходимости подписи запроса агентом регистрации, подходящие EKU итд) но для моего текущего вопроса это неважно.
Основной сценарий атаки подразумевает что у злоумышленника есть права на изменение атрибута UPN атакуемой учетной записи и он изменяет его на UPN привилегированной учетной записи. Но как упоминается в исследовании компании BI.ZONE злоумышленник не может в точности скопировать UPN привилегированной учетной записи в UPN атакуемой учетной записи то это вызовет конфликт. Поэтому если UPN привилегированной учетной записи например Administrator@corp.local то атакующий может присвоить атакуемой учетной записи UPN c фэйковым доменом или вообще без домена, например Administrator@fake.local или просто ADMINISTRATOR. Это будет работать потому что при сопоставлении KDC не будет учитывать домен указанный в UPN? Еще интереснее пример показан в вики к инструменту certipy. Там у привилегированной учетной записи UPN установлен как ADMINISTRATOR а в примере команды назначающей upn атакуемой учетной записи указано administrator. Неужели это тоже сработает и KDC при сопоставлении не обратит внимание на то что у учетной записи в AD UPN начинается с большой буквы, а в сертификате с маленькой?
---
2)Отличие между сценариям esc1 и esc6.
Как я понимаю ESC1 основана на том что в атрибуте шаблона mspki-certificate-name-flag присутствует флаг CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT позволяющий злоумышленнику указать SAN в запросе и благодаря этому получить сертификат на имя любой учетной записи. То есть суть атаки в том что СA доверяет SAN из запроса и добавляет его в сертификат.
В свою очередь ESC6 основан на том что CA настроен с флагом EDITF_ATTRIBUTESUBJECTALTNAME2. Этот флаг указывает что CA должен доверять SAN из запроса и добавлять его в сертификат даже если на уровне шаблона не включен флаг CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT. Тоесть обе атаки работают по одинаковому принципу, но esc1 эксплуатирует настройки на уровне шаблона а esc6 эксплуатирует настройки на уровне центра сертификации? Я правильно понимаю что при наличии szOID_NTDS_CA_SECURITY_EX или включенном на KDC режиме строгого сопоставления обе техники становятся бесполезными?
Понимаю что вместо того чтобы задавать здесь эти вопросы было бы правильнее поднять свой домен и самостоятельно потестировать, но к сожалению у меня железо не потянет виртуализацию сразу нескольких машин с виндой, поэтому пока вынужден спрашивать( Буду очень признателен, если кто прояснит ситуацию и укажет на недочеты в моем понимании вопроса!

 

[al3x_pwn]

Тут что-то не договаривают . ESC9 — это ж классика. Если я правильно помню, речь идет о двух вещах: отсутствие определенных версий TLS и специфические настройки на сервере. Имхо, если не знаете, с чего начать, погуглите про слабые шифры и их отсутствие в конфиге. Хотя... не, лучше так: начните с анализа сетевых пакетов, посмотрите, что сервер отбрасывает и почему. Это даст представление, какие условия не выполняются.

И еще, чтобы не плодить сущности, советую сразу проверить логи сервера — часто вся правда там. В прошлом месяце уже была тема, где обсуждали похожее, поищите, может, найдете что-то полезное.

Кстати, а как у вас с навыками работы с Wireshark? Если с ним на "вы", могу подсказать пару трюков. Но если у вас еще будут проблемы, напишите, постараюсь помочь, как приду домой.

Ну и напоследок — не зацикливайтесь на одном источнике информации, иногда решение лежит на поверхности, а мы его не замечаем. Бывало у меня на пентесте, что неделями копались в одной дыре, а решение оказалось проще простого. В общем, удачи, если что, пишите.

 

[Tak10]

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

 

[Alex Manturov]

ESC1, ESC6, ESC9... Это классические ошибки при настройке сертификатов.
Отсутствие расширения безопасности szOID_NTDS_CA_SECURITY_EX действительно может привести к проблемам с SID запросившей стороны.
Попробуйте добавить это расширение вручную, либо проверьте настройки вашего ЦС.
Если проблема остаётся, то может быть стоит проверить логи ЦС и клиента, чтобы понять, где именно возникает проблема.
Ещё одна возможная причина - неверная настройка групповых политик.
Проверьте, что у вас правильно настроены GPO, связанные с сертификатами и SID.
Если ничего не помогает, то может быть стоит обратиться к документации Microsoft, или к кому-то из наших участников, кто более глубоко разбирается в Active Directory.
Например, @f22 или @INPC могли бы помочь с настройкой и трoubleshooting'ом.