Оригинал - https://posts.specterops.io/attacking-freeipa-part-iii-finding-a-path-677405b5b95e
Перевёл: Эрмано
Специально для xss.pro
Эта заметка является третьей частью серии, посвященной моему опыту атаки на 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.pro
Эта заметка является третьей частью серии, посвященной моему опыту атаки на FreeIPA. В первой части этой серии мы рассмотрели некоторые предпосылки и базовые технологии, используемые FreeIPA. Мы также обсудили несколько механизмов аутентификации и формы учетных данных, в частности, как определить, разобрать и повторно использовать учетные данные в качестве атакующего. Во второй части этой серии мы обсудили различные типы объектов в среде FreeIPA и их значение, а также то, как эти объекты могут быть перечислены для получения ситуационной осведомленности.
Предыдущие статьи:
- https://xss.pro/threads/122951 - первая часть
- https://xss.pro/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 "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.
Доступ к mysql.westeros.local решает задачу получения доступа к конфиденциальной базе данных. Но давайте попробуем расширить доступ к управлению доменом FreeIPA. Быстрый просмотр /tmp/ выявляет два kerberos CCACHE TGT. Мы можем попытаться перечислить эти билеты с помощью наших привилегий sudo.
Во FreeIPA учетная запись "admin" примерно эквивалентна учетной записи "Domain Admin" в традиционном каталоге active directory. Перечисление ее разрешений и атрибутов пользователя показывает, что она является членом групп "admins" и "trust admins", а также нескольких правил Sudo и наборов правил HBAC.
Имея привилегии sudo, мы можем получить доступ к этой учетной записи, создав копию существующего билета и изменив разрешения, чтобы наш текущий пользовательский контекст мог его использовать. Также можно использовать sudo для создания другого агента в корневом контексте, устраняя необходимость копирования или изменения разрешений билета.
С этими новыми разрешениями должно быть возможно боковое перемещение на любой хост внутри среды. Давайте проверим эту теорию, получив агента на "vault.westeros.local".
Заключение
Несмотря на то, что эта лабораторная среда является небольшим и немного надуманным примером производственной среды FreeIPA, она эффективно демонстрирует, как перечислять разрешения и использовать их для бокового перемещения. Надеемся, теперь мы немного лучше понимаем, как применить некоторые из наших предыдущих знаний о FreeIPA в наступательном контексте.