Если вы когда-либо оказывались в ситуации, когда вам нужно было оценить безопасность среды AWS, одним из наиболее важных сервисов, на который стоит обратить внимание, является управление идентификацией и доступом (IAM). Некоторые неправильные конфигурации IAM очень эффективны и легко обнаруживаются, как, например, пользователи, у которых отсутствует MFA. Тем не менее, другие неправильные настройки столь же важны, но их значительно труднее определить, например, у каких пользователей и ролей есть непреднамеренные способы получения административного доступа к учетной записи AWS. Этот пост и соответствующий инструмент https://github.com/BishopFox/iam-vulnerable были созданы, чтобы помочь пентестерам и специалистам по безопасности лучше понять, как выявлять и использовать распространенные неверные конфигурации IAM, которые позволяют повысить привилегии.
(И не забудьте прочитать это https://labs.bishopfox.com/tech-blog/iam-vulnerable-assessing-the-aws-assessment-tools).
Преднамеренно уязвимая инфраструктура как код
IAM Vulnerable использует двоичный файл Terraform для развертывания более 250 ресурсов IAM в выбранной вами учетной записи AWS, так что в течение нескольких минут вы можете начать изучение того, как выявлять и затем использовать намеренно уязвимые конфигурации IAM, позволяющие повысить привилегии. Первоначально проект начинался как реализация Terraform среды Гербена; однако в него вошли более уязвимые конфигурации, которые обычно наблюдаются во время наших тестов на проникновение в облако, такие как цепочки предполагаемых ролей, которые приводят к эскалации привилегий, и другие методы, которые были обнаружены после первоначального исследования Спенсера в 2018 году. На момент выпуска существует 31 уникальный тестовый пример повышения привилегий.
Сценарии использования: идентификация и эксплуатация
Я создал IAM Vulnerable, имея в виду только один вариант использования: автоматическое создание и удаление уязвимой конфигурации IAM в изолированной учетной записи AWS для отработки эксплуатации. Однако стал очевиден второй вариант использования. Имея под рукой намеренно уязвимую игровую площадку, у меня было прекрасное место, чтобы проверить эффективность различных инструментов оценки, которые помогают в идентификации. Я подробно рассмотрю эту тему во второй части статьи.
В этом посте мы расcмотрим:
Как использовать IAM Vulnerable
- Шаг 1. Выберите или создайте учетную запись AWS.
- Шаг 2. Создайте пользователя без полномочий root с правами администратора.
- Шаг 3. Разверните модули IAM Vulnerable Terraform в своей учетной записи.
- Шаг 4. Изучите способы повышения привилегий AWS IAM.
- Шаг 5. Попрактикуйтесь в эксплуатации с использованием вновь созданных пользователей и ролей.
* Поддержка эскалаций привилегий
* Заключение
Как использовать уязвимость IAM
В следующих разделах представлен обзор того, как можно использовать IAM Vulnerable, чтобы получить практический опыт выявления и использования неправильных конфигураций IAM, которые могут привести к эскалации привилегий.
Шаг 1. Выберите или создайте учетную запись AWS
Если у вас уже есть учетная запись AWS для площадки, вы можете использовать ее. Если у вас еще нет учетной записи, создайте новую, чтобы использовать ее в качестве уязвимой площадки.
Прежде чем что-либо развертывать, одно предостережение: я настоятельно рекомендую создать отдельную учетную запись специально для этого варианта использования и не применять эту конфигурацию к какой-либо производственной учетной записи. Для всех путей повышения привилегий требуется аутентифицированный доступ к учетной записи AWS, поэтому вам не нужно беспокоиться о непреднамеренных анонимных или внешних угрозах, но вам по-прежнему не нужен ни один из этих путей в производственной среде.
Шаг 2. Создайте пользователя без полномочий root с правами администратора
Остался еще один шаг, прежде чем вы сможете использовать Terraform для создания своей уязвимой площадки для IAM. Вам нужно будет выбрать пользователя или роль AWS с разрешением на применение ресурсов в вашей учетной записи. По замыслу, каждая роль, которую IAM Vulnerable создает для вас, может быть взята на себя принципалом, который вы используете для запуска Terraform. Однако пользователи root не могут брать на себя роли, поэтому вы не хотите использовать пользователя root для развертывания IAM Vulnerable. Вам потребуется создать пользователя без полномочий root с правами администратора. Вот пример того, как это сделать с помощью документации AWS:
1. Создайте пользователя без полномочий root с правами администратора (https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html)
2. Создайте ключ доступа для этого пользователя (https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)
3. Установите AWS CLI (https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
4. Настройте интерфейс командной строки AWS (https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html) с пользователем-администратором в качестве профиля по умолчанию.
Примечание. Вы можете запустить IAM Vulnerable, используя профиль AWS, отличный от профиля по умолчанию, если хотите. Ознакомьтесь с разделом https://github.com/BishopFox/iam-vu...ofile-other-than-the-default-to-run-terraform в репозитории GitHub для руководство.
Вы можете использовать aws sts get-caller-identity, чтобы убедиться, что ваш профиль настроен правильно:
Убедившись, что ваш интерфейс командной строки работает должным образом, вы готовы к установке Terraform и развертыванию IAM Vulnerable.
Шаг 3. Разверните модули Terraform Vulnerable IAM в своей учетной записи
Для начала вам необходимо установить двоичный файл Terraform, настроить клиент AWS и клонировать репозиторий IAM-Vulnerable. Процесс выглядит примерно так:
1. Установите б инарный файл Terraform (https://www.terraform.io/downloads.html) ,и добавьте двоичное расположение в свой путь.
2. Склонируйте https://github.com/BishopFox/iam-vulnerable репозиторий:
git clone https://github.com/BishopFox/iam-vulnerable
Модульный подход
В репозитории IAM Vulnerable вы заметите несколько модулей, разделенных на две основные категории: бесплатные ресурсы и несвободные ресурсы. Если вы не знакомы с Terraform, подумайте об этих модулях как об автономных наборах ресурсов AWS, которые объединяются или удаляются вместе.
Хотя большинство путей повышения привилегий можно использовать после развертывания только модуля free-resources/privesc-paths, который включен по умолчанию, есть несколько путей, которые нельзя использовать, если не развернуты другие несвободные ресурсы, например Экземпляры EC2 или лямбда-функции. Поскольку с этими другими ресурсами связаны денежные затраты, они не включены по умолчанию.
Модульный подход позволяет вам начать с бесплатных ресурсов, а затем развернуть несвободные ресурсы позже, просто раскомментировать соответствующие модули.
Развертывание бесплатных ресурсов
Следующие несколько шагов позволят развернуть ресурсы из модуля бесплатных ресурсов в вашей учетной записи AWS:
1.cd iam-vulnerable/
2.terraform init
3.terraform apply
После применения конфигурации двоичный файл Terraform выполнит аутентификацию в AWS с использованием указанного вами профиля и развернет все уязвимые ресурсы IAM из модулей свободных ресурсов в целевую учетную запись. Это включает примерно 30 наборов пользователей, ролей и политик, которые соответствуют каждому из уникальных путей эксплойтов для административного доступа к учетной записи на игровой площадке. Использование этих ресурсов не требует затрат на AWS.
Когда вы запускаете terraform apply, двоичный файл Terraform создаст ресурсы в вашей учетной записи AWS, как показано на рисунке ниже:
Если вы хотите удалить из этого модуля все ресурсы, созданные Terraform, вам понадобится всего одна команда:
Развертывание несвободных ресурсов по мере необходимости
Как упоминалось выше, некоторые пути эксплойтов нельзя эксплуатировать, если не присутствуют определенные типы ресурсов. Например, если у вас есть разрешение ssm:StartSession и запущен экземпляр EC2 с подключенной высокопривилегированной ролью и поддерживает агент AWS Systems Manager (SSM), вы можете использовать ssm:StartSession для доступа к экземпляру и privesc с помощью к экземпляру прикреплена высокопривилегированная роль. Однако для успешной практики с этим путем эксплойта вам понадобится экземпляр EC2 с прикрепленной высокопривилегированной ролью.
Когда вы будете готовы поиграть с путями эксплойтов, такими как ssm: StartSession, которые задействуют ресурсы вне IAM, вы можете развернуть и удалить эти ресурсы по запросу, раскомментировав модуль в файле iam-weak / main.tf, как показано ниже:
После того, как вы раскомментировали модуль ec2, запустите terraform init, чтобы установить новый модуль, а затем применить terraform для развертывания ресурсов в новом модуле.
Когда вы закончите использовать несвободный модуль, вы можете просто закомментировать его снова и запустить terraform apply, чтобы удалить ресурсы:
Этот модульный подход позволяет минимизировать затраты за счет включения каждого набора несвободных ресурсов по мере необходимости. Я включил ежемесячную стоимость каждого модуля в IAM Vulnerable README, а также таблицу, в которой показано, какие пути эксплойтов зависят от дополнительных модулей.
Шаг 4. Изучите способы повышения привилегий AWS IAM
Теперь, когда ваша среда настроена, вы готовы к эксплуатации. Если вы новичок в повышении привилегий IAM, потратьте некоторое время на ознакомление с типами возможных путей повышения привилегий и необходимыми предварительными условиями. Вот несколько полезных ссылок:
-https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/
-https://labs.bishopfox.com/tech-blog/privilege-escalation-in-aws
-https://labs.bishopfox.com/tech-blog/5-privesc-attack-vectors-in-aws
-https://github.com/RhinoSecurityLabs/AWS-IAM-Privilege-Escalation
Шаг 5. Попрактикуйтесь в эксплуатации с помощью вновь созданных пользователей и ролей
Используя ресурсы, перечисленные выше, теперь вы готовы начать проходить по путям privesc, указанным в блоше https://labs.bishopfox.com/tech-blog/privilege-escalation-in-aws. Я не буду здесь повторять все этапы эксплуатации, так как сообщение Гербена сегодня так же полезно, как и в 2019 году. Однако я кратко расскажу, как установить все ваши новые уязвимые роли в файле учетных данных, чтобы вы могли легко переключаться между ними.
Пользователи IAM и роли
Во-первых, очень краткое руководство по пользователям IAM и ролям с точки зрения безопасности. Проблема с пользователями IAM заключается в том, что они могут создавать долговечные ключи доступа. Если эти ключи потеряны или взломаны, они могут повредить бизнесу. Как вы можете догадаться, мы все еще находим эти ключи доступа там, где им не место, во время большинства проводимых нами тестов на проникновение в облако. Короче говоря, долговечные ключи доступа - это плохо. Итак, какое решение? Согласно AWS, вы должны отказаться от пользователей IAM и перейти на роли IAM. Роли используют временные учетные данные, срок действия которых истекает, поэтому гораздо меньше риска, что эти учетные данные будут случайно зарегистрированы в Git, сохранены в корзине S3 или сброшены на Pastebin. Чтобы роли работали бесперебойно, ваши пользователи проходят аутентификацию с помощью решения SSO, такого как Okta или AWS SSO, и это решение сопоставляет, какие роли IAM вам разрешено принимать.
Это актуально, потому что некоторые пути privesc доступны только для ролей, а другие доступны только для пользователей. Из-за этого IAM Vulnerable создает как роль, так и пользователя для каждого пути privesc. Я рекомендую научиться работать с обоими типами принципалов IAM.
Ключи доступа пользователя
Каждый путь privesc создает пользователя и набор ключей доступа. Чтобы найти учетные данные для доступа пользователя IAM, созданного Terraform, загляните в файл iam-weak/terraform.tfstate. Просто найдите пользователя, которого хотите использовать, и добавьте эти учетные данные в новый профиль в своем файле учетных данных.
Роли, это легкий путь.
Знаете ли вы, что вы можете настроить профиль для интерфейса командной строки AWS, который ссылается на другой профиль, если между двумя ролями существует доверие IAM? При такой настройке принятие целевой роли происходит прозрачно, если вы используете правильное имя профиля с интерфейсом командной строки AWS. В репозиторий я включил сэмпл https://github.com/BishopFox/iam-vulnerable/blob/main/aws_credentials_file_example, который вы можете использовать в качестве руководства при настройке. Вот фрагмент примера файла конфигурации (i.e., ~/.aws/credentials):
В этом сценарии мы использовали профиль по умолчанию для применения модулей IAM Vulnerable. Все, что вам нужно сделать, это заменить указанный выше номер счета-заполнителя на номер своего реального аккаунта.
В конфигурации, показанной выше, если вы хотите запустить команду с ролью privesc1-CreateNewPolicyVersion-role, все, что вам нужно сделать, это использовать профиль privesc1:
За кулисами интерфейс командной строки AWS использовал пользователя, указанного в профиле по умолчанию, чтобы взять на себя роль privesc1-CreateNewPolicyVersion-role.
Использовать демонстрацию с использованием предполагаемой роли
Следующая демонстрация показывает, как использовать privesc1-CreateNewPolicyVersion-role для создания новой версии политики, которая предоставляет себе права администратора.
Поскольку privesc1-CreateNewPolicyVersion-role имеет разрешение только на выполнение одного действия для запуска, privesc1 сначала даже не может перечислить пользователей IAM:
Теперь давайте обновим эту политику (не забудьте заменить 111111111111 идентификатором своего аккаунта):
Наконец, давайте попробуем снова составить список пользователей IAM, все еще используя privesc1-CreateNewPolicyVersion-role:
Круто! Мы просто использовали профиль privesc1, чтобы выполнить путь privesc CreatePolicyVersion и стать эффективным администратором.
Поддерживаемые пути повышения привилегий
В таблице ниже перечислены 31 путь повышения привилегий, который IAM Vulnerable поддерживает по состоянию на август 2021 года. Этот список включает 21 исходный путь privesc, указанный Спенсером Гитценом, и 10 дополнительных путей, которые я добавил. Большинство новых путей, таких как SSM-SendCommand, SSM-StartSession и CodeBuild-CreateProjectPassRole, были добавлены в IAM Vulnerable после того, как я заметил, что Эрик Стерингер добавил их в Principal Mapper (https://github.com/nccgroup/PMapper) . Другие, такие как EC2InstanceConnect-SendSSHPublicKey, были добавлены на основе оригинального исследования.
Заключение
Предоставление разрешений IAM принципалам AWS, предотвращающих непреднамеренное повышение привилегий, является сложной задачей, и в рамках модели совместной ответственности ответственность за управление этими политиками лежит на клиенте AWS. Отрасль информационной безопасности нуждается в большем количестве специалистов-практиков, которые могут идентифицировать непреднамеренные пути повышения привилегий и продемонстрировать влияние эксплуатации.
IAM Vulnerable позволит вам создать частную среду, в которой вы можете повысить свои навыки IAM privesc от новичка до эксперта в удобном для вас темпе, в своей учетной записи AWS. Вы можете попрактиковаться в эксплуатации повышения привилегий в AWS IAM и протестировать свои любимые инструменты с ними, чтобы более комфортно идентифицироваться. Вы даже можете использовать его в качестве испытательного стенда при создании новых инструментов или обновлении существующих. Я надеюсь, что этот проект вселит в вас уверенность и опыт, которые потребуются для выявления подобных проблем в реальных условиях и помощи в их устранении.
Во второй части этой серии я опробую свои любимые инструменты оценки IAM privesc на площадке, созданной IAM Vulnerable, чтобы увидеть, как работает каждый инструмент, и сделаю обзор возможностей, сильных и слабых сторон каждого инструмента.
Не пропустите часть 2 часть (https://labs.bishopfox.com/tech-blog/iam-vulnerable-assessing-the-aws-assessment-tools) моей серии статей о уязвимостях IAM, где я обсуждаю идентификационный аспект повышения привилегий IAM в целевой учетной записи. Я делюсь своими любимыми инструментами оценки privesc IAM и прихожу к выводу, что, хотя каждый из этих инструментов бесценен для тестировщика на проникновение, ни один из них не может идентифицировать все известные пути privesc, одновременно удаляя все ложные срабатывания.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://labs.bishopfox.com/tech-blog/iam-vulnerable-an-aws-iam-privilege-escalation-playground
(И не забудьте прочитать это https://labs.bishopfox.com/tech-blog/iam-vulnerable-assessing-the-aws-assessment-tools).
Background
В 2018 году Spencer Gietzen (https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation) описал 21 разрешение или комбинацию разрешений, которые позволяют повышать привилегии. В 2019 году Bishop Fox’s показал (https://labs.bishopfox.com/tech-blog/privilege-escalation-in-aws), как вручную использовать каждый из 21 пути повышения привилегий AWS. Исследование Гербена потребовало создания десятков пользователей, ролей, политик и других ресурсов, необходимых для успешной эксплуатации. Когда я сам погрузился в изучение того, как определять и использовать повышение привилегий AWS IAM, я искал простой способ создать все уязвимые пути эскалации, описанные в блоге Гербена, но не смог его найти. Так родился IAM Vulnerable.
Преднамеренно уязвимая инфраструктура как код
IAM Vulnerable использует двоичный файл Terraform для развертывания более 250 ресурсов IAM в выбранной вами учетной записи AWS, так что в течение нескольких минут вы можете начать изучение того, как выявлять и затем использовать намеренно уязвимые конфигурации IAM, позволяющие повысить привилегии. Первоначально проект начинался как реализация Terraform среды Гербена; однако в него вошли более уязвимые конфигурации, которые обычно наблюдаются во время наших тестов на проникновение в облако, такие как цепочки предполагаемых ролей, которые приводят к эскалации привилегий, и другие методы, которые были обнаружены после первоначального исследования Спенсера в 2018 году. На момент выпуска существует 31 уникальный тестовый пример повышения привилегий.
Сценарии использования: идентификация и эксплуатация
Я создал IAM Vulnerable, имея в виду только один вариант использования: автоматическое создание и удаление уязвимой конфигурации IAM в изолированной учетной записи AWS для отработки эксплуатации. Однако стал очевиден второй вариант использования. Имея под рукой намеренно уязвимую игровую площадку, у меня было прекрасное место, чтобы проверить эффективность различных инструментов оценки, которые помогают в идентификации. Я подробно рассмотрю эту тему во второй части статьи.
В этом посте мы расcмотрим:
Как использовать IAM Vulnerable
- Шаг 1. Выберите или создайте учетную запись AWS.
- Шаг 2. Создайте пользователя без полномочий root с правами администратора.
- Шаг 3. Разверните модули IAM Vulnerable Terraform в своей учетной записи.
- Шаг 4. Изучите способы повышения привилегий AWS IAM.
- Шаг 5. Попрактикуйтесь в эксплуатации с использованием вновь созданных пользователей и ролей.
* Поддержка эскалаций привилегий
* Заключение
Как использовать уязвимость IAM
В следующих разделах представлен обзор того, как можно использовать IAM Vulnerable, чтобы получить практический опыт выявления и использования неправильных конфигураций IAM, которые могут привести к эскалации привилегий.
Шаг 1. Выберите или создайте учетную запись AWS
Если у вас уже есть учетная запись AWS для площадки, вы можете использовать ее. Если у вас еще нет учетной записи, создайте новую, чтобы использовать ее в качестве уязвимой площадки.
Прежде чем что-либо развертывать, одно предостережение: я настоятельно рекомендую создать отдельную учетную запись специально для этого варианта использования и не применять эту конфигурацию к какой-либо производственной учетной записи. Для всех путей повышения привилегий требуется аутентифицированный доступ к учетной записи AWS, поэтому вам не нужно беспокоиться о непреднамеренных анонимных или внешних угрозах, но вам по-прежнему не нужен ни один из этих путей в производственной среде.
Шаг 2. Создайте пользователя без полномочий root с правами администратора
Остался еще один шаг, прежде чем вы сможете использовать Terraform для создания своей уязвимой площадки для IAM. Вам нужно будет выбрать пользователя или роль AWS с разрешением на применение ресурсов в вашей учетной записи. По замыслу, каждая роль, которую IAM Vulnerable создает для вас, может быть взята на себя принципалом, который вы используете для запуска Terraform. Однако пользователи root не могут брать на себя роли, поэтому вы не хотите использовать пользователя root для развертывания IAM Vulnerable. Вам потребуется создать пользователя без полномочий root с правами администратора. Вот пример того, как это сделать с помощью документации AWS:
1. Создайте пользователя без полномочий root с правами администратора (https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html)
2. Создайте ключ доступа для этого пользователя (https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)
3. Установите AWS CLI (https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
4. Настройте интерфейс командной строки AWS (https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html) с пользователем-администратором в качестве профиля по умолчанию.
Примечание. Вы можете запустить IAM Vulnerable, используя профиль AWS, отличный от профиля по умолчанию, если хотите. Ознакомьтесь с разделом https://github.com/BishopFox/iam-vu...ofile-other-than-the-default-to-run-terraform в репозитории GitHub для руководство.
Вы можете использовать aws sts get-caller-identity, чтобы убедиться, что ваш профиль настроен правильно:
Убедившись, что ваш интерфейс командной строки работает должным образом, вы готовы к установке Terraform и развертыванию IAM Vulnerable.
Шаг 3. Разверните модули Terraform Vulnerable IAM в своей учетной записи
Для начала вам необходимо установить двоичный файл Terraform, настроить клиент AWS и клонировать репозиторий IAM-Vulnerable. Процесс выглядит примерно так:
1. Установите б инарный файл Terraform (https://www.terraform.io/downloads.html) ,и добавьте двоичное расположение в свой путь.
2. Склонируйте https://github.com/BishopFox/iam-vulnerable репозиторий:
git clone https://github.com/BishopFox/iam-vulnerable
Модульный подход
В репозитории IAM Vulnerable вы заметите несколько модулей, разделенных на две основные категории: бесплатные ресурсы и несвободные ресурсы. Если вы не знакомы с Terraform, подумайте об этих модулях как об автономных наборах ресурсов AWS, которые объединяются или удаляются вместе.
Хотя большинство путей повышения привилегий можно использовать после развертывания только модуля free-resources/privesc-paths, который включен по умолчанию, есть несколько путей, которые нельзя использовать, если не развернуты другие несвободные ресурсы, например Экземпляры EC2 или лямбда-функции. Поскольку с этими другими ресурсами связаны денежные затраты, они не включены по умолчанию.
Модульный подход позволяет вам начать с бесплатных ресурсов, а затем развернуть несвободные ресурсы позже, просто раскомментировать соответствующие модули.
Развертывание бесплатных ресурсов
Следующие несколько шагов позволят развернуть ресурсы из модуля бесплатных ресурсов в вашей учетной записи AWS:
1.cd iam-vulnerable/
2.terraform init
3.terraform apply
После применения конфигурации двоичный файл Terraform выполнит аутентификацию в AWS с использованием указанного вами профиля и развернет все уязвимые ресурсы IAM из модулей свободных ресурсов в целевую учетную запись. Это включает примерно 30 наборов пользователей, ролей и политик, которые соответствуют каждому из уникальных путей эксплойтов для административного доступа к учетной записи на игровой площадке. Использование этих ресурсов не требует затрат на AWS.
Когда вы запускаете terraform apply, двоичный файл Terraform создаст ресурсы в вашей учетной записи AWS, как показано на рисунке ниже:
Если вы хотите удалить из этого модуля все ресурсы, созданные Terraform, вам понадобится всего одна команда:
Развертывание несвободных ресурсов по мере необходимости
Как упоминалось выше, некоторые пути эксплойтов нельзя эксплуатировать, если не присутствуют определенные типы ресурсов. Например, если у вас есть разрешение ssm:StartSession и запущен экземпляр EC2 с подключенной высокопривилегированной ролью и поддерживает агент AWS Systems Manager (SSM), вы можете использовать ssm:StartSession для доступа к экземпляру и privesc с помощью к экземпляру прикреплена высокопривилегированная роль. Однако для успешной практики с этим путем эксплойта вам понадобится экземпляр EC2 с прикрепленной высокопривилегированной ролью.
Когда вы будете готовы поиграть с путями эксплойтов, такими как ssm: StartSession, которые задействуют ресурсы вне IAM, вы можете развернуть и удалить эти ресурсы по запросу, раскомментировав модуль в файле iam-weak / main.tf, как показано ниже:
После того, как вы раскомментировали модуль ec2, запустите terraform init, чтобы установить новый модуль, а затем применить terraform для развертывания ресурсов в новом модуле.
Когда вы закончите использовать несвободный модуль, вы можете просто закомментировать его снова и запустить terraform apply, чтобы удалить ресурсы:
Этот модульный подход позволяет минимизировать затраты за счет включения каждого набора несвободных ресурсов по мере необходимости. Я включил ежемесячную стоимость каждого модуля в IAM Vulnerable README, а также таблицу, в которой показано, какие пути эксплойтов зависят от дополнительных модулей.
Шаг 4. Изучите способы повышения привилегий AWS IAM
Теперь, когда ваша среда настроена, вы готовы к эксплуатации. Если вы новичок в повышении привилегий IAM, потратьте некоторое время на ознакомление с типами возможных путей повышения привилегий и необходимыми предварительными условиями. Вот несколько полезных ссылок:
-https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/
-https://labs.bishopfox.com/tech-blog/privilege-escalation-in-aws
-https://labs.bishopfox.com/tech-blog/5-privesc-attack-vectors-in-aws
-https://github.com/RhinoSecurityLabs/AWS-IAM-Privilege-Escalation
Шаг 5. Попрактикуйтесь в эксплуатации с помощью вновь созданных пользователей и ролей
Используя ресурсы, перечисленные выше, теперь вы готовы начать проходить по путям privesc, указанным в блоше https://labs.bishopfox.com/tech-blog/privilege-escalation-in-aws. Я не буду здесь повторять все этапы эксплуатации, так как сообщение Гербена сегодня так же полезно, как и в 2019 году. Однако я кратко расскажу, как установить все ваши новые уязвимые роли в файле учетных данных, чтобы вы могли легко переключаться между ними.
Пользователи IAM и роли
Во-первых, очень краткое руководство по пользователям IAM и ролям с точки зрения безопасности. Проблема с пользователями IAM заключается в том, что они могут создавать долговечные ключи доступа. Если эти ключи потеряны или взломаны, они могут повредить бизнесу. Как вы можете догадаться, мы все еще находим эти ключи доступа там, где им не место, во время большинства проводимых нами тестов на проникновение в облако. Короче говоря, долговечные ключи доступа - это плохо. Итак, какое решение? Согласно AWS, вы должны отказаться от пользователей IAM и перейти на роли IAM. Роли используют временные учетные данные, срок действия которых истекает, поэтому гораздо меньше риска, что эти учетные данные будут случайно зарегистрированы в Git, сохранены в корзине S3 или сброшены на Pastebin. Чтобы роли работали бесперебойно, ваши пользователи проходят аутентификацию с помощью решения SSO, такого как Okta или AWS SSO, и это решение сопоставляет, какие роли IAM вам разрешено принимать.
Это актуально, потому что некоторые пути privesc доступны только для ролей, а другие доступны только для пользователей. Из-за этого IAM Vulnerable создает как роль, так и пользователя для каждого пути privesc. Я рекомендую научиться работать с обоими типами принципалов IAM.
Ключи доступа пользователя
Каждый путь privesc создает пользователя и набор ключей доступа. Чтобы найти учетные данные для доступа пользователя IAM, созданного Terraform, загляните в файл iam-weak/terraform.tfstate. Просто найдите пользователя, которого хотите использовать, и добавьте эти учетные данные в новый профиль в своем файле учетных данных.
Роли, это легкий путь.
Знаете ли вы, что вы можете настроить профиль для интерфейса командной строки AWS, который ссылается на другой профиль, если между двумя ролями существует доверие IAM? При такой настройке принятие целевой роли происходит прозрачно, если вы используете правильное имя профиля с интерфейсом командной строки AWS. В репозиторий я включил сэмпл https://github.com/BishopFox/iam-vulnerable/blob/main/aws_credentials_file_example, который вы можете использовать в качестве руководства при настройке. Вот фрагмент примера файла конфигурации (i.e., ~/.aws/credentials):
В этом сценарии мы использовали профиль по умолчанию для применения модулей IAM Vulnerable. Все, что вам нужно сделать, это заменить указанный выше номер счета-заполнителя на номер своего реального аккаунта.
В конфигурации, показанной выше, если вы хотите запустить команду с ролью privesc1-CreateNewPolicyVersion-role, все, что вам нужно сделать, это использовать профиль privesc1:
За кулисами интерфейс командной строки AWS использовал пользователя, указанного в профиле по умолчанию, чтобы взять на себя роль privesc1-CreateNewPolicyVersion-role.
Использовать демонстрацию с использованием предполагаемой роли
Следующая демонстрация показывает, как использовать privesc1-CreateNewPolicyVersion-role для создания новой версии политики, которая предоставляет себе права администратора.
Поскольку privesc1-CreateNewPolicyVersion-role имеет разрешение только на выполнение одного действия для запуска, privesc1 сначала даже не может перечислить пользователей IAM:
Теперь давайте обновим эту политику (не забудьте заменить 111111111111 идентификатором своего аккаунта):
Наконец, давайте попробуем снова составить список пользователей IAM, все еще используя privesc1-CreateNewPolicyVersion-role:
Круто! Мы просто использовали профиль privesc1, чтобы выполнить путь privesc CreatePolicyVersion и стать эффективным администратором.
Поддерживаемые пути повышения привилегий
В таблице ниже перечислены 31 путь повышения привилегий, который IAM Vulnerable поддерживает по состоянию на август 2021 года. Этот список включает 21 исходный путь privesc, указанный Спенсером Гитценом, и 10 дополнительных путей, которые я добавил. Большинство новых путей, таких как SSM-SendCommand, SSM-StartSession и CodeBuild-CreateProjectPassRole, были добавлены в IAM Vulnerable после того, как я заметил, что Эрик Стерингер добавил их в Principal Mapper (https://github.com/nccgroup/PMapper) . Другие, такие как EC2InstanceConnect-SendSSHPublicKey, были добавлены на основе оригинального исследования.
| Supported Privilege Escalation Paths |
| IAM Permissions on Other Users |
| IAM-CreateAccessKey |
| IAM-CreateLoginProfile |
| IAM-UpdateLoginProfile |
| PassRole to Service |
| CloudFormation-PassExistingRoleToCloudFormation |
| PassExistingRoleToNewCodeBuildProject |
| DataPipeline-PassExistingRoleToNewDataPipeline |
| EC2-CreateInstanceWithExistingProfile |
| Glue-PassExistingRoleToNewGlueDevEndpoint |
| Lambda-PassExistingRoleToNewLambdaThenInvoke |
| Lambda-PassRoleToNewLambdaThenTrigger |
| SageMaker-CreateNotebookPassRole |
| SageMaker-CreateCreateTrainingJobPassRole |
| SageMaker-CreateProcessingJobPassRole |
| Permissions on Policies |
| IAM-AddUserToGroup |
| IAM-AttachGroupPolicy |
| IAM-AttachRolePolicy |
| IAM-AttachUserPolicy |
| IAM-CreateNewPolicyVersion |
| IAM-PutGroupPolicy |
| IAM-PutRolePolicy |
| IAM-PutUserPolicy |
| IAM-SetExistingDefaultPolicyVersion |
| Privilege Escalation Using AWS Services |
| EC2InstanceConnect-SendSSHPublicKey |
| CloudFormation-UpdateStack |
| Glue-UpdateExistingGlueDevEndpoint |
| Lambda-EditExistingLambdaFunctionWithRole |
| SageMakerCreatePresignedNotebookURL |
| SSM-SendCommand |
| SSM-StartSession |
| STS-AssumeRole |
| Updating an AssumeRole Policy |
| IAM-UpdatingAssumeRolePolicy |
Заключение
Предоставление разрешений IAM принципалам AWS, предотвращающих непреднамеренное повышение привилегий, является сложной задачей, и в рамках модели совместной ответственности ответственность за управление этими политиками лежит на клиенте AWS. Отрасль информационной безопасности нуждается в большем количестве специалистов-практиков, которые могут идентифицировать непреднамеренные пути повышения привилегий и продемонстрировать влияние эксплуатации.
IAM Vulnerable позволит вам создать частную среду, в которой вы можете повысить свои навыки IAM privesc от новичка до эксперта в удобном для вас темпе, в своей учетной записи AWS. Вы можете попрактиковаться в эксплуатации повышения привилегий в AWS IAM и протестировать свои любимые инструменты с ними, чтобы более комфортно идентифицироваться. Вы даже можете использовать его в качестве испытательного стенда при создании новых инструментов или обновлении существующих. Я надеюсь, что этот проект вселит в вас уверенность и опыт, которые потребуются для выявления подобных проблем в реальных условиях и помощи в их устранении.
Во второй части этой серии я опробую свои любимые инструменты оценки IAM privesc на площадке, созданной IAM Vulnerable, чтобы увидеть, как работает каждый инструмент, и сделаю обзор возможностей, сильных и слабых сторон каждого инструмента.
Не пропустите часть 2 часть (https://labs.bishopfox.com/tech-blog/iam-vulnerable-assessing-the-aws-assessment-tools) моей серии статей о уязвимостях IAM, где я обсуждаю идентификационный аспект повышения привилегий IAM в целевой учетной записи. Я делюсь своими любимыми инструментами оценки privesc IAM и прихожу к выводу, что, хотя каждый из этих инструментов бесценен для тестировщика на проникновение, ни один из них не может идентифицировать все известные пути privesc, одновременно удаляя все ложные срабатывания.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://labs.bishopfox.com/tech-blog/iam-vulnerable-an-aws-iam-privilege-escalation-playground