Metabase Zero-Day з CVSS 10 — Framework у числі постраждалих

Уявіть банк, де головні двері зроблені з броньованої сталі, сховище має біометричні замки, а охоронці змінюються кожні чотири години. А тепер уявіть, що бічні двері з написом «скидання пароля» підперті цеглиною. Саме таку картину являє собою zero-day у Metabase, оприлюднений цього тижня, — і цеглина пролежала там достатньо довго, щоб хтось уже встиг пройти через ці двері.

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

Що сталося

Як повідомляє The Hacker News, Metabase оголосила, що її хмарний сервіс був атакований зловмисником, який використав невідомий zero-day у версіях 1.58 і вище. Вразливість дозволяє неавторизованому віддаленому зловмиснику впровадити довільний SQL безпосередньо в базу даних застосунку Metabase — тобто ту нецікаву частину, що зберігає користувачів, сесії, дозволи та рядки підключення до кожного сховища, з яким взаємодіє 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, розповідають усю історію тому, хто хоч раз вивчав логи вебзастосунку о 2-й ночі. Патерн виглядає так: POST /api/session/reset_password повертає 400, після чого GET /api/user/current повертає 200. Простою мовою: надіслати некоректний запит на скидання пароля, а потім перевірити, що ви тепер залогінені під чиїмось акаунтом. Якщо другий виклик повертає 200 без попереднього входу — ендпоінт скидання пароля не просто скидає паролі. Він генерує сесії.

CVSS 10 та рекомендації щодо обхідного шляху натякають на SQL ін'єкцію десь у логіці обробки токена скидання пароля, яка дозволяє зловмисникові записати дані в таблицю сесій, підвищити права до рядка адміністратора або будь-яким іншим чином переконати застосунок, що анонімний користувач тепер є привілейованим. Слова самого CEO Sameer Al-Sakran підтверджують це: «Якщо ви знайдете цей патерн у логах вашого застосунку або у вхідних логах сервера Metabase — ваш екземпляр, швидше за все, скомпрометований.» Це не мова тонкої вразливості. Це мова «ми бачили, як вони залогували запит, а потім бачили, як вони увійшли».

Те, що робить цей клас вразливостей особливо руйнівним саме в BI-продукті, — це радіус ураження. Екземпляр Metabase майже завжди є точкою у вашій інфраструктурі з найширшим доступом до даних і найменшим виробничим рівнем захисту. Він зберігає довгострокові облікові дані до вашої основної репліки, вашого сховища, а іноді й сховища подій. Він працює за гарною сторінкою SSO-входу, що заколисує всіх думкою про внутрішній інструмент. Але щойно pre-auth шлях обходить цей вхід — кожен downstream-обліковий запис стає здобутком, який безпосередньо відображається на техніках ATT&CK для доступу до облікових даних і їх збору.

Кожен, хто хоч раз виконував SELECT * FROM core_session під час розбору інциденту, знає це гнітюче відчуття. Таблиця сесій — це коштовності корони моделі ідентифікації вебзастосунку, і той факт, що власне керівництво Metabase щодо усунення наслідків радить знищити кожен рядок у ній після встановлення патча, — красномовний сигнал. Якби підробка сесій не була можливою, вам не потрібно було б анулювати абсолютно всі сесії.

Хто постраждає

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

Більш складна група — це fintech та 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 на вашому зворотному проксі. 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-інструментів як до критично важливої виробничої поверхні атаки, а не до внутрішнього зручного сервісу.

Цеглину з бічних дверей нарешті прибрали, але сталеві парадні двері ніколи і не були проблемою.