«Где хуже всего оставлять свои секреты?» — что происходит с учетными данными AWS, которые плохо лежат

Я разместил в различных общедоступных онлайн-сервисах canary-токены, регистрируя все попытки доступа, и обнаружил интригующие закономерности в методах атак киберпреступников и в том, как они прочесывают сеть в поисках чужих учетных данных.

Canary-токены: ликбез

Canary-токен — это цифровая ловушка, которая сигнализирует о несанкционированном доступе или активности в системе. Они работают путем внедрения, казалось бы, ценной, но ложной информации (учеток от аккаунтов, ключей API или других конфиденциальных данных) в различные сегменты сети, кодовую базу или приложение. Когда злоумышленник активирует эти токены, срабатывает оповещение, уведомляющее владельца токена о потенциальном взломе. 

Метод исследования

В этом исследовании я использовал учетные данные AWS API в качестве canary-токенов, разместив их в общедоступных местах в интернете. Для генерации токенов я воспользовался сервисом Canarytokens от Thinkst. Это неплохой бесплатный сервис, предоставляющий разные типы токенов: учетные данные AWS, токены DNS, исполняемые токены и многое другое. При срабатывании токена данные об инциденте приходят вам на электронную почту. 

Я решил разместить canary-токены в следующих местах:

• Публичные репозитории кода/образов: GitHub, GitLab, BitBucket, DockerHub.

• Публичные сервисы под моим управлением: FTP-сервер, веб-сервер, блог.

• SaaS-сервисы: Pastebin, JSFiddle.

• Пакетные менеджеры: NPMJS, PyPI.

• Бакеты облачных хранилищ: AWS S3, GCP Google Cloud Storage.

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

Я отслеживал всех, кто использовал мои canary-токены для несанкционированного доступа в AWS, и собирал ценные данные: IP-адреса, user agents, временные метки и методы, используемые злоумышленниками. 

Я решил использовать в качестве приманки реквизиты от AWS, чтобы собрать реальные данные о действиях, которые можно наверняка классифицировать как противоправные. Другие типы токенов, такие как DNS-токены, исполняемые токены или графические токены, могут сработать, если кто-то просто прикасается к ним, например, из обычного любопытства, что не обязательно является сознательным нарушением закона. А вот попытка получить доступ к чужому аккаунту AWS с использованием учетных данных, которые вы нашли в интернете — это уже явно противоправное действие.

Мотивация к исследованию

Моя мотивация для проведения данного исследования проистекает из сочетания личного любопытства и желания напомнить специалистам по кибербезопасности о редко используемом инструменте: canary-токенах. Я нахожу их концепцию интригующей и классной. Идея использования как бы невзначай «оставленных» данных в качестве цифровых ловушек для обнаружения несанкционированного доступа меня заинтересовала, и я захотел выяснить, как они покажут себя в реальных условиях. Меня также заинтриговал вопрос о том, как быстро и как часто злоумышленники сканируют общедоступные ресурсы и взламывают цели, используя незащищенные учетные данные. 

Более того, я считаю, что canary-токены являются недооцененным ресурсом среди ИБ-специалистов. Несмотря на свою простоту и эффективность, эти токены не получили такого широкого распространения, как другие инструменты. Демонстрируя идеи и выводы, полученные в ходе моего исследования, я надеюсь повысить осведомленность о полезности canary-токенов и побудить безопасников использовать их в своих защитных стратегиях.

---

Результаты исследования

Репозитории кода/образов

Репозитории кода — это самое распространенное место, где люди оставляют свои учетные данные, и, очевидно, GitHub — самый популярный сервис в этой категории. Для трех репозиториев кода (GitHub, GitLab и Bitbucket) я клонировал проект Prowler (инструмент облачного аудита с открытым исходным кодом), добавил config-файл, содержащий canary-токен, и поместил измененный код в новые репозитории, настроив их как общедоступные.

Для DockerHub я создал общедоступный Docker-образ с веб-приложением NodeJS, в исходном коде которого жестко прописаны учетные данные.  Любой, кто извлекает образ, может легко увидеть токены в исходном коде. Я дал образу пикантное название, чтобы сделать его более привлекательным для злоумышленников.

На графике ниже можно увидеть количество попыток доступа к GitHub и DockerHub за час с момента публикации canary-токенов. BitBucket и GitLab здесь не показаны: к моему удивлению, никто не проявил интереса к опубликованным на этих платформах токенам.

С GitHub дело обстояло ровно наоборот: первая попытка доступа с помощью canary-токенов была предпринята в течение нескольких секунд после публикации проекта. На DockerHub первая попытка была зафиксирована спустя 170 часов (~7 дней), после чего попытки повторялись каждые несколько дней. 

На следующей диаграмме показано распределение IP-адресов, которые пробовали использовать canary-токены на GitHub в течение первых 500 часов.

Публичные сервисы под моим управлением

Для этой категории я запустил EC2 на AWS, установил несколько сервисов и открыл его для интернета:

