Оффлайн
- Регистрация
- 9 Май 2015
- Сообщения
- 1,483
- Баллы
- 155
Что делать в конце пентеста FreeIPA — когда пароль получен, а доступа к контроллеру домена по SSH нет или там стоит грозная защита, не дающая сдампить id2entry.db и наслаждаться красивым отчетом? В случае с обычной Active Directory ответ очевиден — DCSync, и дело с концом, но для FreeIPA таких ресерчей нет... Что ж, подержи мое пиво, оставшееся у меня после CVE-2024-3183.
Это исследование получило первое место на в категории «Пробив инфраструктуры». Соревнование ежегодно проводится компанией Awillix.
Мое новое исследование напрямую не связано с предыдущим, но из одного вылилось другое, да и на проектах они применяются совместно.
Почему я подался и в номинацию Out of Scope? Считаю, что тут ценнее сам ресерч, а не место его применения.
Рассказ я попытался максимально сократить и убрать технические подробности, которые могут тебе помешать следить за сутью.
DCSync
Что ж, начнем разбираться, как работает репликация в 389 Directory Server. Именно этот продукт отвечает за сервер LDAP во FreeIPA. Давай заглянем в документацию... Впрочем, не заглянем, потому что ее нет!
Тогда откроем исходный код, это нам сильно облегчает анализ по сравнению с тем же Microsoft Domain Controller. И в исходном коде можно увидеть некоторое количество OID, отвечающих за репликацию.
Это только часть OID, отвечающих за репликацию
Однако дело упрощается тем, что репликация здесь вынесена в отдельный из ldap/servers/plugins/replication. Можно изучить его исходники и понаблюдать за трафиком в процессе репликации двух контроллеров доменов. Сделав это, я установил несколько фактов:
Это значит, что аналогия с DCSync не совсем правильна, так как мы не можем инициировать репликацию сами в нашу сторону. Значит, нам нужен DCShadow.
Вспомним оригинальный ресерч по DCShadow и начнем собирать необходимую информацию:
Давай попробуем ответить на эти вопросы.
Это исследование получило первое место на в категории «Пробив инфраструктуры». Соревнование ежегодно проводится компанией Awillix.
Мое новое исследование напрямую не связано с предыдущим, но из одного вылилось другое, да и на проектах они применяются совместно.
Почему я подался и в номинацию Out of Scope? Считаю, что тут ценнее сам ресерч, а не место его применения.
Рассказ я попытался максимально сократить и убрать технические подробности, которые могут тебе помешать следить за сутью.
DCSync
Что ж, начнем разбираться, как работает репликация в 389 Directory Server. Именно этот продукт отвечает за сервер LDAP во FreeIPA. Давай заглянем в документацию... Впрочем, не заглянем, потому что ее нет!
Тогда откроем исходный код, это нам сильно облегчает анализ по сравнению с тем же Microsoft Domain Controller. И в исходном коде можно увидеть некоторое количество OID, отвечающих за репликацию.
Это только часть OID, отвечающих за репликацию
Однако дело упрощается тем, что репликация здесь вынесена в отдельный из ldap/servers/plugins/replication. Можно изучить его исходники и понаблюдать за трафиком в процессе репликации двух контроллеров доменов. Сделав это, я установил несколько фактов:
- В отличие от MS DC нельзя запросить изменения, можно только прийти с новыми.
- Контроллеры домена не используют RPC (собственно, во FreeIPA вообще такого нет).
- Если меняются значения атрибутов, репликация происходит сразу по инициативе контроллера домена, на котором произошло изменение.
Это значит, что аналогия с DCSync не совсем правильна, так как мы не можем инициировать репликацию сами в нашу сторону. Значит, нам нужен DCShadow.
Вспомним оригинальный ресерч по DCShadow и начнем собирать необходимую информацию:
- Как контроллер домена обращается к другому?
- Что нужно, чтобы нас восприняли как другой DC?
- Как нам обработать запрос от другого DC и сохранить результат?
- Какие права нужны для атаки?
Давай попробуем ответить на эти вопросы.