Andy Garcia · dev freelance
FRENES
Volver al blog
Seguridad

La propia app de ASOS envió «ASOS Hacked» a sus clientes. ASOS dice que la entrada fue la cuenta de un empleado

19 de octubre de 2026 8 min de lectura

El martes 6 de octubre, los usuarios de la app de ASOS recibieron una notificación push de la propia app de ASOS. Su título era "ASOS HACKED". Su texto, citado por Malwarebytes: "Estimados DPO e IT de Asos, hemos comprometido por completo la instancia de Snowflake. Contacten con nosotros o la filtraremos." Venía con un enlace a un canal de Telegram. El comunicado de ASOS la sitúa hacia las 10 h, y clientes de Gran Bretaña, Irlanda, Estados Unidos y otros países la comunicaron, según BankInfoSecurity.

Más tarde ese día, ASOS, que declara 16,5 millones de clientes activos, confirmó en un comunicado a la Bolsa de Londres que "se envió una notificación no autorizada a los clientes de ASOS". "Estamos investigando actividad no autorizada que afecta a plataformas de terceros que usamos para comunicarnos con los clientes", dijo. "Tomamos medidas inmediatas para restringir el acceso a las plataformas de notificaciones." Sus acciones cayeron más de un 10 % ese martes, informó PA; FashionUnited situó la caída de la mañana en torno al 11 %, seguida de una recuperación parcial. Esa tarde, ASOS escribió a sus clientes para que "ignoren la notificación y no hagan clic ni interactúen con el enlace externo de terceros que contenía".

El jueves 8 de octubre, ASOS publicó lo que habían revelado sus primeras 48 horas de investigación: "una parte no autorizada accedió a la cuenta de un empleado de ASOS haciéndose pasar por un contacto de confianza para obtener credenciales de acceso. Esas credenciales se usaron después para acceder a información en determinadas plataformas de terceros utilizadas por ASOS".

El relato de ASOS no describe ningún fallo de software. Se engañó a una persona, y un acceso capaz de llegar a los sistemas que hablan con los clientes cambió de manos.

Lanzo apps de iOS como desarrollador independiente y soy CTO de una LegalTech. Leí el incidente con una sola pregunta: ¿quién, fuera de mi propio código, puede hacer hablar a mi app?

Qué está confirmado y qué solo se afirma

La actualización de ASOS dice que el intruso tuvo acceso a "cierta información personal, incluidos nombres y datos de contacto, y cierta información de la cuenta no personal", y que no se accedió a información de tarjetas de pago ni a contraseñas de cuentas. Las plataformas afectadas fueron "bloqueadas de inmediato", y la investigación completa "continuará durante las próximas semanas". ASOS no ha nombrado las plataformas.

El resto viene de los atacantes o de investigadores. La notificación culpaba a Snowflake. Snowflake dijo que "no encontró ninguna vulneración" de su plataforma. En un reportaje publicado el 8 de octubre, la BBC dijo que el grupo, que se hace llamar Xuanye, afirmaba haber pasado por Simon AI, una plataforma de marketing agéntico que, según BankInfoSecurity, ASOS usa sobre su instancia de Snowflake. Una muestra que el grupo envió a la BBC contenía nombres, direcciones, números de teléfono, correos electrónicos, números de cliente, fechas de nacimiento y búsquedas hechas en el sitio, con términos como "glamorous wide fit", según la BBC. Eso va más allá de los "datos de contacto básicos" a los que ASOS había dicho al principio que se podría haber accedido. A Simon AI, adquirida por Monetate en julio, se le había pedido un comentario.

El investigador de seguridad Kevin Beaumont escribió en Mastodon el 8 de octubre que Simon AI no exige autenticación multifactor para las cuentas, que no viene activada por defecto, y que "esta fue la vía de entrada a ASOS". Ni ASOS ni Monetate lo han confirmado. Group-IB, por su parte, dijo a Infosecurity Magazine que el canal de Telegram de la notificación se creó el 6 de octubre, por una cuenta que antes había usado nombres ligados al comercio de objetos de videojuegos.

Así que el punto de entrada está confirmado con las palabras de la propia ASOS. La plataforma, no.

El remitente es más amplio que el proveedor de push

En la mayoría de las apps, el código que recibe un push vive en la app, y el que lo envía vive en otro sitio. Los equipos de marketing necesitan enviar sin esperar a una versión, así que las credenciales de envío van a una plataforma de engagement de clientes y, mediante integraciones, a otras herramientas que pueden disparar un envío.

Un caso de estudio sin fecha en el sitio de Simon AI describe exactamente eso en ASOS: "Simon permitió a ASOS disparar notificaciones push en respuesta a la actividad de un comprador dentro de la app." Malwarebytes señala que ASOS ha descrito usar Simon AI junto con Braze, una plataforma de engagement de clientes, para disparar mensajes como notificaciones push. Ninguno de los reportes que leí vincula a Braze con el incidente.

