Incidentes e Vulnerabilidades
Fraude no 7pay (2019) — como um app de pagamento sem 2FA foi sequestrado
Em julho de 2019, o app de pagamento 7pay da Seven & i foi sequestrado um dia após o lançamento: ~808 usuários perderam ~¥38,6 milhões e o app foi encerrado em ~3 meses. As falhas centrais: ausência de 2FA e uma redefinição de senha que podia enviar a nova senha a um e-mail não cadastrado.
Lemos violações reais e públicas não como notícia repetida, mas como "como você se defende disto?" Este artigo baseia-se no registro público (comunicados das empresas, reguladores, jornalismo confiável). As fontes estão listadas ao final, e nenhum passo de ataque está incluído.
- Alvo
- Contas de usuário no app de pagamento "7pay" (operador: 7pay, Inc. / Seven & i Holdings)
- Detectado
- 2 a 3 de julho de 2019 (acesso não autorizado notado logo após o lançamento)
- Padrão
- Sem 2FA + uma redefinição de senha cujo destino podia ser um endereço não cadastrado → contorno da autenticação → uso fraudulento de saldos
- Escala
- ~808 usuários, ~¥38,6 milhões em fraude (contagem depois refinada pela investigação)
- Causa raiz
- Sem 2FA (só ID + senha) + redefinição de senha entregável a um e-mail não cadastrado + fraca resistência ao credential-stuffing + integração frágil do ID externo (7iD) + revisão insuficiente do fluxo de autenticação antes do lançamento
- Correção real
- Exigir 2FA em ações sensíveis, restringir a redefinição de senha a canais cadastrados, detectar/bloquear o credential-stuffing, revisar os fluxos de autenticação antes do lançamento
O que aconteceu (em termos simples)
Um app de pagamento móvel detém o poder de mover o seu dinheiro. Isso torna "só o verdadeiro dono consegue logar, mais ninguém" — o desenho da autenticação — o cerne. O 7pay era frágil aqui: sua defesa era, na prática, uma única senha.
Dois problemas se somaram. Primeiro, não havia autenticação de dois fatores (2FA): se o ID e a senha batessem, você entrava — então o app era frágil diante do credential-stuffing, em que os atacantes testam IDs/senhas vazados de outros serviços. Segundo, o desenho da redefinição de senha: a nova senha podia ser enviada a um e-mail diferente do cadastrado, então qualquer pessoa com fragmentos de dados pessoais (data de nascimento, telefone, e-mail) podia trocar a senha sem ser o verdadeiro dono. Juntos, isso significava que a defesa de senha única podia ser roubada de frente por meio de uma redefinição frágil.
Guardar uma 'entrada que move dinheiro' com um único fator frágil é o pior caso
O que os atacantes valorizam é uma única porta que leva direto a dinheiro ou dados pessoais. Guardar uma entrada de alto valor — pagamentos, transferências, login administrativo — com uma senha mais uma redefinição frágil é exatamente isso. Além dos pagamentos, qualquer painel administrativo onde um único login alcança saldos ou os dados de todos os usuários carrega o mesmo perigo.
A cadeia de ataque também é um mapa de defesa
Esta foi uma cadeia com um lugar para detê-la em cada passo. Leia-a como onde ela poderia ter sido quebrada, não como um passo a passo.
1. Entrada: login só por ID + senha
Credenciais reutilizadas, vazadas em outro lugar, podiam simplesmente funcionar.
Freio: 2FA / passkeys; detectar e bloquear o credential-stuffing
2. Personificação via redefinição de senha
A nova senha podia ser enviada a um destino não cadastrado.
Freio: redefinição só para canais cadastrados; conferências de identidade mais fortes; notificar na redefinição
3. Conta sequestrada, saldo abusado
A conta sequestrada foi usada para pagar e carregar.
Freio: reautenticar antes de ações sensíveis; detectar e pausar pagamentos anormais; notificar
4. O dano se espalha, o serviço é encerrado
Depois de suspender toda a recarga, o serviço inteiro foi descartado em ~3 meses.
Freio: revisar os fluxos de autenticação antes do lançamento; não construir um ponto único de falha por desenho
Linha do tempo publicada
2019-07-01
O 7pay é lançado (dentro do app da 7-Eleven, integrado ao 7iD).2019-07-02
Começam os primeiros relatos de uso não autorizado (incluindo acesso de IPs no exterior).2019-07-03
Uso não autorizado reconhecido; o acesso do exterior é bloqueado e a recarga por cartão de crédito/débito (top-ups) é suspensa.2019-07-04
Coletiva de imprensa pública; toda a recarga é temporariamente suspensa. A ausência de autenticação de dois fatores é amplamente notada.2019-07-05
O METI do Japão pede uma resposta; começam a investigação da causa raiz e o reforço organizacional.2019-08-01
O encerramento do serviço é anunciado (um reinício seguro levaria tempo considerável).2019-09-30
O 7pay é desligado.
A causa raiz foram camadas falhando, não um único erro
Descartar isso como "a senha foi quebrada" convida a uma repetição. Na realidade, várias camadas de autenticação estavam finas ao mesmo tempo.
O arranjo que falhou
- Um app de pagamento sem autenticação de dois fatores (só ID + senha)
- Redefinição de senha entregável a um e-mail não cadastrado
- Nenhuma resistência ao credential-stuffing com credenciais vazadas
- Revisão insuficiente do fluxo de autenticação antes do lançamento
O arranjo que se sustenta
- Exigir 2FA / passkeys em ações sensíveis
- Enviar senhas de redefinição apenas para canais cadastrados
- Detectar, limitar a taxa e bloquear o credential-stuffing
- Revisar o fluxo de autenticação antes do lançamento (elimine pontos únicos de falha por desenho)
Desenho acima de velocidade: a conta a posteriori supera de longe a antecipada
O 7pay sofreu fraude logo após o lançamento, suspendeu toda a recarga e, em cerca de três meses, descartou o serviço por inteiro. Correr para competir enquanto se pula a revisão do fluxo de autenticação significa que o custo da confiança perdida, da retirada e da reconstrução supera de longe o investimento antecipado em desenho. Projete a autenticação à altura do valor que você protege — antes do lançamento, não depois.
Como você se defende disto
Mesmo que você não construa pagamentos, se há um único lugar onde um login move muito valor, isto é seu. Em ordem de prioridade:
Ofereça autenticação de dois fatores (2FA) em ações sensíveis
Coloque 2FA no login e nas ações que movem dinheiro/dados, e prefira métodos resistentes a phishing, como passkeys, onde puder. Até uma senha de uso único (OTP) é bem mais forte que uma única senha.
Restrinja a redefinição de senha a 'apenas canais cadastrados'
Envie a nova senha ou o link de redefinição apenas ao e-mail/telefone cadastrado — nunca a um destino arbitrário. Não aprove conferências de identidade só com fragmentos (data de nascimento, telefone). Notifique o dono imediatamente quando uma redefinição acontecer.
Presuma o credential-stuffing; detecte-o e limite-o
Ataques que reproduzem credenciais vazadas são dados. Adicione limites de taxa, detecção de login anômalo e bloqueio após N tentativas, e rejeite senhas sabidamente vazadas. Empurre os usuários para longe do reuso.
Revise o fluxo de autenticação antes do lançamento
Tenha o login, a redefinição e a reautenticação revisados por um segundo par de olhos no desenho e antes do lançamento. "Funciona" não é "é seguro." Não pule a revisão da autenticação por velocidade.
Onde isto se sobrepõe a como este site é construído
Em essência, este incidente foi sobre guardar uma ação valiosa com um único fator frágil e, então, deixar uma redefinição frágil roubar esse fator. Essa é a imagem invertida dos próprios princípios deste site — não construa pontos únicos de falha, defenda ações sensíveis em camadas e encolha o raio da explosão. Além dos pagamentos, qualquer painel administrativo onde um único login alcança saldos ou os dados de todos os usuários carrega o mesmo perigo. "Adicionar 2FA, redefinição só para canais cadastrados, reautenticar antes de ações sensíveis" é uma defesa que qualquer um pode implementar em qualquer escala.
Fontes (registro público)
Os fatos aqui baseiam-se nas seguintes informações públicas. Nenhum passo de ataque está incluído — apenas as lições defensivas.
- Seven & i Holdings, "Aviso de descontinuação do serviço '7pay'" (2019) — 7andi.com
- Seven-Eleven Japan, "Acesso não autorizado a algumas contas '7pay'" (2019) — sej.co.jp
- METI do Japão, divulgações sobre a resposta à fraude em pagamentos sem dinheiro (2019) — meti.go.jp
Leia a seguir
- Termos: Autenticação de dois fatores (2FA) / Senha de uso único (OTP)
- Termo: Passkey (autenticação que não depende de uma senha)
- Prática: Autenticação vs autorização / Checklist de base de segurança
FAQ
QQual foi a causa raiz do incidente do 7pay?
O desenho da autenticação. Um app de pagamento foi ao ar sem autenticação de dois fatores (2FA), então o login exigia apenas ID + senha. Pior: o fluxo de redefinição de senha podia enviar a nova senha a um e-mail diferente do cadastrado, então fragmentos de dados pessoais (data de nascimento, telefone, e-mail) bastavam para tomar uma conta. O arranjo também era frágil diante do credential-stuffing (reuso de IDs/senhas vazados de outros serviços).
QEu não construo um serviço de pagamento — isso é relevante para mim?
Sim. O problema real é proteger uma ação valiosa (dinheiro, dados pessoais) com uma única senha e, então, deixar um fluxo de redefinição frágil roubar essa única senha. Ofereça 2FA no login, envie redefinições de senha apenas ao canal cadastrado e reautentique antes de ações sensíveis. Isso vale para qualquer app ou painel administrativo.
QComo usuário individual, o que posso fazer?
Sim: (1) nunca reutilize senhas entre serviços (isso neutraliza o credential-stuffing); (2) ligue o 2FA ou uma passkey onde quer que seja oferecido; (3) ative notificações de transações para pagamentos, para notar anomalias rápido. Mesmo que o desenho do operador seja frágil, não reutilizar senhas fecha o principal caminho de sequestro.