Сплеск витоків персональних даних у Японії через атаки на API та Metabase

З липня по вересень 2026 року японські організації зіткнулися з різким зростанням витоків персональних даних через веб‑системи: за даними Macnica, вже за три квартали зафіксовано 119 інцидентів, тоді як за весь 2025 рік було 84, а окремі випадки (Park24, Monogatari) призводять до компрометації десятків мільйонів записів; JPCERT/CC пов’язує хвилю з масовим зловживанням мобільними та внутрішніми API, а також з експлуатацією критичної вразливості CVE-2026-72898 у Metabase, тому операторам веб‑сервісів, мобільних застосунків і BI‑систем необхідно терміново провести інвентаризацію API, доступних з інтернету, та оновити Metabase до мінімально безпечних версій.

Технічні деталі інцидентів

Масштаб і хронологія

Аналіз центру Macnica показує, що станом на 6 жовтня 2026 року публічно розкрито 119 інцидентів у Японії, де дані витекли через веб‑системи, при цьому:

• 62 інциденти у 2024 році;
• 84 у 2025 році;
• 119 вже у 2026 році, з них 81 — з липня, що вказує на різкий стрибок.

Серія не охоплює програмне забезпечення-вимагач та інші «класичні» атаки — йдеться саме про компрометацію веб‑ та API‑рівнів. JPCERT/CC у своєму повідомленні від 8 жовтня 2026 року (офіційний алерт JPCERT/CC) фіксує вал інцидентів «один за одним» приблизно у вересні.

Характерні великі випадки:

• Park24 (Times Car): несанкціонований доступ до даних близько 6,6 млн акаунтів сервісу каршерингу, а окремо — витік зображень посвідчень особи приблизно 1,6 млн користувачів.
• Monogatari (застосунок Yakiniku King): витік 10 788 963 записів із системи учасників.

Причина в цих інцидентах офіційно ще розслідується, але за масштабом і профілем вони вписуються в серію, описану Macnica.

Основні вектори атак на API

JPCERT/CC виділяє кілька повторюваних моделей зловживання API‑інтерфейсами мобільних і веб‑застосунків:

1. Аналіз мобільного застосунку і вилучення з нього:
   • списку endpointів API бекенду;
   • ключів і токенів API, вшитих у застосунок.

   Зловмисник потім формує прямі HTTP‑запити до цих endpointів, іноді так, щоб трафік нагадував звичайне використання, що ускладнює виявлення.

2. Доступ до «внутрішніх» функцій API, не представлених в інтерфейсі застосунку:
   • зміна рівнів привілеїв користувача;
   • створення несанкціонованих облікових записів;
   • тестування поведінки сервера під час модифікації заголовків, видалення токена або надсилання пошкодженого маркера автентифікації;
   • пошук деталей облікових записів через «сліпу» NoSQL‑ін’єкцію.
3. Повторне використання викрадених API‑ключів, скомпрометованих в інших системах.

Типові помилки на боці захищуваних систем:

• endpointи повертають більше даних, ніж потрібно для конкретної операції;
• API виконує операції з надмірними привілеями;
• функціональність для учасників доступна анонімним користувачам;
• помилки в логіці авторизації та управлінні сесіями.

Macnica додатково підкреслює, що секретні ключі API та паролі баз даних, вбудовані в клієнтський застосунок або код у браузері, легко витягуються навіть із мінімізованого або обфусцьованого коду, тому такі практики є неприпустимими (розбір Macnica).

Експлуатація CVE-2026-72898 у Metabase

Окремий вектор — атаки на Metabase, популярний BI‑інструмент, через критичну SQL‑ін’єкцію CVE-2026-72898 з оцінкою CVSS 10.0 (запис NVD по CVE-2026-72898). Вразливість:

• може бути експлуатована без облікового запису;
• дозволяє проводити SQL‑ін’єкцію у власну базу Metabase;
• дає змогу отримати права адміністратора Metabase;
• звідти атакувальник може вивантажити збережені облікові дані підключених баз даних і отримати доступ до їхнього вмісту.

Metabase повідомила про інцидент у своїй хмарній службі 6 серпня 2026 року та випустила оновлення безпеки (оновлення від 6 серпня). Пізніше компанія опублікувала розширений перелік мінімально безпечних версій для різних гілок продукту (security‑реліз від 12 серпня) і додаткове попередження щодо низки критичних проблем (security advisory GitHub).

Ключова ознака експлуатації CVE-2026-72898 за даними Metabase:

• у логах сервера фіксується POST /api/session/reset_password з кодом відповіді 400;
• потім слідує GET /api/user/current з кодом 200.

Тимчасовий захід для тих, хто не може негайно оновитися, — блокувати endpoint /api/session/reset_password на рівні веб‑сервера або міжмережевого екрана застосунків. Metabase прямо описує це як тимчасовий обхідний шлях, а не повноцінне рішення.

IOC від JPCERT/CC та Macnica

JPCERT/CC опублікував набір показників компрометації (актуальні як орієнтир, а не як «чорний список», оскільки адреси могли бути повторно використані легітимним трафіком).

Підозріла активність API (близько вересня 2026)

• IP: 3.112.252[.]14
• IP: 54.95.112[.]6
• IP: 69.10.51[.]162
• IP: 172.86.91[.]7
• IP: 210.149.87[.]120
• User-Agent: curl/7.88.1
• User-Agent: python-requests/2.34.2
• User-Agent: Mozilla/5.0 ... Chrome/126.0 Safari/537.36

Експлуатація Metabase (початок серпня — початок вересня 2026)

