В современной парадигме информационной безопасности для масс прочно укрепилось мнение, что cyber security — это дорого, сложно, а для рядового пользователя фактически невозможно. Так что если вы хотите в полной мере защитить свои данные и персональную информацию, то заведите себе аккаунт у Google или Amazon, прибейте его гвоздями в плане идентификации владельца и периодически проверяйте тревожные оповещения, что большая и сильная компания пресекла очередную попытку входа.
Но люди, разбирающиеся в ИБ всегда знали: облачные сервисы намного более уязвимы, чем отдельная рабочая станция. Ведь в случае форс-мажорной ситуации ПК можно физически ограничить доступ в сеть, а там уже начинается гонка по смене явок и паролей на всех атакуемых направлениях. Облачная же инфраструктура огромна, зачастую децентрализована, а на одном и том же физическом носителе могут храниться данные нескольких клиентов, либо наоборот, данные одного клиента разнесены по пяти континентам, а объединяет их лишь учетная запись.
Короче говоря, когда интернет был сравнительно свеж и юн (а было это в 2003 году), тогдашние специалисты по информационной безопасности внимательно посмотрели на систему защиты от переполнения буфера 1997 года, и разродились технологией, которую сейчас мы называем Honeytoken или Canarytoken. И пятнадцать лет они исправно работали (и до сих пор работают), вот только последнее исследование говорит, что вместо последнего рубежа обороны в ряде сервисов AWS, Honeytoken превратился в зияющую дыру в ИБ из-за особенностей реализации на стороне Amazon.
Что такое Honeytoken
Honeytoken, как и его идейный прародитель в системе защиты переполнения стека, использует подход «предупредить, а не предотвратить». Фактически, Honeytoken является приманкой для злоумышленников, которая оставляется под видом ценной информации и может быть представлена в виде, например, ссылки. Самый очевидный Honeytoken в практике рядовых пользователей — ссылка-сигнализация, спрятанная в письме с заголовком «данные о банковских счетах» или «мои аккаунты». Принцип также прост: как только злоумышленник позарится на информацию, которой прикидывается Honeytoken, последний отправляет оповещение владельцу/администратору о том, что периметр безопасности был нарушен.
В сам периметр Honeytoken очевидно не включают: в классическом виде это банальная пустышка, которая находится уже внутри периметра и исполняет ту же роль, которую выполняли умирающие в клетках канарейки в шахтерских забоях — предупреждение об опасности.
А вот и прародитель технологии
Подобные «сигнальные системы» сейчас достаточно распространены и используются для предупреждения владельцев персональных аккаунтов и до оповещения о нарушении безопасности AWS. При этом единого стандарта Honeytoken не существует — это может быть что угодно. Например, в списки e-mail адресов клиентов добавляют несколько специальных мертвых ящиков, появление рассылки на которых будет свидетельствовать о сливе всей базы.
В чем заключается найденная в AWS уязвимость
Amazon Web Services активно использует систему Honeytokens для получения оповещений о нарушении периметра облачной безопасности сервиса. «Канарейки» Amazon — это фальшивые ключи доступа к учетной записи. Этот инструмент при всей его простоте крайне важен: облачные сервисы подвергаются постоянным попыткам взлома и прочим атакам. Сам факт обладания знанием о «прорыве» периметра кибербезопасности AWS по одному из направлений — уже половина победы для инженеров Amazon.
Вчера, 2 октября 2018 года, специалисты из Rhino Security Labs опубликовали крайне неприятное исследование, суть которого выражается следующим утверждением: Honeytokens Amazon Web Services можно обойти, никак не потревожив сигнальную систему облака. Это дает злоумышленникам возможность тихо «входить», «брать» что им нужно и также тихо «уходить».
Вся архитектура Honeytokes AWS базируется на использовании фальшивых ключей в связке с CloudTrail, который в том числе ведет журналы активности. Но в свободном доступе в userguide Amazon есть целый список адресов и сервисов, которые не поддерживают CloudTrail. Фактически это означает, что любые запросы в сторону этих сервисов, в том числе и через API, нигде не регистрируются. При этом обратные сообщения с ошибкой доступа Amazon возвращает вместе с ARN.
Далее исследователи из Rhino Security «постучались» AWS AppStream через API DescribeFleets и получили следующую информацию о тестовой учетной записи:
Далее с ее помощью злоумышленник извлекает информацию о IAM user/role следующего плана:
IAM User:
arn:aws:iam::111111111111:user/the-path/TheUserName
IAM Role:
arn:aws:iam::111111111111:role/the-path/TheRoleName/TheSessionName
В итоге, благодаря возврату ARN и полученным данным IAM user/role специалисты смогли через парсинг скомпрометировать ключи-приманки Honeytokes на перечисленных сервисах.
Меры противодействия
Найденный путь ставит под удар не только AWS, но и разработчиков популярных honeytoken-систем для систем Amazon, таких как CanaryToken и SpaceCrab. Оба разработчика были оповещены и принимают все возможные меры для устранения проблемы.
Также специалисты из Rhino Security опубликовали на GitHub PoC-скрипт, который проверит, не является ли предоставленный вам AWS ключ токеном, так как еще не все конфигурации были обновлены.
Реакция Amazon
На репорт со стороны Rhino Security Labs представители Amazon ответили, что ARN не чувствительная информация, CloudTrain работает (и не работает) там, где нужно, и проблемы как таковой нет.
Автор: Crossover
