Критическая уязвимость Metabase с оценкой CVSS 10.0 уже использовалась в атаках на кражу данных, а среди публично подтвержденных пострадавших оказались Framework и Tally. Для русскоязычных IT-команд это плохой, но знакомый сценарий: BI-сервис, который часто считают второстепенной панелью для отчетов, внезапно оказывается короткой дорогой к клиентским базам и сервисным учетным данным.
Metabase раскрыла инцидент 6 августа. По данным BleepingComputer, атакующие использовали ранее неизвестную SQL-инъекцию без аутентификации против Metabase Cloud, а под ударом оказались и self-hosted-установки. CEO компании Sameer Al-Sakran сообщил, что использовавшиеся в атаке endpoints уже заблокированы, а исправление для облачной версии развернуто сразу после обнаружения проблемы. CVE у бага пока нет, но в security advisory он уже помечен как Critical. Речь не о локальном обходе или спорной конфигурации, а о дыре, которая позволяет зайти в инстанс извне и дальше работать уже с правами администратора.
Проблема в том, что уязвимость Metabase открывает не только саму панель аналитики. После получения админ-доступа злоумышленник может менять конфигурацию, вытаскивать сохраненные учетные данные к подключенным базам, читать данные через эти подключения и спокойно выгружать их наружу. Облачных клиентов компания обновила автоматически, а пользователям self-hosted придется чиниться вручную. В списке безопасных релизов указаны 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 и 0.63.5. Тем, кто не может обновиться немедленно, Metabase советует хотя бы временно закрыть доступ к endpoint /api/session/reset_password. Для поиска следов атаки компания рекомендует смотреть на POST-запрос к этому пути с ответом 400, после которого идет успешный GET к /api/user/current. Если такая связка есть в системных логах, инстанс, по сути, уже считается скомпрометированным.
Самый наглядный кейс пока у производителя ноутбуков Framework. В письме клиентам компания сообщила, что 6 августа получила уведомление от Metabase: их инстанс был уязвим, а доступ к нему атакующий получил еще 3 августа. В числе украденных данных названы полные имена, email-адреса, IP-адреса входа, платежные и почтовые адреса доставки, номера телефонов и названия компаний. Для клиентов Framework for Business список шире: там могут фигурировать название компании, телефон, VAT, EIN и email для биллинга. То есть речь не о техническом мусоре и не о паре служебных логов, а о вполне прикладном наборе для фишинга, социальной инженерии и последующих атак на бизнес-контакты.
У Tally, популярного конструктора онлайн-форм, компрометация затронула аналитическую среду Metabase 3 августа. По словам компании, атакующие добрались до email-адресов пользователей и криптографических хэшей паролей. Сами формы и ответы, которые в них оставляли пользователи, затронуты не были, потому что хранятся отдельно. Это важная оговорка, но не повод расслабляться: если парольные хэши попали наружу, дальше все упирается в используемый алгоритм, настройки защиты и то, насколько дисциплинированно пользователи переиспользуют пароли. BleepingComputer запрашивал у Tally детали о схеме хэширования и наличии соли, но на момент публикации ответа не получил. Еще один тревожный сигнал пришел от LexisNexis: компания предупредила клиентов о кибератаке на одного из сторонних поставщиков, из-за которой пострадали Diligence, Metabase API и Newsdesk. Системы пришлось отключить от внешнего контура, а вопрос о возможной утечке данных там пока оставили открытым.
Эта история бьет не только по конкретному продукту, но и по архитектурной привычке рынка. BI-платформы вроде Metabase почти всегда живут ближе к данным, чем хотелось бы: к ним подключают сразу несколько рабочих баз, в них сохраняют сервисные креды, а доступ наружу нередко оставляют ради удобства аналитиков, менеджеров и партнеров. На бумаге это просто инструмент отчетности. На практике это агрегатор доступа ко всему, что компания не хотела бы показывать посторонним. Поэтому атака через SQL-инъекцию здесь быстро превращается из взлома веб-интерфейса в нормальную цепочку кражи данных.
Для разработчиков, SRE и ИБ-команд вывод очень приземленный. Уязвимость Metabase надо воспринимать не как очередной баг в open source, а как инцидент уровня внешнего периметра. Минимальный набор действий компания уже перечислила: срочно обновить инстансы, завершить все активные пользовательские сессии, проверить API-ключи и список администраторов на несанкционированные изменения, сменить учетные данные всех подключенных баз и просмотреть логи с историей запросов на предмет необычных выгрузок. Если Metabase в компании подключена к продовым источникам напрямую, без сегментации и отдельных ограниченных аккаунтов, инцидент становится поводом пересмотреть не только патч-менеджмент, но и саму модель доступа к данным.
Неприятный вопрос после этой атаки звучит уже не так, как обычно. Речь не только о том, кто успеет поставить обновление сегодня, а о том, сколько компаний вообще защищают свои аналитические сервисы с той же дисциплиной, что VPN, почту или IAM. История с Metabase еще раз показала: дашборд с графиками давно перестал быть безобидной надстройкой. Это полноценный шлюз к данным клиентов, и рынок, похоже, снова вспомнил об этом уже после реальной кражи.