nccgroup/berserkoРасширение Burp Suite для выполнения аутентификации Kerberos
Выпущено как программное обеспечение с открытым исходным кодом компанией NCC Group Plc - http://www.nccgroup.trust/
Разработано Ричардом Тернбуллом, richard [dot] turnbull [at] nccgroup [dot] com
http://www.github.com/nccgroup/Berserko
Выпущено под лицензией AGPL, см. LICENSE для получения дополнительной информации
Дальнейшая разработка Berserko будет осуществляться по адресу https://github.com/rteatea/Berserko
Berserko — это расширение Burp для добавления поддержки аутентификации Kerberos. Это полезно для тестирования в домене Windows, когда аутентификация NTLM не поддерживается (Burp уже умеет работать с NTLM). Для работы Berserko не требуется, чтобы машина, на которой запущен Burp, была включена в домен (или даже чтобы на ней была установлена Windows).
Единственное известное нам существующее решение для тестирования приложений Kerberos с помощью Burp — это организация цепочки через Fiddler с настройкой аутентификации согласно этой инструкции. Но Fiddler работает только в Windows, а использование цепочки прокси добавляет сложности и снижает производительность, поэтому удобно иметь возможность Kerberos прямо внутри Burp.
Получите последний jar-файл Berserko на вкладке Releases или из папки berserko\releases
Перейдите на вкладку Extender в Burp, выберите Add, убедитесь, что в качестве Extension type выбран Java, и укажите путь к jar-файлу. Если всё сделано правильно, в интерфейсе Burp должна появиться вкладка Berserko.
На вкладке Berserko в Burp есть различные элементы управления.
Флажок Do Kerberos authentication является главным переключателем. Пока он не включён, Berserko вообще ничего не делает.
Кнопка Restore defaults возвращает Berserko к конфигурации по умолчанию (в которой нет ни данных о домене, ни учётных данных пользователя).
Кнопка Clear Kerberos state очищает все билеты Kerberos и другое состояние на клиенте. Единственная причина, по которой вам может понадобиться это сделать, — если на серверной стороне были изменены настройки Kerberos и вы хотите начать с чистого состояния.
Кнопка Write tickets to log записывает информацию о ваших текущих билетах Kerberos в поток журнала Berserko — это может быть полезно для отладки/поиска неисправностей. Чтобы увидеть журналы, перейдите на вкладку Extender в Burp, выберите Berserko и посмотрите вкладку Output ниже. Возможно, имеет смысл использовать здесь опцию Save to file, поскольку данные билетов могут легко заполнить буфер журнала в графическом интерфейсе.
У некоторых элементов управления есть кнопка справки, которая открывает дополнительную информацию.
Укажите Domain DNS Name и KDC Host с помощью элементов управления в этом разделе. Текстовые поля нельзя редактировать напрямую; для их изменения необходимо использовать кнопку «Change».
Domain DNS Name должно быть DNS-именем домена, к которому вы хотите выполнить аутентификацию (если быть точным, это Kerberos-область). Оно должно выглядеть примерно так: mydomain.acme.local. Это не должно быть NETBIOS-имя домена (которое выглядело бы примерно так: MYDOMAIN).
KDC Host должен быть именем хоста (или IP-адресом) Kerberos KDC (Key Distribution Center). В домене Windows KDC — это просто контроллер домена.
После указания Domain DNS Name вы можете использовать кнопку Auto, чтобы попытаться автоматически найти KDC. Это делается путём отправки DNS SRV-запроса для службы Kerberos. Если один из ваших DNS-серверов является контроллером домена для нужного домена, это должно сработать. Если нет — не сработает. ❗Эта функциональность не будет работать в последних версиях Burp, поскольку необходимые библиотеки DNS не поставляются в составе встроенной JRE. Вы можете обойти это, запустив Burp под полной JRE, как описано в начале этого README.❗
Когда Domain DNS Name и KDC Host введены, используйте кнопку Test domain settings для проверки подключения. При успехе вы получите ответ Successfully contacted Kerberos service.
См. этот файл для получения дополнительной информации о том, как получить правильные значения для этих Domain Settings.
Укажите Username и Password для учётной записи домена с помощью элементов управления в этом разделе. Текстовые поля нельзя редактировать напрямую; для их изменения необходимо использовать кнопку «Change».
Username должно быть просто именем пользователя. Оно должно выглядеть примерно так: bob. Это не должно быть MYDOMAIN\bob или [email protected] или что-то подобное.
После указания учётных данных вы можете использовать кнопку Test credentials. Она попытается получить билет, выдающий билеты (ticket-granting ticket) Kerberos для указанного пользователя. В случае успеха вы получите ответ TGT successfully acquired. В случае неудачи учтите, что это попытка аутентификации в домене, поэтому будьте осторожны, чтобы не заблокировать свою учётную запись.
Пароль не будет сохранён в конфигурации Berserko до следующего раза, если не установлен флажок Save password in Burp config?. Однако все остальные настройки будут сохранены.
Некоторые приложения используют делегирование Kerberos на серверной стороне для передачи идентификационных данных клиента другим серверам (но со стороны клиента нет простого способа определить, используется ли эта функция).
Berserko поддерживает это, но есть одна загвоздка. Делегирование работает только в том случае, если у пользователя есть forwardable TGT (билет, выдающий билеты). К сожалению, реализация Kerberos в Java не предоставляет возможности программно указать, что должен быть получен перенаправляемый (forwardable) билет. Это можно сделать только путём добавления соответствующей записи в файл конфигурации krb5.conf.
Таким образом, для работы делегирования Berserko необходимо указать подходящий файл krb5.conf, и здесь есть два возможных подхода.
Самый простой способ — и рекомендуемый подход — использовать кнопку Create krb5.conf file. Она создаст подходящий файл в выбранном вами месте. Вы можете поместить его во временный каталог, в каталог проекта или куда угодно. Но один и тот же файл можно использовать бессрочно, поэтому, возможно, имеет смысл поместить его в более постоянное место. Кнопка Change позволяет выбрать другой файл для использования.
Если вам интересно, создаваемый файл krb5.conf очень прост и будет иметь следующее содержимое:
[libdefaults]
forwardable = true
В качестве альтернативы вы можете использовать кнопку Change, чтобы указать на существующий файл krb5.conf в системе. Единственная причина, по которой вам может понадобиться это сделать, — если в этом файле есть другие важные настройки Kerberos, которые вы хотите, чтобы Berserko подхватил (в теории это должно работать нормально, но на практике не тестировалось). Обратите внимание, что расположение этого файла по умолчанию в Linux — /etc/krb5.conf — на других операционных системах его, скорее всего, нет. Если вы указываете на существующий файл krb5.conf, убедитесь, что вы отредактировали его для включения перенаправления — добавьте forwardable = true в раздел [libdefaults] (или отдельно для каждой области). Но будьте осторожны. Просьба к Berserko создать файл за вас будет лучшим вариантом в 99% случаев.
Если вы хотите узнать, успешна ли ваша конфигурация делегирования, используйте кнопку Check current config. Она сообщит вам, найден ли файл krb5.conf и корректна ли настройка forwardable. Также обратите внимание, что Berserko сообщит вам, успешно ли он получил перенаправляемый TGT, при использовании кнопки Test credentials.
Хорошая идея — убедиться, что у вас есть перенаправляемый билет до начала использования приложения. Похоже, что IIS может кэшировать статус аутентификации пользователя на серверной стороне таким образом, что переход с неперенаправляемого билета на перенаправляемый не сработает.
Настройки в этом разделе определяют, пытается ли Berserko выполнять аутентификацию Kerberos «реактивно» (т.е. ждать ответа 401 от сервера, а затем повторно отправлять запрос с добавленным заголовком аутентификации Kerberos) или «проактивно» (т.е. добавлять заголовок аутентификации Kerberos к исходящему запросу).
Преимущество проактивной аутентификации в том, что она требует только одного сетевого обмена HTTP, тогда как реактивная аутентификация требует двух. Недостаток проактивной аутентификации в том, что заголовки аутентификации Kerberos могут быть отправлены хостам, которые их не ожидают. Berserko также лучше диагностирует ошибки аутентификации при использовании реактивной стратегии.
Опция Proactive Kerberos authentication, only after initial 401 received — это гибрид этих двух подходов: Berserko будет аутентифицироваться реактивно при первом запросе к хосту, а в дальнейшем — проактивно.
В этом разделе вы можете определить, какие хосты считаются входящими в область действия для аутентификации Kerberos.
По умолчанию установлен флажок All hosts in this Kerberos domain in scope for Kerberos. Это означает, что Berserko будет пытаться выполнять аутентификацию Kerberos только для тех веб-серверов, имя хоста которых заканчивается DNS-именем домена. Во многих ситуациях этого будет достаточно. Однако возможно наличие веб-приложений с поддержкой Kerberos, имя хоста которых не имеет такой формы (при условии, что администратор настроил соответствующий Service Principal Name). Чтобы учесть это, вы можете добавить дополнительные хосты, которые будут считаться входящими в область действия, с помощью списка справа. Обратите внимание, что можно использовать подстановочные знаки (* соответствует нулю или более символов, ? соответствует любому символу, кроме точки).
В качестве альтернативы вы можете установить флажок All hosts in scope for Kerberos authentication. Очевидно, преимущество этого в том, что вам не нужно вручную задавать область действия. Потенциальный недостаток такой конфигурации в том, что Berserko может отправлять запросы Kerberos в KDC для получения служебных билетов для хостов, которые не входят в домен. Это может вызвать проблемы с производительностью и проблемы конфиденциальности (если вы не хотите, чтобы эта информация передавалась в KDC). Это, скорее всего, будет особенно проблематично при стратегии Proactive Kerberos authentication, когда Berserko будет пытаться добавить заголовок аутентификации Kerberos к каждому запросу, проходящему через Burp. Такая комбинация параметров не рекомендуется, и Berserko предупредит вас, если она будет выбрана (но не будет фактически препятствовать этому).
Если не выбраны ни All hosts in this Kerberos domain in scope for Kerberos, ни All hosts in scope for Kerberos authentication, в область действия будут входить только те хосты, которые добавлены в список.
Опция Plain hostnames considered part of domain, если она выбрана, означает, что «простые имена хостов» (т.е. имена хостов, состоящие только из одного компонента) будут считаться частью домена (и, следовательно, автоматически попадать в область действия, если выбрано All hosts in this Kerberos domain in scope for Kerberos). Основная причина, по которой вам может понадобиться отключить эту опцию, — если ваша машина присоединена к другому домену, отличному от того, к которому выполняется аутентификация с помощью Berserko (в этом случае простые имена хостов, вероятно, относятся к хостам в том домене, к которому вы присоединены).
Если выбрана опция Do not perform Kerberos authentication to servers which support NTLM, она укажет Berserko не пытаться выполнять аутентификацию Kerberos для хостов, которые поддерживают NTLM в дополнение к Kerberos (т.е. хостов, возвращающих как заголовки WWW-Authenticate: NTLM, так и WWW-Authenticate: Negotiate).
Здесь можно настроить Alert Level и Logging Level — NONE, NORMAL или VERBOSE.
Alert Level управляет объёмом информации, отправляемой на вкладку Alerts в Burp.
Logging Level управляет объёмом информации, отправляемой в стандартный вывод Berserko (его можно просмотреть на вкладке Extender). Обратите внимание, что повышение Logging Level до VERBOSE приведёт к предоставлению дополнительной информации о любых ошибках или исключениях, которые могут возникнуть.
Если в вашей среде используются доверительные отношения доменов Kerberos, вы можете найти некоторые рекомендации здесь.
По умолчанию Berserko выполняет все взаимодействия Kerberos с KDC через UDP (порт 88). При желании можно использовать TCP. Наиболее распространённая причина для этого — использование переадресации портов SSH для TCP-порта 88. Просто добавьте udp_preference_limit = 1 в ваш файл krb5.conf, чтобы он выглядел так:
[libdefaults]
forwardable = true
udp_preference_limit = 1
Можно настроить SPN, который будет использоваться для конкретного хоста, включив раздел [berserko_spn_hints] в файл krb5.conf (см. выше). Синтаксис показан ниже.
[berserko_spn_hints]
[email protected]
server2.bar.org=app.domain2.local
Целевой сервер указывается слева от знака равенства, а используемый SPN — справа. Область (realm) для SPN может быть указана по желанию (если не указана, Berserko попытается определить правильную область обычным способом). Не включайте сюда часть HTTP/ из SPN.
Berserko несовместим с Burp v2 до версии v2020.5.1. С Burp v1 проблем нет.
Это вызвано тем, что версия OpenJDK, поставляемая с более ранними версиями Burp 2, не включает некоторые функции Kerberos, используемые Berserko. Это приведёт к ошибке java.lang.ClassNotFoundException: com.sun.security.jgss.ExtendedGSSContext при попытке использования Berserko.
Очевидное решение — обновиться до версии v2020.5.1 или новее. Кроме того, Berserko должен работать с любой версией Burp v2, если запускать Burp с использованием полной версии Java runtime environment (т.е. не той, что встроена в Burp).
Предполагая, что java есть в вашем PATH:
java -jar burpsuite_pro.jar