RFC по теме
Неполный список связанных с Kerberos RFC.
| RFC | Описание/статус |
| RFC 4120 | The Kerberos Network Authentication Service (V5). Служба сетевой аутентификации Kerberos (версия 5). C. Neuman, T. Yu, S. Hartman, K. Raeburn. Июль 2005 г. Отменяет RFC1510. Обновлён в RFC4537, RFC5021, RFC5896, RFC6111, RFC6112, RFC6113. Статус: PROPOSED STANDARD. |
| RFC 4121 | The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2. Механизм общего программного интерфейса систем безопасности (GSS-API) Kerberos версии 5: версия 2. L. Zhu, K. Jaganathan, S. Hartman. Июль 2005 г. Обновляет RFC1964. Обновлён в RFC6112. Статус: PROPOSED STANDARD. |
| RFC 6111 | Additional Kerberos Naming Constraints. Дополнительные ограничения именования в Kerberos. L. Zhu. Апрель 2011 г. Обновляет RFC4120. Статус: PROPOSED STANDARD. |
| RFC 6112 | Anonymity Support for Kerberos. Поддержка анонимности для Kerberos. L. Zhu, P. Leach, S. Hartman. Апрель 2011 г. Обновляет RFC4120, RFC4121, RFC4556. Статус: PROPOSED STANDARD. |
| RFC 6113 | A Generalized Framework for Kerberos Pre-Authentication. Обобщенный механизм предварительной аутентификации для Kerberos. S. Hartman, L. Zhu. Апрель 2011 г. Обновляет RFC4120. Статус: PROPOSED STANDARD. |
| RFC 6251 | Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol. Использование Kerberos версии 5 поверх протокола TLS. S. Josefsson. Май 2011 г. Статус: INFORMATIONAL. |
Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.
Нашли ошибку в переводе? Сообщите переводчикам!
S4U2Proxy
OK, what is S4U2Proxy?
S4U2Proxy is an extension that allows a service to use the TGS sent by the client user to order from the KDC a new TGS for a third service, in behalf of the client user.
Please, can you give me an example of S4U2Proxy in Constrained Delegation?
S4U2Proxy Constrained Delegation
In order to clarify the use of S4U2Proxy, the next example is shown where delegation is resolved by applying Constrained Delegation (for sake of clarity it is assumed that User1 is not protected against delegation by Protected Users or NotDelegated, otherwise the delegation would fail): In this example:
- User1 sends the TGS to ServiceZ.
- ServiceZ, owned by UserZ, uses this TGS to ask the KDC for a TGS for ServiceX on behalf of User1.
- The KDC checks:
- If ServiceX is listed in UserZ msDS-AllowedToDelegateTo (Yes).
- If the sent TGS is forwardable (Yes). Constrained Delegation is applied.
- The KDC returns a TGS to ServiceZ to interact with ServiceX on behalf of User1.
- ServiceZ uses the new TGS to interact with ServiceX, by impersonating User1.
Please, can you give me an example of S4U2Proxy in RBCD?
In order to clarify the use of S4U2Proxy, the next example is shown where delegation is resolved by applying RCBD (for sake of clarity it is assumed that User1 is not protected against delegation by Protected Users or NotDelegated, otherwise the delegation would fail):
S4U2Proxy RBCD
In this example:
- User1 sends the TGS to ServiceZ.
- ServiceZ, owned by UserZ, uses this TGS to ask the KDC for a TGS for ServiceX on behalf of User1.
- The KDC checks:
- If ServiceX is listed in UserZ msDS-AllowedToDelegateTo (No). Constrained Delegation cannot be applied.
- If UserZ is listed in msDS-AllowedToActOnBehalfOfOtherIdentity of UserX, the owner of ServiceX (Yes). RBCD can be applied.
- The KDC returns a TGS to ServiceZ to interact with ServiceX on behalf of User1.
- ServiceZ uses the new TGS to interact with ServiceX, by impersonating User1.
OK, anything else?
- The service name is written in the cleartext part of the ticket, which anyone can modify.
- All the services of the same user share the same Kerberos key, therefore any service can decrypt correctly a TGS for another service of the same user.
This trick can be used to bypass the white list (msDS-AllowedToDelegateTo) of services used by Constrained Delegation.
OK, example?
In this example:
- User1 sends the TGS to ServiceZ.
- ServiceZ, owned by UserZ, uses this TGS to ask the KDC for a TGS for ServiceX, owned by UserXY, on behalf of User1.
- The KDC checks:
- If ServiceX is in UserZ msDS-AllowedToDelegateTo (No). Constrained Delegation cannot be applied.
- If UserZ is in UserXY msDS-AllowedToActOnBehalfOfOtherIdentity (No). RBCD cannot be applied.
- The KDC rejects the request made by ServiceZ.
- ServiceZ asks the KDC , on behalf of User1, for a TGS for ServiceY, another service owned by UserXY.
- The KDC checks:
- If ServiceY is in msDS-AllowedToDelegateTo of UserZ (Yes).
- If the sent TGS is forwardable (Yes). Constrained Delegation can be applied.
- The KDC returns a TGS to ServiceZ to interact with ServiceY on behalf of User1.
- ServiceZ (UserZ) changes the target service of the TGS from ServiceY to ServiceX.
- ServiceZ uses the modified TGS to interact with ServiceX, by impersonating User1.
It should be noted that this is not the normal course of action of a legitimate service, since no service is going to edit the service name of the TGS in order to contact with another service. Actually, this behavior is more typical of an attacker, which tries to use this trick to bypass the restriction imposed by the KDC.
Configuring the BIG-IP APM for Kerberos Delegation Authentication
Now that we have configured an active directory account to support delegation we will begin the Kerberos configuration on the BIG-IP. To start we will create an SSO configuration using the configuration items below. If not defined below, leave the default setting.
- Navigate to Access > Single Sign-On > Kerberos > Create
- Name: KCD_SSO_Profile
- Username Source: session.ldap.last.attr.sAMAccountName
- Kerberos Realm: «DEMO.LAB» in all uppercase
- KDC: demo-dc.demo.lab
Note: Defining a KDC is not a requirement as DNS will most often identify the appropriate KDC. However, I will configure it in this demo.
- Account Name: host/kcd.demo.lab
- Account Password: Password
- Confirm Account Password: Repeat Password
- Click Finish
Note: In order to support AES Kerberos Encryption, the account name must be in SPN format as shown in the screenshot above. If it is not, you will receive the following error.
«Kerberos: can’t decrypt S4U2Self ticket for user [email protected] — Decrypt integrity check failed (-1765328353).»
Configuring a LDAP AAA Resource
- Navigate to Access > Authentication > LDAP and select Create
- Name: Demo_LDAP_AAA
- Server Connection: Direct
- Base Port: 389
- Admin DN: CN=admin,CN=Users,DC=demo,DC=lab
- Leave all other settings at their defaults and select Finished
Делегирование KERBEROS
Делегирование используется, когда учетная запись сервера или службы должна выдавать себя за другого пользователя. Самый простой пример, когда веб-сервер олицетворяет пользователей при доступе к внутренним базам данных, обеспечивая доступ к данным.
Существует три вида делегирования:
-
Kerberos Unconstrained Delegation (KUD) — Неограниченное делегирование.
-
Kerberos Constrained Delegation (KCD) — Ограниченное делегирование.
-
Resource-based Constrained Delegation (RBCD) — Делегирование на основе ресурсов.
Мы с вами будем разбирать два последних вида. Про KUD можно почитать тут.
Итак, Kerberos Constrained Delegation или сокращенно KCD.
KCD сокращает набор служб или ресурсов, к которым может подключаться конкретный сервер или приложение при олицетворении другого пользователя. Таким образом, мы можем выдавать себя за другого пользователя, но только на определенной машине и на определенной ее службе.
Схема ограниченного делегирования kerberosНастройка ограниченного делегирования в Active Directory Users and Computers
Зная хэш машинной УЗ CLIENT2, мы можем выдать себя за любого пользователя в домене, но пойти можем только к службе cifs на машине СLIENT1.
С УЗ юзера user1 все то же самое, можем ходить от имени любого другого пользователя, но только на cifs/CLIENT1 и cifs/ADCS.
Resource-based-constrained Delegation (RBCD)
Этот тип делегирования работает точно так же, как и KCD, но наоборот.
Схема ограниченного делегирования на основе ресурсов
Другими словами, если в KCD устанавливалось так называемое исходящее доверие, то в RBCD устанавливается входящее. Один ресурс доверяет другому ресурсу, только набор служб уже неограничен.
За RBCD отвечает атрибут msDS-AllowedToActOnBehalfOfOtherIdentity. Этот атрибут используется для проверки доступа, чтобы определить, есть ли у отправителя запроса разрешение действовать от имени других учеток для служб, работающих под этой учетной записью.
Чтобы эксплуатировать RBCD в своих целях, у нас должна быть возможность создавать компьютеры внутри домена (это можно сделать благодаря атрибуту MS-DS-Machine-Account-Quota, который по умолчанию равен 10). Также нам необходимо иметь Generic Write/Generic ALL права на нашу цель, чтобы у нас была возможность писать в атрибут msDS-AllowedToActOnBehalfOfOtherIdentity.
Совсем недавно появилась возможность сделать это с помощью пользовательской учетки, почитать тут и тут. Советую пробежаться по этим статьям, так как к этому мы еще вернемся.
В настоящее время настроить RBCD через GUI не представляется возможным, но все можно сделать с помощью модуля PowerView:
или Linux:
# krb5.ini
Файл не является обязательным, но может влиять на поведение процесса аутентификации.
На сервере и клиентских машинах Windows он может быть расположен в ${windir}/krb5.ini.
Пример файла krb5.ini
.test.com = TEST.COM
test.com = TEST.COM
default_realm = TEST.COM
kdc_timesync = 1
ccache_type = 4
ticket_lifetime = 600
default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
kdc = CONSOLE
TEST.COM = {
kdc = 192.168.0.1
kdc = 192.168.1.1
default_domain = test.com
}
autologin = true
forward = true
forwardable = true
encrypt = true
Настройка сервера
Данная инструкция сделана в окружении Windows Server2008R2 (контроллер домена), Windows Server2012R2 (RunaWFE Server), Windows7 (RunaWFE client).
В данном разделе регистр может иметь значение, хотя опытным путём было выяснено что логин пользователя, название компьютера сервера и SPN не являются регистрозависимыми.
Constrained Delegation and RBCD
In addition to Unconstrained, there are 2 more kinds of delegation:
- Constrained Delegation
- RBCD (Resource Based Constrained Delegation) (Introduced in Windows Server 2012)
In any of these types, the delegation is constrained to only some whitelisted third-party services.
OK, how can Kerberos create a whitelist of services?
Kerberos is unable by itself to create special tickets to implement delegation for specific groups of services. For this reason Microsoft implemented 2 Kerberos extensions that allow it to obtain this desired behavior:
- S4U2Proxy (Service for User to Proxy)
- S4U2Self (Service for User to Self)
# Термины и определения
| термин | описание | пример |
| DOMAIN_NAME | название домена | test.com |
| REALM | для Active Directory это всегда DOMAIN_NAME в верхнем регистре | TEST.COM |
| SERVER_NAME | название компьютера, где установлен RunaWFE Server | runaserver |
| SERVER_USER | логин пользователя, под которым работает RunaWFE Server | runauser |
| SERVER_SPN | SPN (Service principal name), который соответствует SERVER_USER
Формат FQDN для Windows2008: HTTP/{SERVER_NAME}.{DOMAIN_NAME} Формат FQDN для Windows2003: HTTP/{SERVER_NAME}.{DOMAIN_NAME}@{REALM} Формат NetBIOS для Windows2008: HTTP/{SERVER_NAME} Формат NetBIOS для Windows2003: HTTP/{SERVER_NAME}@{REALM} |
HTTP/runaserver.test.com
HTTP/[email protected] HTTP/runaserver HTTP/[email protected] |
| KEYTAB_PATH | Путь к keytab-файлу ключей, хранящему хеши паролей пользователей | C:/runawfe/krb5.keytab |
Инструменты
| название | описание | расположение | комментарии |
| kinit | Получение тикета TGT из контроллера домена | JDK bin, есть альтернативные реализации | пользователь может быть задан в виде {SERVER_USER} или {SERVER_USER}@{REALM} |
| klist | Просмотр полученных тикетов и возможность их удаления из локального кеша | JDK bin, есть альтернативные реализации | |
| setspn | Создаёт SPN и назначает его пользователю | входит в Windows Server 2008+, ранее доступен в пакете Windows Server support tools | |
| ktpass | Меняет логин пользователя на SPN или формирует keytab файл | входит в Windows Server 2008+, ранее доступен в пакете Windows Server support tools | |
| ktab | Формирует keytab файл | JDK bin | |
| ADSIEdit | Просмотр свойств пользователя в контроллере домена | Windows Server | |
| WireShark | Анализатор траффика |
Описание
| этап | протокол | описание | данные запроса | данные ответа | примечания |
| KRB | аутентификация пользователя клиента | логин пользователя | тикет TGT | при входе в систему | |
| 1 | HTTP | вход в систему | без HTTP заголовка Authorization | HTTP 401 | |
| 2 | KRB | получение сервисного тикета для сервера | {SERVER_SPN} | сервисный тикет | шаг выполняется если тикета ещё нет в кеше клиента |
| 3 | HTTP | продолжение входа в систему | HTTP заголовок Authorization = YIIV… | HTTP 200 | |
| 4 | KRB | аутентификация пользователя сервера | {SERVER_SPN} | тикет TGT | выполняется при отсутствии TGT во время взаимодействия с клиентом, происходит до возврата ответа 3 клиенту |
Выпуск сертификата в центре сертификации
Это самый популярный способ использования PetitPotam. В случае, если в инфраструктуре есть центр сертификации (Active Directory Certificate Services), и в нем активированы службы Web Enrollment или Certificate Enrollment Web Service, атакующий может провести атаку NTLM Relay на центр сертификации, получить сертификат хоста и затем с помощью сертификата получить TGT-билет. Далее можно также получить NTLM-хеш учетной записи хоста.
Как эксплуатировать
Для начала необходимо найти центр сертификации. Лучший способ — посмотреть членов группы CERT PUBLISHERS (ИЗДАТЕЛИ СЕРТИФИКАТОВ). Затем проверяем, открыт ли 80-й порт на хостах из этой группы. Запускаем ntlmrelayx.py с relay-атакой на центр сертификации. В некоторых случаях можно изменить используемый шаблон (например, если в центре сертификации не используются стандартные шаблоны).
Запуск ntlmrelayx.py
Затем эксплуатируем PetitPotam, получаем запрос. Ntlmrelayx.py генерирует запрос, отправляет его в центр сертификации. В результате атаки мы получаем сертификат в base64.
Получение сертификата хоста
Декодируем сертификат и запрашиваем с его помощью TGT-билет. Для этого я использую PKINIT tools (https://github.com/dirkjanm/PKINITtools):
Декодирование сертификатаПолучение TGT с помощью сертификата
Имея TGT-билет хоста, уже можно выполнять какие-то действия. Но я обычно получаю NTLM-хеш учетной записи хоста с использованием утилиты getnthash.py. В параметре key нужно указать AS-REP encryption key, который был получен при выпуске TGT-билета:
Получение NTLM-хеша пароля хоста
Далее этот NTLM-хеш можно использовать для атак Pass-the-Hash или для атаки Silver Ticket. Я выбрала атаку Silver Ticket: создала TGS-билет для пользователя adm, который является администратором домена и администратором на уязвимом хосте. С помощью полученного билета я сдампила учетные данные из памяти процесса lsass.exe и получила пароль администратора домена в открытом виде:
Получение Silver TicketЭкспорт TGSДамп памяти lsass.exe
Как защититься
-
Если не используете службы Certificate Authority Web Enrollment и Certificate Enrollment Web Service, то отключить их.
-
Включить Extended Protection for Authentication (EPA) и установить параметр Require TLS.
-
Запретить NTLM на всех центрах сертификации в домене с помощью групповых политик.
-
Отключить NTLM в IIS на хосте с ролью Центра сертификации.
Подробная инструкция: https://support.microsoft.com/en-gb/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429
S4U2SELF & S4U2PROXY
Во время работы KCD в дело включаются две процедуры, которые имеют название S4U2Self и S4U2Proxy.
S4U2Self позволяет нам получить билет на себя от имени любого пользователя (необходим Forwardable флаг). Если говорить простым языком, то работает как
Тут нужно учесть, что:
-
Если пользователь, которого мы олицетворяем в Protected Users группе, то мы получим валидный билет, но без флага Forwardable
-
Если запрос не сконфигурирован для KCD, то мы получим валидный билет, но без флага Forwardable
-
Если запрос был сконфигурирован для KCD без protocol transition(с флагом kerberos-only), то мы получим валидный билет, но без флага Forwardable
S4U2Proxy позволяет нам получить билет для другого сервиса от имени пользователя клиента.
Если говорить простым языком, то работает как
-
Запрос должен содержать дополнительный билет как доказательство аутентификации.
-
Этот дополнительный билет должен быть с флагом forwardable или содержать rbcd bit.
-
Мы должны иметь возможность злоупотреблять KCD (креды пользователя или креды машины, созданной для злоупотребления rbcd).
-
Если пользователь, которым мы хотим представиться, находится в Protected Users, то ничего не получится.
Все вместе это выглядит вот так:
Главное помнить, что
Разбивка процесса Kerberos (16 шагов)
Теперь мы разберем каждый этап процесса, чтобы вы лучше понимали, что происходит за кулисами:
1. Войти
Пользователь вводит свое имя пользователя и пароль. Затем клиент с поддержкой Kerberos преобразует этот пароль в секретный ключ клиента.
2. Запросы клиентов на сервер выдачи билетов
Затем клиент отправляет серверу аутентификации текстовое сообщение, содержащее:
- введенное имя пользователя
- название запрашиваемой услуги
- сетевой адрес пользователя
- как долго они запрашивают доступ на
3. Сервер проверяет имя пользователя.
Имя пользователя проверяется на соответствие проверенным именам пользователей, хранящимся в KDC. Если имя пользователя знакомо, программа продолжится.
4. Выдача билета. Билет возвращается клиенту.
Сервер аутентификации отправляет клиенту два зашифрованных сообщения:
- Message A может быть расшифрован с помощью секретного ключа клиента, созданного на шаге 1. Он содержит имя TGS, временную метку, время жизни билета и вновь предоставленный сеансовый ключ сервера предоставления билетов.
- Message Bявляется билетом на выдачу билета и может быть расшифрован только с помощью секретного ключа TGS. Он содержит ваше имя пользователя, имя TGS, метку времени, ваш сетевой адрес, время жизни билета и тот же ключ сеанса TGS.
5. Клиент получает сеансовый ключ TGS.
Теперь клиент расшифровывает, message Aиспользуя секретный ключ клиента, предоставляя клиенту доступ к ключу сеанса TGS. Message Bхранится локально в зашифрованном состоянии.
6. Клиент запрашивает доступ к службе с сервера
Теперь клиент отправляет обратно два сообщения:
- Message Cпредставляет собой незашифрованное сообщение, содержащее имя запрошенной службы, время существования и все еще зашифрованное message B.
- Message D является аутентификатором, зашифрованным с помощью сеансового ключа TGS, и содержит ваше имя и временную метку
7. Сервер проверяет службу.
Затем TGS проверяет, существует ли служба запросов в KDC. Если это так, программа продолжается.
8. Сервер получает сеансовый ключ TGS.
Теперь сервер получает все еще зашифрованные message Bотправленные message C. Message B(TGT) затем расшифровывается с использованием секретного ключа TGS сервера, давая серверу сеансовый ключ TGS.
Теперь с помощью этого сеансового ключа TGS сервер может расшифровать message D.
Теперь у сервера есть отметка времени и имя из message Bи message D(сообщения аутентификатора). Сервер следит за тем, чтобы имена и временные метки совпадали, чтобы предотвратить мошеннические сообщения. Он также проверяет метку времени на соответствие времени жизни билета, чтобы убедиться, что время ожидания не истекло.
9. Сервер генерирует служебный сеансовый ключ.
Затем сервер генерирует случайный ключ сеанса службы и еще два сообщения.
- Message E зашифрован с помощью секретного ключа службы и содержит ваше имя, имя запрошенной службы, метку времени, ваш сетевой адрес, время жизни билета и ключ сеанса службы.
- Message Fшифруется с помощью сеансового ключа TGS, хранимого как клиентом, так и сервером. Это сообщение содержит всю ту же информацию, message Eкроме вашего имени пользователя и сетевого адреса.
10. Клиент получает ключ сеанса обслуживания.
Используя ключ сеанса TGS, кэшированный на шаге 5, клиент расшифровывает, message Fчтобы получить ключ сеанса службы.
11. Клиент связывается с Сервисом
Теперь клиент отправляет еще два сообщения, на этот раз службе:
- Message G- еще одно сообщение аутентификатора, на этот раз зашифрованное с помощью сеансового ключа службы. Он содержит ваше имя и метку времени.
- Message Hявляется копией message E, которая все еще зашифрована служебным секретным ключом.
12. Расшифровка сервисов Message G
Затем служба расшифровывает message Hсвой секретный ключ службы, чтобы получить ключ сеанса службы изнутри. С помощью этого ключа сервис расшифровывает message G.
13. Сервис проверяет запрос
Затем служба проверяет запрос, сравнивая имена пользователей, временные метки и время жизни из messages Gи H.
14. Сервис аутентифицируется для клиента.
Затем служба отправляет message Iзашифрованные с помощью сеансового ключа службы, хранимого как службой, так и клиентом. Message I- аутентификатор, содержащий идентификатор службы и временную метку.
15. Клиент проверяет услугу.
Затем клиент расшифровывает, message Iиспользуя ключ сеанса службы, кэшированный с шага 10. Затем клиент проверяет идентификатор и временные метки, содержащиеся в нем. Если оба соответствуют ожидаемым результатам, услуга считается безопасной.
16. Свободное общение между клиентом и службой
Уверенный в том, что и клиент, и служба взаимно аутентифицированы, Kerberos позволяет клиенту связываться со службой.
