Один из клиентов Metabase заметил странные запросы в журналах: сначала шёл сбой на сбросе пароля, потом — успешный запрос к профилю пользователя. После этого стало ясно, что атакующий уже успел попасть внутрь и получить права администратора.

Для компаний, которые хранят отчёты и подключают к Metabase рабочие базы, такой сценарий — не просто сбой в панели. Это риск утечки учётных данных, выгрузки внутренней информации и подмены настроек доступа.

Что случилось в Metabase

Metabase — это платформа для бизнес-аналитики и визуализации данных. В ней команды строят отчёты, подключают базы, смотрят продажи, финансы, клиентские записи и другие чувствительные массивы.

Исследователи сообщили о критической уязвимости без CVE-идентификатора с оценкой CVSS 10.0. По данным разработчика, её уже использовали в реальных атаках как zero-day — то есть до выхода исправления.

Как работала атака

Суть проблемы — в SQL-инъекции. Атакующий без входа в систему мог отправить в приложение вредоносный SQL-запрос и вмешаться в базу самого Metabase.

После этого он получал админские права в инстансе. Дальше открывались почти все двери: можно менять конфигурацию, читать сохранённые учётные данные подключённых баз, смотреть доступные через них данные и выгружать информацию.

Похожая логика уже встречалась в других инцидентах, где одна ошибка в доверии к запросу ломала весь периметр доступа — об этом мы подробно писали в разборе RCE в ИИ-редакторах кода: как одна ошибка задела миллионы.

Почему это опасно

Опасность здесь не только в самой панели Metabase. Если сервис подключён к рабочим базам, злоумышленник может дотянуться до исходных данных через уже сохранённые соединения.

Это особенно больно для компаний, которые используют SQL-запросы для отчётов, выгрузок и внутренней аналитики. В одном месте лежат ключи доступа, в другом — готовые дашборды, а в третьем — следы активности пользователей. Если атакующий захватил админку, он может быстро собрать всё это в один пакет.

Как понять, что вас это касается

Под угрозой все self-hosted-установки Metabase, если они работают на уязвимых версиях. Разработчик отдельно указал линейки, где проблема затрагивала версии x.58.0 — x.58.23, x.59.0 — x.59.20, x.60.0 — x.60.16, x.61.0 — x.61.10, x.62.0 — x.62.8 и x.63.0 — x.63.3.

Есть и косвенный признак компрометации: сначала запрос POST /api/session/reset_password с кодом 400, затем GET /api/user/current с кодом 200. Если такой паттерн есть в логах приложения или в ingress-логах сервера, Metabase советует считать инстанс скомпрометированным.

Отдельный сигнал — неожиданные изменения в списке администраторов, новых API-ключах или истории запросов. Если вы видите активность ночью, чужие IP или массовые выгрузки, это уже повод разбирать инцидент, а не ждать следующего отчёта.

Что делать прямо сейчас

Разработчик уже выпустил исправления и советует ставить их без задержки. До обновления Metabase рекомендует временно закрыть endpoint /api/session/reset_password от публичного доступа.

После установки патча проверьте активные сессии, ключи API и учётки администраторов. Затем смените пароли к подключённым базам, просмотрите журналы хранилища данных и историю запросов. Если сервис стоит в корпоративной сети, полезно сопоставить эти действия с общими принципами защиты веб-приложений — тут пригодится и материал Как перевести сайт на HTTPS и защитить трафик, потому что шифрование и контроль точек входа часто идут рядом.

Для сотрудников, которые работают с дашбордами из публичных сетей, отдельным слоем защиты может быть шифрование трафика на личных устройствах. Это не лечит уязвимость в Metabase, но снижает риск утечки данных в чужой сети.

Практический чек-лист

  • Проверить, не стоит ли у вас уязвимая версия Metabase.
  • Срочно поставить обновление до исправленной версии.
  • До патча закрыть /api/session/reset_password от публичного доступа.
  • Посмотреть логи на связку POST /api/session/reset_password и GET /api/user/current.
  • Отозвать все активные сессии пользователей.
  • Проверить API-ключи и удалить незнакомые.
  • Сменить пароли к подключённым базам данных.
  • Проверить список администраторов и историю запросов.
  • Отдельно разобрать любые выгрузки, которые вы не планировали.
  • Если инстанс работал из публичной сети, проверить все точки доступа и журналы входа.
Поделиться: