Перевод: Jessica Haworth — Denial-of-Wallet attacks: How to protect against costly exploits targeting serverless setups
В последние годы популярность бессерверных (serverless) вычислений резко возросла, поскольку организации продолжают осознавать преимущества этой легко масштабируемой облачной модели инфраструктуры.
Фактически, по оценкам одного исследования, к 2021 году количество бессерверных клиентов превысит семь миллиардов.
Однако с этой тенденцией связан дополнительный риск кибератак, направленных на облачную инфраструктуру.
Среди растущего списка эксплойтов значится атака Denial-of-Wallet — менее известная, но простая в исполнении методика, которая может нанести жертвам серьезный финансовый ущерб.
Эксплойты типа «Denial-of-Wallet» (DoW) похожи на традиционные атаки типа «отказ в обслуживании» (denial-of-service — DoS) в том смысле, что и те, и другие осуществляются с намерением вызвать нарушение работы.
Однако, в то время как атаки DoS направлены на то, чтобы вывести целевой сервис из строя, DoW стремится причинить жертве финансовые потери.
Кроме того, в то время как традиционные сетевые распределенные атаки типа «отказ в обслуживании» (DDoS) наводняют сервер бесполезным трафиком до тех пор, пока он не выйдет из строя, DoW-атаки специально нацелены на бессерверных пользователей.
Вопреки его названию «бессерверный» не означает, что пользователь не подключен к серверу, а скорее, что он платит за доступ к серверу, обслуживаемый третьей стороной.
Атаки типа «Denial-of-Wallet» используют тот факт, что бессерверные поставщики взимают с пользователей плату в соответствии с объемом ресурсов, потребляемых приложением, а это означает, что если злоумышленник затопляет веб-сайт трафиком, владелец сайта может получить огромный счет.
Злоумышленник лично не получает выгоду от атак DoW так, как он может получить от других эксплойтов — за исключением, конечно, причинения своей жертве финансовые потери.
«Когда у вас есть серверы в центре обработки данных, и злоумышленник просто хочет причинить вам вред, он может сделать DDoS-атаки, и ваш сайт выйдет из строя», — объясняет Скотт Пайпер, консультант по безопасности AWS в Summit Route.
«Когда вы работаете в облаке, злоумышленник может сделать так, чтобы ваш сайт работал, но вы обанкротились».
Бессерверные вычисления — это когда серверные службы предоставляются по принципу «используется». Компания платит бессерверному поставщику за инфраструктуру и обслуживание сервера.
Популярные бессерверные бренды включают Amazon Web Services (AWS), Microsoft Azure и Google Cloud Platform (GCP), которые вместе насчитывают многие миллионы пользователей.
У использования бессерверного режима есть очевидные преимущества, один из которых заключается в том, что он позволяет небольшим организациям запускать свои услуги без необходимости инвестировать в оборудование.
Еще одним положительным моментом является то, что, поскольку услуга предоставляется на основе оплаты по факту использования, с пользователя не взимается плата за пропускную способность или ресурсы, которые он не использует.
«Бессерверные вычисления — это архитектура без сохранения состояния для приложений», — сказала The Daily Swig Эрика Виндиш, основатель бессерверного поставщика IOpipe. «Я думаю, что у такой архитектуры есть преимущества с точки зрения безопасности, поскольку она обеспечивает неизменность».
Поскольку бессерверные среды постоянно обновляются, это мешает вредоносным приложениям слишком долго бездействовать в инфраструктуре.
Однако использование бессерверных вычислений сопряжено с определенными рисками. Например, отмечает Виндиш, иногда это может препятствовать возможности выполнить глубокий анализ инфраструктуры.
«Бессерверный режим также создает некоторые проблемы в отношении наблюдения за безопасностью, например, если скомпрометированный контейнер уничтожается каждые пять минут, то как проводить анализ? Нет инструментов, чтобы заморозить или сохранить эти среды для анализа », — сказала она.
Бессерверная модель также заставляет пользователя полагаться на методы обеспечения безопасности поставщика. Если сервер небезопасен, Denial of Wallet — не единственная кибератака, о которой администраторы должны беспокоиться.
Жертва, вероятно, может быстро заметить, что что-то не так, когда их счет окажется выше ожидаемого. Однако есть способы остановить атаку типа «Denial-of-Wallet», прежде чем она станет слишком дорогостоящей.
В первую очередь Piper of Summit Route предлагает настроить оповещение о выставлении счетов. Это уведомит пользователя, если он превысит заранее установленный лимит расходов.
Пользователи также должны использовать ограничения для смягчения любого неконтролируемого кода, особенно строк, которые могут запускать сценарий бесконечного цикла.
«Многие люди рассказывают истории о бесконечных циклах, происходящих в AWS, которые заставляли ресурсы создаваться снова и снова, или о срабатывании Lambda, которое заставляло себя запускать снова», — сказала Пайпер.
«Это достаточно распространенная проблема, и в документации правила событий Cloudwatch даже есть предупреждение».
Он добавил: «Без этих ограничений злоумышленник может попытаться запустить миллион EC2, но из-за подобных ограничений злоумышленник может запустить только несколько десятков EC2».
Происхождение атаки DoW можно проследить до 2008 года, сказала Пайпер The Daily Swig, когда она была названа «Economic Denial of Sustainability» в блоге Rational Security.
Пайпер предполагает, что термин «Denial of Wallet» впервые был использован в 2013 году, указывая на пользователя Twitter по имени @gepeto42.
Не существует реальной пуленепробиваемой защиты от атак типа «Denial-of-Wallet». Вместо этого бессерверным пользователям следует установить указанные выше ограничения для запуска предупреждений, если они станут целью.
В документе OWASP Top 10 Serverless Threats описывается риск DoW:
Чтобы «защитить» от таких атак, AWS позволяет настраивать ограничения для вызовов или бюджета. Однако, если злоумышленник может достичь этого предела, он может вызвать DoS для выбранной учетной записи, что бы помешать войти в личный кабинет.
Нет никакой реальной защиты, которая могла бы остановить бы DoS атаки. В традиционной архитектуре атака не так проста, как в бессерверной. Следовательно, при использование бессерверной архитектуры риск может быть высоким.
Также необходимо принять меры для защиты административных учетных записей, связанных с бессерверной установкой.
Пайпер заявил, что если злоумышленник сможет совершать вызовы API к учетной записи AWS жертвы, «он, вероятно, также сможет удалить все ваши файлы в S3, завершить все ваши экземпляры и вызвать любой хаос, который может привести к еще худшим влияние на бизнес ».
Он предложил смягчить этот сценарий, внедрив службы с минимальными привилегиями, принудительно применяя многофакторную аутентификацию для всех пользователей и внедрив политики управления службами.
Краткий перевод: https://vuejs.org/guide/components/v-model.html Основное использование v-model используется для реализации двусторонней привязки в компоненте. Начиная с Vue…
Сегодня мы рады объявить о выпуске Vue 3.4 «🏀 Slam Dunk»! Этот выпуск включает в…
Vue.js — это универсальный и адаптируемый фреймворк. Благодаря своей отличительной архитектуре и системе реактивности Vue…
Недавно, у меня истек сертификат и пришлось заказывать новый и затем устанавливать на хостинг с…
Каким бы ни было ваше мнение о JavaScript, но всем известно, что работа с датами…
Все, кто следит за последними событиями в мире адаптивного дизайна, согласятся, что введение контейнерных запросов…