Metabase предупредила о критической уязвимости (CVSS 10.0) в своей платформе бизнес-аналитики, которая уже эксплуатируется в реальных атаках. Уязвимость позволяет удалённому злоумышленнику без аутентификации внедрить произвольный SQL в базу данных приложения и получить права администратора. Это даёт доступ к конфигурации, учётным данным подключённых баз данных и всем данным, доступным через эти соединения.
Кто пострадал и что известно об атаке
Metabase сообщила, что атаке подверглись инстансы Metabase Cloud. «Мы недавно обнаружили, что Metabase Cloud подвергся атаке с использованием неизвестной (0-day) уязвимости в версиях 1.58 и выше», — говорится в уведомлении компании. Облачные инстансы уже обновлены до последней версии.
Одной из пострадавших компаний стала Framework. По данным Engadget, производитель ПК уведомил клиентов, что в ходе взлома были получены имена, IP-адреса входа, адреса, номера телефонов и электронные письма. Данные заказов и платёжная информация не пострадали. Подобные инциденты напоминают атаки на Zimbra с кражей почты и 2FA-кодов, где компрометация одного сервиса приводила к утечке чувствительных данных пользователей.
Какие версии уязвимы и что делать
Уязвимости не присвоен идентификатор CVE. Затронуты следующие версии:
-
= x.58.0, < x.58.23 (исправлено в x.58.24)
-
= x.59.0, < x.59.20 (исправлено в x.59.21)
-
= x.60.0, < x.60.16 (исправлено в x.60.17)
-
= x.61.0, < x.61.10 (исправлено в x.61.11)
-
= x.62.0, < x.62.8 (исправлено в x.62.9)
-
= x.63.0, < x.63.3 (исправлено в x.63.5)
Пользователям самостоятельных (self-hosted) инстансов рекомендуется немедленно применить исправления. В качестве временной меры до установки обновления рекомендуется заблокировать эндпоинт /api/session/reset_password. Такой подход аналогичен мерам при других активно эксплуатируемых уязвимостях, например, 0-day в Cisco Secure Firewall Management Center с захардкоженными учётными данными, где также требовалось срочное ограничение доступа к критическим эндпоинтам.
Индикаторы компрометации
Metabase не раскрыла детали вредоносной активности, но опубликовала индикаторы компрометации (IoC):
- Вызов
POST /api/session/reset_passwordсо статусом 400 - Последующий вызов
GET /api/user/currentсо статусом 200
«Если вы видите такой паттерн в журналах приложения или в журналах входящего трафика сервера Metabase, вероятно, ваш инстанс скомпрометирован», — заявил генеральный директор Metabase Самир Аль-Сакран.
Порядок действий после обновления
Клиентам, у которых эндпоинт /api/session/reset_password был публично доступен, после обновления рекомендуется:
- Отозвать все активные пользовательские сессии, удалив все строки из таблицы
core_sessionв базе данных приложения Metabase. - Проверить API-ключи и удалить все неизвестные.
- Проверить учётные записи администраторов на предмет неожиданных изменений.
- Сменить учётные данные для всех подключённых баз данных.
- Проверить журналы хранилища данных на признаки несанкционированного доступа.
- Изучить журналы активности и историю запросов Metabase на предмет подозрительной активности.
Частые вопросы
Кого касается эта уязвимость?
Всех, кто использует Metabase версий от 1.58 и выше, включая облачные и самостоятельные инстансы. Облачные уже обновлены, но пользователям self-hosted версий нужно применить патчи самостоятельно.
Как проверить, скомпрометирован ли мой инстанс?
Проверьте журналы приложения и сервера на наличие последовательности вызовов POST /api/session/reset_password (статус 400) и GET /api/user/current (статус 200). Такая последовательность указывает на вероятную компрометацию.
Что делать, если я не могу обновиться прямо сейчас?
Временно заблокируйте эндпоинт /api/session/reset_password на уровне веб-сервера или файрвола. Это не устраняет уязвимость, но снижает риск эксплуатации до установки патча.
Какие данные может получить атакующий?
Злоумышленник с правами администратора может изменить конфигурацию приложения, украсть сохранённые учётные данные подключённых баз данных, прочитать любые данные через эти соединения и экспортировать их.
Есть ли связь с предыдущими уязвимостями Metabase?
Ровно три года назад Metabase устраняла другую критическую уязвимость (CVE-2023-38646, CVSS 9.8), которая позволяла выполнить код без аутентификации. Текущая проблема — отдельная, но не менее серьёзная.
Нужно ли менять пароли от подключённых баз данных?
Да, это настоятельно рекомендуется, особенно если эндпоинт /api/session/reset_password был доступен извне. Атакующий мог получить к ним доступ через украденные учётные данные.
Что делать, если я нашёл индикаторы компрометации?
Свяжитесь со службой поддержки Metabase, следуйте рекомендованным шагам по отзыву сессий, проверке API-ключей и администраторов, а также смените учётные данные подключённых баз данных.
Источник: thehackernews.com