Критическая уязвимость Metabase с CVSS 10: Framework в числе пострадавших

Представьте банк, где парадная дверь — бронированная плита, хранилище защищено биометрикой, а охрана сменяется каждые четыре часа. А теперь представьте боковую дверь с табличкой «сброс пароля», подпёртую кирпичом. Именно так выглядит уязвимость нулевого дня в Metabase, раскрытая на этой неделе. И кирпич пролежал там достаточно долго, чтобы кто-то уже успел войти.

Metabase — опенсорсный BI-инструмент, который многие инженерные команды незаметно подключают напрямую к своим production-репликам, — предупреждает о pre-auth уязвимости с CVSS 10.0 без присвоенного CVE. Компания подтверждает, что Metabase Cloud был атакован. Framework, производитель модульных ноутбуков, — одна из подтверждённых жертв среди клиентов.

Что произошло

Как сообщает The Hacker News, Metabase раскрыл информацию об атаке на своё облачное предложение: злоумышленник эксплуатировал неизвестную уязвимость нулевого дня в версиях 1.58 и выше. Баг позволяет неаутентифицированному удалённому атакующему внедрять произвольный SQL непосредственно в базу данных приложения Metabase — ту самую скучную часть, которая хранит пользователей, сессии, разрешения и строки подключения для каждого хранилища данных.

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

Metabase Cloud уже обновлён. Пользователям self-hosted решений нужно действовать немедленно. Исправленные версии: x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 и x.63.5. Всё более старое в этих ветках уязвимо. Временное решение, если сегодня ночью вы не можете выполнить патч, — заблокировать эндпоинт /api/session/reset_password на уровне ingress. Эта одна строчка говорит об источнике уязвимости больше, чем само уведомление.

Со стороны клиентских последствий: Framework уведомил своих покупателей о том, что в ходе взлома были получены имена, IP-адреса входа, адреса, номера телефонов и электронная почта — согласно сообщениям, распространённым Engadget. Данные о заказах и платёжная информация не были скомпрометированы — единственное небольшое утешение в целом крайне неприятных выходных для их команды по безопасности.

Неудобная историческая сноска: ровно три года назад Metabase выпустил патч для CVE-2023-38646 — pre-auth RCE с оценкой 9.8. Тот же класс уязвимости, та же поверхность атаки «до авторизации». Другая дверь, тот же кирпич.

Техническая анатомия

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

CVSS 10 и инструкции по обходу уязвимости указывают на SQL-инъекцию где-то в обработке токена сброса пароля, которая позволяет атакующему делать записи в таблицу сессий, эскалировать до записи администратора или иным образом убеждать приложение в том, что анонимный вызывающий теперь является привилегированным пользователем. Слова CEO Самера Аль-Сакрана это подтверждают: «Если вы обнаружите этот паттерн в логах своего приложения или в ingress-логах сервера Metabase, вероятно, ваш инстанс был скомпрометирован.» Это не язык описания тонкого бага. Это язык ситуации «мы видели, как они залогировали запрос, и затем видели, как они получили доступ».

Что делает этот класс уязвимостей особенно разрушительным именно в BI-продуктах — так это радиус поражения. Инстанс Metabase почти всегда является точкой в вашей инфраструктуре с наибольшим охватом данных и наименьшим production-уровнем защиты. Он хранит долгоживущие учётные данные для вашей основной реплики, хранилища данных, иногда хранилища событий. Он работает за красивой SSO-страницей входа, которая убаюкивает всех, заставляя думать, что это внутренний инструмент. Но как только pre-auth путь обходит этот вход, каждая downstream-учётная запись становится добычей, напрямую отображаемой на техники ATT&CK для доступа к учётным данным и их сбора.

Тот, кто хоть раз выполнял SELECT * FROM core_session во время разбора инцидента, знает это тоскливое чувство. Таблица сессий — это сокровищница модели идентификации веб-приложения, а тот факт, что руководство по устранению последствий от самого Metabase предписывает удалить в ней все строки после установки патча, — явный признак. Если бы подделка сессий не была возможна, не нужно было бы аннулировать все сессии в мире.

