Dell исправила серию уязвимостей в Container Storage Modules (CSM), наборе компонентов, которые связывают системы хранения Dell с контейнерными платформами Kubernetes и OpenShift. Часть проблем позволяет обойти проверку подлинности и получить административный доступ к хранилищам и узлам кластера. Исправления вошли в версию 1.18.0, уязвимыми остаются более ранние выпуски, включая все сборки до 1.17.0.
Детали уязвимостей
Первая группа затрагивает модуль авторизации CSM версии 2.4.0. Служба, которая отвечает за обмен данными с массивами хранения по протоколу gRPC (бинарный протокол удалённых вызовов), не проверяет подлинность того, кто к ней обращается. Удалённый атакующий без учётной записи получает учётные данные администратора хранилища сразу для всех зарегистрированных массивов. Оценка по шкале CVSS (общая система оценки уязвимостей) - 10,0 из 10. Столько же получила проблема в прокси и службе арендаторов: обход аутентификации открывает путь к административным правам в службе авторизации и к управлению ресурсами всех арендаторов.
Оператору CSM версии 1.12.0 досталась уязвимость управления правами в обработчике пользовательских ресурсов. Пользователь с низкими правами может отправить специально составленный ресурс и получить доступ уровня root на узлах кластера, оценка - 9,9. Одного такого запроса достаточно, чтобы скомпрометировать все узлы. Здесь срабатывает неприятная особенность контейнерных платформ: объекты, которыми управляет оператор, часто создаются от имени сервисных учётных записей с широкими полномочиями.
В модуле авторизации обнаружились жёстко зашитые учётные данные и криптографический ключ. Знание секрета подписи позволяет подделать административный токен JWT (JSON Web Token, формат токена с электронной подписью) и обойти проверку подлинности. Оценка - 9,8. Dell отдельно просит сменить секреты подписи сразу после обновления, потому что подделанные ранее токены остаются действительными.
Отдельный эпизод связан с компонентом karavi-authorization, который больше не поддерживается. В официальном руководстве по настройке прокси в качестве секрета подписи фигурировала строка-пример, причём на той же странице показывали настоящие токены. Позже страницу удалили без предупреждения о проблеме безопасности. Компании, развернувшие систему по этому руководству и не сменившие секрет, остаются уязвимы: злоумышленнику достаточно знать опубликованное значение. Оценка - 9,8. По сути это атака на цепочку поставок, только источником проблемы стала не библиотека, а документация поставщика.
Через механизм шаблонов в CSM можно внедрить собственные элементы и получить доступ к секретам Kubernetes (объектам, в которых хранят пароли, ключи и сертификаты) и к настройкам ролевого доступа RBAC (управление правами на основе ролей). Оценка - 9,6. Дальше идут проблемы с меньшим рейтингом, но с теми же последствиями. Неверная проверка сертификата в прокси, оценка 8,2, раскрывает учётные данные администратора хранилища атакующему из смежного сегмента сети. Недостаточно случайные значения, 7,7, позволяют незаметно исказить данные. Запись конфиденциальных сведений в журналы, 7,7 и 6,5, отдаёт информацию пользователю с минимальными правами. В драйвере CSI (интерфейс подключения хранилищ к контейнерам) для PowerMax не хватает проверки полномочий в компоненте обратного прокси, оценка 6,1. Драйверы для PowerMax, PowerFlex и PowerStore не проверяют подлинность в одном из сценариев, оценка 5,4.
Помимо собственного кода, обновление закрывает уязвимости в сторонних библиотеках на языке Go: криптографической, сетевой и библиотеке для работы с токенами. Третьи стороны дают заметную долю проблем в контейнерной инфраструктуре, и здесь счёт идёт на десятки идентификаторов.
Затронуты организации, которые работают с массивами Dell из Kubernetes и OpenShift. Это банки, промышленные компании, операторы связи, государственные заказчики. Службы CSM обычно доступны внутри кластера и в смежных сегментах сети, поэтому для части атак достаточно сетевой достижимости сервиса. Уязвимости с максимальной оценкой не требуют учётной записи и участия пользователя, а для эксплуатации проблемы в операторе хватает прав обычного разработчика, у которого есть доступ к пространству имён. Компрометация модуля авторизации ведёт к полному контролю над связанной инфраструктурой хранения сразу по нескольким продуктовым линейкам. Сведений о применении этих уязвимостей в реальных атаках Dell не приводит, но несколько проблем выглядят простыми для эксплуатации, поэтому промедление с обновлением повышает риск.
Обновляться нужно до версии 1.18.0 или более новой. Одного обновления мало: Dell просит сменить секреты подписи токенов, иначе старые значения остаются рабочими. Стоит проверить настройки RBAC на предмет появления незнакомых ролей и привязок, просмотреть журналы на подозрительные обращения к службам авторизации, а при малейших сомнениях отозвать учётные данные администратора хранилища и перевыпустить их. Компонент karavi-authorization не поддерживается, поэтому его нужно заменить поддерживаемым модулем авторизации, а не просто залатать. Обходных способов защиты Dell не предлагает, поэтому единственный рабочий вариант - установить исправленную версию и провести ротацию секретов.
История с жёстко зашитым секретом в документации показывает, где теперь чаще всего рвётся защита. Устаревшие компоненты, примеры конфигураций из руководств и сторонние зависимости становятся точками входа не хуже, чем ошибки в коде самого вендора. Для администраторов кластеров это означает, что проверять нужно не только версию продукта, но и состояние секретов, прав и журналов вокруг него.
Ссылки
