Как тестировщик на проникновение или Red Teamer, рано или поздно вы сталкнетесь с учетными данными AWS IAM ( Identity and Access Management (IAM) — это веб-сервис, который помогает вам безопасно контролировать доступ к AWS resources. Вы используете IAM, чтобы контролировать, кто аутентифицирован и авторизован (имеет разрешения) для использования ресурсов.во время оценки. Ниже приведено пошаговое руководство о том, как вы можете их использовать, что следует учитывать и как избежать обнаружения.)
В AWS обычно есть два типа учетных данных, с которыми вы будете работать: долгосрочные (ключи доступа) и краткосрочные .
Долгосрочные учетные данные будут иметь ключ доступа, начинающийся с AKIA и будет состоять из 20 символов. В дополнение к ключу доступа также будет секретный ключ доступа длиной 40 символов. С помощью этих двух ключей вы потенциально можете отправлять запросы к AWS API. Как следует из названия, эти учетные данные не имеют определенного срока действия и будут использоваться до тех пор, пока они не будут намеренно отключены/деактивированы. В результате это делает их нерекомендуемыми с точки зрения безопасности. Предпочтительны временные учетные данные безопасности. Для сравнения, временные учетные данные будут иметь ключ доступа, начинающийся с ASIA, длиной 20 символов, а также иметь секретный ключ из 40 символов. Кроме того, временные учетные данные безопасности также будут иметь токен сеанса (иногда называемый токеном безопасности). Токен сеанса будет иметь кодировку base64 и будет довольно длинным. С помощью этих трех учетных данных вы потенциально можете отправлять запросы к AWS API. Как следует из названия, эти учетные данные имеют временный срок действия, который определяется при их создании. Это может быть как 15 минут, так и несколько часов.
Чтобы сделать это с краткосрочными учетными данными, установите следующие переменные среды.
Примечание
Возможно, вам также придется указать регион AWS. Это может быть глобально установлено с помощью aws configure команду или через переменную окружения AWS_REGION.
Определение достоверности
Теперь, когда у вас есть учетные данные и они настроены для использования. Как вы поймете действительны ли они (не просрочены и не деактивированы)? Самый простой способ — использовать sts:GetCallerIdentity . Этот метод полезен, потому что он позволяет нам определить, действительны ли учетные данные, а также сообщает нам полезную информацию, такую как имя роли/пользователя, связанного с этими учетными данными, и идентификатор учетной записи AWS, которому они принадлежат.
В качестве дополнительного бонуса мы можем быть уверены, что этот вызов API всегда будет работать. Из документации: «Для выполнения этой операции не требуются разрешения. Если администратор добавит политику вашему пользователю или роли IAM, которая явно запрещает доступ к действию sts:GetCallerIdentity, вы все равно можете выполнить эту операцию».
Совет
Специалистам по оборонной безопасности целесообразно предупреждать о вызовах sts:GetCallerIdentity от личностей, у которых нет истории его вызова. Например, если сервер приложений в производственной среде никогда раньше не вызывал его, это может указывать на компрометацию. Стоит отметить, что sts:GetCallerIdentity может законно использоваться большим количеством проектов, а также отдельными разработчиками. Чтобы попытаться уменьшить количество ложных срабатываний, было бы лучше всего предупреждать только тех пользователях, которые никогда не вызывали его.
Если вы пытаетесь сохранить скрытность, sts:GetCallerIdentity врятли поможет вам в этом. Этот вызов API регистрируется в CloudTrail , что означает, что у защитников будет журнал с дополнительными сведениями о том, что это произошло. Чтобы обойти это, мы можем использовать события данных .
События данных — это массовые вызовы API для ресурсов в аккаунте AWS. Из-за того, что эти API-интерфейсы могут вызываться несколько раз, они по умолчанию не регистрируются в CloudTrail, а в некоторых случаях вообще не могут быть зарегистрированы.
Примером этого может быть sns:Publish . Выполнив этот вызов API (и предоставив действительный идентификатор учетной записи AWS), мы можем получить аналогичную информацию, как sts:GetCallerIdentity.
После обнаружения или кражи учетных данных IAM во время оценки вам необходимо будет определить, для чего они используются и являются ли они действительными. Наиболее распространенным методом для этого является get-caller-identity вызов API. Это выгодно по нескольким причинам, в частности потому, что для вызова не требуются специальные разрешения. К сожалению (хотя и маловероятно ), существует вероятность того, что этот вызов API может отслеживаться для конфиденциальных учетных записей. Кроме того, если наша цель состоит в том, чтобы быть как можно более незаметным, мы можем не захотеть использовать это. В результате нам нужны альтернативы. Хорошая новость для нас заключается в том, что многие сервисы AWS раскрывают вызывающую роль вместе с идентификатором учетной записи в результате ошибки. Нижеследующее, безусловно, не является исчерпывающим списком, и обратите внимание, что принципалу НЕ нужно иметь разрешения IAM, чтобы сделать этот вызов, чтобы вернуть информацию как ошибку.
Не все вызовы API демонстрируют такое поведение. Например, неудачные вызовы API EC2 вернут следующие варианты.
sns:Publish
sns:Publish вернет ARN вызывающего пользователя/роли без регистрации в CloudTrail . Чтобы использовать этот метод, вы должны указать действительный идентификатор учетной записи AWS в вызове API. Это может быть ваш собственный идентификатор учетной записи или идентификатор учетной записи кого-либо еще.
Если вы используете дистрибутив Linux для «пентестинга», такой как Kali Linux , Parrot Security или Pentoo Linux , вы немедленно инициируете обнаружение PenTest GuardDuty . Это связано с тем, что интерфейс командной строки AWS отправляет строку пользовательского агента, содержащую информацию об операционной системе, выполняющей вызов API. Чтобы избежать этого, лучше всего использовать «безопасную» операционную систему, такую как Windows, Mac OS или Ubuntu. Если у вас мало времени или вы просто ДОЛЖНЫ использовать один из этих дистрибутивов Linux, вы можете изменить свою botocore с помощью жестко закодированного пользовательского агента.
Совет
Вы идете против синей команды? Может быть хорошей идеей подделать строку пользовательского агента, которую можно было бы ожидать в среде. Например, если эти учетные данные IAM принадлежат разработчику, который использует рабочую станцию Windows, было бы очень странно, если бы вызовы API внезапно начали иметь пользовательский агент с операционной системой Linux.
Это также может быть полезно для целей обнаружения.
Обход результатов пентеста GuardDuty
При отправке запросов API AWS при обычном тестировании на проникновение GuardDuty ОС обнаружит это и вызовет PenTest Finding .
Это вызвано именем юзерагента, которое передается в запросе API. Изменив это, мы можем предотвратить обнаружение GuardDuty того, что мы работаем с «пентестовым» дистрибутивом Linux. Если ваша оценка требует, чтобы вы оставались незамеченными, вероятно, проще использовать «безопасную» ОС, такую как Ubuntu, Mac OS или Windows. Для этого определите местонахождение вашего session.py в botocore. Например, при установке Kali Linux по умолчанию его можно найти по адресу /usr/local/lib/python3.7/dist-packages/botocore/session.py.
В строке 456 (на момент написания статьи) вы должны увидеть следующее.
platform.system() а также platform.release() похожи на uname -o а также uname -r. При стандартной установке Kali будут сгенерированы следующие значения.
Чтобы обойти это, измените код и замените его законными строками пользовательского агента, такими как найденные в Pacu . С помощью этой возможности вы можете замаскировать свой пользовательский агент, чтобы он выглядел как угодно. Даже произвольные значения, как показано ниже.
Примечание
Этот раздел относится только к учетным данным IAM, полученным из службы метаданных экземпляра EC2. Это не относится к другим учетным данным IAM.
При использовании учетных данных IAM, полученных из инстанса EC2, вы рискуете вызвать обнаружение UnauthorizedAccess:IAMUser/InstanceCredentialExdication.OutsideAWS GuardDuty. Этот вывод предупреждает о сценариях, в которых учетные данные IAM из экземпляра EC2 используются вне AWS (например, ваш домашний IP-адрес).
Это особенно актуально в сценариях, в которых у вас есть доступ к учетным данным IAM, но не к узлу ( подделка запроса на стороне сервера ).
Чтобы обойти это, мы можем использовать конечные точки VPC , которые не будут вызывать это предупреждение. Чтобы упростить задачу, SneakyEndpoints , позволяющий быстро настроить инфраструктуру для обхода этого обнаружения.
Ссылка на инструмент: SneakyEndpoints
Распространенным методом использования сред AWS является использование SSRF, XXE, внедрения команд и т. д. для кражи учетных данных IAM из службы метаданных экземпляра целевого экземпляра EC2. Это может позволить вам выполнять вызовы AWS API в учетной записи жертвы, однако сопряжено с риском. Если вы попытаетесь использовать эти учетные данные за пределами этого хоста (например, со своего ноутбука), будет активировано предупреждение. Существует обнаружение GuardDuty, которая определяет, когда учетные данные IAM используются за пределами EC2, и называется UnauthorizedAccess:IAMUser/InstanceCredentialExdication.OutsideAWS .
Чтобы обойти срабатывание этого предупреждения, злоумышленники могут использовать украденные учетные данные из экземпляра EC2 злоумышленника. Предупреждение обнаруживается только в том случае, если учетные данные использовались за пределами EC2, а не в конкретном экземпляре EC2 жертвы. Таким образом, используя свой собственный или другой экземпляр EC2, злоумышленники могут обойти предупреждение GuardDuty.
20 января 2022 года AWS опубликовала новый вывод GuardDuty под названием UnauthorizedAccess:IAMUser/InstanceCredentialExdication.InsideAWS . Это новое открытие устранило недостатки предыдущего. Теперь, когда учетные данные IAM используются из ЛЮБОГО EC2, если эти учетные данные не принадлежат той же учетной записи, что и экземпляр EC2, использующий их, это вызывает предупреждение. Таким образом, простое использование собственного экземпляра EC2 больше нецелесообразно. Это решает давнюю проблему в сообществе безопасности облачных вычислений.
Однако на данный момент для этого существует функционирующий обходной путь — VPC Endpoints . Использование конечных точек VPC не приведет к срабатыванию предупреждения GuardDuty. Это означает, что, будучи злоумышленником, если вы украли учетные данные IAM у экземпляра EC2, вы можете использовать эти учетные данные у своего экземпляра EC2 при маршрутизации трафика через конечные точки VPC. Это не приведет к срабатыванию обнаружения GuardDuty.
Чтобы сделать эту настройку быстрее (и проще) для тестеров на проникновение и Red Teamers, был создан SneakyEndpoints. В этом проекте есть все конфигурации Terraform, необходимые для развертывания среды для атаки. Он создаст экземпляр EC2 в частной подсети (без доступа к Интернету) и создаст несколько конечных точек VPC, которые вы сможете использовать. Эта настройка гарантирует, что мы случайно не разоблачим себя и не вызовем оповещение.
Примечание
Есть еще один вариант обхода, однако он будет полезен только в нишевых сценариях. Находка InstanceCredentialExdication связана только с учетной записью AWS, а не с экземпляром EC2. В результате, если вы скомпрометируете инстанс EC2 в целевой учетной записи, а затем скомпрометируете ДРУГИЕ инстансы EC2 в этой учетной записи или украдете их учетные данные IAM, вы сможете безопасно использовать их из первоначально скомпрометированного инстанса, не опасаясь срабатывания GuardDuty.
Теперь, когда у вас все настроено и вы знаете, на что обращать внимание, ваш следующий вопрос может быть «Что находится в этой учетной записи AWS?». Если вы выполняете оценку без знаний и, таким образом, не имеете представления о том, какие службы работают в учетной записи, вам будет сложно понять, на что ориентироваться или на что обратить внимание.
Одним из вариантов может быть перечисление связанных со службой ролей в учетной записи. — связанная с сервисом, это особый вид роли IAM, который позволяет сервису AWS выполнять действия в вашей учетной записи. Из-за этого мы потенциально можем перечислить их без аутентификации.
Из предыдущего шага проверки достоверности мы узнаем идентификатор учетной записи AWS, в которой мы работаем. Это в сочетании с этой техникой позволит нам перечислить, какие службы использует учетная запись AWS. Это может быть полезно для ответа на такие вопросы, как «Использует ли наша цель GuardDuty? Является ли эта учетная запись частью организации? Используют ли они контейнеры (ECS, EKS) или они используют EC2?».
Оригинальное исследование: Daniel Grzelak - Remastered Talk by Scott Piper
Дополнительное чтение: Rhino Security
Ссылка на Quiet Riot: Github
Ссылка на инструмент: GitHub
Ссылка на модуль Паку: GitHub
Вы можете перечислить идентификаторы учетной записи, адреса электронной почты корневой учетной записи, роли IAM, пользователей IAM и частичный след учетной записи, злоупотребляя политиками на основе ресурсов . Есть несколько способов сделать это, например, модуль Паку попытается изменить политику AssumeRole роли в ваш учетную запись и указать роль в другой учетной записи. Quiet Riot предлагает масштабируемый метод перечисления каждого из этих элементов с настраиваемыми списками слов для каждого типа элемента.
Другой способ — использовать политики корзины S3. Возьмем следующий пример:
Вы примените эту политику к сегменту ты своя. Указав принципала в целевой учетной записи (123456789123), вы можете определить, существует ли этот принципал. Если установка политики корзины прошла успешно, вы знаете, что роль существует. Если это не удается, вы знаете, что роль не работает.
Предупреждение
Выполнение любого из этих методов приведет к созданию множества событий CloudTrail, в частности UpdateAssumeRolePolicy или PutBucketPolicy в вашей учетной записи. Если вы намерены действовать скрытно, не рекомендуется (или не требуется) использовать учетные данные цели. Вместо этого вы должны использовать свою собственную учетную запись (события CloudTrail будут генерироваться там).
Примечание
Хотя это работает как для пользователей, так и для ролей IAM, это также будет работать с ролями, связанными со службой . Это позволит вам перечислить различные службы, используемые учетной записью, такие как GuardDuty или Organizations.
Чтобы автоматизировать этот процесс, вы можете использовать модуль Pacu или это , которое попытается взломать его для вас.
Перевод ЭТОЙ этой ЭтоЙ эТОй и ЭтОй статей.
Характеристики учетных данных IAM
В AWS обычно есть два типа учетных данных, с которыми вы будете работать: долгосрочные (ключи доступа) и краткосрочные .
Долгосрочные учетные данные будут иметь ключ доступа, начинающийся с AKIA и будет состоять из 20 символов. В дополнение к ключу доступа также будет секретный ключ доступа длиной 40 символов. С помощью этих двух ключей вы потенциально можете отправлять запросы к AWS API. Как следует из названия, эти учетные данные не имеют определенного срока действия и будут использоваться до тех пор, пока они не будут намеренно отключены/деактивированы. В результате это делает их нерекомендуемыми с точки зрения безопасности. Предпочтительны временные учетные данные безопасности. Для сравнения, временные учетные данные будут иметь ключ доступа, начинающийся с ASIA, длиной 20 символов, а также иметь секретный ключ из 40 символов. Кроме того, временные учетные данные безопасности также будут иметь токен сеанса (иногда называемый токеном безопасности). Токен сеанса будет иметь кодировку base64 и будет довольно длинным. С помощью этих трех учетных данных вы потенциально можете отправлять запросы к AWS API. Как следует из названия, эти учетные данные имеют временный срок действия, который определяется при их создании. Это может быть как 15 минут, так и несколько часов.
Работа с ключами
После сбора учетных данных вы, вероятно, захотите использовать их с интерфейсом командной строки AWS. Есть несколько способов сделать это, однако установка их в качестве переменных среды, вероятно, является самым простым. Чтобы сделать это с долгосрочными учетными данными, установите следующие переменные среды.
Код:
export AWS_ACCESS_KEY_ID=AKIAEXAMPLEEXAMPLEEE
export AWS_SECRET_ACCESS_KEY=EXAMPLEEXAMPLEEXAMPLEEXAMPLEEXAMPLESEXAMЧтобы сделать это с краткосрочными учетными данными, установите следующие переменные среды.
Код:
export AWS_ACCESS_KEY_ID=ASIAEXAMPLEEXAMPLEEE
export AWS_SECRET_ACCESS_KEY=EXAMPLEEXAMPLEEXAMPLEEXAMPLEEXAMPLESEXAM
export AWS_SESSION_TOKEN=EXAMPLEEXAMPLEEXAMPLE...<snip>Примечание
Возможно, вам также придется указать регион AWS. Это может быть глобально установлено с помощью aws configure команду или через переменную окружения AWS_REGION.
Определение достоверности
Теперь, когда у вас есть учетные данные и они настроены для использования. Как вы поймете действительны ли они (не просрочены и не деактивированы)? Самый простой способ — использовать sts:GetCallerIdentity . Этот метод полезен, потому что он позволяет нам определить, действительны ли учетные данные, а также сообщает нам полезную информацию, такую как имя роли/пользователя, связанного с этими учетными данными, и идентификатор учетной записи AWS, которому они принадлежат.
В качестве дополнительного бонуса мы можем быть уверены, что этот вызов API всегда будет работать. Из документации: «Для выполнения этой операции не требуются разрешения. Если администратор добавит политику вашему пользователю или роли IAM, которая явно запрещает доступ к действию sts:GetCallerIdentity, вы все равно можете выполнить эту операцию».
Код:
$ aws sts get-caller-identity
{
"UserId": "AROAEXAMPLEEXAMPLEEXA:Nick",
"Account": "123456789123",
"Arn": "arn:aws:sts::123456789123:assumed-role/blah/Nick"
}Совет
Специалистам по оборонной безопасности целесообразно предупреждать о вызовах sts:GetCallerIdentity от личностей, у которых нет истории его вызова. Например, если сервер приложений в производственной среде никогда раньше не вызывал его, это может указывать на компрометацию. Стоит отметить, что sts:GetCallerIdentity может законно использоваться большим количеством проектов, а также отдельными разработчиками. Чтобы попытаться уменьшить количество ложных срабатываний, было бы лучше всего предупреждать только тех пользователях, которые никогда не вызывали его.
Вопросы операционной безопасности
Если вы пытаетесь сохранить скрытность, sts:GetCallerIdentity врятли поможет вам в этом. Этот вызов API регистрируется в CloudTrail , что означает, что у защитников будет журнал с дополнительными сведениями о том, что это произошло. Чтобы обойти это, мы можем использовать события данных .
События данных — это массовые вызовы API для ресурсов в аккаунте AWS. Из-за того, что эти API-интерфейсы могут вызываться несколько раз, они по умолчанию не регистрируются в CloudTrail, а в некоторых случаях вообще не могут быть зарегистрированы.
Примером этого может быть sns:Publish . Выполнив этот вызов API (и предоставив действительный идентификатор учетной записи AWS), мы можем получить аналогичную информацию, как sts:GetCallerIdentity.
Код:
$ aws sns publish --topic-arn arn:aws:sns:us-east-1:*account id*:aaa --message aaa
An error occurred (AuthorizationError) when calling the Publish operation: User: arn:aws:sts::123456789123:assumed-role/example_role/i-00000000000000000 is not authorized to perform: SNS:Publish on resource: arn:aws:sns:us-east-1:*account id*:aaaWhoami - получить основное имя из ключей
После обнаружения или кражи учетных данных IAM во время оценки вам необходимо будет определить, для чего они используются и являются ли они действительными. Наиболее распространенным методом для этого является get-caller-identity вызов API. Это выгодно по нескольким причинам, в частности потому, что для вызова не требуются специальные разрешения. К сожалению (хотя и маловероятно ), существует вероятность того, что этот вызов API может отслеживаться для конфиденциальных учетных записей. Кроме того, если наша цель состоит в том, чтобы быть как можно более незаметным, мы можем не захотеть использовать это. В результате нам нужны альтернативы. Хорошая новость для нас заключается в том, что многие сервисы AWS раскрывают вызывающую роль вместе с идентификатором учетной записи в результате ошибки. Нижеследующее, безусловно, не является исчерпывающим списком, и обратите внимание, что принципалу НЕ нужно иметь разрешения IAM, чтобы сделать этот вызов, чтобы вернуть информацию как ошибку.
Не все вызовы API демонстрируют такое поведение. Например, неудачные вызовы API EC2 вернут следующие варианты.
Код:
An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation.sns:Publish
sns:Publish вернет ARN вызывающего пользователя/роли без регистрации в CloudTrail . Чтобы использовать этот метод, вы должны указать действительный идентификатор учетной записи AWS в вызове API. Это может быть ваш собственный идентификатор учетной записи или идентификатор учетной записи кого-либо еще.
Код:
user@host:$ aws sns publish --topic-arn arn:aws:sns:us-east-1:*account id*:aaa --message aaa
An error occurred (AuthorizationError) when calling the Publish operation: User: arn:aws:sts::123456789123:assumed-role/example_role/i-00000000000000000 is not authorized to perform: SNS:Publish on resource: arn:aws:sns:us-east-1:*account id*:aaaКак избежать обнаружения
Бывают ситуации, когда простое использование учетных данных может предупредить защитников о вашем присутствии. В результате рекомендуется помнить об этих обстоятельствах, чтобы не быть пойманным.Если вы используете дистрибутив Linux для «пентестинга», такой как Kali Linux , Parrot Security или Pentoo Linux , вы немедленно инициируете обнаружение PenTest GuardDuty . Это связано с тем, что интерфейс командной строки AWS отправляет строку пользовательского агента, содержащую информацию об операционной системе, выполняющей вызов API. Чтобы избежать этого, лучше всего использовать «безопасную» операционную систему, такую как Windows, Mac OS или Ubuntu. Если у вас мало времени или вы просто ДОЛЖНЫ использовать один из этих дистрибутивов Linux, вы можете изменить свою botocore с помощью жестко закодированного пользовательского агента.
Совет
Вы идете против синей команды? Может быть хорошей идеей подделать строку пользовательского агента, которую можно было бы ожидать в среде. Например, если эти учетные данные IAM принадлежат разработчику, который использует рабочую станцию Windows, было бы очень странно, если бы вызовы API внезапно начали иметь пользовательский агент с операционной системой Linux.
Это также может быть полезно для целей обнаружения.
Обход результатов пентеста GuardDuty
При отправке запросов API AWS при обычном тестировании на проникновение GuardDuty ОС обнаружит это и вызовет PenTest Finding .
Это вызвано именем юзерагента, которое передается в запросе API. Изменив это, мы можем предотвратить обнаружение GuardDuty того, что мы работаем с «пентестовым» дистрибутивом Linux. Если ваша оценка требует, чтобы вы оставались незамеченными, вероятно, проще использовать «безопасную» ОС, такую как Ubuntu, Mac OS или Windows. Для этого определите местонахождение вашего session.py в botocore. Например, при установке Kali Linux по умолчанию его можно найти по адресу /usr/local/lib/python3.7/dist-packages/botocore/session.py.
В строке 456 (на момент написания статьи) вы должны увидеть следующее.
platform.system() а также platform.release() похожи на uname -o а также uname -r. При стандартной установке Kali будут сгенерированы следующие значения.
Чтобы обойти это, измените код и замените его законными строками пользовательского агента, такими как найденные в Pacu . С помощью этой возможности вы можете замаскировать свой пользовательский агент, чтобы он выглядел как угодно. Даже произвольные значения, как показано ниже.
Эксфильтрация учетных данных GuardDuty
Примечание
Этот раздел относится только к учетным данным IAM, полученным из службы метаданных экземпляра EC2. Это не относится к другим учетным данным IAM.
При использовании учетных данных IAM, полученных из инстанса EC2, вы рискуете вызвать обнаружение UnauthorizedAccess:IAMUser/InstanceCredentialExdication.OutsideAWS GuardDuty. Этот вывод предупреждает о сценариях, в которых учетные данные IAM из экземпляра EC2 используются вне AWS (например, ваш домашний IP-адрес).
Это особенно актуально в сценариях, в которых у вас есть доступ к учетным данным IAM, но не к узлу ( подделка запроса на стороне сервера ).
Чтобы обойти это, мы можем использовать конечные точки VPC , которые не будут вызывать это предупреждение. Чтобы упростить задачу, SneakyEndpoints , позволяющий быстро настроить инфраструктуру для обхода этого обнаружения.
Обход обнаружения утечки учетных данных
Ссылка на инструмент: SneakyEndpoints
Распространенным методом использования сред AWS является использование SSRF, XXE, внедрения команд и т. д. для кражи учетных данных IAM из службы метаданных экземпляра целевого экземпляра EC2. Это может позволить вам выполнять вызовы AWS API в учетной записи жертвы, однако сопряжено с риском. Если вы попытаетесь использовать эти учетные данные за пределами этого хоста (например, со своего ноутбука), будет активировано предупреждение. Существует обнаружение GuardDuty, которая определяет, когда учетные данные IAM используются за пределами EC2, и называется UnauthorizedAccess:IAMUser/InstanceCredentialExdication.OutsideAWS .
Чтобы обойти срабатывание этого предупреждения, злоумышленники могут использовать украденные учетные данные из экземпляра EC2 злоумышленника. Предупреждение обнаруживается только в том случае, если учетные данные использовались за пределами EC2, а не в конкретном экземпляре EC2 жертвы. Таким образом, используя свой собственный или другой экземпляр EC2, злоумышленники могут обойти предупреждение GuardDuty.
20 января 2022 года AWS опубликовала новый вывод GuardDuty под названием UnauthorizedAccess:IAMUser/InstanceCredentialExdication.InsideAWS . Это новое открытие устранило недостатки предыдущего. Теперь, когда учетные данные IAM используются из ЛЮБОГО EC2, если эти учетные данные не принадлежат той же учетной записи, что и экземпляр EC2, использующий их, это вызывает предупреждение. Таким образом, простое использование собственного экземпляра EC2 больше нецелесообразно. Это решает давнюю проблему в сообществе безопасности облачных вычислений.
Однако на данный момент для этого существует функционирующий обходной путь — VPC Endpoints . Использование конечных точек VPC не приведет к срабатыванию предупреждения GuardDuty. Это означает, что, будучи злоумышленником, если вы украли учетные данные IAM у экземпляра EC2, вы можете использовать эти учетные данные у своего экземпляра EC2 при маршрутизации трафика через конечные точки VPC. Это не приведет к срабатыванию обнаружения GuardDuty.
Чтобы сделать эту настройку быстрее (и проще) для тестеров на проникновение и Red Teamers, был создан SneakyEndpoints. В этом проекте есть все конфигурации Terraform, необходимые для развертывания среды для атаки. Он создаст экземпляр EC2 в частной подсети (без доступа к Интернету) и создаст несколько конечных точек VPC, которые вы сможете использовать. Эта настройка гарантирует, что мы случайно не разоблачим себя и не вызовем оповещение.
Примечание
Есть еще один вариант обхода, однако он будет полезен только в нишевых сценариях. Находка InstanceCredentialExdication связана только с учетной записью AWS, а не с экземпляром EC2. В результате, если вы скомпрометируете инстанс EC2 в целевой учетной записи, а затем скомпрометируете ДРУГИЕ инстансы EC2 в этой учетной записи или украдете их учетные данные IAM, вы сможете безопасно использовать их из первоначально скомпрометированного инстанса, не опасаясь срабатывания GuardDuty.
Осведомленность о ситуации
Теперь, когда у вас все настроено и вы знаете, на что обращать внимание, ваш следующий вопрос может быть «Что находится в этой учетной записи AWS?». Если вы выполняете оценку без знаний и, таким образом, не имеете представления о том, какие службы работают в учетной записи, вам будет сложно понять, на что ориентироваться или на что обратить внимание.
Одним из вариантов может быть перечисление связанных со службой ролей в учетной записи. — связанная с сервисом, это особый вид роли IAM, который позволяет сервису AWS выполнять действия в вашей учетной записи. Из-за этого мы потенциально можем перечислить их без аутентификации.
Из предыдущего шага проверки достоверности мы узнаем идентификатор учетной записи AWS, в которой мы работаем. Это в сочетании с этой техникой позволит нам перечислить, какие службы использует учетная запись AWS. Это может быть полезно для ответа на такие вопросы, как «Использует ли наша цель GuardDuty? Является ли эта учетная запись частью организации? Используют ли они контейнеры (ECS, EKS) или они используют EC2?».
Неаутентифицированное перечисление пользователей и ролей IAM
Оригинальное исследование: Daniel Grzelak - Remastered Talk by Scott Piper
Дополнительное чтение: Rhino Security
Ссылка на Quiet Riot: Github
Ссылка на инструмент: GitHub
Ссылка на модуль Паку: GitHub
Вы можете перечислить идентификаторы учетной записи, адреса электронной почты корневой учетной записи, роли IAM, пользователей IAM и частичный след учетной записи, злоупотребляя политиками на основе ресурсов . Есть несколько способов сделать это, например, модуль Паку попытается изменить политику AssumeRole роли в ваш учетную запись и указать роль в другой учетной записи. Quiet Riot предлагает масштабируемый метод перечисления каждого из этих элементов с настраиваемыми списками слов для каждого типа элемента.
Другой способ — использовать политики корзины S3. Возьмем следующий пример:
Код:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Example permissions",
"Effect": "Deny",
"Principal": {
"AWS": "arn:aws:iam::123456789123:role/role_name"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::*bucket you own*"
}
]
}Вы примените эту политику к сегменту ты своя. Указав принципала в целевой учетной записи (123456789123), вы можете определить, существует ли этот принципал. Если установка политики корзины прошла успешно, вы знаете, что роль существует. Если это не удается, вы знаете, что роль не работает.
Предупреждение
Выполнение любого из этих методов приведет к созданию множества событий CloudTrail, в частности UpdateAssumeRolePolicy или PutBucketPolicy в вашей учетной записи. Если вы намерены действовать скрытно, не рекомендуется (или не требуется) использовать учетные данные цели. Вместо этого вы должны использовать свою собственную учетную запись (события CloudTrail будут генерироваться там).
Примечание
Хотя это работает как для пользователей, так и для ролей IAM, это также будет работать с ролями, связанными со службой . Это позволит вам перечислить различные службы, используемые учетной записью, такие как GuardDuty или Organizations.
Чтобы автоматизировать этот процесс, вы можете использовать модуль Pacu или это , которое попытается взломать его для вас.
Код:
usage: main.py [-h] --id ID --my_bucket MY_BUCKET [--wordlist WORDLIST] (--role | --user)
Enumerate IAM/Users of an AWS account. You must provide your OWN AWS account and bucket
optional arguments:
-h, --help show this help message and exit
--id ID The account id of the target account
--my_bucket MY_BUCKET
The bucket used for testing (belongs to you)
--wordlist WORDLIST Wordlist containers user/role names
--role Search for a IAM Role
--user Search for a IAM UserПеревод ЭТОЙ этой ЭтоЙ эТОй и ЭтОй статей.
