Протокол аутентификации в домене windows

Протоколы, составляющие основу процедуры

Аутентификация — это незаменимая процедура для каждого пользователя, компьютера и служебной учетной записи Windows, но ее механизм не изучается системными администраторами досконально. Каждый знает, что для регистрации в компьютере необходимо указать верный пароль, но многим ли известно, что происходит потом? Аутентификация Windows и связанные с ней протоколы активизируются каждый раз, когда пользователь, компьютер или служба регистрируются локально или на контроллере домена (DC). В данной статье речь пойдет сначала об основных принципах аутентификации Windows, а затем о связанных с ней протоколах. В заключение приводятся краткие рекомендации по повышению надежности процедуры аутентификации в сети Windows.

Аутентификация: общие принципы

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

Рисунок 1. Механизмы управления доступом и аутентификация Windows

Идентификация (identification). В процессе идентификации используется набор данных, который уникально идентифицирует объект безопасности (например, пользователя, группу, компьютер, учетную запись службы) в общей службе каталогов. Служба каталогов, такая как Active Directory (AD), позволяет уникально идентифицировать объекты, подобно тому как DNS удостоверяет, что два человека не могут иметь одинаковые адреса электронной почты. Во внутренних механизмах Windows используются SID, глобально уникальные идентификаторы (globally unique identifier, GUID) и другие уникальные тэги. В большинстве случаев для идентификации достаточно ввести уникальное имя учетной записи, такое как Rgrimes. В большом лесу AD приходится применять полные имена пользователей (user principal name, UPN), например rgrimes@banneretcs.com. При использовании смарт-карт субъект безопасности может представить свой цифровой сертификат или ключ.

Аутентификация или проверка подлинности (authentication). После того как субъект безопасности вводит с клавиатуры или иным способом предоставляет необходимую для идентификации информацию (например, имя пользователя, маркер безопасности), он должен ввести с клавиатуры или представить частную информацию для аутентификации (например, пароль и PIN-код). В Windows субъект безопасности вводит эту информацию на экране регистрации с помощью программ Microsoft Graphical Identification and Authentication DLL (msgina.dll) и Winlogon.exe. Протокол аутентификации и механизм системы кодируют представленную информацию на настольном компьютере и передают запрос аутентификации. Служба аутентификации Windows может быть базой данных SAM или AD. База данных SAM обслуживает локальные процедуры регистрации и регистрацию на контроллерах домена Windows NT 4.0. AD аутентифицирует запросы в Windows 2000 или доменах более поздних версий этой операционной системы. Протокол аутентификации (например, LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) используется для транспортировки запросов аутентификации и последующих транзакций между экраном регистрации и службой аутентификации. Чуть ниже каждый протокол аутентификации будет рассмотрен отдельно.

Авторизация (authorization). Если служба аутентификации удостоверяет комбинацию идентификатора и «секретных» данных аутентификации, то подлинность субъекта безопасности считается успешно подтвержденной. Затем система собирает информацию о членстве субъекта безопасности (т. е. пользователя) в группах. Нередко пользователь принадлежит к нескольким точно определенным группам — локальным (local), доменным (domain local), глобальным (global) и универсальным (universal) — в результате обычных процедур назначения членства. Система сверяет локальные группы с локальной базой данных SAM и проверяет локальные и глобальные группы на контроллерах DC в домашнем домене пользователя, а также универсальные группы на DC, который содержит глобальный каталог Global Catalog. Прямо или косвенно система собирает все сведения о членстве в группах, чтобы получить информацию о разрешениях безопасности.

Сразу после аутентификации система собирает идентификаторы SID учетной записи и сведения о членстве в группах в объекте, называемом маркером доступа (access token). Возможно, пользователю придется выйти и вновь зарегистрироваться в системе, чтобы новые разрешения безопасности вступили в силу. Если пользователю нужно получить доступ к объекту (например, файлу, папке, принтеру, разделу реестра), защищенному разрешениями NTFS, то процесс (например, Windows Explorer), выступающий от имени пользователя, предоставляет свой маркер доступа. Каждый объект NTFS располагает списком элементов управления доступом (access control entry, ACE), которые, в сущности, представляют собой знакомые разрешения NTFS (например, Allow Read, Allow Write). Набор элементов ACE, назначенных пользователям и группам, составляет список управления доступом (ACL) данного объекта. Примечательно, что ACL объекта представлен разрешениями безопасности, которые можно просмотреть в Windows Explorer.

Маркер доступа, содержащий учетную запись и группы, с которыми связан пользователь, определяет эффективные разрешения пользователя. Процесс авторизации заключается в разрешении или отказе в доступе к определенному объекту на основе сравнения маркера доступа с ACL объекта. Авторизацию обеспечивает Security Reference Monitor системы Windows (экран 1). В примере, показанном на экране 1, пользователь имеет разрешения Read, Write и Modify. Однако группа Everyone, к которой принадлежит пользователь, не имеет разрешения Modify. Члены других групп располагают разрешениями Read и Modify, но разрешение Deny группы Everyone отменяет разрешение Modify. Объект также располагает списками ACL, которые отказывают в разрешении Full Control группе HR, но пользователь к этой группе не принадлежит. Таким образом, эффективные разрешения пользователя по отношению к объекту на экране 2 — Read и Write.

Отчетность (accounting). Если в Windows режим аудита активизирован, то система сохраняет событие аутентификации в журнале Security, и это последний компонент системы управления доступом — отчетность. Большинство сложных событий начальной регистрации и последующей авторизации происходят за несколько секунд и скрыты от пользователя. Все сложные операции возлагаются на протокол аутентификации.

Задачи протокола

Протокол аутентификации должен выполнять по крайней мере две задачи. Во-первых, он должен безопасно передавать транзакции от запросчика в базу данных аутентификации и на любой другой компьютер, на котором размещен соответствующий ресурс. Во-вторых, он должен безопасно и надежно хранить пароль или маркер. Последнее представляет особый интерес для взломщиков паролей. Протокол аутентификации должен защитить введенную пользователем информацию при пересылке в базу данных аутентификации (т. е. SAM или AD). Для этого протокол подписывает, скрывает или шифрует транзакцию. Кроме того, ей присваивается временная метка, чтобы взломщик не мог воспользоваться учетными данными в будущем. Чтобы не позволить немедленно извлечь пароль пользователя из базы данных, протокол должен обеспечить скрытное хранение паролей в базе данных аутентификации.

В течение более чем десяти лет протоколы аутентификации в основном обеспечивали защиту путем сохранения паролей в скрытой форме (обычно хешированной) в базе данных аутентификации и полного запрета на передачу паролей между запросчиком и базой данных аутентификации простым текстом (даже в скрытой форме). Процесс запрос—ответ выглядит следующим образом:

1. Компьютер получает данные для идентификации и аутентификации от пользователя и запрашивает аутентификацию на соответствующем сервере.
2. Сервер аутентификации генерирует случайное произвольное значение (называемое запросом — challenge) и посылает его запросчику.
3. Запросчик получает запрос и производит над ним и скрытой формой пароля математические операции, а затем передает результат (называемый ответом — response) серверу аутентификации.
4. Сервер аутентификации также выполняет математические манипуляции с запросом методом, идентичным используемому на рабочей станции, и сравнивает результат с полученным ответом. Если результаты совпадают, то запросчик считается успешно аутентифицированным.

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

Локальная и доменная регистрация

При регистрации пользователя одна из первых задач Windows — определить, относится ли процедура только к локальной машине или к учетной записи домена. Пользователи, регистрирующиеся от имени локальной учетной записи, имеют доступ только к ресурсам своего компьютера и только если информация об учетной записи пользователя содержится в локальной базе данных SAM. Если пользователям нужно обратиться к ресурсам на удаленном компьютере без аутентификации в домене, то их учетные записи должны быть продублированы в локальной базе данных SAM каждого доступного компьютера. Учетные записи в каждом компьютере-участнике должны быть синхронизированы (одинаковые имена регистрации, пароли и сроки действия учетных данных на всех машинах). В противном случае положение значительно усложняется. Трудно обслуживать одноранговые (P2P) сети средних размеров, в которых применяются только локальные процедуры регистрации.