Esa es la lección que me llevo, diga lo que diga el informe final. Cualquier herramienta que pueda disparar un envío es un remitente, sea cual sea su categoría en la factura. Una herramienta de marketing con una integración de "disparar push" tiene el mismo alcance sobre la pantalla de bloqueo de tus usuarios que tu propio backend. Y sus accesos suelen estar en manos del equipo de marketing, fuera de los controles que el equipo de ingeniería aplica a producción.

La pantalla de bloqueo es un megáfono

Lo otro que me llamó la atención es a quién iba dirigido el mensaje. Iba dirigido al delegado de protección de datos y al equipo de TI de ASOS. Los clientes eran la audiencia, no el objetivo. Camellia Chan, CEO de X-Phy, lo expresó así a Computer Weekly: "No se quedó en una bandeja de entrada esperando a ser leída; iluminó las pantallas de bloqueo de los usuarios de la app, con el nombre de Asos, antes de que la propia empresa hubiera publicado una declaración."

Una nota de rescate en un sitio de filtraciones necesita que alguien la repita. Una nota de rescate en los teléfonos de los clientes se repite sola. Las acciones cayeron más de un 10 % en la sesión de un día en que la propia ASOS solo podía decir a qué "se podría haber accedido". El daño llegó por el canal antes de que nadie supiera el tamaño de los datos. Y la página de ayuda de ASOS responde ahora a una pregunta que ningún minorista quiere en sus preguntas frecuentes: "¿Es seguro abrir las notificaciones push de ASOS?"

Las claves detrás de un push de iOS

Por el lado de Apple, la documentación es corta y merece releerse. Una sola clave de firma de APNs puede autenticar tokens para varias apps. "Funciona tanto en los entornos de desarrollo como de producción" y "no caduca, pero puede revocarse". Al crear una clave, eliges su configuración de entorno y si es Team Scoped (a nivel de equipo) o Topic Specific (limitada a los topics que selecciones). Solo el titular de la cuenta o un administrador puede gestionar claves. Si una clave puede estar comprometida, el procedimiento de Apple es crear una nueva, pasar a ella y luego revocar la antigua. Revocar, advierte Apple, "afecta a cualquier servicio que use la clave".

Junta esas líneas y el riesgo es evidente. Una clave de todo el equipo que nunca caduca, pegada hace años en el panel de un proveedor, es un permiso permanente para cada app del equipo hasta que alguien la revoque. Y revocarla detiene en el mismo momento todos los envíos legítimos que la usan. Rotar es una migración, no un clic.

Las plataformas de push tienen sus propios ajustes. La documentación pública de Braze, por ejemplo, permite limitar cada clave de API REST a endpoints concretos, como messages.send, y a direcciones IP autorizadas: "Si no especificas ninguna, las solicitudes pueden enviarse desde cualquier dirección IP." Los permisos y las IP autorizadas no se pueden editar después de crear la clave, así que cambiar el alcance significa emitir una clave nueva. Nada de eso ayuda cuando alguien inicia sesión con el acceso robado de un empleado, que es lo que describe ASOS. Esa parte depende de la autenticación multifactor obligatoria y de quién tiene una cuenta.

Qué revisaría antes de la próxima campaña

Esta es la lista que pasaría a cualquier app que envíe push, la mía incluida.

Primero, el inventario. Todo sistema que pueda hacer llegar un push, un correo o un SMS a todos los usuarios: el proveedor de push, la plataforma de datos de clientes, la herramienta de marketing con IA, la herramienta de automatización con un webhook. De cada uno, quién tiene acceso y si la autenticación multifactor es obligatoria, no solo ofrecida.

Segundo, el radio de impacto. Un mensaje a un segmento y un mensaje a todos no deberían requerir el mismo permiso. Si una plataforma admite un paso de aprobación, lo exigiría para los envíos a toda la audiencia.

Tercero, las claves. Cuando se pueda, una clave de APNs Topic Specific por app y por entorno, una lista escrita de cada sitio donde se pegó cada clave y una rotación ensayada una vez, y cronometrada, antes de necesitarla.

Cuarto, el toque. Lo que aparece en la pantalla de bloqueo viene del remitente. Lo que pasa cuando el usuario lo toca pasa por código que yo publico. Si una app abre cualquier URL que llegue en la carga de una notificación, un remitente secuestrado puede enviar a los usuarios a cualquier parte. Una lista de rutas y dominios propios de la app es un cambio pequeño.

Quinto, la alarma y la disculpa. Una alerta cuando un envío llegue a un número inusual de usuarios fuera de una campaña programada, y un mensaje de "por favor, ignoren esto" redactado de antemano para los canales que sigan funcionando. ASOS usó el correo y, según CPO Magazine, un aviso dentro de la app.

Para un CTO, hay una línea más. Los proveedores que auditan los clientes suelen ser los que guardan sus datos. Los que pueden hablar a tus usuarios en tu nombre merecen estar en la misma lista.

La notificación de ASOS iba dirigida a su DPO. Se lee mejor como una nota para todos los que dieron a una herramienta de marketing las llaves de la pantalla de bloqueo de sus usuarios y nunca comprobaron quién más podía iniciar sesión.

Fuentes

¿Un proyecto del mismo estilo?

Diseño y despliego productos como este. Hablemos.

Hablemos