• FTP-сервер с анонимным доступом —  я установил FTP-сервер с открытым исходным кодом, настроил его на разрешение анонимного доступа и поместил в него файл с canary-токеном.

• Веб-сервер — я настроил веб-сервер на порт 80, добавил файл robots.txt и разместил токен по пути /aws.config. Файл robots.txt должен был направлять боты-скрейперы к /aws.config.

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

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

Так или иначе, первые успешные результаты поступили только после того, как токен в /aws.config был перемещен в корневую папку веб-сервера. Потребовалось почти 50 часов, чтобы скрейперы зашли на мой веб-сайт и начали использовать токен.

На диаграмме ниже показано количество попыток доступа в первые 600 часов с момента выпуска токена. Я сравниваю canary-токен в корневом каталоге с токеном на Pastebin (про него в следующем разделе), т. к. у них было сопоставимое количество попыток.

SaaS-сервисы

1) Pastebin — онлайн-сервис, который позволяет пользователям хранить текстовые документы (фрагменты кода, файлы конфигурации, логи) и обмениваться ими. Пользователи могут создать «пасту», отправив текст, который затем сохраняется на сервере Pastebin и которому присваивается уникальный URL-адрес — им можно поделиться с другими пользователями.

Для Pastebin я протестировал 2 токена: один токен — на защищенной паролем пасте с простым для взлома паролем 123456. Второй токен был без пароля.

2) JSFiddle — онлайн-инструмент и среда совместной веб-разработки, которая позволяет пользователям писать, тестировать и обмениваться фрагментами кода на HTML, CSS и JavaScript. Я создал новый фрагмент кода с жестко прописанным canary-токеном, который имитировал службу, перечисляющую бакеты S3.

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

JSFiddle, похоже, не так уж плох — я также получил на нем 0 обращений. Полагаю, поскольку он используется для клиентского кода, разработчики вряд ли часто оставляют в коде что-то секретное и потенциально ценное, поэтому хакеры его и не мониторят.

Затем я задался вопросом, что будет, если опубликовать мой fiddle link на Pastebin без пароля, но даже тогда желающих не нашлось.

Менеджеры пакетов

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

Нахождение секретов в таких пакетах — весьма реалистичный сценарий: иногда разработчики случайно публикуют пакеты с паролями или ключами в них, или по ошибке выкладывают пакет как публичный, а не как приватный. Как видно из приведенных ниже данных, если вы допустите подобную ошибку, скорее всего, ваши секреты попадут в плохие руки в считаные секунды.

Для этого раздела исследования я выбрал два популярных менеджера пакетов: Pypi и NPMJS. Я создал приложения с жестко прописанными в коде canary-токенами и разместил пакеты в этих репозиториях.

Диаграмма ниже отображает количество попыток доступа к NPMJS и Pypi в первые часы после их публикации в открытом доступе.

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

Вероятно, мне следовало предусмотреть этот сценарий и учесть, что canary-токены будут срабатывать не только при запуске пакета злоумышленником, но и в результате работы подобных сервисов. С другой стороны, у меня есть данные, показывающие, что один и тот же IP-адрес несколько раз пытался выполнить вызовы API AWS, используя токены, оставленные в пакетах на Pypi и NPMJS. Такое поведение не свойственно роботам, автоматически скачивающим общедоступные пакеты: это уже явно был злоумышленник, который пытался составить список хранилищ и секретов.

Бакеты

Бакеты в AWS (Amazon Web Services) и GCP (Google Cloud Platform) — это контейнеры, используемые для хранения и управления объектами данных, такими как файлы, образы и резервные копии. В «дырявых» бакетах иногда раскрываются учетные данные: некоторые люди используют бакеты для хранения резервных копий и файлов конфигурации, не осознавая, что бакет настроен как общедоступный.

В этой части части исследования я разместил по одному canary-токену в общедоступных бакетах на AWS S3 и GCP Google Cloud Storage.

Поводом для включения этих бакетов в исследование была моя несколько конспирологическая теория о том, что в мире могут быть злодеи, у которых есть метод идентификации всех общедоступных бакетов. Я надеялся, что мне удастся найти этих рептилоидов и разоблачить их ящероподобные повадки!

Увы, ни один из бакетов не сгенерировал обращений, когда я сделал их общедоступными. Только после того, как я опубликовал адрес бакета на Pastebin, GitHub и на своем сайте, я получил несколько обращений, которые выглядят так, будто кто-то из Соединенных Штатов пытается использовать ряд функций API на AWS (полагаю, это был обычный человек, а не рептилоид).

Скорость получения доступа

Как я уже упоминал, мне было важно узнать, как быстро хакерские боты перехватывают украденные учетные данные и получают к ним доступ. Выяснилось, что в случае некоторых сервисов они делают это чертовски быстро.

Схемы атак

Получив оповещение о срабатывании canary-токена, вы можете посмотреть, какое действие злоумышленника привело к его активации. Оставленные мной токены представляли собой учетные данные API AWS, поэтому я мог отследить, какое событие API AWS пытались вызвать злоумышленники. К сожалению, здесь сервис canarytoken.org немного разочаровывает — он не сохраняет подробную информацию о прошлых событиях (она не отправляется по электронной почте). В общей сложности мне удалось отловить около 70% событий — остальная часть информации была утеряна. Вот график с разбивкой по типу событий:

