Коротко: огромный опенсорс-проект, который последние 3 года теряет разработчиков из-за адской бюрократии и кучи других проблем. Вот про это предыдущий пост, где я рассказывал про все прелести разработки, которые обозначает само же сообщество. Скажем так, OpenStack немного небезопасен.
Для ИБ важно, что внутри 49 независимых команд, огромный легаси-монолит с попытками вынести части нового в отдельные сервисы, практически поломанное взаимодействие между командами и продуктами, нет единого внятного трекинга багов, и очень часто проблемы решаются костылями.
Эта штука — бэк почти всех российских публичных облаков.
Самые частые проблемы — нестыковки модулей, когда один из них создаёт ресурс, второй должен его использовать, но не использует, либо нарушается связь между модулями и ресурсы остаются осиротевшими.
В этой уютной атмосфере, конечно же, ни о какой безопасной разработке речи быть в принципе не может.
Ломают ли его? Конечно. Более того, проблема, которая приводит к возможности злоумышленника получить доступ к томам переехавшей ВМ, принципиально на уровне фикса так и не решилась. И сейчас большая часть российских публичных облаков, которые не закрыли её собственными костылями, уязвимы. В смысле, да, можно пойти и взять тома тех, кто там хостится, при определённом усилии.
Пока мы ковырялись с развёртыванием собственного облака, выявили ещё некоторые нюансы ИБ.
Общая ситуация: проект монструозен
В предыдущем посте я рассказывал, на что в 2025 году похож OpenStack. Коротко:
- Легаси-архитектура — по большей части распределённый монолит, причём некоторые абстракции вроде взаимодействия с сетью или хранением занесены прямо в ядро.
- 49 команд разработки.
- 18 миллионов строк кода.
- Некоторая беда с документацией.
- Баги на стыках модулей могут не править годами либо править силами соседних команд.
- Некоторые модули перестали обновляться, но всё ещё есть в зависимостях, что рождает точки уязвимостей.
Добавьте сверху кучу недокументированного поведения компонентов.
Вообще, на тестовом стенде, когда мы только продумывали архитектуру будущего облака, мы решили, что сделаем клиентский аккаунт через сущность домена у OpenStack. Домен — это некая полностью изолированная область, поэтому в такой логике всё должно быть хорошо. По идее, ни один пользователь домена не может пойти в соседний домен.
Мы знали на тот момент, что многие облачные провайдеры полностью переписывали логику аутентификации и использовали OpenStack только как платформу для выделения ресурсов. Ну то есть всю аутентификацию клали на свою систему, изолируя полностью Openstack-слой. Это вселило в нас некоторые сомнения, но поначалу мы не понимали, с чем это связано.
Мы тоже подключили внешнюю систему для управления аккаунтами и аутентификации пользователей. А вот контролировать разделение прав планировали силами OpenStack.
Оказалось вот что: чтобы администрировать пользователя, чтобы самому добавить в домен пользователя и добавить свои ресурсы, создать сети, загрузить образы — для всего этого нужны права админа. А как только мы даём кому-то в домене права админа, он может ходить в соседний домен! Позже нашёлся и соответствующий баг. С похожими проблемами сталкивались и коллеги из Mail.ru.
При том что в документации написано обратное:
Источник
Так быть не должно, но так работает. Это абсолютно недокументированное поведение безопасности. Что ни делай с перевыпуском токенов, как это всё не пытайся заизолировать — ничего не выйдет. OpenStack просто игнорирует scope, заданный при выпуске токена. В итоге мы переписали эту часть логики и усложнили middleware, которое вызывает API OpenStack.
Проблема известная. Используя эту уязвимость с правами доступа, в принципе, можно получить ресурс других пользователей. У одного публичного провайдера из-за ошибки с очисткой томов злоумышленник получил том предыдущего арендатора с его конфиденциальными данными. Осознанно, то есть злонамеренно.
Потом мы узнали, что у ещё одного провайдера загрузили майнингом вычислительный пул после взлома. Ещё пара закрытых историй, которые не выносятся публично.
Короче, вот наш небольшой обзор того, с чем вам придётся столкнуться. Лучше прочитайте это до того, как делать что-то на OpenStack.
Дисклеймер: информация приведена в образовательных целях. Рекомендации по устранению уязвимостей или защите от них следует искать в официальной документации и сообществах безопасности.
Примеры ключевых уязвимостей
Keystone (CVE-2015-7713, CVE-2017-2673 и другие)
В Keystone — модуле аутентификации — регулярно обнаруживались проблемы с неправильной проверкой прав доступа и утечкой метаданных. Например, CVE-2015-7713 позволяла злоумышленнику определять существующие имена пользователей (user enumeration), а некоторые уязвимости в дальнейшем давали возможность провести брутфорс или повысить права в системе.
Пример: при сценарии user enumeration злоумышленник отправляет множество запросов к Keystone API, проверяя, какие логины уже существуют. В случае слабого контроля на уровне API (ограничение по числу запросов, капчи и т.п.) атакующий мог выявить валидные учётные записи. Дальше, пользуясь уязвимыми правилами аутентификации, можно было провести атаку методом подбора пароля.
В некоторых случаях публичные облачные провайдеры, построенные на OpenStack, имели не до конца корректно настроенный Keystone, и злоумышленникам удавалось автоматически перебрать пароли, получив доступ к ряду виртуальных ресурсов.
Последствия — неавторизованный доступ к ресурсам и развитие атаки на другие сервисы с помощью похищенных учётных данных.
Nova (CVE-2016-2140, CVE-2019-14433, CVE-2020-17376)
Nova, как система для управления виртуальными машинами, исторически страдала от уязвимостей, связанных с некорректной фильтрацией пользовательского ввода при работе с API, а также с ошибками конфигурации при миграции инстансов. Мэтью Бут из Red Hat сообщил об уязвимости в изменении размера/миграции экземпляра Nova. Перезаписав эфемерный или корневой диск вредоносным образом перед запросом изменения размера, аутентифицированный пользователь может прочитать произвольные файлы с вычислительного хоста.
У одного из публичных провайдеров была обнаружена конфигурационная ошибка в Nova: злоумышленник смог отправить специально сформированный запрос к API, что позволило ему получить метаданные других инстансов (такие как IP-адрес и ключи SSH). После этого, используя украденные SSH-ключи, атакующий получил удалённый доступ к виртуальной машине другого арендатора, что фактически нарушило модель многопользовательской изоляции.
Стандартные последствия — компрометация чужих инстансов, хищение данных, возможный сценарий эскалации привилегий в облачной инфраструктуре.
Neutron (CVE-2019-10876, CVE-2021-20267, CVE-2024-53916 и уязвимости сетевых плагинов)
Neutron — сетевой компонент OpenStack, часто становится целью атак из-за сложного взаимодействия сетевых плагинов (Open vSwitch, Linux Bridge, SDN-решения и т.д.). CVE-2019-10876 раскрывала проблему, при которой атакующий мог воспользоваться неправильной валидацией правил безопасности (Security Group Rules) в Neutron для обхода межсетевых фильтров.
Злоумышленник в одном публичном облаке обнаружил, что при настройке двух подсетей на пересекающиеся диапазоны группы безопасности перестают применяться к портам в этом диапазоне. В ряде случаев это позволяло обойти внутренние Access Control List и получить доступ к сервисам, считавшимся доступными только из локальной сети. Это приводило к возможности сканирования внутренних сервисов провайдера, а при наличии других уязвимостей — к дальнейшему проникновению в систему управления облаком.
Другая уязвимость открывает возможность подмены IP-адреса (IP Spoofing) и пересылку трафика в частные сети других арендаторов. Уязвимости существуют как для OVS, так и для Linux Bridge.
Последствия: выход за рамки виртуальной сети, утечки внутренних данных, возможность DDoS-атаки, сканирования или похищения чувствительной информации у соседних инстансов.
Cinder (CVE-2017-15139, CVE-2023-2088 — неправильная очистка томов)
В Cinder (сервис облачного хранилища) время от времени возникают уязвимости, связанные с неправильной очисткой или повторным использованием томов.
CVE-2017-15139 указывала, что при определённых сценариях удаления тома не все данные стирались корректно.
Злоумышленник, получивший новый блочный том (Volume) от провайдера, обнаруживает, что этот том ранее принадлежал другому клиенту. Оказалось, что данные не были очищены должным образом, и часть файлов всё ещё могла быть прочитана. Это позволяло достать конфиденциальную информацию прежнего арендатора (например, логи приложений, бэкапы баз данных).
Типичные последствия — утечка критичных данных, нарушение политики конфиденциальности и возможная финансовая/репутационная угроза для провайдера.
Хотя первые симптомы наблюдались ещё в 2015-м, наличие бага CVE-2023-2088, затрагивающего свежие версии, говорит об актуальности проблемы.
SWIFT (CVE-2022-47950 — доступ к данным чужого хранилища)
У OpenStack поддерживаются две версии API объектного хранилища: S3 и SWIFT API. Проблема касается обеих версий. Себастьен Мериот из OVH сообщил об уязвимости в XML-парсере S3 для SWIFT.
Предоставляя специально созданные XML-файлы, аутентифицированный пользователь может заставить S3 API вернуть произвольное содержимое файла с хост-сервера, что приведёт к несанкционированному доступу на чтение потенциально конфиденциальных данных. Это влияет как на развёртывания S3 API (Rocky или более поздние версии), так и на развёртывания SWIFT (Queens и более ранние версии, которые больше не разрабатываются). Это влияет только на развёртывания с включённой совместимостью с S3. Но ведь все стремятся предоставить клиентам такой функционал!
Уязвимость имела место даже в относительно свежем релизе Anthelope, который до сих пор активно применяется в продакшне.
Топ-5 инцидентов
Взлом инфраструктуры европейских HPC-центров (2020 г.)
В ряде публикаций указывалось, что часть узлов в инфраструктуре была развёрнута на базе OpenStack (хотя HPC-решения — это не всегда «чистый» OpenStack, но интегрированы с ним). Злоумышленники использовали уязвимости и неправильно настроенные конфигурации для установки майнеров криптовалют.
Начали с фишинговых писем, дальше двигались внутри кластера. Результат — остановка ряда HPC-кластеров, утечка внутренней документации, потери времени и ресурсов на восстановление. Описание инцидента: HPCwire: Hacking Streak Forces European Supercomputers Offline in Midst of COVID-19 Research Effort (18 мая 2020) и BBC: Europe's supercomputers hijacked by attackers for crypto mining (май 2020).
Атака на публичные сервисы OVH (2013 г., продолжение уязвимостей в последующие годы)
OVH — крупный европейский хостинг-провайдер, использующий OpenStack для OVH Public Cloud, а также крупнейший контрибьютор OpenStack. В 2013 году сообщалось о крупной серии атак методом брутфорса и угона учётных записей. Хотя точный масштаб и детали не всегда раскрывались, часть утечек связана с неправильной настройкой облачных сервисов OVH на базе OpenStack.
Началось в июне 2013 года, позднее — отдельные инциденты в 2015–2016-м. Суть атаки: массовый перебор логинов и паролей с использованием взломанных баз данных (credential stuffing). Последствия: компрометация виртуальных машин клиентов, финансовые и репутационные потери, необходимость срочных мер по усилению аутентификации (2FA). Детали — YCombinator News: OVH has been compromised.
Компрометация тестовой OpenStack-песочницы TryStack (2012–2014 гг.)
TryStack — это (или была) открытая публичная «песочница» для демонстрации возможностей
OpenStack, поддерживаемая рядом участников сообщества, включая Rackspace. Периодически становилась мишенью взломов, поскольку любые желающие могли зарегистрироваться и разворачивать виртуальные машины. В 2013–2014 годах в блогах и на форумах OpenStack часто упоминали про «захват» ресурсов TryStack злоумышленниками для майнинга криптовалют и спама.
Массовые случаи зафиксированы в 2013–2014 годах. Суть атаки: регистрация фейковых аккаунтов и использование уязвимостей в конфигурации Nova/Neutron для скрытного развёртывания ботов. Последствия: повышенная нагрузка на ресурсы TryStack, блокировка части подсистем, необходимость жёстких лимитов и усиленной модерации аккаунтов.
Утечка данных у одного из азиатских OpenStack-провайдеров (2017 г.)
Название провайдера публично не афишировалось (инцидент рассматривался в виде кейса на одной из закрытых сессий безопасности OpenStack Summit). Утверждалось, что причиной стала неправильно настроенная часть API (Nova или Glance), в результате чего злоумышленник получил метаданные образов нескольких клиентов, включая SSH-ключи и конфигурацию VM. Вероятно, атака была в начале 2017 года. Суть атаки: использование неаутентифицированного вызова к сервисам OpenStack; плохой контроль доступа к API. Последствия: компрометация нескольких десятков виртуальных машин, утечка ключей и образов, временная приостановка сервиса для ряда клиентов. Упоминания на закрытых секциях OpenStack Summit (2017 г.). В открытом доступе конкретный провайдер не назван, но рассуждения о проблеме: YouTube-канал OpenInfra Foundation (сессии о безопасности), отдельные обсуждения в OpenStack Discuss (поиск: metadata leak 2017).
«Наследованный» баг Cinder и последующая компрометация данных (2020 г.)
В одном из публичных облаков (упоминалось на форумах, что провайдер базируется в Северной Америке) обнаружился классический сценарий, связанный с неправильной очисткой томов (Cinder). Злоумышленник, получив «освобождённый» том, восстановил оттуда фрагменты данных предыдущего арендатора и нашёл конфиденциальную информацию. После этого инцидента провайдер провёл срочное обновление и внедрил политику гарантированной очистки (secure wipe) дисков. Дату атаки определить затруднительно, но раскрытие данных произошло летом 2020. Суть атаки: эксплуатировали баг (аналогичный CVE-2017-15139) и низкий уровень безопасности при повторном выделении томов. Последствия: украденные базы данных одного из арендаторов, репутационный удар для провайдера, потенциальные судебные иски. Источники Launchpad (Cinder bugs) — упоминание похожих случаев, общие обсуждения проблемы в OpenStack Security Advisory (OSSA) и на профильных конференциях (OpenInfra Summit 2021).
Ещё десятки случаев не стали публичными
Многие серьёзные взломы или утечки в OpenStack-провайдерах замалчиваются из-за репутационных и юридических рисков. Поэтому конкретных «громких историй» на уровне, скажем, взломов AWS или Azure, в открытых источниках значительно меньше.
Как видите, ЭТО ПОЛНОСТЬЮ БЕЗОПАСНО
Посмотрите багтрекеры компонентов, CVE Details (сайт для поиска уязвимостей по проекту), OpenStack Security Advisory (OSSA), архив рассылки Security, OpenStack Discuss (Security) — там классно искать по ключевым словам security issue, vulnerability и т.д., и ещё есть доклады на OpenInfra Summit — там видеозаписи и сессии, в которых рассматриваются реальные кейсы взломов и выявления уязвимостей.
Что с этим всем делать? Во-первых, регулярно обновляться. Но обновление тут — это особый вид садизма, про это было в прошлом посте. Во-вторых, писать свои костыли там, где не справляется эталонный проект (так и делает часть коммерческих реализаций). В-третьих, возможно, демонтировать совсем глючные модули и писать свои. Важно постоянно мониторить логи и активность, проводить аудит конфигурации сервисов (особенно хранилищ и сетей) — то есть помимо стандартных мониторингов, вам понадобится обвешать всё кастомными, причём с упором на ИБ тоже.
Никогда не разворачивайте OpenStack «из коробки» в чистом виде в публичной среде! Есть проверенные best practices (например, из OpenStack Security Guide).
Даже полная изоляция API OpenStack от конечного пользователя за слоем middleware с проверкой логики (как делают все, у кого OpenStack выглядит не как OpenStack) при кажущейся надёжности, не спасает от проблем.
Что мы со всем этим делали? Ну, замещали компонент за компонентом, а потом поняли, что лучше вложиться в разработку своей платформы. Успешно прошли стадию Proof-of-Concept и усердно пилим MVP. Скоро покажем.