Неограниченное делегирование.
Делегирование - механизм предоставления одному сервису доступа к другому сервису от имени заданного пользователя.
Давайте представим, что пользователь прошел аутентификацию по протоколу Kerberos к внутреннему веб-порталу, который предоставляет интерфейс для работы с базой данных, расположенной на другом сервере. Пользователь, используя этот интерфейс, хочет выгрузить определенные данные. В этот момент возникает так называемая "проблема двойного прыжка Kerberos". Пользователь должен иметь доступ только к тем данным, к которым у него есть разрешение.
Суть проблемы в том, что пользователь прошел авторизацию только на веб-сервере и не знает о сервере базы данных. Веб-сервер не имеет возможности использовать TGS-билет, предоставленный пользователем, для доступа к базе данных, так как этот билет предназначен исключительно для доступа к определенному сервису. Делегирование решает рассмотренную проблему и позволяет веб-серверу обратиться к серверу базы данных от имени аутентифицированного пользователя.
Чтобы учетная запись получила право на неограниченное делегирование в атрибуте UserAccountControl указанной учетной записи необходимо установить флаг TRUSTED_FOR_DELEGATION. По умолчанию указанный флаг активен только у машинных учетных записей контроллеров домена. Для изменения значения флага необходимо наличие привилегии SeEnableDelegationPrivilege, которой изначально обладают только учетные записи с правами уровня администратора домена.
Теперь рассмотрим, как устроен процесс неограниченного делегирования по шагам:
- Сначала User получает TGT в результате обмена KRB AS REQ и KRB AS REP сообщениями.
- Далее User запрашивает TGS-билет для доступа к Сервису А (KRB TGS REQ).
- KDC видит, что у Сервиса А установлен флаг “TRUSTED_FOR_DELEGATION”, разрешающий неограниченную делегацию, и поэтому в ответ User KDC отправляет TGS-билет с флагом ok-as-delegate.
- Получив TGS-билет, User обнаруживает флаг ok-as-delegate и понимает, что ему необходимо передать свои учетные данные Сервису А. Для этого User снова обращается к KDC c просьбой выдать ему перенаправляемый (forwarded) TGT.
- KDC выполняет необходимые проверки и отправляет User TGT с правом передачи.
- User обращается к Сервису А с расширенным KRB AP REQ сообщением. Теперь в аутентификаторе содержится не только метка времени и принципал клиента, но и перенаправляемый (forwarded) TGT вместе с сессионным ключом для общения с KDC.
- Сервис А извлекает сессионный ключ для общения с User из TGS-билета, расшифровывает аутентификатор, выполняет проверки и сохраняет Forwarded TGT для User вместе с соответствующим указанному билету сессионным ключом.
- С использованием полученных аутентификационных данных Сервис А получает TGS-билет к Сервису Б от имени User.
Изначально у атакующего имеется учетная запись с неограниченным делегированием. У учетной записи есть сервис, а сервис предполагает работу в рамках процесса операционный системы. Указанная система сохраняет Forwarded TGT доменных учетных записей, прошедших аутентификацию к сервису. Атака заключается в добыче Forwarded TGT для последующей атаки Pass-the-ticket. Важно понимать, что добытый Forwarded TGT можно использовать для доступа к любому сервису от имени соответствующего пользователя, так как делегирование неограниченное.
Поиск учетных записей с неограниченным делегированием с помощью findDelegation.py:
findDelegation.py -dc-ip $DC_IP $Domain_fqdn/$Username:$Password
Получив административный доступ к серверу с сервисом, обладающим неограниченным делегированием, атакующий может извлечь TGT учетных записей, проходивших аутентификацию к указанному сервису, из памяти процесса lsass.exe сервера.
Осуществить выгрузку можно с помощью Rubeus:
Rubeus.exe dump /service:krbtgt /nowrap
mimikatz # sekurlsa::tickets /export