ShinyHunters знову завдає удару — цього разу по Metabase

Угруповання-вимагач ShinyHunters заявляє про ще одну гучну жертву — цього разу воно нібито зламало Metabase, широко використовувану платформу бізнес-аналітики та візуалізації даних. Заява з’явилася лише через кілька днів після того, як Metabase розкрила критичну вразливість нульового дня, яка, за повідомленнями, відкривала доступ до баз даних, підключених до платформи, — вада, що може поставити під загрозу дані понад 100 000 організацій.

Часова послідовність примітна. Компанія розкриває серйозну ваду безпеки, і вже незабаром відоме угруповання зловмисників заявляє, що використало пов’язані слабкі місця для зламу тієї самої платформи. Незалежно від того, чи ці дві події безпосередньо пов’язані, така послідовність показує, як швидко зловмисники можуть діяти, щойно вразливість стає публічно відомою, і наскільки великими можуть бути ставки, коли одна платформа перебуває в центрі каналів даних багатьох організацій.

Чому злам Metabase мав би таке велике значення

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

Це частина почерку ShinyHunters — угруповання, яке здобуло репутацію завдяки атакам на платформи, багаті на дані, з подальшим оприлюдненням або продажем того, що вони нібито викрали. Раніше угруповання заявляло про відповідальність за інциденти з даними користувачів NVIDIA GeForce NOW, злам Baker Distributing із 260 000 записів, а також про ймовірну компрометацію медичних даних, пов’язаних з Exact Sciences. У кожному з цих випадків діяла схожа схема: знайти платформу з широким доступом до чутливих систем, заявити про доступ до її даних і використати витік як важіль тиску.

Ширший контекст: нульовий день і каскадний ризик

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

Це повторювана тема в сучасних витоках даних: найслабшою ланкою часто є не сама цільова організація, а сторонній постачальник або спільна платформа, що непомітно працює у фоновому режимі. Інциденти з підключеною інфраструктурою — чи то інструмент бізнес-аналітики на кшталт Metabase, чи критичні системи будівель, як у випадку з атакою програм-вимагачів на лікарню у Вінніпезі, що порушила роботу HVAC і систем контролю доступу до дверей, — показують, що зловмисники дедалі частіше шукають вузькі місця, які одночасно зачіпають багато систем, замість того щоб атакувати кожну ціль напряму.

Що це означає для вас

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

Для пересічних споживачів занепокоєння більш опосередковане, але все одно реальне. Якщо компанія, з якою ви маєте справу, використовує Metabase для внутрішньої аналітики, ваші персональні дані можуть перебувати в одній із баз даних під загрозою. Часто майже неможливо побачити, на які постачальники та інструменти компанія покладається за лаштунками, і саме тому такі витоки буває важко передбачити.

Практичні висновки

Організації, які використовують Metabase, повинні негайно перевірити стан виправлень і переглянути журнали на предмет незвичного доступу до підключених баз даних. Командам безпеки також варто ставитися до будь-якого стороннього інструмента аналітики чи бізнес-аналітики як до потенційної точки входу, а не лише як до внутрішньої зручності, і перевіряти, які бази даних відкриваються через такі інтеграції.

Для приватних осіб найкращим захистом залишаються стабільно добрі звички: використовуйте надійні унікальні паролі, вмикайте багатофакторну автентифікацію всюди, де це можливо, і стежте за незвичною активністю в облікових записах, особливо якщо отримали сповіщення про витік, пов’язане із сервісом, яким користуєтеся. Поки деталі щодо зламу Metabase продовжують з’ясовуватися, отримання інформації з перевірених джерел, а не реакція на самі лише заяви, допоможе відрізнити підтверджений ризик від припущень.