Облачное внедрение в крупной организации обычно включает множество услуг от различных провайдеров, каждый из которых имеет свои правила взаимодействия, настройки и даже протоколы. В результате конфигурация безопасности становится настолько сложной, что её трудно отследить и ещё сложнее понять. В нашем новом исследовании мы собрали самые распространённые ошибки развёртывания облачной инфраструктуры на примере Amazon Web Services, и некоторыми из них поделимся в этом посте.

Облачные провайдеры сегодня предлагают сервисы, выходящие за рамки тривиального «дедика» или файлового хранилища. Каждый аспект каждой услуги можно запрограммировать. Это даёт разработчикам и операторам больше возможностей контроля безопасности по сравнению с традиционным ЦОДом. Однако богатство функций и средств их конфигурации приводит к тому, что выполнить настройку можно из нескольких интерфейсов, причём — и это важно — параметры по умолчанию различны для разных способов.

Для опытных пользователей это не представляет проблемы — напротив, они воспользуются наиболее подходящим для задачи средством. Однако для остальных результат может не оправдать их ожидания.

Хранилища Amazon S3

Хранилища Amazon Simple Storage Services или Amazon S3 — одна из самых востребованных облачных услуг, которую используют многие клиенты от мелких компаний до крупных корпораций. Популярность превратила S3 в любимую мишень для злоумышленников, которые ищут недостатки в реализации сервисов и ошибки в их конфигурации.

Самые распространённые векторы атак на Amazon S3, которые использовали киберпреступники, — это:

• хранилища с публичным доступом на запись;
• перехват учётных записей;
• злоупотребление привилегиями.

Общий доступ на запись

В феврале 2018 года на сайте одной из крупнейших американских газет был обнаружен майнер криптовалюты Монеро. Каждый читатель, заходивший на сайт, майнил коины для преступников, добавивших вредоносный код в JavaScript-файлы издания.

Сайт газеты был размещён на хостинге Amazon и хранил все картинки, скрипты и файлы стилей в хранилище S3. Доступ к этому хранилищу был ограничен только чтением, поэтому для администраторов сайта взлом стал полной неожиданностью. Они просто не могли понять, как их взломали, пока специалисты по облачным сервисам не объяснили, что причина — в неправильной настройке прав доступа.

Хранилища Amazon S3 можно использовать через http/https, и в этой части администраторы сайта сделали всё правильно, ограничив доступ только чтением. Однако к S3 можно обратиться и через нативный протокол AWS через командную строку, причём права доступа для таких обращений нужно задавать отдельно, а по умолчанию запись в хранилище через AWS CLI разрешена всем авторизованным в AWS пользователям.


Результат выполнения консольной команды aws s3api get-bucket-acl --bucket <BUCKET_NAME> для хранилища, созданного с правами доступа по умолчанию

Для новых пользователей Amazon S3 необходимость дважды ограничивать права доступа к своему хранилищу далеко не очевидна, что и приводило к многочисленным инцидентам.

В конце 2018 года AWS переопределили политику безопасности, запретив публичный доступ из консоли для новых хранилищ S3, однако при использовании командной строки эта политика не применялась. Доступ по-прежнему нужно было ограничивать отдельной командой.

В 2018-2019 году компрометация хранилищ S3 приобрела массовый характер. Некоторые специалисты по безопасности и доброжелательно настроенные хакеры специально искали открытые для записи ресурсы AWS и оставляли там файлы с предупреждениями.


Анонимное предупреждение о небезопасной конфигурации AWS S3

Кто-то даже предлагал свои услуги по настройке безопасных параметров хранилища:


Предупреждение и предложение услуг от пентестера Random Robbie

Random Robbie — псевдоним пентестера Robbie Wiggins, который в 2018 году оставил своё предупреждение на тысячах открытых для записи хранилищах S3.

Возможность свободно модифицировать сайты, размещённые в хранилищах S3, немедленно воспользовались хакеры. Группировка Magecart массово внедряла вредоносный код для хищения данных банковских карт и сведений об учётных записях пользователей. Ведь всё, что для этого требовалось, — найти сайт, который принимает платежи и использует AWS. В результате преступникам удалось похитить данные сотен тысяч посетителей таких ресурсов.


Пример данных, которые скиммер передавал преступникам

В числе пострадавших от действий Magecart сотни онлайн-магазинов, среди которых известные бренды.

В ходе исследования мы обнаружили, что, несмотря на множество публикаций и рекомендаций относительно безопасной конфигурации сервисов AWS, минимум пять интернет-магазинов из числа скомпрометированных продолжают использовать доступные для записи хранилища S3. На сегодняшний день их сайты не содержат скиммеров, однако их в любой момент могут добавить, поскольку в распоряжении киберпреступников имеются удобные инструменты, облегчающие поиск уязвимых ресурсов.

Инструменты для поиска открытых хранилищ S3

Найти открытые для чтения и записи хранилища помогают инструменты Slurp, Bucket Stream и s3scanner.

Slurp помогает найти возможные имена хранилищ для заданного домена и проверить права на запись в них:


Пример вывода Slurp. Доступ по http закрыт.

Чтобы проверить доступность найденного хранилища через AWS CLI, можно воспользоваться командой get-bucket-acl:


Доступ к ресурсу через AWS API также закрыт

Утилита s3scanner, написанная на Python, с помощью простой эвристики находит возможные имена хранилищ и проверяет доступ к ним.


Поиск и проверка доступности хранилища S3 с помощью s3scanner

Утилита Bucket Stream ищет потенциально уязвимые хранилища S3 в общедоступных источниках, например, в журналах Certificate Transparency и других.

Утилита AWSBucketDump выводит список файлов хранилища, имена которых содержат определённые ключевые слова:


Результат работы утилиты AWSBucketDump

Используя эти утилиты, с декабря 2018 по январь 2019 мы нашли более 5200 уникальных хранилищ S3. Около 4400 из них были доступны для стандартных утилит командной строки AWS. Лишь 79 из них были доступны для чтения, а 40 — для записи. Для доступа к части из них требовалось просто назначить нужные права.

Как утекают учётные записи

Права доступа к ресурсам — источник головной боли разработчиков. А в случае облачных средств проблема становится ещё более острой. Процессы должны пройти аутентификацию, чтобы получить доступ к ресурсам, иначе появляется риск кражи или компрометации данных. Весь вопрос в том, как сделать это, не рискуя скомпрометировать данные при публикации кода в репозитории, как сделал автор следующего фрагмента, размещённого на Pastebin:


Фрагмент опубликованного на Pastebin кода с валидными AWS API ID и key

Используя эти данные, атакующий может получить все права, которые предоставлены учётной записи этого приложения.

Ещё один источник утечек учётных данных — клиентские сертификаты Kubernetes API. С одной стороны, в конфигурации по умолчанию эта система оркестрации контейнеров требует обязательной защиты в виде клиентского сертификата. С другой — разработчики с удивительной наивностью публикуют сертификаты вместе с кодом на GitHub, Pastebin и на других сервисах.

Только на Pastebin нам удалось найти около полусотни различных клиентских сертификатов, размещённых вместе с конфигурационными скриптами.

Если публикация сертификатов в открытом виде где бы то ни было — плохая идея, то размещение его на GitHub — просто отвратительная, ибо:

• чтобы удалить сертификат, вам придётся удалить его из всех сохранённых версий в репозитории;
• если какой-то разработчик сделает форк вашего кода, вместе с ним он получит копию сертификата, удалить которую вы уже не сможете;
• вы не сможете помешать злоумышленнику воспользоваться вашим сертификатом и, скорее всего, ничего не заметите, пока не начнутся реальные проблемы.

Скомпрометированные ключи API и сертификаты могут стать источником серьёзного финансового ущерба, как у российской компании за один день задолжавшей Amazon 12 тыс. долларов США: у неё взломали сайт на Bitrix, на котором, помимо прочего, был указан API ключ для доступа в хранилище S3.


Скриншот из биллинговой панели российской компании, похищенный API ключ которой использовали для создания множества виртуальных машин и майнинга криптовалюты. Источник: habr.com/ru/post/357764

Не менее болезненной может стать утечка клиентских данных, как в компании Imperva в 2019 году. У Imperva тоже похитили API ключ и слили все клиентские данные.

Похищенные учётные записи могут использоваться киберпреступниками для нелегальной торговли выделенными серверами AWS, платить за которые в итоге придётся настоящим владельцам. На форуме lolzteam мы нашли более 250 объявлений, предлагающих «чистые нулевые дедики».


Объявление на форуме lolzteam. Кто в итоге заплатит Amazon?

Третий источник утечек ключей API — это разнообразные обучающие курсы для программистов.

Пытаясь как можно проще объяснить новичкам процесс подключения к сервисам AWS, авторы тиражируют плохую практику, что в дальнейшем приводит к новым и новым случаям компрометации.


Фрагмент из курса по Python, где объясняется, как работать со службами Amazon S3. Ключи предлагается захардкодить в программу

Авторы курса по прогрессивному и безопасному языку Java демонстрируют такое беспечное отношение к безопасности ключей API:


Язык другой, а советы всё те же — ключи прямо в тексте программы.

Наши рекомендации

Неправильная конфигурация облачных служб создаёт множество рисков от нелегального использования арендуемых вычислительных ресурсов для майнинга криптовалюты до хищения данных и внедрения онлайн-скиммеров. В связи с этим мы рекомендуем сотрудникам службы безопасности анализировать сценарии развёртывания облачных вычислений, чтобы выявить потенциальные уязвимости до того, как процесс будет завершён. Скрипты проверки облака, подобные AWS CloudFormation, дают представление о том, как будет работать итоговая инфраструктура, где искать неправильные или отсутствующие настройки безопасности или журналы. Среди разработанных Trend Micro средств обеспечения безопасности имеется продукт, ориентированный на защиту облачных сред, — Deep Security for Amazon EC2 instances. А инструмент Cloud Conformity позволяет облачную среду компании на наличие небезопасных настроек.

Программистам, использующих ключи AWS API для взаимодействия с хранилищами S3, мы предлагаем перейти на работу через AWS Secrets Manager, Docker Secrets, Blackbox, git-secrets и другие тому подобные инструменты, которые позволят исключить компрометацию и вредоносное использование учётных данных, сохранённых вместе с исходными текстами приложения.