19 июля 2019 года банк Capital One получил сообщение, которого боится каждая современная компания — произошла утечка данных. Она затронула более 106 миллионов человек. 140 000 номеров социального страхования США, один миллион номеров социального страхования Канады. 80 000 банковских счетов. Неприятно, согласитесь?
К сожалению, взлом произошёл совсем не 19 июля. Как выяснилось, Пейдж Томпсон, она же Erratic, совершила его между 22 марта и 23 марта 2019 года. То есть почти четыре месяца назад. На самом деле, только с помощью внешних консультантов 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). Ладно, это довольно очевидно. Но что делать, если вы хотите предоставить другим сервисам AWS, например, своим серверам приложений, доступ к своим бакетам S3? Для этого и существуют роли IAM. Они состоят из двух компонентов:
- Trust Policy — какие службы или какие люди могут использовать эту роль?
- Permissions Policy — что позволяет эта роль?
Например, вы хотите создать роль IAM, которая позволит инстансам EC2 получить доступ к бакету S3: во-первых, для роли устанавливается Trust Policy, что EC2 (вся служба) или конкретные инстансы могут «взять на себя» роль. Принятие роли означает, что они могут использовать разрешения роли для выполнения действий. Во-вторых, Permissions Policy позволяет службе/человеку/ресурсу, который «взял на себя роль», делать что-то на S3, будь то доступ к одному конкретному бакету… или к более 700, как в случае Capital One.
Как только вы находитесь в инстансе EC2 с ролью IAM, вы можете получить учётные данные несколькими способами:
- Можете запросить метаданные инстанса по адресу
http://169.254.169.254/latest/meta-dataСреди прочего, по этому адресу можно найти роль IAM с любым из ключей доступа. Конечно, только в том случае, если вы находитесь в инстансе.
- Использовать AWS CLI…
Если установлен интерфейс командной строки AWS, то он загружается с учётными данными из ролей IAM, если они присутствуют. Остаётся только работать ЧЕРЕЗ инстанс. Конечно, если бы их политика Trust Policy была открытой, Пейдж могла бы сделать всё напрямую.
Таким образом, сущность ролей IAM заключаются в том, что они позволяют одним ресурсам действовать ОТ ВАШЕГО ИМЕНИ на ДРУГИХ РЕСУРСАХ.
Теперь, когда вы понимаете роли IAM, мы можем поговорить о том, что сделала Пейдж Томпсон:
- Она получила доступ к серверу (инстанс EC2) через брешь в файрволе
Будь то группы безопасности/ACL или их собственные файрволы веб-приложений, вероятно, дыру оказалось довольно легко закрыть, как указано в официальных записях.
- Оказавшись на сервере, она смогла действовать «как будто» сама была сервером
- Поскольку роль IAM сервера разрешила доступ S3 к этим 700+ бакетам, она смогла получить к ним доступ
С этого момента ей оставалось только запустить команду List Buckets, а затем команду Sync из AWS CLI…
. Предотвращение такого ущерба — вот почему компании так много инвестируют в защиту облачной инфраструктуры, DevOps и экспертов по безопасности. И насколько ценным и экономически эффективным является переход в облако? Настолько, что даже перед лицом всё новых и новых проблем кибербезопасности !
Мораль этой истории: проверяйте свою безопасность; регулярно проводите аудит; уважайте принцип наименьших привилегий для политик безопасности.
( можете посмотреть полный юридический отчёт).
Источник: habr.com