Захват контейнеров между учетными записями: все об этой малоизвестной облачной угрозе

В начале сентября Microsoft подтвердила, что была проинформирована о первом в истории крайне опасном нарушении кибербезопасности. Клиенты, которые использовали предложение Azure «контейнер как услуга» (CaaS) под названием Azure Container Instances (ACI), были уведомлены о том, что подразделение 42 в Palo Alto Networks обнаружило эксплойт, позволяющий злоумышленникам проникать из своих контейнеров в других пользователей. контейнеры. Воспользовавшись уязвимостью двухлетней давности, злоумышленники могли запустить код в контейнерах других пользователей, украсть секреты и изображения и даже запустить операции криптомайнинга. Уязвимость, получившая прозвище «Azurescape», была описана исследователем Unit 42 Ювалем Авраами как «первый захват контейнеров с несколькими учетными записями в общедоступном облаке». Хотя нет никаких доказательств использования этой уязвимости, клиентов по-прежнему просят отслеживать свои контейнеры на предмет несанкционированного использования и отзывать все привилегированные учетные данные, развернутые в ACI до 31 августа 2021 года.

Как произошло это поглощение контейнера между учетными записями?

Инфраструктура ACI

Чтобы понять, что такое поглощение нескольких аккаунтов, во-первых, нужно понять, чем занимается ACI. ACI — это служба, предоставляемая корпорацией Майкрософт, которая позволяет клиентам развертывать контейнеры в Azure без необходимости управлять базовой инфраструктурой. Разработчики могут сосредоточиться на создании и проектировании своих приложений, в то время как ACI занимается масштабированием, маршрутизацией запросов и планированием. Группы контейнеров работают изолированно без общего ядра, что гарантирует их защиту от других групп контейнеров, работающих параллельно в общедоступном облаке.

Инфраструктура ACI включает многопользовательские кластеры Kubernetes (и кластеры сервисной фабрики, которые здесь не рассматриваются), в которых размещаются контейнеры клиентов. Хотя эти кластеры являются мультитенантными, отдельные контейнеры работают в собственном модуле Kubernetes на узле с одним арендатором. Этот подход «узел на арендатора» — это то, как ACI обеспечивает строгие границы между арендаторами. Если злонамеренный пользователь, работающий в кластере, выйдет из своего контейнера, он окажется в изолированном узле и не сможет взаимодействовать с другими контейнерами в кластере, что предотвратит захват нескольких учетных записей. Или, по крайней мере, так должно было быть.

Вырваться из контейнера

Во-первых, Unit 42 запустила WhoC, образ контейнера, который они создали для чтения исполняющей среды контейнера. Они обнаружили, что Microsoft использует устаревшую версию runC (runC v1.0.0-rc2), несмотря на то, что с тех пор было выпущено несколько выпусков, включая стабильный выпуск 1.0 от июня 2021 года. Устаревшей версии runC было почти ПЯТЬ лет, и в ней было два известных CVE для взлома контейнеров. Естественно, команда Unit 42 воспользовалась одной из этих уязвимостей, CVE-2019-5736, чтобы выйти из контейнера и проникнуть в узел Kubernetes. Однако они все еще находились в пределах границ арендатора.

Сканирование среды показало, что кластеры работают под управлением Kubernetes v1.8.4, v1.9.10 или v1.10.9. Все это были старые версии Kubernetes, выпущенные в период с ноября 2017 года по октябрь 2018 года, с несколькими известными уязвимостями. Unit 42 попытался использовать CVE-2018-1002102 для распространения вредоносных Kubelets по кластеру, но потерпел неудачу, когда обнаружил, что Microsoft уже исправила эту уязвимость, вместо этого перенаправляя все запросы exec с api-сервера на пользовательский модуль моста.

Однако это было еще не все. Во время этой попытки Unit 42 обнаружил заголовок авторизации, содержащий токен сервисной учетной записи Kubernetes, который по сути представляет собой незашифрованный веб-токен JSON (JWT), который можно легко расшифровать. Они обнаружили, что этот токен можно использовать для получения доступа к учетной записи службы моста, что позволяет им выполнять команды на любом модуле в кластере, даже на модуле API-сервера. По сути, это сделало их администраторами кластера с контролем над всеми клиентскими контейнерами в многопользовательском кластере.

