[Перевод] Разбираем, как работает Kerberos

Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.

Kerberos — это протокол аутентификации, используемый в контексте Microsoft Active Directory, и незнание принципов его работы, а также неправильная настройка могут привести к появлению уязвимостей, которыми обязательно воспользуются злоумышленники.

Поэтому с его механикой полезно разбираться не только администраторам, но и специалистам по информационной безопасности — эту тему мы в том числе затрагиваем на курсе «Информационная безопасность. Продвинутый уровень».

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

Итак, Kerberos представляет собой сетевой протокол, используемый для аутентификации пользователей и служб в сети. Он основан на концепции «доверенной третьей стороны», то есть использует центральный сервер аутентификации для проверки личности и выдачи билетов, дающих доступ к службам.

Ниже перечислены ключевые элементы Kerberos, о которых мы подробно расскажем в следующих разделах.

Начнем с централизованной аутентификации.

Сервер аутентификации, известный как центр распространения ключей (Key Distribution Center, KDC), отвечает за аутентификацию пользователей и служб. Сам процесс состоит из двух этапов: этапа аутентификации и этапа выдачи билета службы.

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

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

В Kerberos используется взаимная аутентификация, когда не только клиент подтверждает свою личность серверу, но и сервер также подтверждает свою личность клиенту, гарантируя подлинность обеих сторон.

Также, этот протокол часто используется в средах, где взаимодействуют несколько систем, например, в корпоративных сетях. Помимо операционных систем семейства Windows, протокол Kerberos может также применяться и в системах Unix/Linux.

Как работает аутентификация Kerberos?

Протокол Kerberos по аналогии с трехголовым псом Цербером из древнегреческой мифологии, работает с тремя объектами.

• Первый — это центральный сервер Kerberos Distribution Center (KDC), который распределяет билеты. Ему известны все секреты в домене, и в контексте Active Directory это машина с контроллером домена (Domain Controller, DC).

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

• Наконец, последний объект — это сервис, к которому пытается получить доступ клиент. Он должен быть зарегистрирован в KDC. Протокол Kerberos позволяет ему получить подтверждение личности клиента, выданное KDC.

Что касается задействованных объектов и принципов их работы в Active Directory, то здесь есть несколько важных моментов, которые необходимо прояснить.

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

Кроме того, любой клиент может запросить доступ по протоколу Kerberos к любой службе. Однако Kerberos не проверяет, имеет ли клиент право на доступ к запрашиваемой службе, так как эта обязанность возлагается на саму службу.

В свою очередь, служба — это объект домена (пользователь или компьютер), секрет которого известен KDC. У объекта также должен быть один или несколько уникальных идентификатор экземпляра службы Service Principal Name (SPN), зарегистрированных на контроллере домена.

• В случае, если объектом является «компьютер», владелец компьютера и его учетная запись могут регистрировать новые имена участников‑администраторов.

• А в случае, если объектом является пользователь, только администраторы или организации, явно уполномоченные редактировать атрибуты объекта, смогут добавлять новые SPN. То есть пользователь со стандартными привилегиями тоже не может их редактировать.

Центр распространения ключей (KDC)

Секрет KDC — это учетная запись пользователя по умолчанию «krbtgt». Безопасность протокола kerberos зависит от конфиденциальности krbtgt, и утечка этого секрета ставит под угрозу всю логику безопасности протокола.

В Kerberos используется понятие «запросы», и существует два их типа, которые используются на разных этапах работы протокола. Эти заявки генерируются KDC для клиента с использованием секретов, доступных KDC. 

Билет на получение разрешения (TGT)

Первый тип билета: «Билет на получение разрешения» (Ticker Granting Ticket, TGT).

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

Давайте посмотрим команды этапа аутентификации с использованием инструментов impacket и скрипта getTGT.py:

getTGT.py -dc-ip <IP KDC/DC> <domain>/<user>:<password>

Скрипт создаст файл.ccache.

Также можно выполнить аутентификацию с использованием инструмента Rubeus:

Rubeus.exe asktgt /user:<user> /password:<password> /domain:<domain> /dc:<IP KDC/DC> /outfile:<user>_tgt.kirbi

