Оппортунистическая атака «SCARLETEEL» на аккаунт фирмы в Amazon Web Services привела к целенаправленной краже данных после того, как злоумышленник использовал лишние права доступа для проникновения в облачную систему.
Уязвимый контейнер Kubernetes и уязвимые разрешения позволили злоумышленнику превратить оппортунистическую атаку криптоджекинга в широкомасштабное вторжение, направленное на интеллектуальную собственность и конфиденциальные данные.
Атака, которую компания Sysdig, специализирующаяся на облачной безопасности, назвала «SCARLETEEL», началась с того, что хакер атаковал кластер Kubernetes через внутренний сервис для получения временных учетных данных, а затем использовал эти данные для выявления другого сервиса Elastic Compute Cloud (EC2), который был развернут в инфраструктуре целевой компании. В конце концов, компания, которая не была названа в опубликованном сегодня отчете об инциденте, должным образом ограничила объем разрешений для украденных учетных данных, что позволило сдержать атаку.
Однако этот инцидент подчеркивает, что компании должны быть осторожны при настройке элементов управления, позволяющих облачным ресурсам взаимодействовать друг с другом, говорит Майкл Кларк, директор по исследованию угроз компании Sysdig.
«Наличие у ролей EC2 возможности доступа к другим ресурсам может быть обычным явлением, но обычно это жестко ограничено, чтобы предотвратить инциденты, подобные этому» - сообщает он. «Речь идет о том, чтобы понять, как такие неправильные конфигурации могут сочетаться с другими проблемами, ведущими к более масштабному нарушению».
Эта сложная кибератака также показывает, что злоумышленники все чаще выбирают в качестве мишени облачную инфраструктуру. В прошлом хакеры фокусировались на элементарном взаимодействии с облачными сервисами, например, на развертывании программного обеспечения для криптоджекинга, но по мере понимания уязвимостей, вносимых предприятиями в их собственные среды, атаки, ориентированные на облака, становятся все более популярными.
По данным компании CrowdStrike, предоставляющей услуги в области кибербезопасности, в своем последнем ежегодном «Отчете о глобальных угрозах», опубликованном 28 февраля, количество инцидентов, в которых атакующие взаимодействовали с облачными ресурсами, почти утроилось.
«Атакующим потребовалось время, чтобы понять, как действовать в облаке» - заявляет Адам Мейерс, руководитель отдела разведки CrowdStrike. «Организациям действительно необходимо внимательно изучить безопасность своих облаков, потому что облако поставляется безопасным из коробки, но когда люди начинают работать с ним и изменять его, они делают его менее безопасным».
От незначительного взлома к крупному инциденту.
Злоумышленник взломал облачную инфраструктуру объекта через уязвимый интернет-сервис, который позволял получить доступ к кластеру Kubernetes - технологии, используемой для управления и развертывания контейнерных приложений. Попав в кластер, атакующий использовал доступ для развертывания контейнеров с программным обеспечением для криптоджекинга, по сути, похищая вычислительные мощности из облачной инфраструктуры жертвы для добычи криптовалюты.
«Это обычная практика для контейнерных угроз» - заявили исследователи Sysdig в своем анализе, добавив, что злоумышленник затем «использовал эту роль для разведки в облаке, поиска конфиденциальной информации и кражи проприетарного программного обеспечения».
Хакер знал, как перемещаться в облаке AWS, включая службы EC2, подключаться к бессерверным функциям Lambda и использовать сервис непрерывной интеграции и развертывания (CI/CD), известный как Terraform. Поскольку Terraform часто сохраняет состояние своего конвейера в ведрах Simple Storage Service (S3), атакующий смог получить эти файлы и найти по крайней мере еще одно дополнительное удостоверение в данных открытого текста.
Вторая учетная запись, однако, имела ограниченные права доступа, что остановило латеральное движение злоумышленника, говорится в анализе Sysdig. Между тем, попытки разведать имена пользователей и облачную инфраструктуру привели к обнаружению, говорит Кларк.
«Атака была обнаружена благодаря аномальному количеству выполняемых AWS действий, особенно со стороны ролей, которые не должны делать подобные запросы» - сообщает он. «Есть и аспект разведки угроз - некоторые из IP-адресов, которые были задействованы, были связаны с вредоносной деятельностью в прошлом».
Неправильная конфигурация, а не отсутствие MFA.
Какие выводы можно сделать из этой атаки? Во-первых, компаниям необходимо обеспечить хорошую видимость работы и телеметрии своей облачной инфраструктуры. Кроме того, ограничение доступа - даже назначение доступа только для чтения к определенным облачным ресурсам - может иметь большое значение для остановки атаки в процессе ее проведения. Чем больше злоумышленники будут атаковать ресурсы, используя украденные идентификационные данные, тем больше шансов их обнаружить, считают в Sysdig.
«Во-первых, нулевое доверие и принцип наименьших привилегий очень важны, и если вы их реализуете, вы снизите вероятность компрометации» - пишут исследователи. «Во-вторых, надежные средства обнаружения и оповещения должны помочь вам поймать эти действия до того, как злоумышленник проникнет слишком глубоко».
Кларк также отмечает, что технологии многофакторной аутентификации (MFA), скорее всего, не смогут существенно помочь в борьбе с атаками на облачную инфраструктуру, поскольку большинство облачных идентификаторов, которыми пользуются злоумышленники, являются машинными идентификаторами - поэтому необходимо использовать альтернативные средства защиты.
«MFA мог бы быть полезен для других задействованных учетных записей, чтобы предотвратить их доступ» - говорит Кларк, - «но это были внутренние учетные записи, созданные для целей автоматизации, а не те, в которые, как ожидалось, войдет человек».
Источник: https://www.darkreading.com
