Большую часть 2019 года я копался в Office 365 и Azure AD и рассматривал функции в рамках разработки новой оценки Trimarc Microsoft Cloud Security Assessment, которая направлена на улучшение состояния безопасности клиентов
Microsoft Office 365 и Azure AD. Изучая каждую из них, я нашел одну очень интересную.
В мае 2020 года я представил некоторые темы безопасности Microsoft Office 365 и Azure Active Directory в веб-трансляции Trimarc под названием «Обеспечение безопасности Office 365 и Azure AD: защита вашего клиента»
и включил описанный в этой статье путь атаки, использующий малоизвестную функцию .
В то время как Azure использует Azure Active Directory для некоторых вещей, роли Azure AD обычно не влияют напрямую на Azure (или Azure RBAC). В этой статье подробно описывается известная конфигурация (по крайней мере, для тех, кто разбирался в
параметрах конфигурации Azure AD), в которой глобальный администратор (также известный как администратор компании) в Azure Active Directory может получить контроль над Azure через вариант клиента. Эта возможность была добавлена как
«аварийный» вариант, который можно использовать для (повторного) получения прав администратора Azure в случае потери такого доступа.
В этом посте я исследую опасность, связанную с этой опцией, как она настроена в настоящее время (по состоянию на май 2020 года).
Ключевой вывод здесь заключается в том, что если вы не будете тщательно защищать и не контролировать членство в роли глобального администратора и связанные учетные записи, вы можете потерять контроль над системами,
размещенными во всех подписках Azure, а также данными служб Office 365.
Примечание:
Большая часть исследований по этой проблеме проводилась в период с августа по декабрь 2019 года, и с тех пор Microsoft, возможно, внесла изменения в функциональность и / или возможности.
Сценарий атаки:
В этом сценарии Acme использует локальную среду Active Directory. Компания Acme использовала инфраструктуру Azure как услугу (IAAS) в качестве дополнительного центра обработки данных и развернула контроллеры домена в Azure для своей
локальной службы AD (в качестве «облачного центра обработки данных»). ИТ-отдел Acme заблокировал контроллеры домена, следуя советам по усилению защиты, и ограничил администрирование Azure виртуальными машинами, на которых размещены
контроллеры домена. У Acme есть другие конфиденциальные приложения, размещенные на серверах в Azure.
Компания Acme подписалась на Office 365 и запустила пилотную версию. Всем администраторам Active Directory и Exchange (и многим другим ИТ-администраторам) предоставляются права временного Глобального Администратора
(также известного как глобальный администратор или GA) для облегчения пилотного проекта. Так что там больше, чем должно быть, и не очень хорошо защищено.
Роль глобального администратора предоставляет полные права администратора для Azure AD и, в конечном итоге, для всех служб Office 365.
В онлайн-документе Microsoft содержится основная информация (26 мая 2020 г.):
Обратите внимание, что здесь ничего не говорится о возможностях Azure.
Как только у нас будет доступ к порталу Azure AD (который по умолчанию обычно используется всеми пользователями Azure AD).
Мы можем просмотреть несколько различных параметров конфигурации для Azure Active Directory, которая контролирует многие аспекты Office 365.
На этой странице показаны свойства каталога и теперь есть новые параметры управления безопасностью по умолчанию.
Внизу находится переключатель «Управление доступом к ресурсам Azure». А вот это интересно….
Атака
Пароль злоумышленника распыляется на среду Acme Office 365 и идентифицирует учетную запись глобального администратора, не имеющую MFA (многофакторной аутентификации). Поскольку MFA настроено менее 10% глобальных администраторов,
так что это реальная угроза.
Злоумышленник создает новую учетную запись глобального администратора (или использует существующую учетную запись).
В этом примере взломана учетная запись глобального администратора Office 365 «AzureAdmin».
Переходим от глобального администратора Office 365 к администратору подписки теневого Azure
Согласно документации Microsoft, переключение этого параметра с «Нет» на «Да» добавляет учетную запись в роль администратора доступа пользователей в Azure RBAC в корневой области (которая контролирует все подписки в клиенте).
Этот параметр доступен только для учетных записей, которые являются членами роли глобального администратора.
Хотя этот параметр настраивается в разделе «Свойства каталога», на самом деле это параметр конфигурации для каждой учетной записи.
Эта «волшебная кнопка» дает возможность управлять ролями Azure, но не дает прямых прав Azure (для виртуальных машин).
На рисунке ниже показано, что происходит с Elevate Access и точкой соединения между Azure AD и Azure.
Меня больше всего беспокоит то, что для многих организаций группа, управляющая Azure AD и Office 365, часто отличается от группы, управляющей Azure. Это означает, что кто-то может повысить права (например, мошенник-администратор),
и никто этого не заметит. Это потенциально серьезная угроза с точки зрения структуры Azure. Особенно в части обнаружения этой проблемы, которая рассматривается в конце этого сообщения.
Я также нашел API, который кажется подходящим, что означает, что злоумышленнику не нужно будет посещать портал Azure AD для выполнения этого действия.
Интересно то, что если для этого параметра установлено значение «Да», когда учетная запись удаляется из роли глобального администратора, роль RBAC Azure остается и не удаляется.
Фактически, аккаунт не может переключить этот параметр обратно на «Нет», пока он снова не получит права глобального администратора.
Злоумышленник определяет, что у Acme есть несколько локальных контроллеров домена AD в Azure. Чтобы использовать эту конфигурацию, злоумышленник решает создать новую учетную запись и использовать ее для доступа к Azure.
Когда управление доступом Azure включено для контролируемой злоумышленником учетной записи (которую я назвал «хакером», чтобы я не забыл, какую учетную запись я использовал), эта учетная запись может входить в систему
управления подпиской Azure и изменять роли.
Вы заметите, что я также добавил пару других, которые «выглядят» так, как будто они легитимны.
Мониторинг изменений в корневой группе RBAC Azure «Администратор доступа пользователей» немного сложен, поскольку, похоже, нет никакого способа просмотреть это на портале Azure. Основной метод проверки - через Azure CLI.
После идентификации учетной записи, которую необходимо удалить, ее необходимо удалить с помощью Azure CLI (поскольку это роль корневого уровня).
Если попытаться удалить учетную запись из роли подписки, появится следующее сообщение, поскольку ее необходимо удалить на корневом уровне.
Когда учетная запись переключает Повышение доступа с Да на Нет, она автоматически удаляется из Администратора доступа пользователей.
Краткое изложение проблемы
Давайте сделаем здесь паузу и вспомним предыдущую конфигурацию.
Злоумышленник взламывает учетную запись глобального администратора организации либо потому, что он только начинает работать с Office 365, либо не осознает рисков, связанных с защитой общих служб. В любом случае учетные записи GA
не были заблокированы с помощью PIM, условного доступа или MFA. ИЛИ токен сеанса GA был украден, потому что GA использует свой веб-браузер на своей рабочей станции обычного пользователя (которая была взломана).
На выполнение этих действий у злоумышленника есть около часа.
Взломать учетную запись, повысить доступ к Azure, получить права Azure через членство в роли Azure, удалить повышенные права доступа, выполнить вредоносные действия на любой или ВСЕХ виртуальных машинах Azure во всех подписках,
а затем удалить членство в роли в Azure (или нет).
Общее необходимое время: всего несколько минут, возможно, всего 15 минут.
Злоумышленник обновляет членство в роли Azure для выполнения команд на виртуальных машинах Azure:
Установка прав «Владелец» для этой учетной записи очевидна (и возможна, как и добавление учетной записи для администратора виртуальной машины). В результате учетная запись, контролируемая злоумышленником,
получит полный доступ к виртуальным машинам Azure.
Изучая различные роли RBAC в Azure, я понял, что более скрытным методом является «Участник виртуальной машины», который звучит довольно безобидно.
Участник виртуальной машины в соответствии с описанием ролей Azure: (https://docs.microsoft.com/en-us/az...ol/built-in-roles#virtual-machine-contributor)
[цитата из сентября 2019 г.]
Это звучит как очень ограниченный доступ к виртуальной машине Azure, пока вы не рассмотрите возможность запуска PowerShell (с правами Системы) на виртуальной машине.
Это право
Это включает возможность повторно включить учетную запись администратора. На контроллере домена в Azure это будет учетная запись RID 500 для домена.
Как только злоумышленник сможет запустить PowerShell на виртуальной машине Azure, он сможет выполнять команды как System.
Я добавил очевидную учетную запись «хакера» и дополнительную, которая выглядит «нормально» (возможно?) Под названием «Учетная запись службы Azure AD».
Оба они могут запускать команды PowerShell.
В этом примере я запускаю команду PowerShell для запуска
Это произойдет на контроллере домена на базе Azure, а затем реплицируется на контроллеры домена на месте.
Примечание. Возможность запускать команды на виртуальной машине Azure характерна не только для локальных контроллеров домена Active Directory, размещенных в Azure, но и для других систем, размещенных там.
Затем я запускаю команду PowerShell модуля Active Directory, чтобы получить членство в группе администраторов домена, и мы видим, что учетная запись была добавлена.
Предполагая, что ведение журнала PowerShell включено (и отправлено в SIEM), можно увидеть выполнение этой команды. Судя по моему опыту, это не обычное дело.
Как только злоумышленник сможет запустить PowerShell в качестве системы на виртуальной машине Azure, он сможет извлечь что угодно из размещенного в облаке контроллера домена, включая хэш пароля krbtgt,
что означает полную компрометацию локальной среды Active Directory.
В этом примере злоумышленник запускает однострочную команду PowerShell Invoke-Mimikatz, которая выгружает хэш пароля из хеша пароля krbtgt AD.
Обратите внимание, что для того, как я его здесь запустил, для этого потребуется доступ в Интернет. Однако можно было бы скрыть и разместить Invoke-Mimikatz в скомпрометированной системе в корпоративной сети (или в клиенте Azure)
и использовать это вместо этого.
Заключение
Заказчик размещает локальные контроллеры домена Active Directory в облаке Azure. У клиента также есть Office 365 с учетными записями администратора, которые не защищены должным образом.
Пароль злоумышленника распыляется на учетные записи компании и определяет пароль глобального администратора Office 365. С помощью этой учетной записи злоумышленник переходит в Azure и запускает PowerShell на виртуальной машине Azure,
на которой размещены локальные контроллеры домена Active Directory компании. Команда PowerShell может обновить группу администраторов домена в Active Directory или создать дамп хэша пароля krbtgt, который позволяет злоумышленнику создавать
«Золотые билеты» Kerberos в автономном режиме, а затем использовать поддельные билеты проверки подлинности Kerberos TGT в локальной среде AD для доступа к любому ресурсу.
От ТС
Эта статья является переводом, статьи взятой вот тут.
Если у вас есть статьи по Active Directory или Azure на примете, не стесняйтесь и кидайте сюда.
Перевод:
Azrv3l cпециально для xss.pro
Microsoft Office 365 и Azure AD. Изучая каждую из них, я нашел одну очень интересную.
В мае 2020 года я представил некоторые темы безопасности Microsoft Office 365 и Azure Active Directory в веб-трансляции Trimarc под названием «Обеспечение безопасности Office 365 и Azure AD: защита вашего клиента»
и включил описанный в этой статье путь атаки, использующий малоизвестную функцию .
В то время как Azure использует Azure Active Directory для некоторых вещей, роли Azure AD обычно не влияют напрямую на Azure (или Azure RBAC). В этой статье подробно описывается известная конфигурация (по крайней мере, для тех, кто разбирался в
параметрах конфигурации Azure AD), в которой глобальный администратор (также известный как администратор компании) в Azure Active Directory может получить контроль над Azure через вариант клиента. Эта возможность была добавлена как
«аварийный» вариант, который можно использовать для (повторного) получения прав администратора Azure в случае потери такого доступа.
В этом посте я исследую опасность, связанную с этой опцией, как она настроена в настоящее время (по состоянию на май 2020 года).
Ключевой вывод здесь заключается в том, что если вы не будете тщательно защищать и не контролировать членство в роли глобального администратора и связанные учетные записи, вы можете потерять контроль над системами,
размещенными во всех подписках Azure, а также данными служб Office 365.
Примечание:
Большая часть исследований по этой проблеме проводилась в период с августа по декабрь 2019 года, и с тех пор Microsoft, возможно, внесла изменения в функциональность и / или возможности.
Сценарий атаки:
В этом сценарии Acme использует локальную среду Active Directory. Компания Acme использовала инфраструктуру Azure как услугу (IAAS) в качестве дополнительного центра обработки данных и развернула контроллеры домена в Azure для своей
локальной службы AD (в качестве «облачного центра обработки данных»). ИТ-отдел Acme заблокировал контроллеры домена, следуя советам по усилению защиты, и ограничил администрирование Azure виртуальными машинами, на которых размещены
контроллеры домена. У Acme есть другие конфиденциальные приложения, размещенные на серверах в Azure.
Компания Acme подписалась на Office 365 и запустила пилотную версию. Всем администраторам Active Directory и Exchange (и многим другим ИТ-администраторам) предоставляются права временного Глобального Администратора
(также известного как глобальный администратор или GA) для облегчения пилотного проекта. Так что там больше, чем должно быть, и не очень хорошо защищено.
Роль глобального администратора предоставляет полные права администратора для Azure AD и, в конечном итоге, для всех служб Office 365.
В онлайн-документе Microsoft содержится основная информация (26 мая 2020 г.):
https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-rolesОбратите внимание, что здесь ничего не говорится о возможностях Azure.
Как только у нас будет доступ к порталу Azure AD (который по умолчанию обычно используется всеми пользователями Azure AD).
Мы можем просмотреть несколько различных параметров конфигурации для Azure Active Directory, которая контролирует многие аспекты Office 365.
На этой странице показаны свойства каталога и теперь есть новые параметры управления безопасностью по умолчанию.
Внизу находится переключатель «Управление доступом к ресурсам Azure». А вот это интересно….
Атака
Пароль злоумышленника распыляется на среду Acme Office 365 и идентифицирует учетную запись глобального администратора, не имеющую MFA (многофакторной аутентификации). Поскольку MFA настроено менее 10% глобальных администраторов,
так что это реальная угроза.
Злоумышленник создает новую учетную запись глобального администратора (или использует существующую учетную запись).
В этом примере взломана учетная запись глобального администратора Office 365 «AzureAdmin».
Переходим от глобального администратора Office 365 к администратору подписки теневого Azure
Согласно документации Microsoft, переключение этого параметра с «Нет» на «Да» добавляет учетную запись в роль администратора доступа пользователей в Azure RBAC в корневой области (которая контролирует все подписки в клиенте).
Этот параметр доступен только для учетных записей, которые являются членами роли глобального администратора.
Хотя этот параметр настраивается в разделе «Свойства каталога», на самом деле это параметр конфигурации для каждой учетной записи.
Эта «волшебная кнопка» дает возможность управлять ролями Azure, но не дает прямых прав Azure (для виртуальных машин).
На рисунке ниже показано, что происходит с Elevate Access и точкой соединения между Azure AD и Azure.
Меня больше всего беспокоит то, что для многих организаций группа, управляющая Azure AD и Office 365, часто отличается от группы, управляющей Azure. Это означает, что кто-то может повысить права (например, мошенник-администратор),
и никто этого не заметит. Это потенциально серьезная угроза с точки зрения структуры Azure. Особенно в части обнаружения этой проблемы, которая рассматривается в конце этого сообщения.
Я также нашел API, который кажется подходящим, что означает, что злоумышленнику не нужно будет посещать портал Azure AD для выполнения этого действия.
Интересно то, что если для этого параметра установлено значение «Да», когда учетная запись удаляется из роли глобального администратора, роль RBAC Azure остается и не удаляется.
Фактически, аккаунт не может переключить этот параметр обратно на «Нет», пока он снова не получит права глобального администратора.
Злоумышленник определяет, что у Acme есть несколько локальных контроллеров домена AD в Azure. Чтобы использовать эту конфигурацию, злоумышленник решает создать новую учетную запись и использовать ее для доступа к Azure.
Когда управление доступом Azure включено для контролируемой злоумышленником учетной записи (которую я назвал «хакером», чтобы я не забыл, какую учетную запись я использовал), эта учетная запись может входить в систему
управления подпиской Azure и изменять роли.
Вы заметите, что я также добавил пару других, которые «выглядят» так, как будто они легитимны.
Мониторинг изменений в корневой группе RBAC Azure «Администратор доступа пользователей» немного сложен, поскольку, похоже, нет никакого способа просмотреть это на портале Azure. Основной метод проверки - через Azure CLI.
Bash:
az role assignment list --role "User Access Administrator" --scope "/"После идентификации учетной записи, которую необходимо удалить, ее необходимо удалить с помощью Azure CLI (поскольку это роль корневого уровня).
Если попытаться удалить учетную запись из роли подписки, появится следующее сообщение, поскольку ее необходимо удалить на корневом уровне.
Когда учетная запись переключает Повышение доступа с Да на Нет, она автоматически удаляется из Администратора доступа пользователей.
Bash:
Get-AzRoleAssigment | where {$_.RoleDefinitionName -eq "User Access Administrator" ` -and $_.SingInName -eq "<username@example.com>" -and $_.Scope -eq "/"}Краткое изложение проблемы
Давайте сделаем здесь паузу и вспомним предыдущую конфигурацию.
- Злоумышленник взламывает учетную запись глобального администратора, используя пароль для клиента Office 365 Acme, и находит его с неверным паролем (без MFA). ИЛИ токен сеанса GA был украден, потому что GA использует свой веб-браузер на своей рабочей станции обычного пользователя (которая была взломана)
- Злоумышленник аутентифицируется с помощью этой учетной записи и использует права учетной записи для создания другой учетной записи, используемой для атаки, или использования взломанной учетной записи.
- Злоумышленник переключает параметр «Управление доступом к ресурсам Azure» на «да», что добавляет учетную запись Azure AD к роли «Администратор доступа пользователей» Azure RBAC на корневом уровне, которая применяется ко всем подпискам.
- Администратор доступа пользователей предоставляет возможность изменять членство в любой группе в Azure.
- Теперь злоумышленник может настроить любую учетную запись Azure AD для получения привилегированных прав на подписки Azure и / или виртуальные машины Azure.
Злоумышленник взламывает учетную запись глобального администратора организации либо потому, что он только начинает работать с Office 365, либо не осознает рисков, связанных с защитой общих служб. В любом случае учетные записи GA
не были заблокированы с помощью PIM, условного доступа или MFA. ИЛИ токен сеанса GA был украден, потому что GA использует свой веб-браузер на своей рабочей станции обычного пользователя (которая была взломана).
На выполнение этих действий у злоумышленника есть около часа.
Взломать учетную запись, повысить доступ к Azure, получить права Azure через членство в роли Azure, удалить повышенные права доступа, выполнить вредоносные действия на любой или ВСЕХ виртуальных машинах Azure во всех подписках,
а затем удалить членство в роли в Azure (или нет).
Общее необходимое время: всего несколько минут, возможно, всего 15 минут.
Злоумышленник обновляет членство в роли Azure для выполнения команд на виртуальных машинах Azure:
Установка прав «Владелец» для этой учетной записи очевидна (и возможна, как и добавление учетной записи для администратора виртуальной машины). В результате учетная запись, контролируемая злоумышленником,
получит полный доступ к виртуальным машинам Azure.
Изучая различные роли RBAC в Azure, я понял, что более скрытным методом является «Участник виртуальной машины», который звучит довольно безобидно.
Участник виртуальной машины в соответствии с описанием ролей Azure: (https://docs.microsoft.com/en-us/az...ol/built-in-roles#virtual-machine-contributor)
«Позволяет вам управлять виртуальными машинами, не получая к ним доступ, и не получая доступ в виртуальную сеть или учетной записи хранения, к которой они подключены». [цитата из сентября 2019 г.]
Это звучит как очень ограниченный доступ к виртуальной машине Azure, пока вы не рассмотрите возможность запуска PowerShell (с правами Системы) на виртуальной машине.
Это право
Microsoft.Compute/virtualMachines/runCommand/action, которое входит в состав Virtual Machine Contributor.Это включает возможность повторно включить учетную запись администратора. На контроллере домена в Azure это будет учетная запись RID 500 для домена.
Как только злоумышленник сможет запустить PowerShell на виртуальной машине Azure, он сможет выполнять команды как System.
Я добавил очевидную учетную запись «хакера» и дополнительную, которая выглядит «нормально» (возможно?) Под названием «Учетная запись службы Azure AD».
Оба они могут запускать команды PowerShell.
В этом примере я запускаю команду PowerShell для запуска
net localgroup, которая обновляет локальную группу администраторов. Когда это выполняется на контроллере домена, это относится к группе администраторов домена. Это произойдет на контроллере домена на базе Azure, а затем реплицируется на контроллеры домена на месте.
Примечание. Возможность запускать команды на виртуальной машине Azure характерна не только для локальных контроллеров домена Active Directory, размещенных в Azure, но и для других систем, размещенных там.
Затем я запускаю команду PowerShell модуля Active Directory, чтобы получить членство в группе администраторов домена, и мы видим, что учетная запись была добавлена.
Предполагая, что ведение журнала PowerShell включено (и отправлено в SIEM), можно увидеть выполнение этой команды. Судя по моему опыту, это не обычное дело.
Как только злоумышленник сможет запустить PowerShell в качестве системы на виртуальной машине Azure, он сможет извлечь что угодно из размещенного в облаке контроллера домена, включая хэш пароля krbtgt,
что означает полную компрометацию локальной среды Active Directory.
В этом примере злоумышленник запускает однострочную команду PowerShell Invoke-Mimikatz, которая выгружает хэш пароля из хеша пароля krbtgt AD.
Обратите внимание, что для того, как я его здесь запустил, для этого потребуется доступ в Интернет. Однако можно было бы скрыть и разместить Invoke-Mimikatz в скомпрометированной системе в корпоративной сети (или в клиенте Azure)
и использовать это вместо этого.
Заключение
Заказчик размещает локальные контроллеры домена Active Directory в облаке Azure. У клиента также есть Office 365 с учетными записями администратора, которые не защищены должным образом.
Пароль злоумышленника распыляется на учетные записи компании и определяет пароль глобального администратора Office 365. С помощью этой учетной записи злоумышленник переходит в Azure и запускает PowerShell на виртуальной машине Azure,
на которой размещены локальные контроллеры домена Active Directory компании. Команда PowerShell может обновить группу администраторов домена в Active Directory или создать дамп хэша пароля krbtgt, который позволяет злоумышленнику создавать
«Золотые билеты» Kerberos в автономном режиме, а затем использовать поддельные билеты проверки подлинности Kerberos TGT в локальной среде AD для доступа к любому ресурсу.
От ТС
Эта статья является переводом, статьи взятой вот тут.
Если у вас есть статьи по Active Directory или Azure на примете, не стесняйтесь и кидайте сюда.
Перевод:
Azrv3l cпециально для xss.pro