На DC не распространяется требование синхронизации нескольких учетных записей пользователей на разных компьютерах. При доменной аутентификации компьютеры, зарегистрированные в домене, отыскивают контроллеры DC, чтобы предъявить учетные данные доменной учетной записи пользователя при запросах аутентификации. Таким образом, если удаленный пользователь пытается получить доступ к локальному ресурсу какой-нибудь машины, то этот компьютер просит DC проверить идентичность запрашивающего пользователя. Учетные записи пользователя домена располагаются только на DC и создаются лишь один раз. Любой компьютер-участник, которому нужно удостоверить учетную запись в домене, может обратиться к контроллерам DC в любое время. Проблемы синхронизации имен регистрации, паролей и сроков их действия не возникает, так как учетные данные и управление учетной записью осуществляются только в одном месте — на DC. Независимо от типа регистрации (локальной или доменной), Windows должна аутентифицировать запрос пользователя.

Протоколы аутентификации Windows

Как отмечалось выше, в Windows применяется четыре основных протокола аутентификации: LAN Manager, NTLM, NTLMv2 и Kerberos. LAN Manager появился во времена DOS и продолжал использоваться с первыми версиями Windows. NTLM был выпущен вместе с NT. Новшеством пакета обновлений NT Server 4.0 Service Pack 4 (SP4) стал NTLMv2, а Windows 2000 привнесла Kerberos. По умолчанию все компьютеры с Windows 2000 и более новыми операционными системами совместимы со всеми четырьмя протоколами аутентификации. Передавая в эти системы соответствующие команды, другие рабочие станции и серверы могут выбирать протокол для обработки запроса аутентификации. Системы Windows 9x и более поздние с полным набором программных исправлений совместимы с LM, NTLM и NTLMv2. На платформе Microsoft Kerberos может использоваться только клиентами Windows 2000 (или более новыми) при обращениях в домены Windows 2000 (и выше). Компьютер с Windows 2000 или более новой версией операционной системы должен иметь Kerberos и по крайней мере еще один из протоколов аутентификации.

Исследования в области безопасности показали, что более старые протоколы (LM и NTLM) уязвимы в случае прослушивания и атак с разгадыванием пароля.

Поэтому, если возможно, рекомендуется использовать только Kerberos и NTLMv2. Чтобы убедиться в правильности этого совета, следует оценить возможности каждого протокола.

LAN Manager

Компания IBM разработала протокол LAN Manager, применив его в ранних версиях Windows и сетях Windows. Как все протоколы аутентификации Microsoft, LAN Manager генерирует хеш паролей (LM hash), который хранится и используется отправителем и получателем в процессе аутентификации. LAN Manager формирует LM-хеши, изменяя все буквы пароля на верхний регистр, разбивая пароль на две 7-символьные половины, а затем шифруя. В дальнейшем LM-хеш используется в нескольких последовательных операциях, аналогичных процессу запрос—ответ, описанному выше.

Если раньше LAN Manager был вполне приемлем, то сейчас он считается очень ненадежным. С помощью специальных инструментов пароли, зашифрованные методом хеширования LAN Manager, можно всего за несколько секунд преобразовать в простой текст. LM-хешам свойственны принципиальные недостатки, а также имеется ряд уязвимых мест:

• пароли могут состоять из ограниченной последовательности 128 символов ASCII;
• длина пароля не превышает 14 символов;
• если пароль содержит менее 14 символов, то отсутствующие символы заменяются легко угадываемой хешированной формой, что позволяет точно определить длину пароля;
• перед кэшированием LAN Manager преобразует все буквенные символы пароля в верхний регистр.

Почему LAN Manager до сих пор не вышел из употребления? В целях обратной совместимости он активен по умолчанию во всех компьютерах Windows, в том числе Windows Server 2003. В новейших базах данных аутентификации Windows слабый LM-хеш хранится наряду с более надежными просто на случай, если придется выполнить транзакцию LAN Manager. Если на предприятии не используются другие приложения, требующие аутентификации LAN Manager, то можно (и нужно) LAN Manager отключить.

NTLM

С появлением NT компания Microsoft спроектировала и развернула более надежный протокол аутентификации NTLM. В NTLM используется более эффективный алгоритм аутентификации, который создает более надежный хеш паролей (NTLM hash). Пароль NTLM может содержать до 128 символов. В отличие от хеширования LAN Manager, ограниченного использованием только символов ASCII, NTLM совместим с полным набором символов Unicode, что повышает сложность паролей. NTLM-хеш отсекается на 128-м символе, преобразуется в 16-разрядное значение Unicode, обрабатывается распределительной функцией MD4 и сохраняется в 32-символьной шестнадцатеричной строке. За счет использования NTLM-хеша в операциях запрос—ответ последовательность аутентификации NTLM гораздо сложнее процедуры LAN Manager.

NTLMv2

В итоге выяснилось, что и NTLM уязвим, и специалисты Microsoft подготовили NTLMv2, который до сих пор считается достаточно надежным, хотя сейчас предпочтительный протокол — Kerberos. NTLMv2 по-прежнему широко используется для локальной регистрации и в некоторых других случаях. NTLMv2 похож на NTLM, но в хеше пароля NTLMv2 используется аутентификация сообщений HMAC-MD5, а последовательности запрос—ответ присваивается метка времени, чтобы предотвратить атаки, в ходе которых взломщик записывает учетные данные и впоследствии их использует.

В целом NTLMv2 более устойчив к атакам с применением «грубой силы», нежели NTLM, так как в протоколе применяется 128-разрядный ключ шифрования. Известно только о двух программах взлома паролей (одна из них — LC5 компании Symantec), с помощью которых удавалось открыть хеши паролей NTLMv2.

Kerberos

Компания Microsoft приняла Kerberos в качестве выбираемого по умолчанию протокола доменной аутентификации для доменов Windows 2000, а затем и AD. Kerberos — открытый стандарт, пригодный для взаимодействия с инородными доменами (называемыми областями — realm — в UNIX и Linux). Каждый DC в доменах AD играет роль сервера распределения (Kerberos Distribution Server, KDC) и может участвовать в процедуре аутентификации. Безопасность повышается благодаря следующим характеристикам Kerberos:

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

Краткое описание работы Kerberos:

1. После успешной обычной аутентификации компьютер пользователя запрашивает билет безопасности из сервера Kerberos (DC) для будущих запросов аутентификации.
2. Сервер Kerberos выдает запросчику билет для участия в будущих событиях аутентификации и авторизации без повторного предъявления первоначальных учетных данных аутентификации.
3. Когда запросчику нужно обратиться к ресурсу сервера-участника, он получает другой билет доступа от сервера Kerberos и предъявляет его серверу ресурса для проверки.
4. Первоначальные учетные данные аутентификации не передаются по сетевым каналам ни в одном из последующих сеансов аутентификации (до тех пор, пока не истечет срок действия билета, выданного на этапе 2).

Следует обратить внимание, что, хотя принцип работы Kerberos напоминает инфраструктуру с частным открытым ключом (public key infrastructure, PKI), вся информация защищается с использованием симметричных ключей (в отличие от асимметричных ключей, применяемых в большинстве служб аутентификации).

Смарт-карты

Надежность паролей и других методов аутентификации на основе одного параметра быстро снижается. Электронная коммерция проникает в повседневную жизнь и возрастает как число способов кражи личных данных (спам, мошенничество с URL), так и вероятность злоупотреблений паролями. Многие специалисты считают, что аутентификация с двумя параметрами — в форме смарт-карт, USB-устройств или других криптографических устройств — в будущем станет обычным явлением для транзакций в Internet. Разработчики Microsoft встраивают в свои решения функции для работы с цифровыми сертификатами и смарт-картами. Для использования смарт-карт необходимо установить службу Certificate Services и распространить сертификаты смарт-карт. Конечно, нужны также физические смарт-карты, устройства считывания и программное обеспечение поставщика. Затем при необходимости пользователи могут вставлять свои смарт-карты в локальные устройства чтения для доступа к компьютеру Windows. При грамотном использовании смарт-карты могут существенно повысить надежность аутентификации.

Защита протокола аутентификации

В некоторых статьях ошибочно утверждается, что взломать механизм аутентификации Microsoft по-прежнему просто. В действительности из 20 существующих инструментов взлома пароля только два работают с NTLMv2 и лишь один — с Kerberos. Но, предприняв несколько простых шагов, можно отвести и эту угрозу. Для предотвращения попыток разгадывания и сброса пароля нужно принять следующие меры (большинство параметров можно настроить локально или с помощью Group Policy).

