Национальная команда реагирования на компьютерные инциденты Японии JPCERT/CC связала недавний рост утечек веб-данных с двумя основными причинами: злоупотреблением API мобильных приложений и известными уязвимостями программного обеспечения, включая эксплуатируемую ошибку SQL-инъекции в Metabase. Эта история — полезное напоминание о том, что утечки веб-данных в Японии и слабости мобильных API обычно являются проблемами на стороне сервера, в системах, которые пользователи не видят и не контролируют.

Что JPCERT/CC обнаружила за утечками данных в Японии

Согласно отчёту, JPCERT/CC связывает недавний всплеск утечек данных в Японии со злоупотреблением API мобильных приложений и с уязвимостями, которые уже были публично известны. Одним из названных примеров является ошибка SQL-инъекции в Metabase, которую эксплуатировали злоумышленники.

Общая черта в том, что это не экзотические атаки. Известные уязвимости и плохо защищённые интерфейсы — это точки входа. В резюме исходного материала утечки не связываются с какими-либо действиями отдельных пользователей, и это важно для того, как читателям следует думать о риске: персональные данные были раскрыты сервисами, которые их хранили.

Как SQL-инъекции и открытые мобильные API приводят к утечке персональных данных

Два технических термина лежат в основе этой истории, поэтому полезно определить их просто.

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

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

В обоих случаях слабость находится у организации, эксплуатирующей сервис. Установка исправлений для известных уязвимостей и усиление контроля доступа к API — это исправления, и оба являются задачей оператора, а не клиента.

Что японским пользователям и сервисам следует проверить сейчас

Для организаций акцент отчёта на известных уязвимостях указывает на базовый чек-лист:

  • Убедитесь, что любое развёртывание Metabase обновлено до версии, устраняющей эксплуатируемую ошибку SQL-инъекции.
  • Проверьте API мобильных приложений, чтобы убедиться, что каждый запрос аутентифицирован и что пользователи могут получать только свои собственные записи.
  • Относитесь к публично раскрытым уязвимостям как к срочным, поскольку злоумышленники уже их используют.

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

Как ограничить свою подверженность после утечки

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

Что действительно помогает — это ограничение ущерба, когда утечка происходит:

  • Используйте уникальный пароль для каждого аккаунта. Если один сервис взломан, злоумышленники не смогут повторно использовать те же учётные данные в другом месте. Менеджер паролей делает это практичным.
  • Включите мониторинг утечек. Многие браузеры, менеджеры паролей и независимые сервисы предупредят вас, когда ваш email появится в известной утечке.
  • Делитесь меньшим объёмом данных с приложениями. Поля, которые вы никогда не предоставляли, не могут быть утечены. Пропускайте необязательные детали и используйте отдельный адрес электронной почты для сервисов с низким уровнем доверия.
  • Включите многофакторную аутентификацию там, где она предлагается, чтобы одного утёкшего пароля было недостаточно.
  • Будьте осторожны с неожиданными сообщениями. Утёкшие контактные данные часто питают целенаправленный фишинг.

Что это значит для вас

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

Свежий пример того, как выглядит крупномасштабное раскрытие в Японии, смотрите в нашем материале об утечке в KDDI, которая раскрыла 12,2 млн email клиентов в Японии. Одни только адреса электронной почты могут показаться незначительными, но именно такие данные питают фишинговые кампании.

Ключевые выводы

Утечки веб-данных в Японии, связанные со злоупотреблением мобильными API и неисправленным программным обеспечением, — это проблема на стороне сервиса, и VPN их не решит. Используйте уникальные пароли, включите мониторинг утечек, включите многофакторную аутентификацию и давайте приложениям только те данные, которые им действительно нужны. Эти привычки не остановят утечку, но они могут не дать ей превратиться в гораздо более серьёзную проблему для вас.