Новые пути атаки? AS запрошенные билеты на обслуживание

Jul 18, 2023

Главная » Кибербезопасность » Новости SBN » Новые пути атак? AS запрошенные билеты на обслуживание

Помогая Эндрю Шварцу с его постом о Kerberos FAST (в котором содержится дополнительная информация о том, что такое FAST и как он работает, так что прочтите), я заметил кое-что интересное. AS-REQ для учетных записей компьютеров не защищены. Это описано Microsoft здесь:

Бронирование Kerberos использует билет выдачи билетов (TGT) для устройства для защиты обмена службами аутентификации с KDC, поэтому обмен службами аутентификации компьютера не защищен. TGT пользователя используется для защиты обмена TGS с KDC.

Это заставило меня задуматься, можно ли запросить служебные билеты (ST) у службы аутентификации (AS). Возможность запрашивать ST у AS имеет несколько последствий, включая новые пути атак, обходы обнаружения и потенциальное ослабление мер безопасности. Обо всех проблемах, обсуждаемых в этом посте, сообщалось в Microsoft, и они «считались намеренными» (рис. 1).

Во-первых, вот общий обзор типичного потока Kerberos (рис. 2, получено из ADSecurity):

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

Например, сеансовый ключ TGT хранится в разделе, зашифрованном с помощью ключа, используемого для подтверждения личности запрашивающего при запросе TGT. Обычно этот ключ является долгосрочным ключом (хешем пароля) учетной записи. Но в случае шифрования с открытым ключом для начальной аутентификации (PKINIT) в протоколе Kerberos ключ извлекается из сертификата. Сеансовый ключ ST хранится в разделе, зашифрованном с помощью сеансового ключа TGT.

Ключ сеанса билета необходим для использования билета на следующем этапе потока Kerberos.

Запрос Kerberos состоит из двух основных разделов:

Тело запроса отправляется в основном в виде открытого текста и содержит несколько фрагментов информации:

Ответ Kerberos состоит из нескольких разделов и содержит зашифрованную часть:

Часть потока Kerberos, которой посвящен этот пост, — это AS-REQ/AS-REP, который обычно используется для запроса TGT. При нормальной работе AS-REQ имеет одно из двух значений внутри своего поля.взлетаетполе внутри req-body:

Я заметил, что при принудительном использовании безопасного туннелирования Kerberos Flexible Authentication Secure Tunneling (FAST) учетные записи компьютеров по-прежнему отправляли свои AS-REQ без защиты. Я задавался вопросом, можно ли использовать AS-REQ для прямого запроса ST, а не TGT. Это заставило меня изменить Rubeus, чтобы определить, следует ли указывать другой SPN ввзлетает AS-REQ приведет к тому, что контроллер домена ответит ST для этого SPN. Как оказалось, ответ был «да» (рис. 3).

Используя учетную запись компьютера, я могу запросить ST без использования защиты, когда применяется FAST. Что еще возможно?

Kerberoasting, открытый Тимом Медином, представляет собой метод восстановления открытого текстового пароля или NT-хеша для учетной записи службы, обычно учетной записи пользователя с именем SPN. Kerberoasting возможен, поскольку часть ST зашифрована с помощью долгосрочного ключа учетной записи службы (хеша пароля). Извлекая зашифрованную часть билета, можно сформировать хеш из различных паролей в открытом виде и попытаться расшифровать зашифрованную часть. Если расшифровка прошла успешно, то используемый хэш является долгосрочным ключом, используемым для шифрования билета. Этот ключ затем может быть использован для аутентификации в качестве учетной записи службы.

Более того, любая учетная запись может запросить ST для любой услуги. Таким образом, для выполнения атаки необходима возможность аутентификации в Active Directory (AD). По крайней мере, раньше это было правдой.

Сначала я попытался использовать учетную запись, которая не требовала предварительной аутентификации (DONT_REQ_PREAUTH), для запроса ST. Если учетная запись не требует предварительной аутентификации для аутентификации, TGT может быть запрошен без необходимости данных предварительной аутентификации, которые зашифрованы с помощью той или иной формы учетных данных (например, хэша пароля, сертификата). Если злоумышленник не получил действительные учетные данные для учетной записи, действительная предварительная аутентификация не может быть сгенерирована. Если предварительная аутентификация не требуется, это не проблема.