• Отключить хранение LM-хешей, как описано в статье Microsoft «How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases» (http://support.microsoft.com/ default.aspx?scid=kb;en-us;299656). Это делается для того, чтобы помешать взломщикам открыть исходный пароль.
• Отключить все протоколы аутентификации, кроме NTLMv2 и Kerberos (после исчерпывающего тестирования). Процедура описана в статье Microsoft TechNet «Network security: LAN Manager authentication level» (http://www.microsoft.com/resources/ documentation/windowsserv/2003/ standard/proddocs/en-us/576.asp).
• Запретить начальную загрузку со сменных носителей, чтобы предотвратить запуск инструментов взлома пароля в обход операционной системы. Запрет начальной загрузки со всех дисков, кроме выбираемого по умолчанию, предотвращает доступ автономных программ взлома пароля к базе данных аутентификации, где хранятся хеши паролей.
• Пользователи должны назначать сложные пароли длиной не менее 8 символов.
• Пользователи должны менять свои пароли по крайней мере раз в квартал.
• Активизировать блокировку учетной записи хотя бы на одну минуту с автоматическим сбросом. Это предотвращает разгадывание паролей в сети.

Обязанности пользователей

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

Роджер Граймз — Редактор Windows IT Pro и консультант по проблемам безопасности. Имеет сертификаты CPA, CISSP, CEH, CHFI, TICSA, MCT, MCSE: Security и Security+. roger@banneretcs.com

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

Для начала внесем ясность в термины. Многие путают понятия аутентификации и авторизации, хотя это различные процедуры.

• Аутентификация — происходит от английского слова authentication, которое можно перевести как идентификация или проверка подлинности. Это полностью отражает суть процесса — проверка подлинности пользователя, т.е. мы должны удостовериться, что пользователь, пытающийся получить доступ к системе именно тот, за кого себя выдает.
• Авторизация — перевод слова authorization означает разрешение, т.е. проверка прав доступа к какому-либо объекту. Процесс авторизации может быть применен только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, мы должны выяснить личность объекта, которому мы собираемся предоставить какие-либо права.

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

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

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

Локальная аутентификация

Прежде всего начнем с локальной аутентификации, когда пользователь хочет войти непосредственно на рабочую станцию, не входящую в домен. Что происходит после того, как пользователь ввел свой логин и пароль? Сразу после этого введенные данные передаются подсистеме локальной безопасности (LSA), которая сразу преобразует пароль в хэш, хэширование — это одностороннее криптографическое преобразование, делающее восстановление исходной последовательности невозможным. В открытом виде пароль нигде в системе не хранится и не фигурирует, пользователь — единственный кто его знает.

Затем служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля).

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

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

LAN Manager (LM)

Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп, откуда перекочевал в семейство Windows 9.х. Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор. И если современной системе поступит запрос на аутентификацию по протоколу LM, то, при наличии соответствующих разрешений, он будет обработан.

Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:

• Пароль регистронезависимый и приводится к верхнему регистру.
• Длина пароля — 14 символов, более короткие пароли дополняются при создании хэша нулями.
• Пароль делится пополам и для каждой части создается свой хэш по алгоритму DES.

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

А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.

NT LAN Manager (NTLM)

Новый протокол аутентификации появился в Windows NT и благополучно, с некоторыми изменениями, дожил до наших дней. А до появления Kerberos в Windows 2000 был единственным протоколом аутентификации в домене NT.

Сегодня протокол NTLM, точнее его более современная версия NTLMv2, применяются для аутентификации компьютеров рабочих групп, в доменных сетях Active Directory по умолчанию применяется Kerberos, однако если одна из сторон не может применить этот протокол, то по согласованию могут быть использованы NTLMv2, NTLM и даже LM.

Принцип работы NTLM имеет много общего с LM и эти протоколы обратно совместимы, но есть и существенные отличия. NT-хэш формируется на основе пароля длиной до 128 символов по алгоритму MD4, пароль регистрозависимый и может содержать не только ACSII символы, но и Unicode, что существенно повышает его стойкость по сравнению с LM.

Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:

Допустим локальный компьютер хочет получить доступ к некоторому файловому ресурсу на другом ПК, который мы будем считать сервером, при этом совсем не обязательно наличие на этом ПК северной ОС или серверных ролей. С точки зрения протокола NTLM клиент это тот, кто обращается, сервер — к кому обращаются.

Чтобы получить доступ к ресурсу клиент направляет серверу запрос с именем пользователя. В ответ сервер передает ему случайное число, называемое запросом сервера. Клиент в свою очередь шифрует данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, однако, несмотря на то, что NT-хэш 128-битный, в силу технических ограничений используется 40 или 56 битный ключ (хеш делится на три части и каждая часть шифрует запрос сервера отдельно).

Зашифрованный хэшем пароля запрос сервера называется ответом NTLM и передается обратно серверу, сервер извлекает из хранилища SAM хэш пароля того пользователя, чье имя было ему передано и выполняет аналогичные действия с запросом сервера, после чего сравнивает полученный результат с ответом NTLM. Если результаты совпадают, значит пользователь клиента действительно тот, за кого себя выдает, и аутентификация считается успешной.

В случае доменной аутентификации процесс протекает несколько иначе. В отличие от локальных пользователей, хэши паролей которых хранятся в локальных базах SAM, хэши паролей доменных пользователей хранятся на контроллерах доменов. При входе в систему LSA отправляет доступному контроллеру домена запрос с указанием имени пользователя и имени домена и дальнейший процесс происходит как показано выше.

В случае получения доступа к третьим ресурсам схема также немного изменяется:

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

Как видим, хэш пароля ни при каких обстоятельствах по сети не передается. Хэш введенного пароля хранит служба LSA, хэши паролей пользователей хранятся либо в локальных хранилищах SAM, либо в хранилищах контроллера домена.

Но несмотря на это, протокол NTLM на сегодняшний день считаться защищенным не может. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль.

Но и перехваченного хэша может оказаться вполне достаточно, так как NTLM-ответ генерируется на базе пароля пользователя и подлинность клиента сервером никак не проверяется, то возможно использовать перехваченные данные для неавторизованного доступа к ресурсам сети. Отсутствие взаимной проверки подлинности также позволяет использовать атаки плана человек посередине, когда атакующий представляется клиенту сервером и наоборот, устанавливая при этом два канала и перехватывая передаваемые данные.

NTLMv2

Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено.

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

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

Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.

Криптостойкость данного алгоритма является актуальной и на сегодняшний день, известно только два случая взлома данного хэша, один из них произведен компанией Symantec в исследовательских целях. Можно с уверенностью сказать, что в настоящий момент нет массовых инструментов для атак на NTLMv2, в отличие от NTLM, взломать который может любой вдумчиво прочитавший инструкцию школьник.

Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.

При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается.

Настройки безопасности

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

За выбор протокола аутентификации отвечает локальная или групповая политика. Откроем редактор политик и перейдем в Конфигурация компьютера — Конфигурация Windows — Политики безопасности — Локальные политики — Параметры безопасности, в этом разделе найдем политику Сетевая безопасность: уровень проверки подлинности LAN Manager.

В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля, которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.

В нашей же политике мы видим широкий выбор значений, очевидно, что сегодня безопасными могут считаться политики начиная с Отправлять только NTLMv2-ответ и ниже по списку.

Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее:

Наименование настройки	Клиентский компьютер	Контроллер домена	Lm Compatibility Level
Отправлять LM- и NTLM-ответы	Клиентские компьютеры используют LM и NTLM аутентификацию, и никогда не используют сеансовую безопасность NTLMv2.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	0
Отправлять LM- и NTLM- использовать сеансовую безопасность NTLMv2	Клиентские компьютеры используют LM и NTLM аутентификацию, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	1
Отправлять только NTLM-ответ	Клиентские компьютеры используют проверку подлинности NTLMv1, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	2
Отправлять только NTLMv2-ответ	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	3
Отправлять только NTLMv2-ответ. Отказывать LM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM, и будут принимать только NTLM и NTLMv2.	4
Отправлять только NTLMv2-ответ. Отказывать LM и NTLM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM и NTLM, и будут принимать только NTLMv2.	5

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

После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя. Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Сегодня мы с вами рассмотрим протокол аутентификации Kerberos. Пройдемся по самому протоколу и рассмотрим его работу в рамках Microsoft Active Directory.

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

История

Самая первая версия протокола была разработана в далеком 1988 году в MIT для проекта «Афина». Версии с 1 по 3 использовались исключительно внутри MIT.

4 версия была разработана Стивеном Миллером и Клиффордом Нейманном, она хоть и была публичной, но для очень ограниченного количества компаний, включая проект «Афина». И только 5 версия протокола Kerberos, которая вышла в 1993 году уже стала по настоящему публичной и была описана в RFC 1510.  

Microsoft Windows Server и Active Directory используют расширенный протокол Kerberos 5 версии, описанный в RFC 4120.

Kerberos в Active Directory

Kerberos сейчас считается основным протоколом при работе в домене Microsoft Windows и состоит из набора компонентов:

Описание работы протокола Kerberos

 Для общего понимания для начала нарисуем схему и потом пройдем по всем пунктам. Схема работы протокола представлена ниже:

Рассмотрим каждый шаг более подробно:

1. AS_REQ (Preauthentication Request). Данный этап мы проходим, когда авторизуемся на нашей рабочей станции в домене (вводим наш логин и пароль). Формат отправляемого запроса выглядит следующим образом:

Client Name – имя пользователя;

Service Name – обращение к сервису krbtgt на стороне контроллера домена;

Client Time – метка времени с рабочей станции, откуда мы пытаемся авторизоваться. Метка шифруется хэшем пароля пользователя для предотвращения атак с повторной передачей.

По умолчанию, разница во времени между клиентом и KDC должна быть не более 5 минут, иначе запрос будет отклонен;

2. AS_REP. После того, как контроллер домена получит наш пакет – он сразу же попытается расшифровать присланную метку времени используя локальную копию хэша пароля пользователя из базы Active Directory. Если провести операцию не получается, то такой запрос будет отклонен, а клиенту возвращена ошибка. Если же все проходит успешно, то формируется сообщение AS_REP. Формат данного сообщения приведен ниже:

Client Name – имя пользователя;

Session Key – случайно сгенерированный криптографический ключ, который в дальнейшем будет использоваться для взаимодействия между пользователем и AD;

Token Information – токен пользователя, содержащий все данные по пользователю – состав групп, права и т.д.;

Lifetime/Expiry – время жизни TGT;

По умолчанию время жизни TGT составляет 10 часов.

В сообщении AS_REP у нас 2 блока – один шифруется хэшем пароля пользователя, второй – шифруется секретом KDC. Секрет KDC хранится в AD на контроллере. Клиент расшифровывает свою часть сообщения, а TGT просто сохраняется в памяти. Именно внутри блока TGT у нас хранится Token Information.

После успешно принятого сообщения AS_REP нам уже не требуется пароль, поскольку дальнейшее взаимодействие между клиентом и контроллером AD будет происходит посредством защищенного Session Key;

3. TGS_REQ. Вот и настал момент, когда нам необходимо обратиться к какому – либо сервису по Kerberos. В случае с AD это практически любой сервис (Exchange, SharePoint, файловые серверы и т.д.). Для того, чтобы мы смогли запросить доступ к сервису, данный сервис должен иметь свой SPN.

Итак, мы хотим обратиться к сервису через Kerberos – для этого мы посылаем на KDC сообщение TGS_REQ следующего содержания:

Service Principal – SPN запрашиваемого сервиса;

Client Name – имя пользователя;

Time Stamp – метка времени;

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

4. TGS_REP. Если на предыдущем этапе у нас все прошло хорошо, то в ответ KDC формирует нам TGS_REP пакет со следующим содержимым:

Service Principal – SPN сервиса;

Time Stamp – метка времени;

Service Session Key – это сессионный ключ, который будет использоваться уже при общении со службой;

Client Name – имя пользователя.

Здесь у нас также ответ представлен из двух блоков: первый блок – шифруется сессионным ключом клиента, который был получен на этапе AS_REP, второй блок – шифруется хэшем пароля службы;

5. AP_REQ. После того, как клиент получит ответ TGS_REP, он «идет» с ним к целевому сервису уже с запросом AP_REQ следующего содержания:

Client Name – имя пользователя;

Time Stamp – метка времени;

Service Principal – SPN запрашиваемого сервиса;

Service Session Key – это сессионный ключ, который будет использоваться уже при общении со службой;

Token Information – токен пользователя, содержащий все данные по пользователю – состав групп, права и т.д.;   

Здесь у нас также представлены 2 блока – один блок шифруется сессионным ключом службы, второй – секретом службы;

6. После поступления запроса AP_REQ служба дешифрует свой блок, получая Service Session Key, которым затем дешифрует первый блок, обеспечивая проверку подлинности;

7. AP_REP. Данный пакет у нас на рисунке выше помечен пунктирной стрелкой. По сути, после получения AP_REQ и его расшифровки у службы нет обязательного требования отправки данного пакета. Он может быть отправлен в случае, например, возникшей ошибки или если была запрошена взаимная проверка подлинности.

Итог

В этой статье мы с вами расмотрели, как происходит взаимодействие по протоколу Kerberos в среде Active Directory. Естественно, сам протокол не ограничивается только этими пакетами. Гораздо больше технической информации можно найти в RFC 1510 и RFC 4120.

Пятая часть перевода статьи zer1t0, посвященная атакам на протокол аутентификации Kerberos.

• Атаки на Active Directory: часть 1
• Атаки на Active Directory: часть 2
• Атаки на Active Directory: часть 3
• Атаки на Active Directory: часть 4
• Атаки на Active Directory: часть 5
• Атаки на Active Directory: часть 6
• Атаки на Active Directory: часть 7

Kerberos

Основы Kerberos

Kerberos является предпочтительным протоколом аутентификации в сетях Active Directory для учетных записей домена (его нельзя использовать в рабочих группах) и описан в RFC 4120. Kerberos фокусируется на использовании токенов, называемых «билетами», которые позволяют пользователю пройти аутентификацию.

Принципы Kerberos

Наиболее распространенными субъектами Kerberos являются пользователи и службы, причем последний тип используется чаще всего. Чтобы запросить билет для службы, необходимо указать имя субъекта-службы (SPN). Например, HTTP/computer. Существует несколько основных типов Kerberos, которые можно использовать для запроса службы: NT-SRV-INST, NT-SRV-HST или NT-SRV-XHST. С другой стороны, можно использовать участников для представления пользователей, и как правило они обычно используются для указания имени клиента, запрашивающего билет. Пользователь обычно представляется SamAccountName (например, «foo») с использованием типа NT-PRINCIPAL. Однако существует также тип NT-ENTERPRISE, который допускает более явные форматы для идентификации пользователя, например SamAccountName@DomainFQDN (например, «foo@contoso.local»). NT-ENTERPRISE может быть полезен для идентификации пользователей из разных доменов, при междоменном запросе.

Информация предоставлена исключительно в ознакомительных целях. Не нарушайте законодательство!

Билеты

Билеты представляют собой частично зашифрованные структуры, которые содержат:

• целевой субъект (обычно служба), для которого применяется билет;
• информация, связанная с клиентом, такая как имя и домен;
• ключ для установления безопасных каналов между клиентом и сервисом;
• временные метки для определения периода, в течение которого билет действителен.

Определение билета

Cертификат атрибута привилегий
Помимо обычных данных билета, реализация Kerberos в Active Directory обычно включает в поле билета authorization-data важную структуру аутентификации Active Directory: PAC.

PAC (сертификат атрибута привилегий) содержит информацию о безопасности, связанную с клиентом:

• домен клиента: включает имя домена и SID (LogonDomainName и LogonDomainId соответственно);
• пользователя клиента: имя пользователя и RID пользователя (EffectiveName и UserId соответственно);
• группы клиентов: идентификаторы RID (GroupId) тех групп домена, к которым принадлежит пользователь;
• другие группы: PAC включает в себя другие SID (ExtraSids), которые ссылаются на не доменные группы, которые могут применяться для междоменной аутентификации, а также общеизвестные SID, используемые для указания особых характеристик.

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

• подпись сервера: подпись содержимого PAC, созданная с помощью того же ключа, который использовался для шифрования билета;
• подпись KDC: подпись подписи сервера, созданная с помощью ключа KDC. Это можно использовать для проверки того, что PAC был создан KDC, и предотвращения атак Silver Ticket.
• подпись билета: подпись содержимого билета, созданная с помощью ключа KDC. Эта подпись была недавно введена для предотвращения атаки Bronze bit.

Компоненты Kerberos

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

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

Затем у нас есть второй компонент — служба. В случае с Kerberos обычно говорится о сервере приложений (AP), то есть о машине, которая предлагает услугу, к которой пользователь хочет получить доступ. Точкой доступа здесь может быть любой компьютер домена.

И, наконец, нам нужно, чтобы кто-то предоставил пользователю билеты. Для этого предназначен KDC (Центр распределения ключей). KDC в Active Directory является контроллером домена, поскольку именно он имеет доступ к базе данных домена, необходимой для аутентификации пользователей.

В Kerberos TGT предоставляются службой/сервером аутентификации (AS), а ST — службой/сервером выдачи билетов (TGS). Обе службы запрашивают у KDC ключи Kerberos. Однако, поскольку все эти службы обычно работают на одном сервере, для простоты будем называть их просто KDC.

Типы билетов

Итак, теперь, когда у нас есть клиент, сервер приложений, KDC и билеты, давайте посмотрим, как работает протокол Kerberos. Для этого мы должны иметь в виду, что в протоколе Kerberos есть два типа билетов:

ST
Первый тип — это ST (Сервисные билеты), которые клиент предъявляет AP/службе, чтобы получить к ним доступ. KDC выдает ST для клиентов, которые запрашивают их.

В Active Directory клиент может получить ST для любой службы, зарегистрированной в базе данных домена, не имеет значения, имеет ли пользователь доступ к службе (Kerberos не обрабатывает авторизацию) или даже если служба не запущена.

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

В случае Active Directory обычно целевыми субъектами являются службы, принадлежащие учетным записям пользователей (или учетным записям компьютеров, которые также являются пользователями в Active Directory). В этом случае TGT шифруются ключом владельца учетной записи службы.

Из этой информации мы можем сделать несколько выводов:

Во-первых, если мы знаем ключ (который получен из пароля), мы можем подделать билеты. С точки зрения Active Directory, если мы знаем ключ пользователя, мы можем создавать собственные билеты для доступа к любой службе этого пользователя. Эти индивидуальные билеты известны как Silver Ticket.

Например, если вы знаете пароль учетной записи компьютера (хранящийся в секретах LSA машины), вы можете создать Silver Ticket для службы SMB и получить доступ к машине как администратор.

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

Этот метод может быть полезен в некоторых ситуациях, например, если вы можете получить ST для администратора базы данных MSSQL на машине A (SPN = MSSQLSvc\machineA), вы можете изменить службу, чтобы она указывала на службу SMB той же самой машины. машина (SPN = CIFS\machineA) и получить доступ к машине A.

TGT
Чтобы получить ST от KDC, пользователь должен предъявить билет другого типа, TGT (билет на получение билетов). TGT — это как ST для KDC.

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

Поскольку вы можете создать билет для любого клиента, вы можете выдавать себя за любого пользователя в домене, включая администраторов. Golden Ticket можно даже использовать для компрометации всего леса, установив специальные привилегированные SID в PAC, например Enterprise Admins.

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

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

Получение билетов билетов

Теперь, когда мы знаем об ST и TGT, давайте более подробно рассмотрим, как работает Kerberos, а значит, как выдаются билеты:

Процесс Kerberos

1. Клиент запрашивает TGT в AS (KDC), отправляя сообщение AS-REQ. В сообщение AS-REQ клиент может включить отметку времени, зашифрованную с помощью своего ключа Kerberos. Это называется предварительной аутентификацией Kerberos и иногда не требуется.
2. AS (KDC) проверяет метку времени и отвечает сообщением AS-REP, которое содержит две зашифрованные части: TGT, зашифрованный с помощью ключа KDC, и данные клиента, зашифрованные с помощью ключа клиента. Некоторая информация, такая как ключ сеанса, реплицируется в обеих частях, поэтому и пользователь, и KDC могут совместно использовать ее.
3. После этого клиент подключается к службе в точке доступа и согласовывает протокол аутентификации с SPNEGO. Если выбран Kerberos, клиенту необходимо получить ST для целевой службы.
4. Поэтому он запрашивает ST у KDC, отправляя TGS-REQ, который включает его TGT и имя участника-службы целевой службы. Он также отправляет данные, зашифрованные с помощью сеансового ключа, такие как имя пользователя клиента и отметка времени, для проверки соединения.
5. KDC расшифровывает TGT своим ключом, получая таким образом доступ к имени пользователя и сеансовому ключу. KDC использует ключ сеанса для расшифровки имени пользователя, отправленного пользователем, чтобы проверить его правильность. Убедившись, что все правильно, KDC отвечает сообщением TGS-REP, которое содержит две зашифрованные части: ST для целевой службы, зашифрованную с помощью ключа пользователя службы, и данные клиента, зашифрованные с помощью ключа сеанса. Некоторая информация, такая как ключ сеанса службы, реплицируется в обеих частях, поэтому и пользователь, и служба могут совместно использовать ее.
6. Клиент отправляет ST службе в сообщении AP-REQ (внутри прикладного протокола). Служба расшифровывает ST и получает ключ сеанса службы и PAC. Служба будет использовать информацию безопасности PAC о клиенте, чтобы определить, есть ли у пользователя доступ к его ресурсам.
7. Если служба хочет проверить PAC, она может использовать протокол Netlogon, чтобы запросить у контроллера домена проверку подписи PAC с помощью KERB_VERIFY_PAC_REQUEST (необязательно).
8. Сервер проверит PAC и ответит кодом, указывающим, что PAC правильный (необязательно).
9. Наконец, если этого требует клиент, служба должна аутентифицировать себя, отвечая на сообщение AP-REQ сообщением AP-REP и используя сеансовый ключ в качестве доказательства того, что служба может расшифровать ST и, следовательно, это настоящий сервис, а не подделка (необязательно).

Kerberos, в отличие от NTLM, имеет сообщения, которые не включены в другой протокол приложения. Так обстоит дело с AS-REQ и TGS-REQ, которые отправляются непосредственно в DC.

Службы Kerberos

Контроллер домена прослушивает Kerberos на портах 88/TCP и 88/UDP.

Порты Kerberos

Помимо KDC, в Kerberos есть еще одна служба, kpasswd, позволяющая менять пароли пользователей в домене. kpasswd можно найти в портах 464/TCP и 464/UDP контроллеров домена. Его можно использовать с утилитой ksetup, с экрана CTRL+ALT+DEL «Изменить пароль» или с помощью Rubeus changepw.

Утилита смены пароля использует kpasswd

Ключи Kerberos

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

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

• RC4-HMAC: ключ, используемый для RC4, представляет собой NT-хэш пользователя;
• AES128-CTS-HMAC-SHA1-96: Ключ, используемый для AES128, представляет собой хэш из 16 байтов, полученный из пароля пользователя (а также домена и имени пользователя);
• AES256-CTS-HMAC-SHA1-96: ключ, используемый для AES256, представляет собой хэш из 32 байтов, полученный из пароля пользователя (а также домена и имени пользователя);
• DES-CBC-MD5: этот ключ устарел, но ключ по-прежнему хранится в базе данных домена для пользователей.

В зависимости от выбранного алгоритма Kerberos использует нужный ключ, поэтому используя термин «ключ Kerberos» имеется в виду любой из возможных ключей, согласованных с помощью Kerberos. В Active Directory рекомендуется использовать AES256.

Базовые атаки Kerberos

Теперь, когда мы знаем основы Kerberos, давайте объясним некоторые атаки Kerberos.

Брутфорс Kerberos

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

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

• KDC_ERR_PREAUTH_FAILED — неверный пароль;
• KDC_ERR_C_PRINCIPAL_UNKNOWN — недопустимое имя пользователя;
• KDC_ERR_WRONG_REALM — неверный домен;
• KDC_ERR_CLIENT_REVOKED — отключенный/заблокированный пользователь.

Проверяя сообщения об ошибках, вы можете не только проверить действительные учетные данные, но также перечислить учетные записи пользователей и узнать, не заблокировала ли ваша атака какую-либо учетную запись. Будьте осторожны, запуская такие атаки!

Еще одна вещь, которую следует иметь в виду, это то, что ошибки аутентификации регистрируются не с обычным событием ошибки входа в систему (код: 4625), а с ошибкой предварительной аутентификации Kerberos (код: 4771), которая поу молчанию не регистрируется.

Вы можете использовать Rubeus brute, kerbrute (Go), kerbrute (Python) или cerbero, чтобы запустить атаку грубой силы Kerberos.

$ python kerbrute.py -domain contoso.local -users users.txt -passwords passwords.txt -dc-ip 192.168.100.2
Impacket v0.9.22 — Copyright 2020 SecureAuth Corporation

Атака грубой силы Kerberos с помощью kerbrute.py

Kerberoasting

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

Большинство сервисов регистрируются в учетных записях компьютеров, которые имеют автоматически генерируемые пароли из 120 символов, которые меняются каждый месяц, поэтому взломать их ST невозможно.

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

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

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

(&(samAccountType=805306368)(servicePrincipalName=*))

В частности, чтобы получить ST для взлома, вы можете использовать сценарий impacket GetUserSPNs.py, команду Rubeus kerberoast или сценарий Invoke-Kerberoast.ps1.

Kerberoast с GetUserSPNs.py

Когда у вас есть ST, вы можете попытаться взломать их с помощью hashcat. Чтобы их легко взломать, ST следует запрашивать в зашифрованном виде с помощью RC4, однако запросы могут быть обнаружены как обычный трафик (например, Microsoft ATA ), поскольку для большинства запросов требуется шифрование AES256.

Также возможно выполнять Kerberoasting, не зная SPN служб. Помните, что вы можете запросить билет Kerberos для разных субъектов в домене, включая как службы, так и пользователей.

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

ST, полученный для пользователя в качестве целевого основного имени, также шифруется с помощью ключа пользователя, поэтому его можно использовать в Kerberoasting. Это также может быть полезно для перебора пользователей, поддерживающих kerberoaste, в случае, если вы не можете перечислить их через LDAP, поскольку основное имя пользователя без SPN не может быть разрешено.

Этот метод используется сценарием impacket GetUserSPNs.py. Его также можно использовать с командой Rubeus kerberoast с флагом /enterprise и командой cerbero kerberoast.

Кроме того, если у вас есть разрешение Validated-SPN для учетной записи пользователя, вы можете добавить имена участников-служб к этой учетной записи, сделав ее поддерживающей Kerberoasteable. Таким образом, вы можете запросить ST для этой службы учетной записи и попытаться взломать ее. По умолчанию учетные записи не имеют разрешений Validated-SPN на самих себя.

ASREProast

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

Однако в редких случаях предварительная аутентификация Kerberos отключается для учетной записи путем установки флага DONT_REQUIRE_PREAUTH. Таким образом, любой может выдать себя за эти учетные записи, отправив сообщение AS-REQ, и ответ AS-REP будет возвращен из KDC, что данные зашифрованы с помощью пользовательского ключа Kerberos.

Определение сообщения AS-REP

Вы не можете получить доступ к данным AS-REP напрямую, поскольку они зашифрованы с помощью ключа пользователя (который получен из пароля пользователя), но вы можете попытаться взломать офлайн-атаку, чтобы узнать пароль пользователя.

Атака ASREProast состоит в том, чтобы идентифицировать пользователей без предварительной аутентификации Kerberos и отправить AS-REQ от их имени, чтобы получить часть данных, зашифрованных с помощью ключа пользователя в сообщении AS-REP. После получения выполняется атака взлома в автономном режиме с целью восстановления пароля пользователя. Фильтр LDAP для пользователей без предварительной аутентификации Kerberos:

(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=4194304))

