В Японии участились утечки персональных данных из веб-систем компаний и сервисов. JPCERT/CC связывает их с злоупотреблением API для мобильных приложений, ошибками в настройке прав доступа и известной уязвимостью в Metabase.

Что это за явление

Речь не о едином громком взломе, а о серии разрозненных инцидентов. Атакующие ищут слабые места в публичных веб-системах, внутренних административных панелях и BI-инструментах, а затем вытаскивают оттуда базы клиентов, записи аккаунтов и служебные данные.

Особенность этой волны в том, что злоумышленники не всегда лезут через «главный вход». Они используют мобильные API, забытые внутренние методы, украденные ключи доступа и известные ошибки в популярных продуктах. Иногда сервер при этом выглядит для обычного пользователя вполне рабочим.

Как это работает технически

JPCERT/CC описывает несколько сценариев. Первый — атака на API, которыми пользуется мобильное приложение: злоумышленник изучает приложение, находит скрытые точки запроса и обращается к ним напрямую, минуя экранные ограничения. Если сервер плохо проверяет права, он отдаёт больше данных, чем должен.

Второй сценарий — перебор слабых мест в логике самой системы. Речь о доступе к функциям для анонимных пользователей, чрезмерных правах, ошибках сессий, SQL-инъекциях и попытках угадать или украсть токены. По сути, это не «магия хакеров», а эксплуатация недосмотра со стороны разработчиков и администраторов.

Третий — атака на Metabase, BI-платформу для работы с данными. В уязвимой версии злоумышленник мог выполнить SQL-инъекцию, получить административный доступ, а затем добраться до подключённых баз. В таком сценарии один сервер открывает дорогу сразу к нескольким массивам информации.

Почему это опасно

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

Отдельный риск — цепочка «одна система → другая система». Если атакующий получил ключи или доступ к BI-инструменту, он может читать данные из подключённых хранилищ, выгружать отчёты и собирать картину бизнеса целиком. Именно так часто и выглядят серьёзные утечки: сначала небольшой технический промах, потом — большой провал в защите данных.

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

Как понять, что это касается вас

Если компания держит мобильное приложение, личный кабинет, внутреннюю BI-панель или публичный API, риск прямой. Особенно если разработчики не ограничили доступ к каждому endpoint, а часть сервисов торчит в интернет без строгой проверки прав.

Тревожные признаки простые: резкий рост запросов к API, странные POST-запросы к служебным маршрутам, неожиданные изменения ролей пользователей, появление неизвестных ключей доступа и жалобы на утечки без понятной причины. Если в логах есть цепочка подозрительных запросов к админским функциям, реагировать нужно сразу.

Пользователю тоже стоит насторожиться, если сервис внезапно сбросил сессии, просит заново войти или сообщает о смене пароля без вашего участия. Это не всегда означает взлом, но такой сигнал уже нельзя игнорировать.

Как защититься

Админам и ИБ-командам нужно проверить, закрыт ли доступ к каждому API-методу, нет ли лишних прав у внутренних функций и защищены ли токены. Для BI-систем и админок важны актуальные патчи, журналирование запросов и отдельный контроль для публичных и непубличных endpoint.

Если используется Metabase, обновление до безопасной версии — не рекомендация «на потом», а срочный шаг. Пока апдейт не поставлен, нужно ограничить доступ к уязвимому маршруту и проверить логи на подозрительные запросы. После обновления полезно сбросить активные сессии, пересмотреть API-ключи и заменить пароли к подключённым базам.

Тем, кто работает из дороги, из гостиницы или через общественные точки доступа, стоит смотреть не только на пароли и 2FA, но и на то, как сервисы защищают трафик и метаданные от пассивного наблюдения. В таких сценариях уместен и инструмент вроде защищённого канала для удалённой работы, если он вписан в политику компании и не нарушает локальные требования.

Чек-лист на сейчас

  • Проверьте, какие API доступны извне, и закройте лишние endpoint.
  • Сверьте права доступа у мобильного приложения, админок и BI-систем.
  • Обновите Metabase и другие веб-продукты до безопасных версий.
  • Посмотрите логи на странные POST-запросы, всплески ошибок и неизвестные ключи.
  • Смените пароли и токены там, где могли утечь учётные данные.
  • Пересмотрите доступ к подключённым базам и отключите неиспользуемые учётки.
  • Если вы пользователь сервиса, включите уведомления о входах и смене пароля.
Поделиться: