Разработчики Metabase сообщили о критической SQLi-уязвимости с оценкой 10,0 по CVSS. По их данным, дыру уже используют в атаках: злоумышленники получили доступ к облачному сервису Metabase Cloud и добрались как минимум до клиентов Framework и Tally.

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

Что произошло и почему это важно

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

Проблема уже вышла за рамки теории. Разработчики заявили, что атакующие использовали 0-day против Metabase Cloud, а компания заблокировала задействованные эндпоинты и выпустила исправление. Для self-hosted-инсталляций патч нужно ставить вручную.

Это ровно тот класс инцидентов, о которых мы уже писали в разборе атак с мгновенным захватом админ-доступа: в таких историях время между публикацией дыры и первыми компрометациями измеряется часами, а не неделями.

Как работает атака

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

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

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

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

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

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

Разработчики советуют считать инстанс скомпрометированным, если в логах есть цепочка: POST-запрос к /api/session/reset_password с ответом 400, а затем успешный GET-запрос к /api/user/current с кодом 200. Это не единственный признак, но один из самых характерных.

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

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

Патчи уже вышли для всех затронутых веток. Безопасными разработчики считают версии 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 и 0.63.5.

Если обновить Metabase немедленно не получается, временно закройте доступ к /api/session/reset_password. Это не заменяет патч, но снижает риск повторной атаки на уязвимый инстанс.

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

Для удалённых сотрудников и фрилансеров, которые заходят в корпоративные панели из поездок и отельных сетей, полезно заранее держать под рукой [инструмент для защищённого подключения]https://freedome.space) — не как замену обновлениям, а как дополнительный слой на случай работы вне офиса и проверки подозрительных сценариев входа.

Почему утечка может быть шире, чем кажется

По данным отчётов о пострадавших клиентах, у Framework в руки злоумышленников могли попасть имена, email-адреса, IP-адреса, телефоны, платёжные и почтовые адреса. Для корпоративных аккаунтов список ещё шире: название компании, VAT, EIN и платёжный email.

У Tally, по информации издания Bleeping Computer, атакующие добрались до email-адресов и хешей паролей пользователей. Формы и ответы на них хранились отдельно, поэтому их не задело, но сам факт компрометации аналитического окружения уже неприятен.

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

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

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