Вы можете использовать такие инструменты, как сценарий impacket GetNPUsers.py, команду asreproast Rubeus или сценарий ASREEProast.ps1 для извлечения зашифрованных данных AS-REP.

Если у вас есть пользователь TGT, вы можете взломать его с помощью hashcat. Вы можете запросить AS-REP с шифрованием RC4, чтобы его было легче взломать.

Pass the Key/Over Pass the Hash

Как вы могли заметить, для запроса TGT пользователю нужно использовать не пароль, а ключ Kerberos. Следовательно, если злоумышленник может украсть ключ Kerberos (хэш NT или ключи AES), его можно использовать для запроса TGT от имени пользователя без необходимости знать пароль пользователя.

Обычно в Windows ключи Kerberos кэшируются в процессе lsass, и их можно получить с помощью команды mimikatz sekurlsa::ekeys. Также вы можете создать дамп процесса lsass с помощью таких инструментов, как procdump, sqldumper или других, и извлечь ключи в автономном режиме с помощью mimikatz.

В случае Linux ключи Kerberos хранятся в файлах keytab, чтобы их можно было использовать для службы Kerberos. Файл keytab обычно можно найти в /etc/krb5.keytab, или в значении, указанном переменными среды KRB5_KTNAME или KRB5_CLIENT_KTNAME, или указанном в файле конфигурации Kerberos в /etc/krb5.conf.

