Хабрахабр

[Перевод] Технические детали взлома банка Capital One на AWS

Она затронула более 106 миллионов человек. 19 июля 2019 года банк Capital One получил сообщение, которого боится каждая современная компания — произошла утечка данных. 80 000 банковских счетов. 140 000 номеров социального страхования США, один миллион номеров социального страхования Канады. Неприятно, согласитесь?

Как выяснилось, Пейдж Томпсон, она же Erratic, совершила его между 22 марта и 23 марта 2019 года. К сожалению, взлом произошёл совсем не 19 июля. На самом деле, только с помощью внешних консультантов Capital One сумела узнать, что нечто произошло.
Бывшая сотрудница Amazon арестована, ей грозит штраф в размере $250 тыс. То есть почти четыре месяца назад. Почему? и пять лет тюрьмы… но осталось много негатива. Потому что многие компании, которые пострадали от взломов, пытаются отмахнуться от ответственности за укрепление своей инфраструктуры и приложений на фоне роста киберпреступности.

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

Во-первых, что случилось?

В Capital One работало около 700 бакетов S3, которые Пейдж Томпсон скопировала и выкачала.

Во-вторых, это ещё один случай неправильно настроенной политики бакетов S3?

Нет, не в этот раз. Здесь она получила доступ к серверу с неверно настроенным файрволом и оттуда провела всю операцию.

Подождите, как такое возможно?

Ну, давайте начнём с входа на сервер, хотя у нас мало подробностей. Нам только сказали, что это произошло через «неверно настроенный файрвол». Итак, что-то настолько простое, как неправильные настройки групп безопасности или конфигурация файрвола веб-приложения (Imperva), или сетевого файрвола (iptables, ufw, shorewall и т. д.). Capital One только признала свою вину и сказала, что закрыла дыру.

Безусловно, этому помог тот факт, что хакер предположительно оставила в открытом доступе ключевую идентифицирующую информацию, сказал Стоун. Стоун сказал, что Capital One изначально не заметил уязвимость файрвола, но быстро отреагировал, как только узнал о ней.

Если вас интересует, почему мы не углубляемся в эту часть, поймите, что из-за ограниченной информации мы можем только спекулировать. Это бессмысленно, учитывая, что взлом зависел от бреши, оставленной Capital One. И если они не расскажут нам больше, мы просто будем перечислять все возможные способы, как Capital One оставила свой сервер открытым в комбинации со всеми возможными способами, которыми кто-то может использовать один из этих различных вариантов. Эти бреши и методы могут варьироваться от дико глупых оплошностей до невероятно сложных паттернов. Учитывая диапазон возможностей, это превратится в длинную сагу без реального заключения. Поэтому сосредоточимся на анализе той части, где у нас есть факты.

Так что первый вывод: знайте, что позволяют ваши файрволы

Установите политику или правильный процесс для гарантии, что открыто ТОЛЬКО то, что должно быть открыто. Если вы используете ресурсы AWS, такие как Security Groups или Network ACL, очевидно, чеклист для проверки может быть длинным… но как многие ресурсы создаются автоматически (т. е. CloudFormation), также можно автоматизировать их аудит. Будь то самодельный скрипт, который просматривает новые объекты на предмет брешей, или что-то вроде аудита безопасности в процессе CI/CD… есть много простых вариантов, чтобы избежать этого.

И поэтому, откровенно говоря, всегда шокирует видеть, как действительно что-то довольно простое становится единственной причиной взлома компании. «Забавная» часть истории заключается в том, что если бы Capital One закрыла дыру с самого начала… ничего бы не случилось. Особенно такой большой, как Capital One.

Итак, хакер внутри — что случилось дальше?

Ну, после проникновения в инстанс EC2… многое может пойти не так. Вы ходите практически по лезвию ножа, если позволяете кому-то зайти так далеко. Но как она попала в бакеты S3? Чтобы понять это, давайте обсудим роли IAM (IAM Roles).

Ладно, это довольно очевидно. Итак, один из способов получить доступ к сервисам AWS — быть Пользователем (User). Для этого и существуют роли IAM. Но что делать, если вы хотите предоставить другим сервисам AWS, например, своим серверам приложений, доступ к своим бакетам S3? Они состоят из двух компонентов:

  1. Trust Policy — какие службы или какие люди могут использовать эту роль?
  2. Permissions Policy — что позволяет эта роль?

Например, вы хотите создать роль IAM, которая позволит инстансам EC2 получить доступ к бакету S3: во-первых, для роли устанавливается Trust Policy, что EC2 (вся служба) или конкретные инстансы могут «взять на себя» роль. Принятие роли означает, что они могут использовать разрешения роли для выполнения действий. Во-вторых, Permissions Policy позволяет службе/человеку/ресурсу, который «взял на себя роль», делать что-то на S3, будь то доступ к одному конкретному бакету… или к более 700, как в случае Capital One.

Как только вы находитесь в инстансе EC2 с ролью IAM, вы можете получить учётные данные несколькими способами:

  1. Можете запросить метаданные инстанса по адресу http://169.254.169.254/latest/meta-data

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

  2. Использовать AWS CLI…

    Остаётся только работать ЧЕРЕЗ инстанс. Если установлен интерфейс командной строки AWS, то он загружается с учётными данными из ролей IAM, если они присутствуют. Конечно, если бы их политика Trust Policy была открытой, Пейдж могла бы сделать всё напрямую.

Таким образом, сущность ролей IAM заключаются в том, что они позволяют одним ресурсам действовать ОТ ВАШЕГО ИМЕНИ на ДРУГИХ РЕСУРСАХ.

Теперь, когда вы понимаете роли IAM, мы можем поговорить о том, что сделала Пейдж Томпсон:

  1. Она получила доступ к серверу (инстанс EC2) через брешь в файрволе

    Будь то группы безопасности/ACL или их собственные файрволы веб-приложений, вероятно, дыру оказалось довольно легко закрыть, как указано в официальных записях.

  2. Оказавшись на сервере, она смогла действовать «как будто» сама была сервером
  3. Поскольку роль IAM сервера разрешила доступ S3 к этим 700+ бакетам, она смогла получить к ним доступ

С этого момента ей оставалось только запустить команду List Buckets, а затем команду Sync из AWS CLI…
Банк Capital One оценивает ущерб от взлома в сумму от 100 до 150 МИЛЛИОНОВ долларов. Предотвращение такого ущерба — вот почему компании так много инвестируют в защиту облачной инфраструктуры, DevOps и экспертов по безопасности. И насколько ценным и экономически эффективным является переход в облако? Настолько, что даже перед лицом всё новых и новых проблем кибербезопасности общий рынок публичных облаков вырос на 42% в первом квартале 2019 года!

Мораль этой истории: проверяйте свою безопасность; регулярно проводите аудит; уважайте принцип наименьших привилегий для политик безопасности.

(Здесь можете посмотреть полный юридический отчёт).

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть