Сервисы аналитики редко становятся объектом атак до момента, когда они открывают доступ к конфиденциальной корпоративной информации. Компания Metabase опубликовала тревожное сообщение о том, что её облачную платформу успешно атаковали, используя ранее неизвестную уязвимость, затронувшую версии 1.58 и более новые. После инцидента компания блокировала каналы атаки, выпустила исправление и обновила все облачные инстансы своих клиентов.
Для самостоятельно развёрнутых экземпляров Metabase риск остаётся актуальным вплоть до применения патча. Злоумышленник, получивший доступ к системе, мог выполнять произвольные SQL-команды, обращаясь к внутренней базе данных приложения, и впоследствии получить права суперпользователя. Это давало возможность переконфигурировать параметры Metabase и получить доступ к учётным данным для подключения к другим системам.
Административные привилегии открывали доступ к логинам и паролям подключённых хранилищ информации, данным, доступным через эти соединения, и функциям выгрузки информации. Однако Metabase не подтверждает, что нарушители совершили все возможные действия в процессе реальной атаки. Компания описывает только потенциальные риски, которые создаёт успешная эксплуатация этого дефекта безопасности после первичного взлома.
Признаками компрометации в логах являются специфические паттерны активности. Обычно сначала записывается запрос POST на адрес /api/session/reset_password с кодом ошибки 400, после чего следует запрос GET к /api/user/current с успешным кодом 200. Компания предупреждает, что обнаружение такой последовательности событий в журналах приложения или сетевом трафике сервера с большой вероятностью свидетельствует о взломе инстанса.
Для веток версий с 58 по 63 Metabase выпустила безопасные обновления: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 и 0.63.5. Более ранние версии этих веток остаются под угрозой и должны быть обновлены в срочном порядке. Инсталляции более ранних версий (до 58) защищены от этой конкретной уязвимости. Администраторам локальных установок необходимо обновить свои системы до защищённой версии.
После установки обновления рекомендуется завершить все текущие пользовательские сессии, провести аудит API-ключей и административных профилей, обновить пароли для подключённых хранилищ и проанализировать журналы баз данных, историю выполненных запросов и лог активности самого приложения. Если срочное обновление невозможно, следует временно ограничить доступ к эндпоинту /api/session/reset_password на уровне файрвола или обратного прокси-сервера.