В итоге будет создан файл.kirbi.

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

Также, содержимое этих элементов можно просмотреть в файлах, созданных с помощью приведенных выше команд.

Обратите внимание, что содержимое TGT частично зашифровано с помощью секрета KDC. Таким образом, клиент не может изменить эту часть или получить к ней доступ.

Если говорить более конкретно, то информация, полученная на этапе «аутентификации», распределяется следующим образом:

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

Таким образом, клиент не может подделать свою личность, поскольку для изменения TGT требуется секрет KDC.

Сервисный билет (TGS)

Сервисный билет получается на этапе предоставления услуги (TGS), когда клиент запрашивает доступ к сервису, используя TGT и ранее полученный сеансовый ключ и ориентируясь на существующее имя участника сервиса (SPN).

Ниже приведены команды, используемые для выполнения этапа «Предоставление услуги по выдаче билетов» путем явного указания билета, полученного на предыдущем этапе.

С использованием библиотеки impacket и примера сценария «getST.py».:

KRB5CCNAME=<TGT_ccache_file> getST.py -dc-ip <IP KDC/DC> -spn <Target_SPN> <domain>/<user> -no-pass -k 

Использование инструмента Rubeus:

Rubeus.exe asktgs /ticket:<TGT_kirbi_file> /service:<Target_SPN> /dc:<IP KDC/DC> /outfile:<user>_st_<SPN>.kirbi

ПРИМЕЧАНИЕ: Impacket можно использовать для связи этапов AS и TGS, чтобы получить заявку на обслуживание, напрямую предоставив секрет клиента.

getST.py -dc-ip <IP KDC/DC> -spn <Target_SPN> <домен>/<пользователь>:<пароль>

В конце этого этапа клиент получает сервисный билет (ST) и ключ сеанса обслуживания.

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

Короче говоря, содержимое ST аналогично TGT, за исключением того, что поле, связанное с «Именем участника службы» (SPN), будет содержать ссылку на объявленную службу. В случае TGT это поле относится к услуге «krbtgt» в KDC.

Аутентификация с помощью Kerberos для доступа к сервису

После получения сервисного билета (ST) клиент может пройти аутентификацию для доступа к сервису.

Этот этап называется «запрос приложения» (application request, AP), и его можно проиллюстрировать следующим образом:

В зависимости от того, используете ли вы impacket или Rubeus, процесс доступа к сервисам будет отличаться.

Большинство инструментов на основе библиотеки impacket поддерживают использование Kerberos.

Здесь мы предполагаем, что на одном из предыдущих этапов был создан файл «.ccache». Этот файл «.ccache» может содержать либо TGT, либо ST, но процедура остается неизменной. В случае с TGT инструмент автоматически выполнит этап TGS.

Файл «.ccache» интегрируется путем указания пути к нему в переменной среды KRB5CCNAME, а затем применения параметров Kerberos для используемого скрипта.

Обратите внимание, что в экосистеме impacket существует столько скриптов, сколько есть сервисов для взаимодействия (smbclient‑ng.py, dnstool.py, wmiexec.py и так далее).

Вот пример взаимодействия со службой SMB с использованием скрипта smbclient-ng.py.

$ export KRB5CCNAME=/path/to/user.ccache

$ smbclient-ng.py --kdcHost= -d -u --host -k --nopass

Аутентификация в сервисе с помощью Rubeus

Процесс взаимодействия с тикетами, сгенерированными Rubeus, отличается. Он включает в себя применение тикета, сгенерированного непосредственно в сеансе входа в систему.

Это действие может выполняться различными способами в зависимости от уровня привилегий.

Если пользователь Rubeus не является администратором устройства, он может использовать параметр «/ptt», чтобы применить сгенерированный запрос к текущему сеансу.

Однако это приведет к перезаписи сеанса и, следовательно, к изменению доступа текущего пользователя к устройству.

Rubeus.exe asktgt /user: /password: /domain: /dc:<IP KDC/DC> /ptt

или

Rubeus.exe ptt /ticket:<path/to/ticket.kirbi>

Если вы являетесь администратором компьютера с Windows, можно создать «резервный процесс», к которому вы можете применить сгенерированные вами заявки. Для этой цели можно использовать параметры «/ptt» и «/createnetonly».