Кто пострадает

Начнём с очевидных жертв. Framework уже сделал публичное заявление. Любая компания, запускающая self-hosted Metabase на версии старше исправленных релизов, с эндпоинтом сброса пароля, доступным из публичного интернета, должна считать себя скомпрометированной до тех пор, пока логи не докажут обратное. Не «наблюдайте за индикаторами» — а именно считайте. Паттерн IoC легко найти через grep, и если вы его обнаружили, вы уже находитесь в режиме раскрытия информации.

Более сложная группа — финтех и iGaming. Metabase обожают дата-команды в платёжных стартапах, букмекерских конторах и необанках именно потому, что он делает SQL доступным для продакт-менеджеров, не предоставляя им прямых учётных данных к хранилищу. Это удобство достигается за счёт того, что инструмент хранит эти учётные данные от их имени. Каждая сохранённая строка подключения к Postgres-реплике, полной клиентских PAN, KYC-записей или истории ставок, теперь под вопросом. Ротируйте их. Все. Не только те, которые, как вам кажется, использовались недавно.

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

Операторы криптовалютных и DeFi-проектов, запускающие Metabase для off-chain аналитики, должны быть не менее обеспокоены — но по другой причине. Украденные внутренние метрики по потокам ордеров, позициям ликвидности и балансам казначейства — это то, что через неделю может оказаться в X, использованное конкурентом или шортистом. Риск раскрытия — не только регуляторный. Он репутационный, а рынок движется быстрее любого плана реагирования на инциденты.

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

Руководство для команд безопасности

Порядок действий важен. Сначала выполните патч до версий исправленных веток: x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 или x.63.5. Если вы не можете выполнить патч в течение следующего часа, заблокируйте /api/session/reset_password на уровне reverse proxy. Nginx, Cloudflare, правила ALB — всё, что у вас есть. Этот единственный блок разрывает цепочку эксплойта перед незаткнутыми инстансами.

Затем выполните grep по IoC в ваших ingress-логах и логах приложения. POST на reset_password с ответом 400, за которым следует GET user/current с ответом 200 — это характерный отпечаток. Расширьте временное окно настолько, насколько позволяет хранение логов, поскольку раскрытие квалифицирует это как zero-day — эксплуатация предшествовала исправлению. Сопоставьте совпадения с обновлениями каталога CISA KEV в ближайшие дни, поскольку статус активной эксплуатации, вероятно, там появится.

Считайте инстанс скомпрометированным, если обнаружили паттерн. Затем следуйте собственному чеклисту Metabase после обновления: удалите все строки в core_session, чтобы завершить активные сессии; проверьте и удалите неизвестные API-ключи; проведите аудит каждой учётной записи администратора на предмет изменений, которых вы не делали; ротируйте все учётные данные для подключённых баз данных; получите аудит-логи хранилища, чтобы узнать, кто и что запрашивал. Также проверьте историю активности и запросов в Metabase на предмет несанкционированного экспорта.

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

Ключевые выводы

• Metabase раскрыл pre-auth SQL-инъекцию с CVSS 10.0 без присвоенного CVE, затрагивающую версии начиная с 1.58; исправление выпущено в релизах x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 и x.63.5.
• Metabase Cloud активно эксплуатировался, и Framework публично подтвердил, что были получены имена клиентов, IP-адреса входа, адреса, номера телефонов и электронная почта.
• IoC — это POST на /api/session/reset_password со статусом 400, за которым следует GET /api/user/current со статусом 200. Этот паттерн в ваших логах является веским сигналом компрометации.
• Постпатч-устранение последствий включает очистку таблицы core_session, аудит API-ключей и учётных записей администраторов, ротацию всех учётных данных подключённых баз данных и проверку аудит-логов хранилища.
• Metabase закрыл аналогичную pre-auth уязвимость CVE-2023-38646 с CVSS 9.8 ровно три года назад. Боковая дверь снова и снова оказывается подпёртой. Относитесь к BI-инструментам как к production-критичной поверхности атаки, а не к внутреннему удобству.

Кирпич из боковой двери теперь убран, но стальная парадная дверь никогда и не была проблемой.