• IP: 213.163.202[.]171
• IP: 221.216.140[.]49
• IP: 221.216.140[.]129
• User-Agent: python-requests/2.33.1
• User-Agent: Metabase-GHSA-vwf4/2.0

Macnica окремо виділяє IP 210.149.87[.]120 і 69.10.51[.]162 як пріоритетні для перевірки, наголошуючи, що наявність звернень з цих адрес — лише привід до поглибленого аналізу логів, а не прямий доказ атаки.

Контекст загроз і географія

Хоча JPCERT/CC і Macnica не пов’язують серію витоків із конкретним угрупованням, простежується єдиний стиль: зловмисники масово «зондують» будь-які публічні веб‑системи, де можуть опинитися персональні дані, і використовують будь-яку виявлену слабкість в автентифікації, авторизації, конфігурації або відомих вразливостях.

Список постраждалих систем виходить далеко за межі інтернет‑магазинів: сервіси для учасників, бізнес‑системи, клієнтська підтримка, бібліотечні каталоги, системи бронювання туристичних поїздів. Macnica також виявила 99 аналогічних інцидентів у 13 країнах і регіонах поза Японією (у тому числі 30 — у Південній Кореї, 11 — у Франції та 8 — у Польщі), що свідчить про глобальний характер підходу зловмисників.

Застосування автоматизації (аж до добору вразливостей за допомогою ШІ) наразі не підтверджено: в логах немає прямих ознак такого використання, але охоплення та інтенсивність сканування роблять повністю ручний підхід малоймовірним — це важливий сигнал для перегляду діапазону тестованих сценаріїв під час аудиту безпеки.

Оцінка впливу для організацій

Найбільшому ризику піддаються:

• організації з масовими споживчими мобільними застосунками (банкінг, ритейл, транспорт, розваги);
• сервіси з моделлю «обліковий запис + бонуси/підписка», де зберігаються контактні дані, історія замовлень, номери карт лояльності;
• компанії, які використовують Metabase, особливо в режимі прямого доступу в інтернет до панелі та API;
• структури, де BI‑платформи мають доступ до промислових баз даних із персональною інформацією.

Потенційні наслідки бездіяльності:

• масові витоки персональних даних (імена, контакти, документи, поведінкові дані);
• регуляторні санкції з боку комісій із захисту даних (в Японії — Комісія із захисту персональної інформації, яка вже випустила свій алерт і методичні вказівки: alert PPC, guidance PPC);
• компрометація бізнес‑аналітики та промислових БД через Metabase як єдину точку входу;
• репутаційна шкода та зростання витрат на повідомлення постраждалих і подальші позови.

Практичні рекомендації щодо захисту

1. Невідкладні заходи для власників Metabase

1. Визначити всі інстанси Metabase (on‑premise і в cloud), доступні з інтернету.
2. Порівняти поточні версії з мінімально безпечними, опублікованими Metabase (перелік безпечних релізів), і негайно оновитися щонайменше до рекомендованого релізу.
3. До оновлення — заблокувати /api/session/reset_password ззовні як тимчасове пом’якшення ризику.
4. Перевірити логи на наявність послідовності:
   • POST /api/session/reset_password → HTTP 400;
   • GET /api/user/current → HTTP 200.

   У разі виявлення такого ланцюжка слід вважати сервер скомпрометованим.

5. Для інстансів, де endpoint був доступний з інтернету, після оновлення виконати повний цикл відновлення, рекомендований Metabase:
   • анулювати всі активні користувацькі сесії;
   • перевірити та видалити підозрілі API‑ключі;
   • аудитувати облікові записи адміністраторів;
   • змінити паролі та ключі всіх підключених баз даних;
   • проаналізувати логи сховищ даних на предмет аномальних запитів;
   • вивчити історію запитів у Metabase щодо неочікуваних вибірок.

2. Посилення API та мобільних бекендів

Рекомендації JPCERT/CC та OWASP API Security (OWASP API Security Top 10) задають базовий мінімум контролю:

• обмеження кількості запитів за одиницю часу (rate limiting), особливо для:
  • автентифікації та входу;
  • скидання пароля;
  • надсилання SMS і поштових сповіщень;
  • пошуку та інших ресурсомістких функцій.
• жорстка авторизація на кожному endpointі, включно з «непублічними»:
  • перевірка прав не лише для користувацьких, але й для адміністративних операцій;
  • окрема перевірка допустимих HTTP‑методів.
• принцип мінімально необхідних прав:
  • обмеження областей даних для кожного ключа й токена;
  • відмова від «універсальних» ключів з усіма правами.
• короткий строк життя API‑токенів і можливість оперативного відкликання у разі витоку.
• заборона на зберігання секретів (ключі API, паролі БД) у мобільних застосунках і фронтенд‑коді.
• включення адміністративних функцій до периметра регулярного тестування на вразливості.

3. Моніторинг і ретроспективний аналіз логів

У найближчий місяць доцільно виконати поглиблений розбір журналів веб‑серверів, API‑шлюзів і БД за період не менше 30 днів, звертаючи увагу на:

• аномально великий обсяг API‑запитів з однієї IP‑адреси;
• сплески відповідей 403, 404, 503 та інших помилок;
• звернення до неіснуючих endpointів і файлів;
• суттєве зростання загальної кількості запитів зі статусом 200 (зловживання «легітимними» викликами);
• використання адміністративних функцій із нетипових IP‑адрес;
• зростання навантаження на базу даних і пул сесій, що збігається з аномаліями в трафіку;
• збільшення кількості спроб входу до системи.

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