D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Оригинал - https://posts.specterops.io/attacking-freeipa-part-iii-finding-a-path-677405b5b95e
Перевёл: Эрмано
Специально для XSS.IS
Эта заметка является третьей частью серии, посвященной моему опыту атаки на FreeIPA. В первой части этой серии мы рассмотрели некоторые предпосылки и базовые технологии, используемые FreeIPA. Мы также обсудили несколько механизмов аутентификации и формы учетных данных, в частности, как определить, разобрать и повторно использовать учетные данные в качестве атакующего. Во второй части этой серии мы обсудили различные типы объектов в среде FreeIPA и их значение, а также то, как эти объекты могут быть перечислены для получения ситуационной осведомленности.
Предыдущие статьи:
Прежде чем мы погрузимся в наш путь атаки, давайте вкратце рассмотрим лабораторную среду, в которой мы будем работать. Если вы хотите следить за развитием событий, я опубликовал пост с подробным описанием того, как вы можете настроить свою собственную лабораторию FreeIPA, чтобы следить за развитием событий в этой серии или даже проводить свои собственные исследования. Вы можете найти этот пост здесь: https://posts.specterops.io/building-a-freeipa-lab-17f3f52cd8d9
После настройки и создания лаборатории мы можем приступить к работе. Отправной точкой в этом упражнении будет предоставление доступа к взломанному веб-серверу в управляемой среде FreeIPA. Доступ будет предоставлен через платформу Apfell C2 с помощью агента Poseidon. Целью является получение учетных данных администратора домена и утечка конфиденциальных данных из базы данных SQL.
Атака
Получив доступ, мы должны начать выполнять базовое перечисление. В рамках этой статьи я сосредоточусь только на аспектах перечисления хостов в FreeIPA, но в реальной среде вам, скорее всего, потребуется выполнить более полное перечисление, чем показано в этой статье.
Получив доступ к взломанному веб-серверу, мы обнаружили, что в данный момент находимся в пользовательском контексте "nginxadmin". Утилита управления ipa также присутствует в своем стандартном расположении: /usr/bin/ipa и, наконец, в каталоге /tmp/ хранится несколько билетов, один из которых доступен для чтения нашему пользователю. Давайте проверим его валидность и применим его к нашему обратному вызову Poseidon.
Импортировав этот билет в наш агент, мы можем приступить к перечислению разрешений, связанных с учетной записью "nginxadmin".
На основе вышеприведенного результата мы можем определить правило Sudo и правило HBAC, которые применяются к этой учетной записи. Правила Sudo можно использовать для ограничения или делегирования возможности выполнять команды с правами sudo на хостах, включенных в домен. Правила HBAC используются для делегирования доступа к определенным ресурсам. Давайте рассмотрим подробнее правила Sudo и правила HBAC.
HBACПравило делегирования доступа к хосту
Правило Sudo, делегирующее доступ к sudo
Просмотр правила HBAC "Web-Admin" показывает, что "nginxadmin" имеет доступ ко всем службам на сайтах mysql.westeros.local и web.westeros.local. Это означает, что мы должны иметь возможность использовать SSH и SCP с действительным TGT для "nginxadmin".
Правило Sudo "Web-Sudo" показывает нам, что "nginxadmin" имеет возможность запускать sudo от имени любого пользователя или группы и для любой команды. Это правило применяется как к "mysql.westeros.local", так и к "web.westeros.local".
Между правилом HBAC и правилом Sudo "nginxadmin" должен иметь возможность как аутентифицироваться на "mysql.westeros.local", так и выполнять команды от имени root через sudo.
Копирование полезной нагрузки Poseidon на mysql.westeros.local через scp, а затем ее выполнение
Новая проверка агента для mysql.westeros.local, демонстрирующего горизонтальное перемещение
Доступ к mysql.westeros.local решает задачу получения доступа к конфиденциальной базе данных. Но давайте попробуем расширить доступ к управлению доменом FreeIPA. Быстрый просмотр /tmp/ выявляет два kerberos CCACHE TGT. Мы можем попытаться перечислить эти билеты с помощью наших привилегий sudo.
Билеты Kerberos CCACHE по умолчанию хранятся в /tmp/.
Klist можно использовать для перечисления принципалов внутри определенных билетов или в текущей сессии
Во FreeIPA учетная запись "admin" примерно эквивалентна учетной записи "Domain Admin" в традиционном каталоге active directory. Перечисление ее разрешений и атрибутов пользователя показывает, что она является членом групп "admins" и "trust admins", а также нескольких правил Sudo и наборов правил HBAC.
Свойства пользователя для учетной записи "admin" в FreeIPA
Имея привилегии sudo, мы можем получить доступ к этой учетной записи, создав копию существующего билета и изменив разрешения, чтобы наш текущий пользовательский контекст мог его использовать. Также можно использовать sudo для создания другого агента в корневом контексте, устраняя необходимость копирования или изменения разрешений билета.
Создание нового агента от имени root
Установка переменной окружения KRB5CCNAME
С этими новыми разрешениями должно быть возможно боковое перемещение на любой хост внутри среды. Давайте проверим эту теорию, получив агента на "vault.westeros.local".
Копирование и выполнение агента с помощью scp и ssh
Регистрация нового агента с сайта vault.westeros.local
Заключение
Несмотря на то, что эта лабораторная среда является небольшим и немного надуманным примером производственной среды FreeIPA, она эффективно демонстрирует, как перечислять разрешения и использовать их для бокового перемещения. Надеемся, теперь мы немного лучше понимаем, как применить некоторые из наших предыдущих знаний о FreeIPA в наступательном контексте.
Перевёл: Эрмано
Специально для XSS.IS
Эта заметка является третьей частью серии, посвященной моему опыту атаки на FreeIPA. В первой части этой серии мы рассмотрели некоторые предпосылки и базовые технологии, используемые FreeIPA. Мы также обсудили несколько механизмов аутентификации и формы учетных данных, в частности, как определить, разобрать и повторно использовать учетные данные в качестве атакующего. Во второй части этой серии мы обсудили различные типы объектов в среде FreeIPA и их значение, а также то, как эти объекты могут быть перечислены для получения ситуационной осведомленности.
Предыдущие статьи:
- https://xss.is/threads/122951 - первая часть
- https://xss.is/threads/123166/ - вторая часть
Прежде чем мы погрузимся в наш путь атаки, давайте вкратце рассмотрим лабораторную среду, в которой мы будем работать. Если вы хотите следить за развитием событий, я опубликовал пост с подробным описанием того, как вы можете настроить свою собственную лабораторию FreeIPA, чтобы следить за развитием событий в этой серии или даже проводить свои собственные исследования. Вы можете найти этот пост здесь: https://posts.specterops.io/building-a-freeipa-lab-17f3f52cd8d9
После настройки и создания лаборатории мы можем приступить к работе. Отправной точкой в этом упражнении будет предоставление доступа к взломанному веб-серверу в управляемой среде FreeIPA. Доступ будет предоставлен через платформу Apfell C2 с помощью агента Poseidon. Целью является получение учетных данных администратора домена и утечка конфиденциальных данных из базы данных SQL.
Атака
Получив доступ, мы должны начать выполнять базовое перечисление. В рамках этой статьи я сосредоточусь только на аспектах перечисления хостов в FreeIPA, но в реальной среде вам, скорее всего, потребуется выполнить более полное перечисление, чем показано в этой статье.
Получив доступ к взломанному веб-серверу, мы обнаружили, что в данный момент находимся в пользовательском контексте "nginxadmin". Утилита управления ipa также присутствует в своем стандартном расположении: /usr/bin/ipa и, наконец, в каталоге /tmp/ хранится несколько билетов, один из которых доступен для чтения нашему пользователю. Давайте проверим его валидность и применим его к нашему обратному вызову Poseidon.
Импортировав этот билет в наш агент, мы можем приступить к перечислению разрешений, связанных с учетной записью "nginxadmin".
На основе вышеприведенного результата мы можем определить правило Sudo и правило HBAC, которые применяются к этой учетной записи. Правила Sudo можно использовать для ограничения или делегирования возможности выполнять команды с правами sudo на хостах, включенных в домен. Правила HBAC используются для делегирования доступа к определенным ресурсам. Давайте рассмотрим подробнее правила Sudo и правила HBAC.
HBACПравило делегирования доступа к хосту
Правило Sudo, делегирующее доступ к sudo
Просмотр правила HBAC "Web-Admin" показывает, что "nginxadmin" имеет доступ ко всем службам на сайтах mysql.westeros.local и web.westeros.local. Это означает, что мы должны иметь возможность использовать SSH и SCP с действительным TGT для "nginxadmin".
Правило Sudo "Web-Sudo" показывает нам, что "nginxadmin" имеет возможность запускать sudo от имени любого пользователя или группы и для любой команды. Это правило применяется как к "mysql.westeros.local", так и к "web.westeros.local".
Между правилом HBAC и правилом Sudo "nginxadmin" должен иметь возможность как аутентифицироваться на "mysql.westeros.local", так и выполнять команды от имени root через sudo.
Копирование полезной нагрузки Poseidon на mysql.westeros.local через scp, а затем ее выполнение
Новая проверка агента для mysql.westeros.local, демонстрирующего горизонтальное перемещение
Доступ к mysql.westeros.local решает задачу получения доступа к конфиденциальной базе данных. Но давайте попробуем расширить доступ к управлению доменом FreeIPA. Быстрый просмотр /tmp/ выявляет два kerberos CCACHE TGT. Мы можем попытаться перечислить эти билеты с помощью наших привилегий sudo.
Билеты Kerberos CCACHE по умолчанию хранятся в /tmp/.
Klist можно использовать для перечисления принципалов внутри определенных билетов или в текущей сессии
Во FreeIPA учетная запись "admin" примерно эквивалентна учетной записи "Domain Admin" в традиционном каталоге active directory. Перечисление ее разрешений и атрибутов пользователя показывает, что она является членом групп "admins" и "trust admins", а также нескольких правил Sudo и наборов правил HBAC.
Свойства пользователя для учетной записи "admin" в FreeIPA
Имея привилегии sudo, мы можем получить доступ к этой учетной записи, создав копию существующего билета и изменив разрешения, чтобы наш текущий пользовательский контекст мог его использовать. Также можно использовать sudo для создания другого агента в корневом контексте, устраняя необходимость копирования или изменения разрешений билета.
Создание нового агента от имени root
Установка переменной окружения KRB5CCNAME
С этими новыми разрешениями должно быть возможно боковое перемещение на любой хост внутри среды. Давайте проверим эту теорию, получив агента на "vault.westeros.local".
Копирование и выполнение агента с помощью scp и ssh
Регистрация нового агента с сайта vault.westeros.local
Заключение
Несмотря на то, что эта лабораторная среда является небольшим и немного надуманным примером производственной среды FreeIPA, она эффективно демонстрирует, как перечислять разрешения и использовать их для бокового перемещения. Надеемся, теперь мы немного лучше понимаем, как применить некоторые из наших предыдущих знаний о FreeIPA в наступательном контексте.