Написал: Эрмано
Специально для XSS
Приветстую, форумчане.
Недавно плотно сел за изучение Kerberos, всё начиналось хорошо - атаки все были понятны, механизм аутентификации хорошо расписан, однако как только дело дошло до темы делегирования начались проблемы. Сразу в эту тему я не въехал и практически весь декабрь потратил на её изучение. Мне помогли несколько статей, которые не раз будут тут упомянуты.
Вообще что такое делегирование?
Делегирование это механизм, позволяющий одному сервису обратиться к другому от имени определённого пользователя.
Как пример часто приводят функционал веб-сервиса для поиска чего либо: пользователь передаёт свои идентификационные данные, чтобы веб-сервис смог получить доступ к БД с этими данными.
В Kerberos делегирование делится на несколько видов:
Неограниченное делегирование позволяет сервису обращаться к другому от имени почти любых пользователей(если не установлен флаг NOT_DELEGATED в аттрибуте UAC). Также для права на неограниченное делегирование нужно, чтобы у владельца целевого сервиса в UAC был установлен флаг TRUSTED_FOR_DELEGATION(ADS_UF_TRUSTED_FOR_DELEGATION) и владелец имел привилегию SeEnableDelegationPrivilege.
К сожалению практики в этой статье не будет, так как я в настройке AD относительно плох и всё поломал, однако возможно в следующих статьях я покажу атаки на делегацию(скорее всего так и будет).
Также я буду вставлять схемы из thehacker.recipes, т.к. они уж больно мне нравятся:
Пример атаки на неограниченное делегирование
Ограниченное делегирование
При ограниченном делегировании сервис может обратиться к другому определённому сервису, от имени практически любого пользовтеля.
S4U2Proxy
S4U2Self
Поддерживает 2 расширения - S4U2Proxy(Service for User to Proxy) и S4U2Self(Service for User to Self).
S4U2Proxy
S4U2Proxy - использование только протокола Kerberos для аутентификации.
Для настройки указанного вида делегирования в атрибуте
S4U2Self
S4U2Self - расширение, которое позволяет использовать протоколы помимо Kerberos для аутентификации. Для доступа к такому виду делегирования в аттрибуте UAC учётной записи должен быть установлен флаг TRUSTED_FOR_AUTH_DELEGATION. Тоже требует указания SPN при обращении к которым приведенной учетной записи требуется олицетворять других пользователей.
Когда изучал также использовал данную картинку(опять же с thehacker.recipes):
Ограниченное делегирование на основе ресурсов
Во время изучения данного вида делегирования, мне хотелось всё бросить, позжея так и сделал я смог побороть себя и изучил.
RBCD - вид делегирования при котором сервисы сами определяют, кто может к ним обращаться от имени других пользователей. Если раньше был "ответственный", который решал кто к кому и от имени кого может обращаться, то сейчас это каждый решает сам.
Чтобы настроить RBCD нужно иметь право на запись в атрибут
Ну и заключительная схема:
Итог
В этой статье я хотел кратко и понятно рассказать про делегирование в Kerberos. Надеюсь эта статья кому-то поможет въехать в эту тему, намного быстрее, чем мне
. Также после праздников планирую написать про реализацию атак на делгацию, где мы ещё раз рассмотрим темы из этой статьи.
Также вот ресурсы, которые помогли мне как в осмыслении данной темы, так и в написани этой статьи:
www.tarlogic.com
www.thehacker.recipes
С вами был Эрмано.
С наступающим Новым Годом!
P.S. Не пинайте за множество вставок и картинок.
Специально для XSS
Приветстую, форумчане.
Недавно плотно сел за изучение Kerberos, всё начиналось хорошо - атаки все были понятны, механизм аутентификации хорошо расписан, однако как только дело дошло до темы делегирования начались проблемы. Сразу в эту тему я не въехал и практически весь декабрь потратил на её изучение. Мне помогли несколько статей, которые не раз будут тут упомянуты.
Вообще что такое делегирование?
Делегирование это механизм, позволяющий одному сервису обратиться к другому от имени определённого пользователя.
Как пример часто приводят функционал веб-сервиса для поиска чего либо: пользователь передаёт свои идентификационные данные, чтобы веб-сервис смог получить доступ к БД с этими данными.
В Kerberos делегирование делится на несколько видов:
- Неограниченное(Unconstrained)
- Ограниченное(Constrained), которое делится ещё на два подвида:
- S4U2Proxy - с использованием только протокола Kerberos
- S4U2Self - с использование протоколов помимо Kerberos
- Делегирование на основе ресурсов(Resource-based Constrained Delegation)
Неограниченное делегирование позволяет сервису обращаться к другому от имени почти любых пользователей(если не установлен флаг NOT_DELEGATED в аттрибуте UAC). Также для права на неограниченное делегирование нужно, чтобы у владельца целевого сервиса в UAC был установлен флаг TRUSTED_FOR_DELEGATION(ADS_UF_TRUSTED_FOR_DELEGATION) и владелец имел привилегию SeEnableDelegationPrivilege.
К сожалению практики в этой статье не будет, так как я в настройке AD относительно плох и всё поломал, однако возможно в следующих статьях я покажу атаки на делегацию(скорее всего так и будет).
Также я буду вставлять схемы из thehacker.recipes, т.к. они уж больно мне нравятся:
Ограниченное делегирование
При ограниченном делегировании сервис может обратиться к другому определённому сервису, от имени практически любого пользовтеля.
Поддерживает 2 расширения - S4U2Proxy(Service for User to Proxy) и S4U2Self(Service for User to Self).
S4U2Proxy
S4U2Proxy - использование только протокола Kerberos для аутентификации.
Для настройки указанного вида делегирования в атрибуте
msds-allowedtodelegateto учетной записи необходимо указать SPN при обращении к которым приведенной учетной записи требуется олицетворять других пользователей.
S4U2Self
S4U2Self - расширение, которое позволяет использовать протоколы помимо Kerberos для аутентификации. Для доступа к такому виду делегирования в аттрибуте UAC учётной записи должен быть установлен флаг TRUSTED_FOR_AUTH_DELEGATION. Тоже требует указания SPN при обращении к которым приведенной учетной записи требуется олицетворять других пользователей.
Когда изучал также использовал данную картинку(опять же с thehacker.recipes):
Ограниченное делегирование на основе ресурсов
Во время изучения данного вида делегирования, мне хотелось всё бросить, позже
RBCD - вид делегирования при котором сервисы сами определяют, кто может к ним обращаться от имени других пользователей. Если раньше был "ответственный", который решал кто к кому и от имени кого может обращаться, то сейчас это каждый решает сам.
Чтобы настроить RBCD нужно иметь право на запись в атрибут
msDS-AllowedToActOnBehalfOfOtherIdentity УЗ.Ну и заключительная схема:
Итог
В этой статье я хотел кратко и понятно рассказать про делегирование в Kerberos. Надеюсь эта статья кому-то поможет въехать в эту тему, намного быстрее, чем мне
. Также после праздников планирую написать про реализацию атак на делгацию, где мы ещё раз рассмотрим темы из этой статьи.Также вот ресурсы, которые помогли мне как в осмыслении данной темы, так и в написани этой статьи:
Kerberos (III): How does delegation work?
Kerberos delegation. Delegation allows one service to impersonate the client user to interact with a second service.
www.tarlogic.com
Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory
Back in March 2018, I embarked on an arguably pointless crusade to prove that the TrustedToAuthForDelegation attribute was meaningless, and that “protocol transition” can be achieved without it. I believed that security wise, once constrained delegation was enabled (msDS-AllowedToDelegateTo was...
eladshamir.com
Delegations | The Hacker Recipes
Comprehensive cybersecurity guides and strategies for ethical hacking and penetration testing
www.thehacker.recipes
С вами был Эрмано.
С наступающим Новым Годом!
P.S. Не пинайте за множество вставок и картинок.
Вложения
Последнее редактирование:
