Andy Garcia · dev freelance
FRENES
Retour au blog
Sécurité

L'app d'ASOS a poussé « ASOS HACKED » à ses clients. ASOS dit que l'entrée était un seul compte d'employé

19 octobre 2026 8 min de lecture

Le mardi 6 octobre, les utilisateurs de l'app ASOS ont reçu une notification push venue de l'app ASOS elle-même. Son titre : « ASOS HACKED ». Son texte, cité par Malwarebytes : « Chers DPO et équipe IT d'Asos, nous avons entièrement compromis l'instance Snowflake. Engagez le contact avec nous, ou nous la divulguerons. » Elle contenait un lien vers un canal Telegram. Le communiqué d'ASOS la situe vers 10 h, et des clients en Grande-Bretagne, en Irlande, aux États-Unis et dans d'autres pays l'ont signalée, selon BankInfoSecurity.

Plus tard dans la journée, ASOS, qui annonce 16,5 millions de clients actifs, a confirmé dans un communiqué à la Bourse de Londres qu'« une notification client non autorisée a été envoyée aux clients d'ASOS ». « Nous enquêtons sur une activité non autorisée impliquant des plateformes tierces que nous utilisons pour communiquer avec nos clients », a-t-elle indiqué. « Nous avons immédiatement restreint l'accès aux plateformes de notification. » Son action a perdu plus de 10 % ce mardi-là, selon PA ; FashionUnited a évalué la baisse du matin à environ 11 %, suivie d'un rebond partiel. Le soir, ASOS a écrit à ses clients pour qu'ils « ignorent la notification et ne cliquent pas sur le lien tiers externe qu'elle contenait, ni n'interagissent avec lui ».

Le jeudi 8 octobre, ASOS a publié ce que ses 48 premières heures d'enquête avaient établi : « une partie non autorisée a obtenu l'accès à un compte d'employé d'ASOS en se faisant passer pour un contact de confiance afin d'obtenir des identifiants de connexion. Ces identifiants ont ensuite servi à accéder à des informations sur certaines plateformes tierces utilisées par ASOS ».

Le récit d'ASOS ne décrit aucune faille logicielle. Une personne a été trompée, et un identifiant capable d'atteindre les systèmes qui parlent aux clients a changé de mains.

Je livre des apps iOS en développeur indépendant, et je suis CTO d'une LegalTech. J'ai lu l'incident avec une seule question : qui, en dehors de mon propre code, peut faire parler mon app ?

Ce qui est confirmé, et ce qui est seulement revendiqué

La mise à jour d'ASOS dit que l'intrus a eu accès à « certaines informations personnelles, dont des noms et des coordonnées, et à certaines informations de compte non personnelles », et qu'aucune information de carte bancaire ni aucun mot de passe de compte n'a été consulté. Les plateformes touchées ont été « immédiatement verrouillées », et l'enquête complète « se poursuivra dans les semaines à venir ». ASOS n'a pas nommé les plateformes.

Le reste vient des attaquants ou de chercheurs. La notification accusait Snowflake. Snowflake a dit n'avoir « trouvé aucune compromission » de sa plateforme. Dans un reportage publié le 8 octobre, la BBC a écrit que le groupe, qui se fait appeler Xuanye, affirmait être passé par Simon AI, une plateforme de marketing agentique qu'ASOS utilise, selon BankInfoSecurity, par-dessus son instance Snowflake. Un échantillon envoyé par le groupe à la BBC contenait des noms, adresses, numéros de téléphone, e-mails, numéros de client, dates de naissance et recherches faites sur le site, avec des termes comme « glamorous wide fit », selon la BBC. C'est plus que les « coordonnées de base » qu'ASOS avait d'abord dit pouvoir avoir été consultées. Simon AI, rachetée par Monetate en juillet, avait été sollicitée pour un commentaire.

Le chercheur en sécurité Kevin Beaumont a écrit sur Mastodon le 8 octobre que Simon AI n'impose pas l'authentification multifacteur pour les comptes, qu'elle n'est pas activée par défaut, et que « c'était la voie d'entrée chez ASOS ». Ni ASOS ni Monetate ne l'ont confirmé. Group-IB, de son côté, a dit à Infosecurity Magazine que le canal Telegram de la notification avait été créé le 6 octobre, par un compte qui avait porté auparavant des noms liés au commerce d'objets de jeux vidéo.

Le point d'entrée est donc confirmé par ASOS elle-même. La plateforme, non.

L'expéditeur est plus large que le fournisseur de push

Dans la plupart des apps, le code qui reçoit un push vit dans l'app, et celui qui l'envoie vit ailleurs. Les équipes marketing doivent pouvoir envoyer sans attendre une mise en production : les identifiants d'envoi sont donc placés dans une plateforme d'engagement client et, via des intégrations, dans d'autres outils capables de déclencher un envoi.

Une étude de cas sans date sur le site de Simon AI décrit exactement cela chez ASOS : « Simon a permis à ASOS de déclencher des notifications push en réponse à l'activité d'un acheteur dans l'app. » Malwarebytes note qu'ASOS a décrit utiliser Simon AI avec Braze, une plateforme d'engagement client, pour déclencher des messages comme des notifications push. Aucun des articles que j'ai lus ne relie Braze à l'incident.

C'est la leçon que j'en tire, quel que soit le rapport final. Tout outil qui peut déclencher un envoi est un expéditeur, quelle que soit sa catégorie sur la facture. Un outil marketing doté d'une intégration « déclencher un push » a la même portée sur l'écran de verrouillage de tes utilisateurs que ton propre backend. Et ses accès sont généralement détenus par l'équipe marketing, en dehors des contrôles que l'équipe technique applique à la production.

L'écran de verrouillage est un mégaphone

L'autre chose qui m'a frappé, c'est à qui s'adressait le message. Il visait le délégué à la protection des données et l'équipe IT d'ASOS. Les clients étaient le public, pas la cible. Camellia Chan, CEO de X-Phy, l'a formulé ainsi à Computer Weekly : « Elle n'est pas restée dans une boîte de réception à attendre d'être lue ; elle a allumé les écrans de verrouillage des utilisateurs de l'app, sous le nom d'Asos, avant que l'entreprise n'ait elle-même publié une déclaration. »

Une demande de rançon sur un site de fuites a besoin que quelqu'un la répète. Une demande de rançon sur les téléphones des clients se répète toute seule. L'action a perdu plus de 10 % en séance un jour où ASOS ne pouvait elle-même dire que ce qui « pourrait avoir été consulté ». Le dégât est passé par le canal avant que quiconque connaisse le volume de données. Et la page d'aide d'ASOS répond maintenant à une question qu'aucun distributeur ne veut voir dans sa FAQ : « Les notifications push d'ASOS sont-elles sûres à ouvrir ? »

Les clés derrière un push iOS

Côté Apple, la documentation est courte et mérite d'être relue. Une seule clé de signature APNs peut authentifier des jetons pour plusieurs apps. Elle « fonctionne à la fois pour les environnements de développement et de production », et elle « n'expire pas, mais peut être révoquée ». Quand tu crées une clé, tu choisis sa configuration d'environnement et si elle est Team Scoped (à l'échelle de l'équipe) ou Topic Specific (limitée aux topics que tu sélectionnes). Seul le titulaire du compte ou un administrateur peut gérer les clés. Si une clé risque d'être compromise, la procédure d'Apple consiste à en créer une nouvelle, à basculer dessus, puis à révoquer l'ancienne. Révoquer, prévient Apple, « affecte tous les services qui utilisent la clé ».

Mets ces lignes bout à bout et le risque est clair. Une clé valable pour toute l'équipe, qui n'expire jamais, collée il y a des années dans le tableau de bord d'un prestataire, est une autorisation permanente pour chaque app de l'équipe jusqu'à ce que quelqu'un la révoque. Et la révoquer arrête au même moment tous les envois légitimes qui l'utilisent. Une rotation est une migration, pas un clic.

Les plateformes de push ont leurs propres réglages. La documentation publique de Braze, par exemple, permet de limiter chaque clé d'API REST à des endpoints précis, comme messages.send, et à des adresses IP autorisées : « Si vous n'en spécifiez aucune, les requêtes peuvent être envoyées depuis n'importe quelle adresse IP. » Les permissions et les IP autorisées ne se modifient pas après la création d'une clé, donc changer le périmètre revient à émettre une nouvelle clé. Rien de tout cela n'aide quand quelqu'un se connecte avec l'identifiant volé d'un employé, ce que décrit ASOS. Cette partie relève de l'authentification multifacteur imposée, et de la question de savoir qui détient un compte.

Ce que je vérifierais avant la prochaine campagne

Voici la liste que je passerais sur toute app qui envoie des push, la mienne comprise.

D'abord, l'inventaire. Tous les systèmes qui peuvent faire arriver un push, un e-mail ou un SMS à tous les utilisateurs : le fournisseur de push, la plateforme de données clients, l'outil marketing à base d'IA, l'outil d'automatisation avec un webhook. Pour chacun, qui a un accès, et si l'authentification multifacteur est imposée, pas seulement proposée.

Ensuite, le rayon d'action. Un message à un segment et un message à tout le monde ne devraient pas demander la même permission. Si une plateforme propose une étape d'approbation, je l'exigerais pour les envois à toute l'audience.

Puis les clés. Autant que possible, une clé APNs Topic Specific par app et par environnement, une liste écrite de chaque endroit où chaque clé a été collée, et une rotation répétée une fois, chronométrée, avant d'en avoir besoin.

Quatrièmement, le tap. Ce qui s'affiche sur l'écran de verrouillage vient de l'expéditeur. Ce qui se passe quand l'utilisateur touche la notification passe par du code que je livre. Si une app ouvre n'importe quelle URL reçue dans la charge utile d'une notification, un expéditeur détourné peut envoyer les utilisateurs n'importe où. Une liste d'autorisation des routes et domaines propres à l'app est un petit changement.

Cinquièmement, l'alarme et les excuses. Une alerte quand un envoi atteint un nombre inhabituel d'utilisateurs hors campagne planifiée, et un message « merci d'ignorer » rédigé à l'avance pour les canaux qui fonctionnent encore. ASOS a utilisé l'e-mail et, selon CPO Magazine, un avis dans l'app.

Pour un CTO, il y a une ligne de plus. Les prestataires que les clients auditent sont généralement ceux qui stockent leurs données. Ceux qui peuvent parler à tes utilisateurs en ton nom doivent figurer sur la même liste.

La notification d'ASOS s'adressait à son DPO. Elle se lit mieux comme une note à tous ceux qui ont donné à un outil marketing les clés de l'écran de verrouillage de leurs utilisateurs sans jamais vérifier qui d'autre pouvait s'y connecter.

Sources

Un projet du même genre ?

Je conçois et déploie des produits comme celui-ci. Parlons-en.

Discutons