Как пустой бакет S3 может разорить Вас
Представьте, что Вы создаете пустой частный бакет AWS S3 в выбранном Вами регионе. Как думаете, каким будет Ваш счет за услуги AWS на следующее утро?
Несколько недель назад я начал работать над PoC системы индексирования документов для своего клиента. Я создал один бакет S3 в регионе eu-west-1 и загрузил туда сразу несколько файлов. Два дня спустя я проверил свою страницу AWS, прежде всего для того, чтобы убедиться в том, что то, что я делаю, укладывается в рамки free-tier. Очевидно, что это было не так. Мой счет составил более 1300 долларов, а схема биллинга показала почти 100 000 000 запросов S3 PUT, выполненных всего за один день!
Откуда поступали эти запросы?
По умолчанию AWS не ведет журнал запросов, выполняемых к бакетам S3. Однако такие журналы можно включить с помощью AWS CloudTrail или S3 Server Access Logging. Включив журнал CloudTrail, я сразу же обнаружил тысячи запросов на запись, исходящих из нескольких учетных записей, то есть не из AWS.
Но зачем каким-то третьим лицам бомбардировать мой бакет S3 несанкционированными запросами?
Была ли это какая-то DDoS-атака на мой аккаунт? Против AWS? Как выяснилось, один из самых популярных инструментов с открытым исходным кодом по умолчанию хранил свои резервные копии в S3. А в качестве имени бакета они использовали...внимание… то же самое имя, которое я использовал для своего бакета. Это означало, что каждое развертывание этого инструмента со значениями конфигурации по умолчанию пыталось хранить свои резервные копии в моем бакете S3!
Примечание: я не могу раскрыть название инструмента, о котором я говорю, так как это подвергнет пострадавшие компании риску утечки корпоративных данных.
Итак, орда неправильно настроенных систем пытается хранить свои данные в моем личном бакете S3. Но почему именно я должен платить за эту ошибку? А вот почему:
S3 взимает плату за несанкционированные входящие запросы
Это было подтверждено в ходе моего общения со службой поддержки AWS. Они написали следующее:
Да, S3 взимает плату за неавторизованные запросы (4xx)[1]. Это ожидаемо.
Итак, если я сейчас открою терминал и наберу:
aws s3 cp ./file.txt s3://your-bucket-name/random_key
Я получу ошибку AccessDenied, но платить за этот запрос будете Вы. И для этого мне даже не нужна своя учетная запись AWS.
Еще один вопрос не давал мне покоя: почему более половины моего счета приходило из региона us-east-1? Ведь там у меня не было ни одного бакета! Ответ на этот вопрос заключается в том, что запросы S3 без указанного региона по умолчанию направляются в us-east-1 и перенаправляются по мере необходимости. А за этот перенаправленный запрос платит владелец бакета…
Аспект безопасности
Теперь мы понимаем, почему мой бакет S3 был атакован миллионами запросов и почему в итоге я получил огромный счет за S3. В этот момент у меня возникла еще одна идея, которую я захотел проверить. Если все эти неправильно настроенные системы пытались создать резервные копии своих данных в моем бакете S3, то почему бы мне просто не позволить им это сделать? Я открыл свой бакет для публичной записи и собрал более 10 ГБ данных менее чем за 30 секунд. Конечно, я не могу раскрыть, чьи это были данные. Но я был поражен тем, как всего лишь одна на первый взгляд невинная оплошность в настройках может привести к утечке данных!
Какие уроки я вынес из этой ситуации?
Урок 1: Любой, кто знает имя любого из Ваших бакетов S3, может взвинтить Ваш счет за AWS по своему усмотрению.
Все, что Вы можете сделать это удалить Ваш бакет. Вы не можете защитить его с помощью таких сервисов, как CloudFront или WAF, если доступ к нему осуществляется напрямую через S3 API. Стандартные запросы S3 PUT стоят 0.005 долларов за 1 000 шт, одна машина может легко выполнять тысячи таких запросов в секунду.
Урок 2: Добавление суффикса к именам бакетов может повысить их безопасность
Такая практика снижает уязвимость системы перед неверно настроенными программами или преднамеренными атаками. Избегайте использования коротких и общих имен бакетов S3.
Урок 3: При выполнении большого количества запросов к S3 не забудьте указать регион AWS.
Так Вы сможете избежать дополнительных расходов на перенаправление S3 API.
Послесловие:
- Я сообщил о своих выводах разработчикам уязвимого open-source инструмента. Они быстро исправили конфигурацию по умолчанию.
- Я уведомил команду безопасности AWS. Я предложил им ограничить использование злополучного имени бакета S3, чтобы защитить своих клиентов от непредвиденных расходов, а пострадавшие компании - от утечки данных. Но они не захотели устранять ошибки в конфигурации сторонних продуктов.
- Я сообщил об этой проблеме двум компаниям, чьи данные я обнаружил в своем бакете. Они не ответили на мои письма, возможно, посчитав их спамом.
- AWS была достаточно любезна, чтобы аннулировать мой счет за S3. Однако они подчеркнули, что это было сделано в виде исключения.