После этого вы можете скопировать его на свой локальный компьютер и/или получить список его ключей с помощью klist (Kerberos MIT) или cerbero.

Чтение keytab с помощью klist

Получив ключи Kerberos, вы можете запросить TGT в Windows с помощью команды Rubeus asktgt.

На компьютере с Linux вы можете использовать утилиты MIT Kerberos011, чтобы создать keytab с ключом и запросить TGT, или использовать ключ напрямую с помощью скрипта impacket getTGT.py или команды cerbero ask.

Pass-The-Key с cerbero

Билеты Kerberos имеют два формата: ccache и krb. Первый используется машинами Linux для хранения билетов (обычно в файлах). Формат krb используется в Windows для хранения билетов в памяти lsass, а также является форматом для передачи билетов по сети. Вы можете конвертировать билеты из одного формата в другой с помощью скрипта ticket_converter.py или команды cerbero convert.

Конвертирование билета с помощью ticket_converter.py

Кроме того, вы можете вычислить ключи Kerberos из пароля пользователя с помощью команды cerbero hash. Также ключи AES можно рассчитать с помощью Get-KerberosAESKey.ps1 или хэша NT с помощью нескольких строк Python.

Вычисление ключей Kerberos с помощью cerbero

Pass the Ticket

Техника Pass the Ticket заключается в краже билета и связанного сеансового ключа и использовании их для олицетворения пользователя для доступа к ресурсам или услугам. Можно использовать как TGT, так и ST, но TGT предпочтительнее, поскольку они позволяют получить доступ к любой службе (используя ее для запроса ST) от имени пользователя, тогда как ST ограничены только одной службой (или несколькими, если SPN изменен на другой сервис того же пользователя).

