Статья является переводом. Оригинал вот
В случае состязательных режимов, доступ к консоли AWS лучше, чем к API. В этой статье мы покажем вам процесс исследования и релизним новый инструмент, который мы создали!
Было бы желание...
Клиенты часто просят нас протестировать приложения, сети и/или инфраструктуру, размещенные на Amazon Web Services (AWS). В рамках этих проверок, мы часто находим активные учетные данные IAM различными способами. Эти учетные данные позволяют владельцу выполнять привилегированные действия в службах AWS в пределах учетной записи AWS.
Эти учетные данные представлены в двух формах, обе из которых работают с CLI AWS:
Недавно у нас был прекрасный пример этой ситуации. Выполняя тест на проникновение в облако с
Однако, легко забыть специфический синтаксис CLI даже для самых простых команд. Приведенный ниже пример показывает довольно простую процедуру рекогносцировки, которую мы могли бы выполнить, описывая запущенные EC2 экземпляры. Вверху мы видим простую в использовании опцию фильтрации консольного интерфейса AWS. Внизу мы видим мои попытки запомнить конкретное имя фильтра.
Скриншот консоли управления EC2, рядом с примером использования AWS CLI для EC2.
Было ли это "instance-state", "state", "status..."?
Вместо того, чтобы перебирать синтаксис AWS CLI, мы исследовали методы получения доступа к консоли AWS.
... способ найдется
К счастью, в AWS есть такой механизм получения доступа к консоли AWS с использованием учетных данных API -
На тему Federation
AWS написала несколько блогов (
Однако есть пару предостережений - вам нужны временные учетные данные. Наиболее распространенный механизм получения этих учеток - вызов метода AssumeRole в службе STS - как следует из названия, это позволяет вызывающему абоненту получить доступ к роли IAM с соответствующей политикой доверия к роли.
Однако, sts:AssumeRole обычно считается "опасным" разрешением, поскольку оно может быть использовано для повышения привилегий, вплоть до рута - по этой причине мы рекомендуем клиентам избегать предоставления этого разрешения, если в этом нет необходимости. Независимо от этого, нам также необходимо знать о роли, которую мы можем взять на себя, и которая может быть доступна. Есть и другие распространенные способы получения учетных данных - наиболее известным является sts:GetSessionToken,. Он часто используется для предоставления пользователю временных учетных данных на основе многофакторной аутентификации - однако, учетные данные, выданные с этой конечной точки, не работают с конечной federation точкой, и при попытке их использования, они будут выдавать ошибку.
Сообщение об ошибке AWS: "Amazon Web Services Вход в систему // Для federated входа могут использоваться только federation токены или asume role токены Пожалуйста, свяжитесь с Вашим администратором".
Вот блин! Снова неудача. Удостоверения GetSessionToken, похоже, здесь не работают.
Постоянный и Временный
К счастью для нас, есть еще один вариант. Хотя, как правило, он предназначен для аутентификации IDP из-за «пределов» учетной записи AWS, sts:GetFederationToken отлично подходит для нашей задачи. Это наталкивает меня на одну мысль: sts:GetFederationToken является более старой функцией AWS API, по сравнению с новыми (такие как
В нашем случае нас не волнует ограничение доступа, поэтому мы можем предоставить встроенную AWS-управляемую политику AdministratorAccess для полного набора эффективных разрешений. Ради упрощения, этот API метод считается неопасным и включен в политику AWS-управляемого ReadOnlyAccess. Это соответствует нашим целям здесь - мы не повышаем привилегия, просто делаем их более простыми в использовании. Тем не менее, консольный доступ могут использовать для поиска дальнейших возможных повышений привилегий.
Имея эти временные учетные данные под рукой, мы можем запросить у federation service нашу волшебную ссылку для входа. В ответ мы получаем URL для получения доступа к консоли AWS. Больше никаких копирований или вставок из окна!
Правильный инструмент для правильной работы - AWS Consoler
Для того чтобы облегчить аналитический процесс, я разработал инструмент для получения доступа к консоли AWS, который я назвал "AWS Consoler" (креативно, да я знаю...). Ознакомиться с инструментом (и его инструкцией по применению) можно в репозитории на GitHub. Как и в случае со всеми нашими инструментами с открытым исходным кодом, мы приветствуем запросы на пул!
Этот инструмент имеет разнообразные возможности и глубокую интеграцию с AWS SDK для Python (boto3). Учетные данные могут быть переданы в командной строке, как и следовало ожидать. Однако, так как мы используем boto3, они также могут быть взяты из именованных профилей AWS CLI, через встроенную логику для переменных окружения в boto3, или даже через IAM Metadata Service (при запуске на вычислительных ресурсах AWS) - boto3 делает для нас всю грязную работу. Передайте свои учетные данные, и вы получите ту самую ссылку для входа в консоль AWS в выбранном вами регионе. Если вы ненавидите копирование/вставки так же сильно, как и я, инструмент также может открыть эту ссылку в стандартном браузере вашей системы.
Вот некоторые примеры использования, которые, как мы ожидаем, будут помогать пользователям.
Предотвращение
Если вы разработчик или инженер, работающий в среде AWS, у вас может появиться вопрос: "как мне это предотвратить?". К счастью, такой тип доступа относительно легко предотвратить, и подпадает под нашу методику обеспечения безопасности облачных сред:
Обратите внимание на минимально допустимый набор разрешений.
При настройке разрешений IAM для пользователя, роли или другого IAM principal’a давайте только те разрешения, которые абсолютно необходимы для нормальной работы. Дополнительные разрешения, такие как sts:GetFederationToken, sts:AssumeRole и другие операции STS, представляют собой риск повышения привилегий и могут быть опасны при неправильном применении.
Если Вы используете политику, управляемую AWS, мы бы рекомендовали проверить, не включает ли она разрешения, которые не нужны для обычной работы. Замена политик, управляемых AWS, на политики, управляемые клиентами, является одним из наших предложений для сценариев, в которых политика, управляемая AWS, не совсем соответствует специфическим требованиям пользователя или роли IAM.
Пример политики IAM, предоставляющей полные действия STS по всем имеющимся ресурсам.
Это действительно отличный пример того, чего не следует делать.
Не используйте жестко закоденные учетные данные в вашей среде
Первоначальная точка входа в эту эскалацию требует получения полномочий AWS. Часто мы находим эти
Ограничение доступа к службе метаданных инстанций EC2.
Убедитесь, что вы ограничены в доступе к этой службе используя стандартных приложений, особенно если обрабатываете пользовательские данные на этих ресурсах. В общем, вам лучше ограничить это с помощью правил iptables, правил брандмауэра Windows или других правил маршрутизации на ваших вычислительных ресурсах. Кроме того, вы можете ограничить это и оно может быть установлено во время запуска инстанса.
Снимок экрана консоли управления EC2, демонстрирующий отключение службы метаданных IAM для конкретного экземпляра.
Новые возможности в EC2 позволяют полностью отключить службу метаданных IAM, если она не нужна.
Обратите внимание, что при использовании ECS, у задач по метаданным существует дополнительная конечная точка метаданных -
Установите ключи условий на политиках IAM для ролей исполнения
При использовании ролей исполнения с вашими вычислительными ресурсами, рассмотрите возможность ограничения политики только этим конкретным ресурсом. Это можно выполнить с помощью ряда
Заключение
С помощью этого блога и AWS Consoler мы надеемся облегчить жизнь редтимеров, блютимеров, баг хантеров и других людей в сфере безопасности. Не стесняйтесь сообщить нам, как вы используете AWS Consoler, через комментарии ниже, или в ваших любимых социальных сетях. Вы можете найти меня как в
Ссылка скрыта от гостей
В случае состязательных режимов, доступ к консоли AWS лучше, чем к API. В этой статье мы покажем вам процесс исследования и релизним новый инструмент, который мы создали!
Было бы желание...
Клиенты часто просят нас протестировать приложения, сети и/или инфраструктуру, размещенные на Amazon Web Services (AWS). В рамках этих проверок, мы часто находим активные учетные данные IAM различными способами. Эти учетные данные позволяют владельцу выполнять привилегированные действия в службах AWS в пределах учетной записи AWS.
Эти учетные данные представлены в двух формах, обе из которых работают с CLI AWS:
- Постоянные учетные данные
- Обычно предоставляя отдельных пользователей IAM, эти аккаунты содержат ключ доступа (который обычно начинается с AKIA) и секретный ключ.
- Временные учетные данные
- Как правило, это происходит от принятия на себя роли IAM, они также содержат токен сессии (и ключ доступа, начиная с ASIA). Обычно эти учетные данные используются вашими приложениями или пользователями с AWS CLI или SDK для интеграции с различными службами AWS.
Недавно у нас был прекрасный пример этой ситуации. Выполняя тест на проникновение в облако с
Ссылка скрыта от гостей
, мы разместили несколько жестко зашифрованных учетных данных AWS в части инфраструктуры управления, в учетной записи клиента. Эти учетные данные отлично работали с AWS API, и были действительно полезны для таких инструментов, как ScoutSuite и Pacu. Оба этих инструмента используют AWS API/CLI/SDK, которые, как правило, обладают большими возможностями, чем консоль.Однако, легко забыть специфический синтаксис CLI даже для самых простых команд. Приведенный ниже пример показывает довольно простую процедуру рекогносцировки, которую мы могли бы выполнить, описывая запущенные EC2 экземпляры. Вверху мы видим простую в использовании опцию фильтрации консольного интерфейса AWS. Внизу мы видим мои попытки запомнить конкретное имя фильтра.
Скриншот консоли управления EC2, рядом с примером использования AWS CLI для EC2.
Было ли это "instance-state", "state", "status..."?
Вместо того, чтобы перебирать синтаксис AWS CLI, мы исследовали методы получения доступа к консоли AWS.
... способ найдется
К счастью, в AWS есть такой механизм получения доступа к консоли AWS с использованием учетных данных API -
Ссылка скрыта от гостей
.На тему Federation
AWS написала несколько блогов (
Ссылка скрыта от гостей
,
Ссылка скрыта от гостей
) на эту тему и имеет
Ссылка скрыта от гостей
по их использованию. Все это свидетельствует, что они позволяют преобразовывать определенные типы временных учетных данных в консольные federation токены. Эти токены могут быть включены в URL, который предоставляет доступ к консоли AWS. Все, что нужно, это набор обращений к конечной federation точке, и вы получаете волшебный токен, который дает прямой доступ к консоли AWS.Однако есть пару предостережений - вам нужны временные учетные данные. Наиболее распространенный механизм получения этих учеток - вызов метода AssumeRole в службе STS - как следует из названия, это позволяет вызывающему абоненту получить доступ к роли IAM с соответствующей политикой доверия к роли.
Однако, sts:AssumeRole обычно считается "опасным" разрешением, поскольку оно может быть использовано для повышения привилегий, вплоть до рута - по этой причине мы рекомендуем клиентам избегать предоставления этого разрешения, если в этом нет необходимости. Независимо от этого, нам также необходимо знать о роли, которую мы можем взять на себя, и которая может быть доступна. Есть и другие распространенные способы получения учетных данных - наиболее известным является sts:GetSessionToken,. Он часто используется для предоставления пользователю временных учетных данных на основе многофакторной аутентификации - однако, учетные данные, выданные с этой конечной точки, не работают с конечной federation точкой, и при попытке их использования, они будут выдавать ошибку.
Сообщение об ошибке AWS: "Amazon Web Services Вход в систему // Для federated входа могут использоваться только federation токены или asume role токены Пожалуйста, свяжитесь с Вашим администратором".
Вот блин! Снова неудача. Удостоверения GetSessionToken, похоже, здесь не работают.
Постоянный и Временный
К счастью для нас, есть еще один вариант. Хотя, как правило, он предназначен для аутентификации IDP из-за «пределов» учетной записи AWS, sts:GetFederationToken отлично подходит для нашей задачи. Это наталкивает меня на одну мысль: sts:GetFederationToken является более старой функцией AWS API, по сравнению с новыми (такие как
Ссылка скрыта от гостей
,
Ссылка скрыта от гостей
, и
Ссылка скрыта от гостей
/
Ссылка скрыта от гостей
). Разрешение предназначено для аутентификации с помощью набора постоянных учетных данных IAM (т.е. приложений локального сервера) и «объединения» пользователя (не являющегося IAM) в AWS, путем предоставления временных учетных данных доступа. Метод позволяет задавать разрешения нового пользователя с помощью одной или нескольких политик, а именно: разрешения принимаются за пересечением вызывающего пользователя IAM, а также политик, поставляемых во время вызова sts:GetFederationToken.В нашем случае нас не волнует ограничение доступа, поэтому мы можем предоставить встроенную AWS-управляемую политику AdministratorAccess для полного набора эффективных разрешений. Ради упрощения, этот API метод считается неопасным и включен в политику AWS-управляемого ReadOnlyAccess. Это соответствует нашим целям здесь - мы не повышаем привилегия, просто делаем их более простыми в использовании. Тем не менее, консольный доступ могут использовать для поиска дальнейших возможных повышений привилегий.
Имея эти временные учетные данные под рукой, мы можем запросить у federation service нашу волшебную ссылку для входа. В ответ мы получаем URL для получения доступа к консоли AWS. Больше никаких копирований или вставок из окна!
Правильный инструмент для правильной работы - AWS Consoler
Для того чтобы облегчить аналитический процесс, я разработал инструмент для получения доступа к консоли AWS, который я назвал "AWS Consoler" (креативно, да я знаю...). Ознакомиться с инструментом (и его инструкцией по применению) можно в репозитории на GitHub. Как и в случае со всеми нашими инструментами с открытым исходным кодом, мы приветствуем запросы на пул!
Этот инструмент имеет разнообразные возможности и глубокую интеграцию с AWS SDK для Python (boto3). Учетные данные могут быть переданы в командной строке, как и следовало ожидать. Однако, так как мы используем boto3, они также могут быть взяты из именованных профилей AWS CLI, через встроенную логику для переменных окружения в boto3, или даже через IAM Metadata Service (при запуске на вычислительных ресурсах AWS) - boto3 делает для нас всю грязную работу. Передайте свои учетные данные, и вы получите ту самую ссылку для входа в консоль AWS в выбранном вами регионе. Если вы ненавидите копирование/вставки так же сильно, как и я, инструмент также может открыть эту ссылку в стандартном браузере вашей системы.
Вот некоторые примеры использования, которые, как мы ожидаем, будут помогать пользователям.
Bash:
$> aws_consoler -v -a AKIA[REDACTED] -s [REDACTED]
2020-03-13 19:44:57,800 [aws_consoler.cli] INFO: Validating arguments...
2020-03-13 19:44:57,801 [aws_consoler.cli] INFO: Calling logic.
2020-03-13 19:44:57,820 [aws_consoler.logic] INFO: Boto3 session established.
2020-03-13 19:44:58,193 [aws_consoler.logic] WARNING: Creds still permanent, creating federated session.
2020-03-13 19:44:58,698 [aws_consoler.logic] INFO: New federated session established.
2020-03-13 19:44:59,153 [aws_consoler.logic] INFO: Session valid, attempting to federate as arn:aws:sts::123456789012:federated-user/aws_consoler.
2020-03-13 19:44:59,668 [aws_consoler.logic] INFO: URL generated!
https://signin.aws.amazon.com/federation?Action=login&Issuer=consoler.local&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2Fconsole%2Fhome%3Fregion%3Dus-east-1&SigninToken=[REDACTED]Предотвращение
Если вы разработчик или инженер, работающий в среде AWS, у вас может появиться вопрос: "как мне это предотвратить?". К счастью, такой тип доступа относительно легко предотвратить, и подпадает под нашу методику обеспечения безопасности облачных сред:
Обратите внимание на минимально допустимый набор разрешений.
При настройке разрешений IAM для пользователя, роли или другого IAM principal’a давайте только те разрешения, которые абсолютно необходимы для нормальной работы. Дополнительные разрешения, такие как sts:GetFederationToken, sts:AssumeRole и другие операции STS, представляют собой риск повышения привилегий и могут быть опасны при неправильном применении.
Если Вы используете политику, управляемую AWS, мы бы рекомендовали проверить, не включает ли она разрешения, которые не нужны для обычной работы. Замена политик, управляемых AWS, на политики, управляемые клиентами, является одним из наших предложений для сценариев, в которых политика, управляемая AWS, не совсем соответствует специфическим требованиям пользователя или роли IAM.
Пример политики IAM, предоставляющей полные действия STS по всем имеющимся ресурсам.
Это действительно отличный пример того, чего не следует делать.
Не используйте жестко закоденные учетные данные в вашей среде
Первоначальная точка входа в эту эскалацию требует получения полномочий AWS. Часто мы находим эти
Ссылка скрыта от гостей
данные в какой-то среде. Мы бы рекомендовали перейти к использованию таких вещей, как роли исполнения для ваших вычислительных ресурсов в AWS. Внедрение варьируется в зависимости от вычислительного ресурса - например, в EC2 есть
Ссылка скрыта от гостей
, в ECS -
Ссылка скрыта от гостей
, в Lambda -
Ссылка скрыта от гостей
. Таким образом, AWS SDK могут автоматически получать кратковременные учетные данные для аутентификации в сервисах AWS.Ограничение доступа к службе метаданных инстанций EC2.
Ссылка скрыта от гостей
- это веб-сервис, работающий во всех EC2-средах по заранее определенному IP-адресу. Обычно этот сервис используется для вычисления ресурсов, чтобы получить информацию об окружении, в котором они были развернуты. Эта информация обычно включает в себя следующее:- Конфигурация VPC
- EC2-пользовательские данные
- Теги, связанные с инстансом EC2
- Временные учетные данные IAM для выполнения ролей
Убедитесь, что вы ограничены в доступе к этой службе используя стандартных приложений, особенно если обрабатываете пользовательские данные на этих ресурсах. В общем, вам лучше ограничить это с помощью правил iptables, правил брандмауэра Windows или других правил маршрутизации на ваших вычислительных ресурсах. Кроме того, вы можете ограничить это и оно может быть установлено во время запуска инстанса.
Снимок экрана консоли управления EC2, демонстрирующий отключение службы метаданных IAM для конкретного экземпляра.
Новые возможности в EC2 позволяют полностью отключить службу метаданных IAM, если она не нужна.
Обратите внимание, что при использовании ECS, у задач по метаданным существует дополнительная конечная точка метаданных -
Ссылка скрыта от гостей
. Убедитесь, что вы ограничиваете доступ и к этому.Установите ключи условий на политиках IAM для ролей исполнения
При использовании ролей исполнения с вашими вычислительными ресурсами, рассмотрите возможность ограничения политики только этим конкретным ресурсом. Это можно выполнить с помощью ряда
Ссылка скрыта от гостей
, в том числе ограничивающих VPC и/или IP-адрес вызывающего абонента.Заключение
С помощью этого блога и AWS Consoler мы надеемся облегчить жизнь редтимеров, блютимеров, баг хантеров и других людей в сфере безопасности. Не стесняйтесь сообщить нам, как вы используете AWS Consoler, через комментарии ниже, или в ваших любимых социальных сетях. Вы можете найти меня как в
Ссылка скрыта от гостей
, так и в
Ссылка скрыта от гостей
.