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