Вторая уязвимость?

Хотите верьте, хотите нет, но токен служебной учетной записи был лишь первой из двух уязвимостей, обнаруженных командой Unit 42. Они могут получить полный административный контроль над многопользовательским кластером, используя уязвимость подделки запросов на стороне сервера (SSRF) в модуле моста. Они обнаружили, что API-сервер на самом деле не проверял, является ли значение status.hostIP действительным IP-адресом. Кроме того, API-сервер принимал любые строки, даже компоненты URL. Они ввели значение hostIP, которое заставило модуль моста выполнить команду в контейнере API-сервера вместо своего собственного контейнера, что снова дало им статус администратора в многопользовательском кластере.

Что исправить?

Плохая новость заключается в том, что Microsoft запускала ACI на устаревшем программном обеспечении с известными уязвимостями. Хорошей новостью является то, что они исправили его, как только Unit 42 сообщил им об эксплойте и уведомил клиентов в зоне атаки, чтобы они отозвали все учетные данные, развернутые до 31 августа 2021 года. Модули моста больше не отправляют токены учетной записи службы узлам при выдаче exec. запросы, и они проверяют правильность поля status.hostIP перед отправкой запросов exec. Однако эта атака служит мрачным напоминанием об уязвимостях, которые можно использовать изнутри, даже при соблюдении адекватных мер безопасности.

В дополнение к регулярному отзыву развернутых учетных данных Microsoft рекомендовала следовать своим рекомендациям по безопасности ACI и лучшим практикам (ссылки здесь и здесь). Они также рекомендовали более глубокий мониторинг безопасности и настройку предупреждений для уведомления клиентов о любом подозрительном поведении.

Подразделение 42, обнаружившее эксплойт, рекомендовало предприятиям применять подход глубокоэшелонированной защиты (DiD) к кибербезопасности. DiD включает в себя многоуровневые механизмы безопасности по всей сети, чтобы покрыть ряд потенциальных нарушений. Хотя это может не изолировать компанию от всех возможных атак, оно увеличивает избыточность, так что в случае отказа одной защиты может сработать другая мера безопасности для защиты ваших данных. DiD эффективно уменьшает поверхность вашей атаки.

Защитите себя от захвата контейнеров между учетными записями

Во-первых, не думайте, что ваш поставщик облачных услуг применяет передовые методы обеспечения безопасности и использует последние версии программного обеспечения. Если вы хотите, чтобы ваши контейнеры работали в безопасной среде, вам нужно знать, на что вы подписываетесь. Проведите аудит защиты и инфраструктуры ваших провайдеров, прежде чем доверить им свои данные. Спросите их об их механизмах обнаружения атак нулевого дня.

Во-вторых, используйте подход глубокоэшелонированной защиты. Усиление защиты и увеличение избыточности безопасности увеличивает сложность атаки. Это повышает вероятность того, что вредоносная активность будет обнаружена и устранена до того, как будет нанесен реальный ущерб. Вот некоторые принципы DiD:

• Наименьшие привилегии: Центральным принципом подхода глубокоэшелонированной защиты является принцип минимального доступа: доступ к системам и ресурсам предоставляется только основным пользователям, и этот доступ регулярно аннулируется.
• Обнаружение и предотвращение. Для глубокой обороны также требуются системы углубленного мониторинга, которые предупреждают вас о подозрительном поведении и внедряют автоматические протоколы безопасности в ответ на потенциальные нарушения и атаки нулевого дня.
• Брандмауэры: Брандмауэры служат воротами безопасности для ваших приложений и сетей, и они могут обнаруживать и блокировать доступ к злоумышленникам или подозрительным точкам доступа.
• Сегментация сети: разделение вашей сети на сегменты для каждого раздела вашего бизнеса может гарантировать, что брешь в одном отделе не поставит под угрозу непрерывность всего вашего бизнеса.
• Пароли. Еще одним требованием являются надежные, сложные пароли, в идеале с многофакторной аутентификацией.

Сегодня недостаточно слепо доверять поставщику облачных услуг. Хотя новые виды атак, такие как захват нескольких учетных записей, усложняют безопасность, вы можете защитить свою организацию от них, приняв необходимые меры предосторожности.