Incidentes y vulnerabilidades
Fraude de 7pay (2019) — Cómo se secuestró una app de pago sin 2FA
En julio de 2019, la app de pago 7pay de Seven & i fue secuestrada un día después de su lanzamiento: ~808 usuarios perdieron ~¥38,6 millones y la app se cerró en unos tres meses. Los fallos: sin 2FA y un restablecimiento de contraseña que enviaba la nueva a un correo no registrado. Defiéndete exigiendo 2FA.
Leemos brechas reales y públicas no como noticias reproducidas, sino como «¿cómo te defiendes de esto?». Este artículo se basa en el registro público (comunicados de la empresa, reguladores, periodismo reputado). Las fuentes se listan al final y no se incluye ningún manual de ataque.
- Objetivo
- Cuentas de usuario de la app de pago «7pay» (operador: 7pay, Inc. / Seven & i Holdings)
- Detectado
- 2–3 de julio de 2019 (acceso no autorizado advertido justo tras el lanzamiento)
- Patrón
- Sin 2FA + un restablecimiento de contraseña cuyo destino podía ser una dirección no registrada → elusión de la autenticación → uso fraudulento de saldos
- Escala
- ~808 usuarios, ~¥38,6 millones en fraude (la cifra se afinó luego en la investigación)
- Causa raíz
- Sin 2FA (solo ID + contraseña) + restablecimiento de contraseña entregable a un correo no registrado + escasa resistencia al relleno de credenciales + integración débil del ID externo (7iD) + revisión insuficiente del flujo de autenticación antes del lanzamiento
- Solución real
- Exigir 2FA en acciones sensibles, restringir el restablecimiento de contraseña a canales registrados, detectar/bloquear el relleno de credenciales, revisar los flujos de autenticación antes del lanzamiento
Qué ocurrió (en términos sencillos)
Una app de pago móvil tiene el poder de mover tu dinero. Eso hace que «solo el dueño real pueda iniciar sesión, nadie más» —el diseño de la autenticación— sea la clave. 7pay era débil aquí: su defensa era, en la práctica, una sola contraseña.
Se combinaron dos problemas. Primero, no había autenticación de dos factores (2FA): si el ID y la contraseña coincidían, entrabas — así que la app era débil frente al relleno de credenciales, donde los atacantes prueban IDs/contraseñas filtrados de otros servicios. Segundo, el diseño del restablecimiento de contraseña: la nueva podía enviarse a un correo distinto del registrado, así que cualquiera con fragmentos de datos personales (fecha de nacimiento, teléfono, correo) podía reemplazar la contraseña sin ser el dueño real. Juntos, significaban que la defensa de una sola contraseña podía robarse de frente a través de un restablecimiento débil.
Proteger una 'entrada que mueve dinero' con un único factor débil es el peor de los casos
Lo que los atacantes valoran es una única puerta que se conecta directamente con dinero o datos personales. Proteger una entrada de alto valor —pagos, transferencias, inicio de sesión de administrador— con una contraseña más un restablecimiento débil es exactamente eso. Más allá de los pagos, cualquier panel de administración donde un inicio de sesión alcanza saldos o los datos de todos los usuarios conlleva el mismo peligro.
La cadena del ataque es también un mapa de defensa
Esta fue una cadena con un punto para detenerla en cada paso. Léela como dónde podría haberse roto, no como un manual.
1. Entrada: inicio de sesión solo con ID + contraseña
Credenciales reutilizadas filtradas en otro lugar simplemente podían funcionar.
Freno: 2FA / passkeys; detectar y bloquear el relleno de credenciales
2. Suplantación mediante el restablecimiento de contraseña
La nueva contraseña podía enviarse a un destino no registrado.
Freno: restablecer solo a canales registrados; verificación de identidad más fuerte; notificar al restablecer
3. Cuenta secuestrada, saldo abusado
La cuenta secuestrada se usó para pagar y recargar.
Freno: reautenticar antes de acciones sensibles; detectar y pausar pagos anómalos; notificar
4. El daño se extiende, el servicio se clausura
Tras suspender toda recarga, el servicio entero se desechó en ~3 meses.
Freno: revisar los flujos de autenticación antes del lanzamiento; no construir por diseño un punto único de fallo
Cronología publicada
2019-07-01
7pay se lanza (dentro de la app de 7-Eleven, integrada con 7iD).2019-07-02
Comienzan los primeros informes de uso no autorizado (incluido acceso desde IPs extranjeras).2019-07-03
Se reconoce el uso no autorizado; se bloquea el acceso desde el extranjero y se suspende la recarga (ingresos) con tarjeta de crédito/débito.2019-07-04
Rueda de prensa pública; se suspende temporalmente toda recarga. La ausencia de autenticación de dos factores se señala ampliamente.2019-07-05
El METI de Japón solicita una respuesta; comienzan la investigación de la causa raíz y el reforzamiento organizativo.2019-08-01
Se anuncia la abolición del servicio (un reinicio seguro llevaría un tiempo considerable).2019-09-30
7pay cierra.
La causa raíz fue el fallo de varias capas, no un solo error
Descartar esto como «se descifró la contraseña» invita a que se repita. En realidad, varias capas de autenticación eran delgadas a la vez.
El montaje que falló
- Una app de pago sin autenticación de dos factores (solo ID + contraseña)
- Restablecimiento de contraseña entregable a un correo no registrado
- Sin resistencia al relleno de credenciales con credenciales filtradas
- Revisión insuficiente del flujo de autenticación antes del lanzamiento
El montaje que aguanta
- Exigir 2FA / passkeys en acciones sensibles
- Enviar las contraseñas de restablecimiento solo a canales registrados
- Detectar, limitar la tasa y bloquear el relleno de credenciales
- Revisar el flujo de autenticación antes del lanzamiento (eliminar por diseño los puntos únicos de fallo)
El diseño por encima de la velocidad: la factura a posteriori supera con creces la inicial
7pay sufrió fraude justo tras el lanzamiento, suspendió toda recarga y, en unos tres meses, desechó el servicio por completo. Correr para competir mientras se omite la revisión del flujo de autenticación significa que el coste de la confianza perdida, la retirada y la reconstrucción supera con creces la inversión inicial de diseño. Diseña la autenticación a la medida del valor que proteges — antes del lanzamiento, no después.
Cómo te defiendes de esto
Aunque no construyas pagos, si existe un único lugar donde un inicio de sesión mueve mucho valor, esto es cosa tuya. Por orden de prioridad:
Ofrece autenticación de dos factores (2FA) en acciones sensibles
Pon 2FA en el inicio de sesión y en las acciones que mueven dinero/datos, y prefiere métodos resistentes al phishing como las passkeys donde puedas. Incluso una contraseña de un solo uso (OTP) es mucho más fuerte que una sola contraseña.
Restringe el restablecimiento de contraseña a 'solo canales registrados'
Envía la nueva contraseña o el enlace de restablecimiento solo al correo/teléfono registrado — nunca a un destino arbitrario. No superes las verificaciones de identidad solo con fragmentos (fecha de nacimiento, teléfono). Notifica al dueño de inmediato cuando ocurra un restablecimiento.
Da por hecho el relleno de credenciales; detéctalo y limítalo
Los ataques que reproducen credenciales filtradas están asegurados. Añade límites de tasa, detección de inicios de sesión anómalos y bloqueo tras N intentos, y rechaza contraseñas conocidas por estar comprometidas. Empuja a los usuarios a no reutilizar.
Revisa el flujo de autenticación antes del lanzamiento
Haz que el inicio de sesión, el restablecimiento y la reautenticación sean revisados por un segundo par de ojos en el diseño y antes del lanzamiento. «Funciona» no es «es seguro». No omitas la revisión de autenticación por velocidad.
Dónde esto se solapa con cómo está construido este sitio
En su núcleo, este incidente trató de proteger una acción valiosa con un único factor débil, y luego dejar que un restablecimiento débil robara ese factor. Es la imagen especular de los propios principios de este sitio — no construir puntos únicos de fallo, defender las acciones sensibles por capas y reducir el radio de explosión. Más allá de los pagos, cualquier panel de administración donde un inicio de sesión alcanza saldos o los datos de todos los usuarios conlleva el mismo peligro. «Añade 2FA, restablece solo a canales registrados, vuelve a autenticar antes de acciones sensibles» es una defensa que cualquiera puede implementar a cualquier escala.
Fuentes (registro público)
Los hechos aquí se basan en la siguiente información pública. No se incluye ningún manual de ataque — solo las lecciones defensivas.
- Seven & i Holdings, «Aviso de discontinuación del servicio '7pay'» (2019) — 7andi.com
- Seven-Eleven Japan, «Acceso no autorizado a algunas cuentas de '7pay'» (2019) — sej.co.jp
- METI de Japón, divulgaciones sobre la respuesta al fraude en pagos sin efectivo (2019) — meti.go.jp
Leer a continuación
- Términos: Autenticación de dos factores (2FA) / Contraseña de un solo uso (OTP)
- Término: Passkey (autenticación que no depende de una contraseña)
- Práctica: Autenticación frente a autorización / Lista de comprobación de seguridad base
FAQ
Q¿Cuál fue la causa raíz del incidente de 7pay?
El diseño de autenticación. Una app de pago se lanzó sin autenticación de dos factores (2FA), así que el inicio de sesión solo requería ID + contraseña. Peor aún, el flujo de restablecimiento de contraseña podía enviar la nueva a un correo distinto del registrado, así que fragmentos de datos personales (fecha de nacimiento, número de teléfono, correo) bastaban para tomar el control de una cuenta. El montaje también era débil frente al relleno de credenciales (reutilizar IDs/contraseñas filtrados de otros servicios).
QNo construyo un servicio de pago, ¿esto me afecta?
Sí. El problema real es proteger una acción valiosa (dinero, datos personales) con una sola contraseña, y luego dejar que un flujo de restablecimiento débil robe esa única contraseña. Ofrece 2FA en el inicio de sesión, envía los restablecimientos de contraseña solo al canal registrado y vuelve a autenticar antes de acciones sensibles. Eso aplica a cualquier app o panel de administración.
QComo usuario individual, ¿qué puedo hacer?
Sí: (1) nunca reutilices contraseñas entre servicios (esto neutraliza el relleno de credenciales); (2) activa el 2FA o una passkey allí donde se ofrezca; (3) habilita las notificaciones de transacciones en los pagos para que detectes anomalías rápido. Aunque el diseño del operador sea débil, no reutilizar contraseñas cierra la principal vía de secuestro.