Событие InvokeModel в AWS относится к действию по вызову модели машинного обучения, развернутой в сервисах AWS, таких как AWS SageMaker. Когда это событие запускается, указанная модель обрабатывает входные данные и возвращает результаты прогнозирования. У меня есть несколько идей, почему это оказалось популярным выбором у злоумышленников, но я оставлю вам возможность поразмышлять над этим самостоятельно.

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

На этой диаграмме показано общее число попыток доступа через токены, размещенные на разных сервисах (включая сервисы, у которых не было обращений). 

Анализ IP-адресов

В общей сложности в логах canary-токенов было найдено 45 уникальных IP-адресов. Вот подробная информация о них:

Разбивка IP-адресов злоумышленников по странам слабо отличается от того, что мы обычно наблюдаем в других подобных исследованиях киберактивности. Большинство айпишников относятся к Соединенным Штатам, также отметились несколько стран Азии. Единственный сюрприз для меня здесь — отсутствие китайских IP-адресов. Впрочем, я бы не придавал особого значения источнику IP-адресов, поскольку многие злоумышленники наверняка используют в целях осторожности какой-нибудь зарубежный автоматизированный облачный сервис. AWS Internal и SNS попали в диаграмму из-за того, что CanaryTokens иногда указывает их в качестве источника IP-адресов.

Анализ вредоносных IP-адресов

Мне также было интересно, будут ли IP-адреса отмечены как вредоносные в каком-нибудь сервисе по тестированию IP-адресов. VirusTotal предоставляет бесплатный IP-скан, который проверяет классификацию IP-адресов с использованием 92 различных движков. При проверке движок относит IP к одной из четырех категорий: «Чистый», «Без рейтинга», «Вредоносный», «Подозрительный». Я прогнал все 45 уникальных IP-адресов по каждому из 92 движков (всего 4140 результатов) и получил следующие результаты:

• Чистые: 1283 (31.0%);

• Без рейтинга: 2848 (68.8%);

• Подозрительные: 2 (0.04%);

• Вредоносные: 7 (0.02%).

Результаты этого анализа показывают, что метод классификации вредоносных IP-адресов для выявления этого типа атак в принципе бесполезен из-за высокой частоты ложноотрицательных срабатываний.

Анализ user agent 

Данные по user agent дают представление о том, как боты получали доступ к AWS. Такие данные легко подделать, но они могут быть использованы для идентификации злоумышленников: можно отследить номер версии ПО, используемого для доступа к AWS.

На следующей диаграмме показано количество попыток доступа для каждого user agent.

Большинство запросов было выполнено с использованием той или иной версии botocore3 (основной библиотеки, используемой в официальном AWS SDK). Также представлено большое количество хорошо известных HTTP-библиотек, таких как python-requests, axios и AIOHttp. Это дает основания полагать, что попытки доступа выполнялись автоматически с использованием специально разработанных инструментов (а не вручную с помощью AWS CLI).

Заключительные мысли

Вещи, которые меня удивили

Анализ собранных данных преподнес два неожиданных открытия:

1. Никаких попыток доступа к BitBucket и GitLab. Приступая к эксперименту, я был уверен, что токены на этих сервисах будут найдены довольно быстро — возможно, не так быстро, как на GitHub, но все же я не ожидал, что будет 0 обращений. Я до сих пор не уверен, как это объяснить: возможно, эти сервисы менее популярны, или их сложнее сканировать ботами-скрейперами.

2. Я нахожу довольно удивительным, что некоторые токены были схвачены и использованы буквально через несколько секунд после размещения. Токен NPMJS был схвачен менее чем за минуту (включая дополнительное время на вход в аккаунт и обнаружение попытки доступа). С GitHub и Pypi та же ситуация — токены на этих платформах были активированы через пару минут после того, как я их разместил. 

Мнение о canary-токенах 

Как я уже упоминал в начале, canary-токены — это недооцененный инструмент, позволяющий дешево и быстро создать дополнительный слой безопасности для приложения или ИТ-продукта. Несмотря на свою простоту, они могут сыграть решающую роль в обнаружении несанкционированного доступа и потенциальных угроз. 

Стратегически разместив canary-токены в своих системах, вы заранее выявлять вредоносную активность, быстрее на нее реагировать и митигировать последствие. Развертывание canary-токенов требует минимальных усилий и затрат, но при этом они могут значительно повысить уровень вашей безопасности. 

О том, как научиться самостоятельно работать с этим инструментом, можно прочитать в другом моем посте.

Выводы из эксперимента

Основной вывод: существуют группы злоумышленников, которые весьма эффективно используют веб-скрейперы, чтобы «пылесосить» сеть на предмет плохо лежащих секретов. Скорее всего, хакеры перехватят ваш токен или пароль в течение нескольких минут или часов в зависимости от того, на каком сервисе вы его оставили 

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