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…Банк Capital One оценивает ущерб от взлома в сумму от 100 до 150 МИЛЛИОНОВ долларов. Предотвращение такого ущерба — вот почему компании так много инвестируют в защиту облачной инфраструктуры, DevOps и экспертов по безопасности. И насколько ценным и экономически эффективным является переход в облако? Настолько, что даже перед лицом всё новых и новых проблем кибербезопасности общий рынок публичных облаков вырос на 42% в первом квартале 2019 года!
Мораль этой истории: проверяйте свою безопасность; регулярно проводите аудит; уважайте принцип наименьших привилегий для политик безопасности.
(Здесь можете посмотреть полный юридический отчёт).
Комментарии (24)
Tangeman
12.08.2019 14:29Взломом это можно назвать только с большой натяжкой — это типичный inside job.
Что удивляет больше — это абсолютно не связанный с чем-либо пассаж о том что нужно идти в облако (хотя, вероятно, это просто реклама AWS), несмотря на то что в данном случае именно сотрудница облачного провайдера стала причиной проблемы.
jetcar
14.08.2019 10:47социальная инженерия != взлом? если данные утекли то это взлом, зделано это через найденую дырку в софте или физически пришли и утащили жёсткие диски это без разницы, особо важные данные охраняют не только настройками, но и физически, а ещё и от работников всех уровней, если тупо доверять облачному сервису то это сомнительный подход
vanyas
12.08.2019 15:16+1Не понятно еще, как она на EC2 инстанс попала, кроме плохо нстроенного фаервола, нужна же еще учетка на сервере или уязвимость…
w0den
12.08.2019 22:09Возможно это просто совпадение, но «Бывшая сотрудница Amazon» звучит слишком подозрительно. Было бы интересно узнать, в каком подразделении она работала, а также, когда и почему перестала там работать.
Tangeman
12.08.2019 23:19+1Возможно это просто совпадение, но она была системным инженером в AWS где-то между 2015 и 2016 годами.
Почему она перестала там работать — гораздо более сложный вопрос, но судя по столь короткому сроку наводит на вполне очевидные мысли…
w0den
13.08.2019 04:33Интересно… В таком случае можно предположить, что Capital One не единственная жертва.
erty
13.08.2019 08:59> сообщение, которого боится каждая современная компания — произошла утечка данных
Не боится.
* О сообщении узнают полтора технаря на хабре.
* Инвесторам говорите «Ой извините. Это были хакиры. В вот у нас зато занавески красивые.»
* Продолжаешь грести бабло.
Пока ещё ни одной конторки не закрыли за утечку. Чего бояться-то? Вот утечка туалета в офисе — это гораздо страшнее.dimka11
13.08.2019 18:03Как же GDPR и штрафы? А еще потеря доверия.
erty
14.08.2019 11:18Все уже перестали пользоваться фэйсбуком, убером или British Airlines? Я видимо в какой-то другой вселенной живу.
Сейчас справа от меня сидит человек, который до этого работал в МФЦ (это где все ваши персданные, паспорта и прочие документы хранятся). Я уже даже не смеюсь, когда он рассказывает, что безопасности там нет в принципе. Все данные валяются как половые тряпки по углам. Можно просто прийти с ноутом, воткнуться в сетку и всё скопировать. Это ещё в лучшем случае. Ноль контроля, ноль ответственности, ноль желания что-то менять.
MikhailZakharov
В дополнение к выводам. В последние несколько лет чаще стали требовать от продуктов поддержки внутреннего шифрования. Если хакер получает достаточные привелегии для скачивания данных, то еще их нужно будет расшифровать.
lair
Если предполагается, что этот EC2-instance имеет доступ к этим данным для своей работы, то он будет иметь доступ и к ключу шифрования.
MikhailZakharov
Я не эксперт в AWS, могу здесь ошибиться. Когда приложение пишет данные в хранилище (неважно где оно расположено), этот поток уже может быть зашифрован. То есть получая доступ к хранилищу, сами данные нужно будет дешифровать.
lair
Вот только в описанном случае атакующая не просто "получила доступ к хранилищу", а получила доступ к инстансу, у которого была роль для доступа к хранилищу. Предположительно, если инстансу дали доступ на чтение, то он должен что-то с данными делать, а если так — то он будет их и расшифровывать, поэтому доступ к ключу у него тоже будет.
MikhailZakharov
Инстанс имеет доступ к чтению, и читает он шифрованные данные. Расшифровка идет в памяти. Аналогия. Развернута виртуальная машина, на которой ничего нет, кроме «Блокнота». Инстансу — этой виртуалке дали доступ на чтение к хранилищу. Блокнот умеет шифровать. Хакер получает доступ к инстансу и может прочитать сохраненные в хранилище данные блокнота, но там они шифрованы.
lair
В памяти того же инстанса? С помощью чего?
(Но вообще, по умолчанию, AWS S3 работает не так — вы передаете ключ в запрос к хранилищу и получаете уже расшифрованные данные)
MikhailZakharov
С помощью собственного алгоритма, или стороннего crypto service provider. Про пояснение о S3 спасибо (все хочу посмотреть детали). Такие требования появляются из-за случаев с Capital One. Тоесть получение привелегий учетной записи, под которой работает инстанс приложения, не должен давать доступ к данным. Внутреннее шифрование сужает доступ до приложения (как владельца ключа). Ключ, конечно, тоже можно стащить, но это другая история.
lair
Собственный алгоритм — зло, выкидываем. Остаются стандартные алгоритмы, ключи от которых хранятся где?
Это невыполнимое требование, потому что если инстанс имеет доступ к этим данным, то эти данные из него можно достать.
В случае стандартного развертывания на EC2 приложение — и есть инстанс, вы ничего не можете "сузить".
MikhailZakharov
Это, действительно, важный момент. В моей практике есть только ПО, которое работает на Windows Server. Там в качестве хранилища можно использовать как встроенный контейнер сертификатов, так и стороннее ПО типа Крипто API. Доступ к ключу будет иметь определенный аккаунт под которым работает ПО.
Обычно под конкретное приложение дается отдельный аккаунт. Т.е. в этом случае надо получать доступ именно к нему. То есть слабым звеном остаюся администратор, который имеет доступ к хранилищу сертификатов и учетная запись, под которой крутится сервис-приложение.
В случае с EC2 приложением, наверное да, только использование встроенных в AWS сервисов.
lair
Правильной параллелью со случившимся будет "скомпроментирован такой аккаунт". И далее становится понятно, что шифрование не поможет.
MikhailZakharov
Managed Service Accounts могут усложнить задачу. Пароль автоматически регулярно меняется без участия админа. Только атака на конкретное приложение. От инсайда, как в этом примере спасет, если только инсайдер не имеет доступ к сертификатам.
lair
Неа. Потому что "инсайд как в этом примере" — это кто-то нашел способ залогиниться на инстанс под учетной записью, которая там была установлена. Если бы для этой учетной записи соблюдали правила безопасности, это бы ничем не отличалось от вашего случая.
ilyapirogov
Если злоумышленник залогинился в инстансе под root'ом, то он сможет сделать все что угодно:
И этот список можно продолжать долго.
По этому, в конечном случае, шифрование здесь не спасет. Оно, конечно, усложнит жизнь и придется постараться чуть больше чем просто вызвать
s3cmd sync s3://..., но принципиально это не решение проблемы.