В Windows билеты можно найти в памяти процесса lsass и извлечь их с помощью команды mimikatz sekurlsa::tickets или команды дампа Rubeus. Другая возможность состоит в том, чтобы сбросить процесс lsass с помощью таких инструментов, как procdump, sqldumper или других, и извлечь билеты в автономном режиме с помощью mimikatz или pypykatz. Эти команды извлекают билеты в формате krb.

Сброс памяти lsass с помощью procdump

Получение билетов из дампа lsass с помощью pypykatz

С другой стороны, на Linux-машинах, входящих в домен, билеты хранятся по-другому. Билеты обычно можно найти по умолчанию в каталоге /tmp в файлах с форматом, krb5cc_%{uid}, где uid — это uid пользователя. Чтобы получить билеты, просто скопируйте файлы (если у вас есть права). Однако также возможно, что билеты хранятся в ключах ядра Linux, а не в файлах, но вы можете получить их с помощью tickey.

Чтобы быть уверенным, где билеты хранятся на компьютере с Linux, вы можете проверить файл конфигурации Kerberos /etc/krb5.conf.

Чтобы использовать билеты на компьютере с Windows, вы должны внедрить их в процесс lsass, что можно сделать с помощью команды mimikatz kerberos::ptt или команды Rubeus ptt. Эти утилиты читают билеты в формате krb.

Внедрение TGT в текущую сессию Windows

После внедрения билетов в сеанс вы можете использовать любой инструмент для выполнения действий, выдавая себя за пользователя по сети, например psexec.

В Linux вы можете использовать билеты с утилитами impacket, указав переменную среды KRB5CCNAME на файл билета. Затем используйте утилиты c параметрами impacket -k -no-pass. Здесь нужны билеты в формате ccache.

Чтобы преобразовать билеты между форматами krb (Windows) и ccache (Linux), вы можете использовать скрипт ticket_converter.py или команду cerbero convert.

Golden/Silver ticket

В Active Directory TGT Kerberos шифруются с помощью ключей учетной записи krbtgt. Если знать ключи можно создать пользовательские TGT, известные как Golden Tickets.

Чтобы получить ключи krbtgt, вам необходимо получить доступ к базе данных Active Directory. Вы можете сделать это, выполнив удаленную атаку dcsync с помощью команды mimikatz lsadump::dsync или скрипта impacket secretsdump.py, либо локально выгрузив файл NTDS.dit с помощью ntdsutil или vssadmin.

Ключи krbtgt, полученные с помощью secretsdump.py

Точно так же можно создать пользовательский ST для службы, известной как Silver Ticket, если мы получим ключи Kerberos пользователя службы. Ключи для пользователя службы можно получить, изучив процесс lsass на машинах домена, на которых пользователь вошел в систему, выполнив Kerberoast, создав дамп базы данных Active Directory и т. д.

И в Golden Ticket, и в Silver Ticket билете можно создать билет для любого пользователя в домене и даже для несуществующего. Более того, мы можем дать высокие привилегии пользователю билета, изменив группы пользователей PAC и включив, например, группу «Администраторы домена», чтобы иметь привилегии администраторов домена.

Кроме того, мы должны подписать PAC билета с помощью ключа krbtgt, но это невозможно сделать для Silver Ticket, поскольку мы просто знаем ключ службы пользователя, здесь используется поддельная подпись, поскольку для службы довольно странно проверять с помощью контроллера домена подпись ПАК.

Для создания Golden Ticket и Silver ticket билетов вы можете использовать команду mimikatz kerberos::golden или скрипт impacket ticketer.py. Затем вы можете использовать их как любой билет. Если можете, используйте ключ AES256, чтобы избежать обнаружения такими решениями, как ATA.

Создаем Golden Ticket с помощью ticketer.py

После создания Golden Ticket дают вам права, указанные в билете, позволяя вам выдавать себя за любого пользователя, даже несуществующего, в домене и получать доступ к любой службе в домене. Следует иметь в виду, что после создания ЗGolden Ticket его необходимо использовать в течение 20 минут, в противном случае KDC проверит информацию PAC, чтобы убедиться, что она верна.

Случаем использования Silver Ticket является доступ к компьютеру в качестве администратора, когда у вас есть пароль учетной записи домена компьютера. У вас нет прав администратора на компьютере с его учетной записью домена компьютера, но вы можете использовать его пароль для создания Silver Ticket для его служб и выдачи себя за администратора.

Таким образом, Silver Tickets можно использовать для доступа к сервису одного пользователя, а Golden Ticket — для доступа к любому сервису в домене.

Kerberos между доменами

Golden Ticket также можно использовать для компрометации всего леса. Но перед этим давайте рассмотрим, как работает Kerberos в доверенных доменах.

Ранее мы видел, что пользователь домена может получить доступ к службам в доверительных доменах (используя входящие или двунаправленные доверительные отношения ). Процесс доступа к ресурсам внешнего домена также требует аутентификации, которую может обеспечить Kerberos.

Однако KDC (DC) может выдавать ST только для служб в своем домене, так как же работает Kerberos между доменами? Что ж, необходимо запросить ST на сервер DC внешнего домена, а для этого нам потребуется TGT для этого сервера. TGT для внешнего KDC, известного как межобластной TGT, выдается нашим KDC, когда мы запрашиваем ST для службы в другом домене. Шаги следующие:

Kerberos между доменами

• Клиент/пользователь из домена foo.com использует SPNEGO для согласования проверки подлинности Kerberos с желаемой службой, в данном случае HTTP\srvbar (веб-сервер на сервере srvbar) из домена bar.domain;
• Клиент запрашивает ST, используя свой TGT foo.com, для HTTP\srvbar в свой KDC, отправляя сообщение TGS-REQ;
• KDC определяет, что эта служба находится в доверенном домене bar.com. Таким образом, KDC foo.com создает TGT для bar.com, используя в качестве ключа шифрования (и подписи PAC) ключ межобластного доверия (секретный ключ, совместно используемый обеими сторонами доверия). Затем KDC возвращает TGT bar.com в сообщении TGS-REP. PAC, включенный в TGT bar.com, является копией TGT PAC foo.com;
• Клиент использует TGT bar.com, чтобы запросить HTTP\srvbar ST у KDC bar.com, отправив сообщение TGS-REQ. KDC bar.com проверяет билет, расшифровывая его с помощью межобластного ключа доверия.
• Затем он создает ST для HTTP\srvbar для клиента. Когда создается новый ST, PAC из TGT копируется и при необходимости фильтруется. Обычно удаляются лишние SID, не входящие в лес доверенного домена;
• Наконец, клиент использует ST для аутентификации в службе HTTP\srvbar.

Любопытно, что обычно TGT между областями шифруются с использованием алгоритма RC4 вместо AES256.

Атака на историю SID

Что интересно в этом процессе, так это то, как PAC копируется между заявками при междоменном взаимодействии. Такое поведение может позволить злоумышленнику, способному создать Golden Ticket для домена, скомпрометировать весь лес.

Как мы видели ранее, в PAC есть поле для включения дополнительных SID, которые идентифицируют специальные объекты. Это поле обычно используется для включения тех SID, которые хранятся в атрибуте SIDHistory.

История SID используется для миграции. Когда пользователь мигрирует из домена в другой, привилегии пользователя сбрасываются, создается новый SID, пользователь добавляется в новые группы и т. д. Однако SID из групп, к которым пользователь принадлежит в старом домене, сохраняются. в атрибуте История SID.

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

Однако дополнительные SID могут быть опущены (не скопированы в ST PAC) в соответствии с политикой фильтрации SID. Как правило, домены разрешают SID из других доменов в лесу (по умолчанию), но отбрасывают дополнительные SID из внешних лесов в соответствии с правилом ForestSpecific, поскольку лес является границей безопасности Active Directory. Кроме того, домены одного и того же леса также могут быть помещены в карантин, что позволит удалить лишние SID с помощью политики QuarantinedWithinForest.

Напротив, история SID может быть включена в доверии между доменами разных лесов с некоторыми ограничениями. Допускаются группы с SID целевого (доверяющего) леса, у которых RID выше 1000. Следовательно, административные группы, такие как «Администраторы домена» (RID = 512), чей RID ниже 1000, фильтруются, но группы с более высоким RID, принадлежащие этим административным группам (становятся также административными группами), такие как административные группы Exchange.

Затем, если история SID редактируется, могут быть введены административные привилегии для других доменов. Например, если вы внедрите SID Enterprise Admins в историю SID пользователя, то пользователь может иметь административные привилегии во всем лесу. Атрибут SID History можно редактировать непосредственно в базе данных Active Directory с помощью команды mimikatz misc::addsid.

Однако, как мы уже говорили ранее, история SID копируется в PAC TGT, поэтому, если мы можем создать Golden Ticket, мы можем внедрить нужные SID истории непосредственно в атрибут дополнительных SID PAC. Затем, когда мы используем этот билет «Golder», его PAC копируется в межобластной TGT. Впоследствии, при использовании этого межобластного TGT для получения ST для службы во внешнем домене, если этот домен находится в том же лесу, привилегированные SID могут быть скопированы в ST PAC, что дает нам привилегии, которые у нас были изначально вводится в билет Golder.

Интересным SID для внедрения является один из «Администраторов предприятия», эта группа существует только в корневом домене леса и по умолчанию добавляется как член всех групп «Администраторы домена» всех доменов в лесу.

На самом деле, если вы скомпрометируете корневой лес домена и создадите Golden Ticket, который включает группу «Администраторы предприятия» (чей RID равен 519 и включен по умолчанию для impacket и mimikatz), вам не нужно создавать Golden Ticket с дополнительными SID, поскольку у вас уже есть разрешения на управление всем лесом, даже доменами, помещенными в карантин (поскольку нет дополнительных SID для фильтрации). Добавление «Enterprise Admins» к дополнительным SID необходимо только в том случае, если вы скомпрометировали некорневой домен и хотите скомпрометировать другой домен леса, за исключением доменов, помещенных в карантин, которые фильтруют дополнительные SID.

Pass-The-Ticket с корпоративными администраторами в дополнительных SID

Тем не менее, для выполнения атаки dcsync в другом домене, возможно, с использованием групп SID «Контроллеры домена предприятия» (S-1-5-9) и «Контроллеры домена» (S-1-5-21-domain-516).

Для создания Golden Ticket вы можете использовать команду mimikatz kerberos::golden или скрипт impacket ticketer.py, аналогичный созданию Golden Ticket, но с добавлением дополнительных SID. Если можете, используйте ключ AES256, чтобы избежать обнаружения такими решениями, как ATA.

Межрегиональный TGT

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

Чтобы получить ключ доверия между областями, обычно вам нужно сделать дамп базы данных домена. Более того, есть одна ситуация, когда через Kerberoast можно было получить trust-key.

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

Наконец, после получения ключа доверия для создания билета между областями можно использовать команду mimikatz kerberos::golden или скрипт impacket ticketer.py. Затем вы можете использовать его как любой билет. Билеты между трастами шифруются с помощью ключа RC4, то есть хэша NT доверительной учетной записи.

Делегация Kerberos

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

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

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

Для выполнения делегирования Kerberos в Active Directory существует два подхода:

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

Поговорим о том, как работает делегирование Kerberos. Но сначала давайте рассмотрим меры против делегирования, которые мешают делегированию работать.

Меры против делегирования Kerberos

Существует два механизма, позволяющих избежать делегирования определенной учетной записи пользователя (олицетворения в Kerberos):

• установка флага NOT_DELEGATED в атрибуте UserAccountControl учетной записи пользователя;
• добавление пользователя в группу защищенных пользователей.

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

Фильтр LDAP для получения учетных записей, защищенных от делегирования

Чтобы найти защищенные делегированные учетные записи, вы можете использовать такие инструменты, как Powerview, модуль Powershell ActiveDirectory или ldapsearch.

Неограниченное делегирование Kerberos

При неограниченном делегировании Kerberos служба может олицетворять пользователя клиента, поскольку при этом службе отправляется собственный TGT. Затем служба может использовать TGT пользователя (без каких-либо ограничений) для запроса новых ЗБ для других служб от имени клиента.

KDC устанавливает флаг OK-AS-DELEGATE в ST для любой службы, владелец которой — пользователь службы, имеющей установленный флаг UserAccountControl TRUSTED_FOR_DELEGATION. Проверяя флаги OK-AS-DELEGATE и FORWARDABLE, клиент знает, должен ли он запрашивать отправку TGT целевой службе, чтобы разрешить неограниченное делегирование.

В случае клиентов, являющихся членами группы «Защищенные пользователи» или имеющих установленный флаг UserAccountControl NOT_DELEGATED, когда флаг FORWARDABLE в протоколе ST.

Кроме того, для установки флага TRUSTED_FOR_DELEGATION в учетной записи пользователя требуется SeEnableDelegationPrivilege.

Давайте рассмотрим пример:

Неограниченный процесс делегирования

• клиент запрашивает ST для службы HTTP\websrv (веб-служба на сервере websrv), используя свой TGT. Служба HTTP\websrv принадлежит пользователю websrv$ (помните, что имена пользователей [[#computer-accounts][computer account]] заканчиваются на =$=);
• KDC проверяет, установлен ли флаг TRUSTED_FOR_DELEGATION для websrv$. Следовательно, KDC возвращает клиенту ST для HTTP\websrv с флагом OK-AS- DELEGATE (и FORWARDABLE );
• клиент проверяет флаг OK-AS-DELEGATE, указывающий, что служба использует делегирование, поэтому он решает запросить у KDC сообщение FORWARDED TGT для отправки службе;
• KDC возвращает TGT с установленным флагом FORWARDED;
• клиент отправляет ST с включенным FORWARDED TGT в websrv, чтобы получить доступ к службе HTTP\websrv;
• Иногда HTTP\websrv должен олицетворять клиента для доступа к службе базы данных, расположенной в dbsrv. Поэтому веб-служба запрашивает ST для MSSQLSvc\dbsrv от имени клиента, используя полученный клиентский TGT;
• KDC возвращает клиенту ST для доступа к службе MSSQLSvc\dbsrv;
• наконец, служба HTTP\websrv использует ST для доступа к MSSQLSvc\dbsrv, выдавая себя за клиента.

Вероятно, наиболее важным фактом, который следует иметь в виду, является то, что любой ST, который будет отправлен на HTTP\websrv, будет содержать TGT от клиента. Поэтому, если кто-то скомпрометирует сервер websrv, он сможет получить все эти TGT и использовать их для олицетворения любого из клиентов с помощью атаки Pass the Ticket.

Для получения билетов с компьютера Windows (включая делегированные TGT) можно использовать команду mimikatz sekurlsa::tickets или команду дампа Rubeus. Другой подход заключается в сбросе процесса lsass с помощью таких инструментов, как procdump, sqldumper или других, и извлечении билетов в автономном режиме с помощью mimikatz или pypykatz.

Но помните, что TGT включены во все ЗБ для служб учетной записи, для которой установлен флаг UserAccountControl TRUSTED_FOR_DELEGATION. Поэтому в предыдущем примере, где учетная запись компьютера websrv$ была владельцем службы HTTP\websrv, любой ST, запрошенный для любой другой службы websrv$, такой как, например, CIFS\websrv (для доступа к общим ресурсам SMB ), также будет содержать клиент TGT.

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

(UserAccountControl:1.2.840.113556.1.4.803:=524288)

Чтобы найти учетные записи с неограниченным делегированием, вы можете использовать такие инструменты, как Powerview, сценарий impacket findDelegation.py, модуль Powershell ActiveDirectory или ldapsearch.

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

Кроме того, вы можете получить TGT учетной записи компьютера, заставив его подключиться к вашему серверу с ошибкой принтера. Ошибка принтера использует вызов RPC интерфейса RPRN RPC, который позволяет любым « аутентифицированным пользователям » указать целевому компьютеру сервер для подключения через SMB.

Чтобы вызвать ошибку принтера, вы можете использовать инструмент SpoolSample или скрипт printerbug.py. Вы должны передать имя хоста в качестве аргумента, чтобы целевая машина могла использовать Kerberos. Если вы предоставите IP-адрес, то для аутентификации будет использоваться NTLM, и делегирование выполняться не будет. Кроме того, вы можете сканировать компьютеры, на которых включена служба спулинга (по умолчанию она включена), с помощью скрипта SpoolerScan.ps1.

Отслеживать появление TGT можно с помощью команды Rubeus.

Для этого нам нужно изменить SPN учетной записи неограниченного делегирования, которую мы скомпрометировали. Плохая новость заключается в том, что для этого нам нужно разрешение Validated-SPN, которое по умолчанию не предоставляется собственной учетной записи. Однако в случае учетных записей компьютеров они могут добавлять имена участников-служб по умолчанию, соответствующие их именам хостов, которые, к счастью, включают имена хостов, добавленные в msDS-AdditionalDnsHostName, которые могут быть изменены самой учетной записью. Затем мы можем добавить в качестве нового имени хоста имя хоста нашей машины и создать таким образом имена участников-служб, которые указывают на нашу машину. Мы можем сделать это с помощью addspn.py. Также мы можем добавить SPN с помощью утилиты setspn.

Чтобы имя хоста указывало на нашу машину, мы можем создать пользовательскую запись ADIDNS с помощью Powermad или dnstool.py.

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

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

Неограниченное делегирование Kerberos между лесами

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

В следующей последовательности описываются сообщения Kerberos, участвующие в атаке с ошибкой принтера между доменами в случае включения делегирования TGT. Злоумышленник отправляет вызов RPC от barsrv к foosrv, чтобы указать этому последнему подключиться к udbarsrv, который имеет неограниченное делегирование. После этого TGT foosrv$ (пользователь домена foosrv) может быть получен в udbarsrv.

Шаги следующие:

Сообщения Kerberos в ошибке принтера в разных доменах (делегирование включено)

• barsrv (из домена bar.com) отправляет TGS-REQ в KDC bar.com с запросом ST для службы SMB (cifs) foosrv (поскольку ошибка принтера использует RPC через SMB);
• KDC bar.com проверяет, находится ли запрошенная служба в доверенном домене foo.com и выдает TGT barsrv$ для этого домена;
• Затем barsrv использует свой TGT foo.com, чтобы запросить у KDC ST foo.com для службы cifs/foosrv;
• Затем KDC foo.com возвращает ST для barsrv$ для cifs/foosrv;
• Затем barsrv аутентифицируется с помощью foosrv и выполняет вызов ошибки принтера RpcRemoteFindFirstPrinterChangeNotification, указывая foosrv на подключение к серверу udbarsrv (домен bar.com) с помощью SMB;
• foosrv запрашивает у KDC foo.com ST для службы SMB udbarsrv (cifs/udbarsrv);
• KDC проверяет, находится ли запрошенная служба foo.com в доверенном домене bar.com и выдает TGT для foosrv$ для этого домена. Этот TGT включает флаг OK-AS-DELEGATE, который указывает, что делегирование TGT включено для bar.com от foo.com;
• Затем foosrv использует новый TGT, чтобы запросить у KDC bar.com ST для cifs/udbarsrv;
• KDC bar.com возвращает ST для foosrv$ для cifs/udbarsrv. Для этого ST установлен флаг OK-AS-DELEGATE, указывающий, что службы используют неограниченное делегирование;
• Таким образом, foosrv проверяет, что cifs/udbarsrv использует делегирование и разрешено делегирование bar.com, поэтому запрашивает у KDC foo.com перенаправленный TGT;
• KDC foo.com возвращает TGT для пользователя foosrv$ на сервер foosrv;
• Наконец, foosrv подключается к udbarsrv и выполняет аутентификацию, включая собственный TGT. Теперь злоумышленник на этой машине может вспомнить TGT и использовать его для доступа к foosrv.

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

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

Практическая подготовка

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