На сегодняшний день Active Direvtory является неотъемлемой частью функционирования любой корпоративной сети под управлением Windows. Протокол Kerberos используется в инфраструктуре Active Directory (AD) для аутентификации пользователей и сервисов. В этой статье мы поговорим о том, как работает этот протокол, и рассмотрим типовые атаки на него.
Модель аутентификации Kerberos
Механизм Kerberos аналогичен трёхголовому псу Церберу из греческой мифологии. Рабочая модель этого протокола основана на трёх компонентах:
Пользователь (клиент), запрашивающий определённую услугу
Приложение (целевой сервер), предоставляющее требуемую услугу
Доверенный сторонний сервер, называемый центром распространения ключей (KDC). Он обычно устанавливается на контроллерах домена в любой среде AD.
KDC логически идентифицируется тремя основными компонентами:
Базой данных (Db)
Сервером выдачи билетов (TGS)
Сервером авторизации (AS)
Используя несколько этапов, включая выдачу билетов, шифрование и дешифрование, билеты Kerberos способствуют процессу аутентификации.
Рассмотрим в общих чертах процесс аутентификации Kerberos:
Любой пользователь или клиент, которому требуется аутентификация во время входа в систему, вводит пароль. Этот пароль обрабатывается для получения хэша, который вычисляется с помощью алгоритма хэширования пароля.
Клиент запрашивает билет на выдачу билета (TGT), сообщая своё имя участника-пользователя (UPN) в KDC. В данном случае используется команда Kerberos KRB_AS_REQ.
Этот хэш пароля проверяется, обрабатывается и затем используется AS KDC для генерации секретного ключа клиента/пользователя.
На этом этапе AS также генерирует секретный ключ TGS после подтверждения доступности TGS.
AS обрабатывает сеансовый ключ 1 (SK1), который становится частью зашифрованного TGT, доставляемого клиенту, для подтверждения его первоначальной идентичности.
TGT отправляется клиенту из KDC после поиска UPN клиента в базе данных KDC. Здесь используется команда Kerberos KRB_AS_REP.
В TGT содержится идентификатор клиента, сетевой адрес клиента, временная метка, время жизни и ключ SK1. Важно отметить, что шифрование информации в TGT выполняется с использованием как секретного ключа клиента или пользователя, так и секретного ключа TGS.
После получения этого ответа клиент использует хеш своего пароля для извлечения SK1.
Каждый раз, когда клиенту требуется услуга или доступ к какому-либо сетевому ресурсу, TGT необходимо продлевать по истечении срока действия от KDC.
На этом завершается первый этап установления основной личности клиента, что открывает путь для последующих этапов аутентификации.
Для доступа к определенной услуге, например, для удаленного входа на новую рабочую станцию или доступа к веб-браузеру или файловой системе, требуются последующие этапы аутентификации, подтверждающие, что клиенту разрешен доступ к этой услуге.
Сначала, клиент обрабатывает имеющийся билет TGT, добавляет имя участника службы (SPN) требуемой службы и отправляет серверу выдачи сертификатов (TGS) аутентификатор, зашифрованный с помощью SK1, а затем секретным ключом TGS. В данном случае используется команда Kerberos KRB_TGS_REQ.
Сервер выдачи сертификатов (TGS) запрашивает инициализацию сеанса между клиентом и целевым сервером с помощью сеансового ключа службы (SK2).
Сервер выдачи сертификатов (TGS) использует секретный ключ TGS для расшифровки аутентификатора и извлечения SK1. После успешной проверки действительности билета TGT и совпадения информации о клиенте на билете TGT и в аутентификаторе сервер выдачи сертификатов (TGS) создает SK2.
Центр KDC включает SK2 вместе с идентификатором клиента, сетевым адресом, временной меткой и т. д. в билет службы и отправляет его клиенту. В данном случае используется команда Kerberos KRB_TGS_REP.
Этот билет зашифрован с помощью секретного ключа сервера, предоставленного базой данных (DB). Он снова дважды шифруется с помощью SK1 и отправляется клиенту. Этот билет также содержит сертификат атрибута привилегий (PAC), который подтверждает, что привилегии клиента зашифрованы и подписаны KDC.
Клиент может только расшифровать этот билет сервиса, чтобы извлечь SK1, сгенерировать новое сообщение аутентификатора, зашифровать его с помощью SK2 и отправить на целевой сервер для окончательной расшифровки и аутентификации для доступа к сервису. Здесь используется команда Kerberos KRB_AP_REQ.
Целевой сервер, используя свой секретный ключ, расшифровывает билет сервиса. Он обращается к SK2 и расшифровывает аутентификатор. Он может сначала идентифицировать себя, то есть аутентифицировать себя на клиенте, с помощью необязательной команды Kerberos KRB_AP_REP, в случаях, когда для повышения безопасности требуется взаимная аутентификация.
Если идентификатор клиента и другая информация из билета сервиса и PAC совпадают с информацией на аутентификаторе, между клиентом и целевым сервером устанавливается безопасное аутентифицированное соединение для предоставления необходимого сервиса.
Эти шаги выполняются для определения того, можно ли считать аутентификацию между клиентом и сервером успешной или неудачной с использованием протокола Kerberos.
Одним из наиболее заметных преимуществ использования этой модели аутентификации является то, что пароли никогда не хранятся в виде открытого текста и не передаются по сети в исходном виде. Однако Kerberos не является безупречным и далее мы поговорим о тех атаках, которые злоумышленники могут реализовать на данный протокол.
Старый добрый брут
Разговор об атаках на Kerberos по праву можно начать с перебора имен пользователей и паролей. Для этого нам нужна только сетевая доступность контроллера домена. Атака заключается в отправке KRB_AS_REQ сообщения с отключенной предварительной аутентификацией. Контроллер домена обрабатывает полученное сообщение по-разному в зависимости от наличия или отсутствия учетной записи.
Так, в случае, если учетная запись отсутствует, то в ответе будет «пользователь не известен». Если учетная запись присутствует и у нее включена предварительная аутентификация (по умолчанию в Active Directory), то в ответе будет «требуется предварительная аутентификация». Ну а в случае, если учетная запись присутствует и у нее отключена предварительная аутентификация, то в ответ будет передано KRB_AS_REP сообщение.
В результате успешной атаки мы получим перечень, содержащий некоторые действительные имена учетных записей пользователей домена.
В качестве примера воспользуемся утилитой kerbrute_linux_amd64.
./kerbrute_linux_amd64 userenum -d $Domain_fqdn $users_list --output $filename
Атака AS-REP roasting
AS-REP roasting — это метод постэксплуатации, позволяющий злоумышленнику получить зашифрованные хеши паролей для определенных учетных записей пользователей AD с отключенной предварительной аутентификацией Kerberos.
В типичном процессе аутентификации Kerberos пользователь отправляет AS-REQ в KDC и должен подтвердить свою личность (обычно путем шифрования временной метки с помощью ключа, полученного из пароля), прежде чем сервер вернет сообщение AS-REP (Authentication Service Reply), содержащее билет на выдачу билета (TGT).
Если предварительная аутентификация Kerberos отключена для учетной записи пользователя (распространенная ошибка конфигурации для учетных записей служб или устаревших систем), KDC отправляет AS-REP, содержащий данные, зашифрованные хешем пароля пользователя, без требования подтверждения личности.
В результате злоумышленник может используя такие инструменты GetNPUsers.py или Rubeus выполнить перечисление учётных записей с отключённой предварительной аутентификацией.
Для этого необходимо отправить специально созданные запросы AS-REQ для этих учётных записей. Центр KDC ответит сообщениями AS-REP, содержащими данные, зашифрованные хешем пароля пользователя. Затем злоумышленник извлечет эту информацию и может попытаться подобрать хеш офлайн с помощью таких инструментов, как Hashcat или John the Ripper, надеясь узнать настоящий пароль.
Поскольку взлом происходит офлайн, отсутствует риск блокировки учётной записи или обнаружения традиционными инструментами мониторинга аутентификации.
Ниже, на рисунке показано, как после выявления уязвимых учётных записей злоумышленник отправляет запрос на аутентификацию AS-REQ в центр распространения ключей KDC. Пользователям без предварительной аутентификации KDC отправляет сообщение AS-REP, содержащее зашифрованный блок, который можно подобрать методом подбора в офлайн-режиме.
Далее злоумышленник перехватывает ответ AS-REP от KDC. Ответ содержит зашифрованные данные с использованием хеша пароля пользователя, что позволяет злоумышленнику извлечь их и подготовить к офлайн-взлому, например с помощью Hashcat.
Pass The Key (Overpass The Hash)
Для реализации атаки Pass The Key атакующий преобразует хеш пароля (NTLM/Kerberos) в билет Kerberos, минуя необходимость знать сам пароль. Для этого, атакующему необходимо получить хеш пароля (тут нам поможет все тот же Mimikatz) или Kerberos TGT из памяти. Затем этот хэш можно использовать для генерации нового TGT.
В качестве примера можно воспользоваться утилитой getTGT:
# с NT-хешем (overpass-the-hash)
getTGT.py -hashes 'LMhash:NThash' $DOMAIN/$USER@$TARGET
# с ключом AES (128 или 256 бит) (pass-the-key)
getTGT.py -aesKey 'KerberosKey' $DOMAIN/$USER@$TARGET
Золотой и серебряный билет
И в завершении Golden Ticket— продвинутая атака на Kerberos, позволяющая злоумышленнику создавать поддельные TGT-билеты с неограниченными правами в домене. Это одна из самых опасных атак в Active Directory.
В Kerberos билет TGT выдается KDC и подписывается ключом учетной записи krbtgt. Если злоумышленник получает хеш пароля krbtgt, он может генерировать любые TGTбез взаимодействия с KDC.
Для реализации этой атаки злоумышленнику необходим доступ к хешу пароля krbtgt. Обычно его получают через компрометацию контроллера домена. Далее он может оффлайн сгенерировать билеты TGT с помощью Mimikatz.
Silver Ticket—это атака, при которой злоумышленник создает поддельный TGS-билет (Service Ticket) для конкретного сервиса, обходя проверки KDC. В отличие от Golden Ticket, эта атака не требует доступа к хешу krbtgt, но имеет более узкую область применения.
Для реализации атаки злоумышленник должен получить хеш пароля сервисного аккаунта (например, через Mimikatz или Kerberoasting). И также, сервис должен использовать Kerberos (NTLM не подойдет).
Заключение
Протокол Kerberos является неотъемлемой частью инфраструктуры Active Directory. Но при этом важно понимать, что небезопасная настройка этого протокола и использование устаревших операционных систем, а также отсутствие наложенных средств защиты т регулярного мониторинга ИБ могут привести к компрометации всей инфраструктуры AD.
Проведение регулярных пентестов позволит выявить и устранить слабые места в сетевой инфраструктуре быстрее, чем их найдут злоумышленники.
Kerberos-атаки хорошо показывают, как легко рушится безопасность там, где конфигурации устарели, а процессы не пересмотрены. Чтобы видеть такие дыры до злоумышленников и понимать их механику не теоретически, а руками, стоит разбирать реальные векторы атак в изолированной среде.
В практическом курсе по пентесту это как раз и делают: от анализа инфраструктуры до эксплуатации уязвимостей и построения устойчивых систем с учётом полученного опыта. Чтобы узнать, подойдет ли вам программа курса, пройдите вступительный тест.
А для знакомства с форматом обучения и экспертами приходите на бесплатные демо-уроки:
24 ноября: «Пентестирование инсайдерских угроз: тестируем, имитируем, защищаем». Записаться
3 декабря: «Атака DLL hijacking в контексте безопасности Windows». Записаться
10 декабря: «Атаки на доступность. ping&pig рушим сеть». Записаться