Des clés d'administration dans le frontend : la fuite de données de Manchester Airports Group
La semaine dernière, Manchester Airports Group a révélé que des attaquants avaient compromis des systèmes contenant des données de parkings, de salons, de réservations Fast Track et d’inscriptions au Wi-Fi des terminaux dans les aéroports de Manchester, Londres Stansted et East Midlands. Le 3 septembre, le groupe d’extorsion a publié environ 550 Go de données après que MAG a refusé de payer. Les données exposées concernent environ 8,8 millions de personnes et incluent adresses e-mail, numéros de téléphone, immatriculations de véhicules et codes postaux. L’exploitation aéroportuaire n’a pas été affectée.
Les attaquants affirment avoir utilisé des clés administratives d’une plateforme marketing tierce, exposées dans du JavaScript côté client. MAG a confirmé que les données se trouvaient dans une base hébergée par un tiers et enquête sur la manière dont les clés ont été exposées. Cette méthode repose sur la parole de l’attaquant plutôt que sur une conclusion réglementaire, mais l’affirmation est précise et plausible.
Une défaillance qui n’avait rien de sophistiqué
Le JavaScript côté client est public par définition. Le navigateur de chaque visiteur le télécharge, et le lire ne demande rien de plus que la console de développement intégrée à ce navigateur. Un identifiant placé là n’est pas caché, il est publié.
Il s’agit d’un schéma récurrent, pas d’un écart inhabituel. Les plateformes marketing, les outils d’analyse et les intégrations de réservation sont mis en place sous pression temporelle par des équipes dont la mission est la conversion, pas la sécurité. Une clé se retrouve collée dans un script frontend parce que c’est le moyen le plus rapide de le faire fonctionner — et cela fonctionne parfaitement, ce qui explique que personne ne la revoie jamais. La conséquence est une compromission qui se situe entièrement en dehors du périmètre que la plupart des organisations consacrent leur budget à défendre. Aucun pare-feu ni agent de poste de travail n’était pertinent ici. L’identifiant était en vitrine.
Refuser de payer était le bon choix, et cela a quand même fait mal
MAG n’a pas payé, et l’exploitation s’est poursuivie sans interruption. C’était la bonne décision, et elle a privé le groupe de ses revenus.
Mais publier les données était en soi le message. Diffuser gratuitement neuf millions d’enregistrements n’est pas seulement une représaille contre une victime, c’est une démonstration adressée à toute organisation qui observe. Ce sont les clients, qui n’ont pris part à aucune décision, qui en subissent les conséquences.
La leçon pour les organisations plus petites est qu’une décision de rançon n’équivaut pas à un plan de gestion d’incident. MAG a pu refuser parce que seules des données étaient en jeu, jamais l’exploitation. Une entreprise confrontée à un chiffrement opérationnel se trouve dans une situation différente, et le moment pour déterminer dans laquelle vous seriez se situe avant qu’elle ne survienne.
Par où commencer
Commencez par l’exposition qu’avait MAG. Ouvrez votre propre site, consultez le code source de la page et les scripts chargés, et recherchez tout ce qui ressemble à une clé, un jeton ou un secret. Cela prend une heure et vous montre exactement ce qu’un attaquant voit. Tout élément trouvé doit être changé, pas simplement supprimé.
Étendez cela aux plateformes derrière ces scripts. L’automatisation marketing, les systèmes de réservation et les outils d’analyse accumulent discrètement des données personnelles et apparaissent rarement dans l’inventaire censé indiquer où résident les données clients. Déterminez quels tiers détiennent les données de vos clients, quels champs, et pour combien de temps. Des données supprimées selon un calendrier ne peuvent pas fuiter.
Lorsque des intégrations nécessitent des identifiants, limitez-les à la fonction minimale et conservez-les côté serveur. Une clé permettant un export en masse ne devrait jamais être accessible depuis un navigateur, et la plupart des intégrations frontend n’en ont de toute façon pas besoin.
Enfin, définissez à l’avance, au niveau du conseil, votre position face à l’extorsion : qui décide, quelles sont les obligations réglementaires, et ce que vous diriez à vos clients. Le refus de MAG a semblé net parce que les enjeux opérationnels étaient faibles. Cette clarté est bien plus difficile à atteindre à trois heures du matin, systèmes chiffrés.
Message clé : Des attaquants auraient atteint 8,8 millions d’enregistrements clients grâce à des clés administratives visibles dans le JavaScript d’un site, et publié 550 Go après le refus de la rançon. Aucun périmètre n’a dû être franchi, car l’identifiant était déjà public. Auditez votre frontend à la recherche de secrets exposés, cartographiez les prestataires tiers qui détiennent les données de vos clients, et définissez votre position face à l’extorsion avant d’en avoir besoin.
