Metabase - открытая платформа для бизнес-аналитики, которую используют для построения отчётов и визуализации данных. Разработчики раскрыли сведения об уязвимости нулевого дня в этом продукте, которую злоумышленники уже эксплуатируют в реальных атаках. Проблема затрагивает самостоятельно развёрнутые установки Metabase версии 0.58 и новее. С её помощью атакующий может внедрять произвольные SQL-запросы в базу данных приложения, получить права администратора и добраться до информации в подключённых базах. Разработчики выпустили исправления для всех поддерживаемых веток.
Детали уязвимости
Первой целью атаки стала облачная версия платформы - Metabase Cloud. Компания заблокировала уязвимые сетевые адреса и подготовила патч. Защищённые версии уже работают во всех облачных экземплярах. Подписчикам облачного сервиса дополнительные действия не требуются. Организации, которые запускают платформу на собственных серверах, остаются под угрозой до установки обновления.
Уязвимость кроется в эндпоинте сброса пароля - сетевом адресе, через который пользователи восстанавливают доступ к учётной записи. Отправляя специально сформированный запрос на этот адрес, злоумышленник может внедрить собственный код на языке SQL в базу данных самого приложения Metabase. SQL - это язык запросов к базам данных, а внедрение SQL-кода позволяет выполнять команды, которые штатные функции не должны допускать. В базе приложения Metabase хранятся учётные записи, настройки и другие внутренние данные платформы. Успешная эксплуатация даёт атакующему права администратора. Это позволяет менять конфигурацию, похищать сохранённые учётные данные для подключённых баз, читать информацию из этих источников и экспортировать её.
Особенно высок риск для компаний, использующих Metabase как центральную аналитическую площадку. Платформа обычно связана с производственными базами данных, облачными хранилищами и другими критическими источниками информации. Такие системы часто имеют доступ к большим объёмам чувствительных данных. Компрометация открывает злоумышленнику не только контроль над самой платформой, но и потенциальный доступ к этим данным. При этом сама система может не содержать критических сведений, но открывать доступ к хранилищам, где они находятся. Для организаций это оборачивается риском утечки коммерческой информации, персональных данных клиентов и других охраняемых сведений.
Компания также описала в бюллетене характерную последовательность запросов, которая может указывать на попытку атаки или успешную эксплуатацию. Сначала идёт обращение к эндпоинту сброса пароля (/api/session/reset_password), завершающееся ответом с кодом 400. Затем следует запрос к эндпоинту получения данных текущего пользователя (/api/user/current) с ответом 200. Обнаружив такую цепочку в журналах приложения, на обратном прокси или во входящих записях, администраторам следует считать экземпляр скомпрометированным и приступить к процедурам реагирования. Промедление в такой ситуации даёт злоумышленнику дополнительное время для закрепления в системе и расширения доступа. Особое внимание стоит уделить журналам за период до установки патча. Следы атаки могут появиться за несколько дней или недель до официального раскрытия.
Проблема не затрагивает версии ниже 0.58. Компания определила минимальные безопасные версии для всех остальных веток. Для ветки 0.63 это версия 0.63.5, для 0.62 - 0.62.9, для 0.61 - 0.61.11, для 0.60 - 0.60.17, для 0.59 - 0.59.21, для 0.58 - 0.58.24. К примеру, экземпляр с версией 0.58.6 следует обновить до 0.58.24 или более поздней версии. Выбор конкретной версии зависит от используемой ветки: обновляться нужно в пределах своей линейки релизов. Узнать текущую версию можно в интерфейсе Metabase: нужно открыть меню в правом верхнем углу и выбрать пункт "О Metabase".
Пользователям Docker необходимо загрузить обновлённый образ metabase/metabase соответствующей версии и перезапустить контейнеры. Тем, кто разворачивает платформу из JAR-архива, нужно заменить текущий пакет приложения на исправленный. Если обновление невозможно выполнить немедленно, в качестве временной меры рекомендуется закрыть доступ к эндпоинту сброса пароля. Такая блокировка снижает вероятность эксплуатации, но не устраняет угрозу полностью. Поэтому после неё всё равно потребуется установить патч.
После установки исправления администраторам, у которых эндпоинт сброса пароля был доступен из интернета, следует отозвать все активные пользовательские сессии. Для этого нужно удалить данные о сессиях из базы данных приложения. Также необходимо пересмотреть API-ключи (программные ключи доступа) и удалить незнакомые, проверить учётные записи администраторов на предмет несанкционированных изменений и ротировать учётные данные для всех подключённых баз. Дополнительно стоит изучить журналы хранилища данных, историю активности Metabase и историю запросов. Подозрительный доступ, неожиданные выгрузки или необычная SQL-активность могут свидетельствовать о следах злоумышленника. Злоумышленник мог добавить нового администратора или изменить параметры существующих учётных записей, поэтому проверка списка администраторов обязательна. Если есть сомнения в целостности конфигурации, проще восстановить экземпляр из резервной копии, созданной до предполагаемой даты атаки.
Разработчики оперативно закрыли проблему во всех поддерживаемых ветках. Основная рекомендация для самостоятельно развёрнутых установок - перейти на исправленную версию в кратчайшие сроки. Атаку на облачный сервис обнаружили до выпуска патча, что указывает на растущий интерес злоумышленников к аналитическим инструментам, подключённым к конфиденциальным данным. Промедление с обновлением в таких условиях напрямую увеличивает вероятность компрометации. Своевременное обновление и контроль доступа к эндпоинтам восстановления пароля остаются ключевыми мерами защиты для подобных платформ.
Ссылки
