Инциденты и уязвимости
Мошенничество с 7pay (2019) — как платёжное приложение без 2FA было захвачено
В июле 2019 платёжное приложение 7pay от Seven & i захватили на следующий день после запуска: ~808 пользователей потеряли ~¥38,6 млн, а сервис закрыли за ~3 месяца. Причины — отсутствие 2FA и сброс пароля на незарегистрированный адрес. Защита: 2FA и сброс только на зарегистрированные каналы.
Мы читаем реальные публичные инциденты не как повтор новостей, а через вопрос «как вы от этого защищаетесь?». Эта статья основана на публичной информации (заявления компании, регуляторы, авторитетные СМИ). Источники перечислены в конце, и никаких инструкций по атаке здесь нет.
- Цель
- Аккаунты пользователей в платёжном приложении «7pay» (оператор: 7pay, Inc. / Seven & i Holdings)
- Обнаружено
- 2–3 июля 2019 (несанкционированный доступ замечен сразу после запуска)
- Схема
- Отсутствие 2FA + сброс пароля с возможной отправкой на незарегистрированный адрес → обход аутентификации → мошенническое использование балансов
- Масштаб
- ~808 пользователей, ~¥38,6 млн мошенничества (число позже уточнено расследованием)
- Первопричина
- Нет 2FA (только ID + пароль) + сброс пароля с доставкой на незарегистрированный email + слабая устойчивость к подстановке учётных данных + слабая интеграция внешнего ID (7iD) + недостаточная проверка потока аутентификации перед запуском
- Настоящее решение
- Требовать 2FA на чувствительных действиях, ограничить сброс пароля зарегистрированными каналами, обнаруживать/блокировать подстановку учётных данных, проверять потоки аутентификации перед запуском
Что произошло (простыми словами)
Мобильное платёжное приложение держит власть двигать ваши деньги. Именно поэтому «войти может только настоящий владелец и никто больше» — дизайн аутентификации — становится ключевым. Здесь 7pay был слаб: его защита сводилась фактически к одному паролю.
Наложились две проблемы. Во-первых, не было двухфакторной аутентификации (2FA): если ID и пароль совпадали, вы уже внутри — поэтому приложение было слабо против подстановки учётных данных, когда злоумышленники подставляют ID/пароли, утёкшие из других сервисов. Во-вторых, дизайн сброса пароля: новый пароль мог быть отправлен на адрес электронной почты, отличный от зарегистрированного, так что любой, у кого были фрагменты личных данных (дата рождения, телефон, email), мог заменить пароль, не будучи настоящим владельцем. Вместе это означало, что защиту из одного пароля можно было украсть в лоб через слабый сброс.
Защищать «вход к деньгам» одним слабым фактором — худший случай
Ценность для атакующих — это единственные ворота, которые напрямую ведут к деньгам или личным данным. Защищать вход высокой ценности — платежи, переводы, вход администратора — одним паролем плюс слабым сбросом означает ровно это. Помимо платежей, любая админ-панель, где один вход достаёт до балансов или данных всех пользователей, несёт ту же опасность.
Цепочка атаки — это ещё и карта обороны
Это была цепочка, где было место остановить её на каждом шаге. Читайте это как где её можно было разорвать, а не как инструкцию.
1. Вход: только по ID + паролю
Переиспользованные учётные данные, утёкшие в другом месте, могли просто сработать.
Стоп: 2FA / passkey; обнаружение и блокировка подстановки учётных данных
2. Выдача себя за другого через сброс пароля
Новый пароль можно было отправить на незарегистрированный адрес.
Стоп: сброс только на зарегистрированные каналы; более строгая проверка личности; уведомление о сбросе
3. Аккаунт захвачен, баланс использован
Захваченный аккаунт использовали для оплаты и пополнения.
Стоп: повторная аутентификация перед чувствительными действиями; обнаружение и приостановка аномальных платежей; уведомление
4. Ущерб растёт, сервис закрыт
После приостановки всех пополнений весь сервис свернули примерно за 3 месяца.
Стоп: проверять потоки аутентификации перед запуском; не создавать единую точку отказа по замыслу
Опубликованная хронология
2019-07-01
Запуск 7pay (внутри приложения 7-Eleven, интеграция с 7iD).2019-07-02
Начинают поступать первые сообщения о несанкционированном использовании (включая доступ с зарубежных IP).2019-07-03
Несанкционированное использование признано; зарубежный доступ блокируется, пополнение с кредитных/дебетовых карт приостановлено.2019-07-04
Публичная пресс-конференция; всё пополнение временно приостановлено. Широко отмечается отсутствие двухфакторной аутентификации.2019-07-05
Японское METI требует реакции; начинаются расследование первопричин и организационное усиление.2019-08-01
Объявлено о ликвидации сервиса (безопасный перезапуск потребовал бы значительного времени).2019-09-30
7pay закрывается.
Первопричина — обрушение слоёв, а не одна ошибка
Списать это на «пароль взломали» — значит напроситься на повтор. На деле несколько слоёв аутентификации были тонкими одновременно.
Схема, которая рухнула
- Платёжное приложение без двухфакторной аутентификации (только ID + пароль)
- Сброс пароля с доставкой на незарегистрированный адрес электронной почты
- Никакой устойчивости к подстановке учётных данных с утёкшими паролями
- Недостаточная проверка потока аутентификации перед запуском
Схема, которая держится
- Требовать 2FA / passkey на чувствительных действиях
- Отправлять сброшенные пароли только на зарегистрированные каналы
- Обнаруживать, ограничивать частоту и блокировать подстановку учётных данных
- Проверять поток аутентификации перед запуском (устранять единые точки отказа по замыслу)
Дизайн важнее скорости: счёт постфактум затмевает вложения заранее
7pay принял на себя мошенничество сразу после запуска, приостановил всё пополнение и примерно за три месяца полностью свернул сервис. Гонка за конкуренцией при пропуске проверки потока аутентификации означает, что цена утраченного доверия, ухода и восстановления намного превосходит первоначальные вложения в дизайн. Проектируйте аутентификацию под ту ценность, которую защищаете — до запуска, а не после.
Как вы от этого защищаетесь
Даже если вы не создаёте платежи, если есть единственное место, где один вход двигает много ценности, это про вас. В порядке приоритета:
Предложите двухфакторную аутентификацию (2FA) на чувствительных действиях
Ставьте 2FA на вход и на действия, двигающие деньги/данные, и предпочитайте устойчивые к фишингу методы вроде passkey, где можете. Даже одноразовый пароль (OTP) намного сильнее одного пароля.
Ограничьте сброс пароля «только зарегистрированными каналами»
Отправляйте новый пароль или ссылку сброса только на зарегистрированные email/телефон — никогда на произвольный адрес. Не проходите проверку личности по одним лишь фрагментам (дата рождения, телефон). Немедленно уведомляйте владельца, когда происходит сброс.
Считайте подстановку учётных данных данностью; обнаруживайте и ограничивайте её
Атаки, повторяющие утёкшие учётные данные, — данность. Добавьте ограничения частоты, обнаружение аномального входа и блокировку после N попыток и отклоняйте известные скомпрометированные пароли. Подталкивайте пользователей отказаться от повторного использования.
Проверяйте поток аутентификации перед запуском
Пусть вход, сброс и повторную аутентификацию проверит вторая пара глаз на этапе проектирования и перед запуском. «Работает» — это не «безопасно». Не пропускайте проверку аутентификации ради скорости.
Где это пересекается с тем, как устроен наш сайт
По сути этот инцидент был про защиту ценного действия одним слабым фактором и последующее позволение слабому сбросу украсть этот фактор. Это зеркальное отражение собственных принципов нашего сайта — не создавать единые точки отказа, защищать чувствительные действия слоями и сжимать радиус поражения. Помимо платежей, любая админ-панель, где один вход достаёт до балансов или данных всех пользователей, несёт ту же опасность. «Добавить 2FA, сброс только на зарегистрированные каналы, повторная аутентификация перед чувствительными действиями» — это защита, которую любой может внедрить в любом масштабе.
Источники (публичная информация)
Факты здесь основаны на следующей публичной информации. Никаких инструкций по атаке — только уроки обороны.
- Seven & i Holdings, «Уведомление о прекращении сервиса „7pay“» (2019) — 7andi.com
- Seven-Eleven Japan, «Несанкционированный доступ к некоторым аккаунтам „7pay“» (2019) — sej.co.jp
- Japan METI, публикации о реагировании на мошенничество с безналичными платежами (2019) — meti.go.jp
Читать дальше
- Термины: Двухфакторная аутентификация (2FA) / Одноразовый пароль (OTP)
- Термин: Passkey (аутентификация, не полагающаяся на пароль)
- Практика: Аутентификация и авторизация / Чек-лист базовой безопасности
FAQ
QКакова первопричина инцидента 7pay?
Дизайн аутентификации. Платёжное приложение вышло без двухфакторной аутентификации (2FA), поэтому для входа хватало ID + пароля. Хуже того, поток сброса пароля мог отправить новый пароль на адрес электронной почты, отличный от зарегистрированного, так что фрагментов личных данных (дата рождения, номер телефона, email) было достаточно для захвата аккаунта. Схема также была слаба против подстановки учётных данных (повторное использование ID/паролей, утёкших из других сервисов).
QЯ не создаю платёжный сервис — это касается меня?
Да. Реальная проблема в том, чтобы защищать ценное действие (деньги, личные данные) одним паролем, а затем позволять слабому потоку сброса украсть этот единственный пароль. Предлагайте 2FA при входе, отправляйте сброс пароля только на зарегистрированный канал и повторно проверяйте личность перед чувствительными действиями. Это применимо к любому приложению или админ-панели.
QЧто может сделать сам пользователь?
Да: (1) никогда не используйте один пароль в разных сервисах (это нейтрализует подстановку учётных данных); (2) включайте 2FA или passkey везде, где они предлагаются; (3) включите уведомления о транзакциях для платежей, чтобы быстро замечать аномалии. Даже если дизайн оператора слаб, отказ от повторного использования паролей закрывает главный путь к захвату.