Компании все чаще используют облачные сервисы для хранения данных, виртуальных машин, контейнеров, бессерверных функций и многого другого. С ростом популярности облачных сервисов интерес киберзлоумышленников к ним соответственно возрос. Из-за того, что любой человек может легко установить облачный инстанс – и не всегда в соответствии с протоколами ИТ-безопасности, – злоумышленники используют новые способы получения доступа к данным и активам организации. Когда мы говорим об облачных сервисах в целом, и о AWS в частности, нельзя игнорировать связь между локальной средой и облаком. Использование технологии обмана в облаке жизненно важно для защиты современных быстрорастущих сред.
По мере того, как ваша сеть переходит в облако, уровень обмана также должен перемещаться. Существует множество способов развертывания ресурсов-обманок в облаке. Давайте рассмотрим сценарий атаки и покажем некоторые оповещения, вызванные нашим уровнем обмана.
В этом сценарии атаки мы начнем с киберпротивника, который уже получил доступ к вашей сети, и покажем различные способы получения учетных данных AWS. Затем мы покажем некоторые сценарии перечисления, которые могут быть использованы злоумышленниками для сбора разведывательной информации об облачной среде, чтобы повысить привилегии и подключиться к некоторым облачным инстансам.
Эксплойты нулевого дня обнаруживаются часто, и они всплывают, когда вы меньше всего этого ожидаете. Развертывание решения для обмана позволяет проактивно подготовить сеть к кибер-атакам. После развертывания приманки будут поджидать всех злоумышленников, которые проберутся в вашу среду — как локальную, так и облачную.
Сценарий: Кибер-атаки в облачных средах без технологии обмана
Каждая большая атака начинается с одного маленького шага. В действительности существует множество способов, с помощью которых злоумышленник может получить доступ к вашей сети. Совсем недавно были опубликованы две атаки нулевого дня, которые позволяют удаленно выполнить код (RCE) и получить быстрый доступ к уязвимым машинам: Log4j и Spring4shell. В недавнем блоге мы показали, как такие атаки могут быть использованы для быстрого получения учетных данных AWS. Многие подобные атаки дают доступ к машинам жертв, и, оказавшись внутри, злоумышленники могут получить учетные данные AWS, которые открывают двери для латерального перемещения через облако.
Вот как киберпротивники получают такой доступ:
Первоначальный доступ: Учетные данные AWS
Например, чтобы подключиться к AWS с помощью программного доступа, администратору учетной записи необходимо сгенерировать ключ доступа и секрет ключа доступа для конкретного пользователя AWS. Это часто встречается при работе с интерфейсом командной строки (CLI) AWS. Злоумышленник, имеющий доступ к этим ключам, получит доступ к среде AWS этого пользователя.
Если на машине жертвы используется AWS CLI, эти учетные данные обычно сохраняются открытым текстом на этой машине. Обычно их легко найти в одном из этих мест:
• При загрузке учетных данных из AWS они сохраняются в файле формата CSV. Имя файла по умолчанию: <USER>_credentials.csv.
• В большинстве случаев автоматические инструменты (например, AWS CLI или Python’s boto3) используют файл учетных данных, расположенный в каталоге «.aws». На машинах Linux этот файл будет находиться здесь: ~/.aws/credentials, а на машинах Windows — здесь: C:\Users\USERNAME\.aws\credentials
• Вместо того чтобы сохранять их в файлах, некоторые конфигурации будут хранить ключи в переменных окружения на машине: AWS_ACCESS_KEY_ID И AWS_SECRET_ACCESS_KEY. Их можно легко получить с помощью команд среды Windows или Linux.
• В редких случаях учетные данные будут записаны и жестко закодированы в коде или скриптах, которые их используют. Сохранять ключи в коде – плохая практика, но это делается, особенно во время первоначального написания кода.
Перечисленные выше места и векторы атак – это верхушка айсберга. Существует гораздо больше способов получения доступа и кражи ключей доступа. Важно защитить свои учетные данные. Кроме того, будьте готовы к сценарию, когда ваши ключи доступа будут взломаны. Давайте рассмотрим следующий этап и то, как быстро может развиваться атака, если злоумышленник завладеет вашими ключами.
Расширение плацдарма: Перечисление и эскалация
Ключи доступа дают злоумышленнику определенный доступ к вашей облачной среде. Цель злоумышленника – использовать этот ключ, чтобы все глубже и глубже проникнуть в вашу среду. Уровень доступа, которого он сможет достичь, будет зависеть от того, как был настроен конкретный пользователь, конфигурации вашей облачной среды и, конечно, от навыков вашего киберпротивника.
Чтобы ускорить доступ, давайте воспользуемся двумя скриптами перечисления облаков, которые мы недавно опубликовали. Один из них перечисляет инстансы EC2, а другой – роли AWS. Их можно использовать для сбора информации, повышения привилегий и попытки подключения к работающим инстансам. При наличии доступа к этим ключам этап перечисления и эскалации не обязательно должен происходить внутри вашей сети. Злоумышленник может сделать это, не выходя из дома или из любого другого места.
Сценарий 1 – ec2_enumeration
Этот сценарий имеет два режима: перечисление и подключение. В режиме перечисления будут перечислены инстансы EC2 в целевой среде AWS. Он перечислит доступные экземпляры и покажет, к каким из этих инстансов у нас есть разрешения на подключение. Режим подключения откроет SSH-соединение с инстансом. Для режима подключения мы используем опцию Amazon «EC2 Instance connect», которая позволяет пользователям открывать соединение с инстансом без использования открытых или закрытых ключей. Этот сценарий в основном основан на AWS SDK для phyton, Boto3 и AWS EC2 instance connect CLI. Для получения более подробной информации ознакомьтесь с этим скриптом на GitHub.
Сценарий 2 – перечисление_ролей
Ролевой сценарий имеет три режима: перечисление, детализация и принятие. В режиме перечисления будут перечислены роли, дана краткая информация о каждой из них и отмечено, какие роли могут быть приняты с существующими разрешениями. В режиме детализации будет показана более подробная информация о роли и ее политиках. В режиме assume будет сделана попытка принять выбранную роль. Этот сценарий в основном основан на AWS SDK для phyton, Boto3. Для получения более подробной информации ознакомьтесь с этим скриптом на GitHub.
Будем использовать эти два сценария вместе для перечисления и эскалации привилегий, которые у нас есть изначально. Сначала проверим, к каким инстансам и ролям мы можем получить доступ с первоначальным пользователем, к которому мы подключаемся. Затем мы примем на себя роли, к которым у нас есть доступ, и повторим попытку перечисления, чтобы определить дополнительные роли и инстансы, которые теперь открыты. Наконец, мы воспользуемся сценарием инстансов, чтобы получить shell-доступ к одному из инстансов и выполнить действия с ним.
Шаг 1: Перечисление
На этом этапе мы перечисляем доступные инстансы EC2 и роли. Он показывает, к каким инстансам можно подключиться и какие роли можно взять на себя. Когда мы находим роль, которую можно принять и которая имеет интересные разрешения, мы можем описать ее более подробно.
.
Изображение шага 1.1 – перечисление инстансов – ни к одному из экземпляров нельзя подключиться с нашими учетными данными.
Изображение шага 1.2 – перечисление ролей – 3 роли могут быть приняты нашим пользователем, одна из них имеет права на EC2 и S3.
Изображение шага 1.3 – описание роли: Iam_role_1
Шаг 2: Назначить роль
Далее давайте воспользуемся опцией «Assume Role» в скрипте. Сценарий примет эту роль и выдаст нам действительный токен, который можно использовать для следующих итераций.
.
Изображение шага 2 – получение учетных данных после Assume Role
Шаг 3: Перечисление
Используйте новый токен и повторно выполните команды перечисления, чтобы определить дополнительные инстансы. На изображениях ниже мы видим, что были определены новые экземпляры EC2, включая те, которые позволяют нам использовать учетные данные для подключения.
Изображение шага 3 – перечисление инстансов – 7 экземпляров могут быть подключены с нашими новыми учетными данными
Шаг 4: Подключение к инстансу
Наконец, на основе идентифицированных экземпляров мы выберем тот, к которому хотим подключиться, используя режим подключения скрипта. Подключимся к этому экземпляру.
Оставим на усмотрение читателей, какими могут быть дальнейшие шаги на этом этапе. Злоумышленники обычно предпочитают добывать биткоины или шифровать файлы данных.
Изображение шага 4 – подключение к инстансу
Развертывание технологии обмана для проактивной киберзащиты
Решение на основе технологии обмана, такое как Fidelis Deception®, позволяет пользователям быстро и легко распространять ложные ресурсы в реальной облачной среде. Вся активность на этих ресурсах будет постоянно отслеживаться и выдавать высокоточные, действенные предупреждения.
В этом примере среды мы использовали следующие ресурсы-приманки.
• Экземпляры EC2 — мы развернули 2 ложных экземпляра EC2.
• Роли IAM — мы развернули 3 ложные роли с различными политиками.
• S3 — мы развернули два хранилища S3 с несколькими ложными документами.
Мы также создали связи между ложными ресурсами. Например, роль decoy имеет права доступа к экземплярам decoy EC2 и файлам decoy S3.
Подобно тому, как сетевая среда обмана должна соответствовать локальной местности, облачные ресурсы-обманки должны органично вписываться в облачную среду. Атакующий не должен понять, что его привели к ложным ресурсам с помощью технологии обмана, и должен поверить, что он взаимодействует с ценными активами.
В показанных ниже оповещениях мы увидим оповещения, сработавшие во время фазы перечисления и фазы эскалации привилегий, описанных выше.
Предупреждение 1 — Перечисление EC2
Предупреждение 2 — Присвоение роли
Предупреждение 3 — Подключение EC2
Защита облака с помощью технологии обнаружения
Для обеспечения безопасности организации необходимо защищать облако так же тщательно, как и сеть. Мы описали несколько способов, с помощью которых злоумышленник может получить доступ в отсутствие технологии обмана.
Киберпротивники могут совершать эти действия из любого места, и им, конечно, не обязательно находиться внутри вашей сети. Однако атаки могут исходить и от внутренних угроз. Традиционные средства сетевой безопасности не смогут эффективно отразить эти атаки. Технология обмана обеспечивает защиту от внешних угроз и вредоносного ПО, а также защиту от внутренних угроз.
С помощью правильных инструментов вы можете перейти к проактивной киберзащите с помощью решения по обману, которое не зависит от того, как злоумышленник проник в вашу среду. Цель технологии обмана – быстро обнаружить злоумышленников, которые проникли в вашу среду, и отвлечь их от производственных активов.
Fidelis Deception имеет несколько уровней обмана, которые могут быть развернуты в вашей облачной среде. В этом блоге мы рассмотрели развертывание облачных ресурсов-обманок. Дополнительные уровни – это обманки, которые могут быть развернуты на серверах в облаке, или обманки, которые могут быть развернуты в виде капсул в контейнерах. Вы можете еще больше усилить защиту в облачных средах, обеспечив видимость этих динамичных, распределенных и разнообразных систем. Созданная для облака платформа управления положением, защиты рабочих нагрузок и безопасности контейнеров, такая как Fidelis CloudPassage Halo®, в сочетании с Fidelis Network®, может обеспечить вам глубокую видимость облака, которая вам необходима, а также оценку рисков ваших облачных активов в режиме реального времени, чтобы вы могли постоянно совершенствовать свою защиту.
Источник: https://bit.ly/3ZzUIwW