Rubeus.exe asktgt /user: /password: /domain: /dc:<IP KDC/DC> /ptt /createnetonly:C:PathtoProgramtolaunch

С помощью команды «klist» можно перечислить заявки Kerberos на активную сессию.

После настройки сеанса входа в систему можно будет беспрепятственно взаимодействовать с целевой службой.

При использовании параметра createnetonly важно понимать, что только сетевые взаимодействия klist будут осуществляться с применением внедренной идентификационной информации.

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

Управление секретными данными при аутентификации по протоколу Kerberos

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

Этот секретный ключ, также известный как ключ Kerberos, вычисляется путем применения хэш‑функции к паролю учетной записи объекта (пользователя или компьютера).

Для наглядности давайте рассмотрим, как с помощью программы Rubeus вычислить ключи Kerberos на основе пароля учетной записи.

Rubeus.exe hash /password:<пароль> /user:<имя пользователя> /domain:<домен>

Хэш‑функции, используемые в протоколе Kerberos

Можно использовать несколько хеш‑функций, каждая из которых будет генерировать свой ключ для одного и того же пароля. Чтобы определить, какой ключ используется для шифрования, при передаче зашифрованного элемента всегда указывается свойство «тип шифрования» или «etype».

В среде Active Directory доступны два алгоритма хеширования RC4_HMAC и AES256_CTS_HMAC_SHA1.

• RC4_HMAC (etype 23): хеш, полученный с помощью этого алгоритма, похож на хеш NT. Этот формат хеширования используется в других программах и протоколах Windows (например, в NTLM). В настоящее время этот алгоритм считается недостаточно надёжным, из‑за чего исходный пароль становится проще вычислить при взломе. Именно такой тип операции используется, например, при атаке kerberoast.

• AES256_CTS_HMAC_SHA1 (etype 18): это самый надёжный алгоритм, предлагаемый реализацией протокола Kerberos в Windows и его следует использовать вместо других алгоритмов. Для злоумышленника, который хочет остаться незамеченным в сети, ключ, полученный с помощью этого алгоритма, будет выглядеть более легитимным.

Как работают ключи?

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

Для использования протокола Kerberos достаточно знать только ключи. Поэтому такие инструменты, как impacket или Rubeus, позволяют использовать эти ключи напрямую, без пароля.

С помощью impacket:

getTGT.py -hashes :<NTHASH> <domain>/<username> -no-pass

или

getTGT.py -aes <aeskey> <domain>/<username> -no-pass

С помощью Rubeus:

Rubeus.exe asktgt /rc4:<NTHASH> /user:<username> /domain:<domain>

или

Rubeus.exe asktgt /aes256:<aeskey> /user:<username> /domain:<domain>

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

Большинство инструментов для извлечения секретных данных могут отображать такие ключи.

Пример извлечения ключей Kerberos и хэша NT с помощью утилиты secretsdump.

Вывод

Подводя итог этой статье, отметим, что Kerberos представляет собой сетевой протокол аутентификации, который позволяет пользователям и сервисам безопасно доказывать свою подлинность друг другу в незащищённой сети, используя симметричную криптографию и доверенную третью сторону KDC.

Вместо передачи паролей по сети Kerberos выдаёт клиенту временные зашифрованные «билеты», которые подтверждают его личность и дают доступ к конкретным ресурсам, при этом поддерживается единый вход SSO и взаимная аутентификация.

Протокол лежит в основе аутентификации в Windows Active Directory, а также используется в Linux/Unix‑средах.

Разобраться в механике Kerberos — первый шаг. Следующий — научиться находить слабые места инфраструктуры и понимать, какие действия атакующего могут остаться незамеченными.

Углубить знания и получить больше практики можно на бесплатных уроках OTUS:

• 21 октября, 20:00. «Пентест инфраструктуры: поиск слепых зон IDS/IPS». Записаться

• 18 ноября, 20:00. «Что SIEM не увидит "из коробки": корреляция событий и оценка качества детектора». Записаться

Больше полезных материалов по инфраструктуре можно найти в дайджесте.