British Airways : l’on connait désormais le coût de la cécité sur les actifs web !

Ne pas surveiller efficacement ses actifs web peut conduire à voir ses sites infectés... même sans être compromis ! La compagnie aérienne British Airways en a fait l'amère expérience. Ainsi que 380 000 de ses utilisateurs. Cela lui a coûté 200 millions d'euros.

« Dura lex, sed lex« . Pour British Airways, la loi en question, c’est le règlement européen sur la protection des données à caractère personnel (RGPD). Et elle est dure, en effet : le Britannique vient d’être condamné par l’Information Commissioner’s Office (l’équivalent britannique de notre CNIL) à verser une amende de 183 millions de livres, soit 1,5% de son chiffre d’affaires mondial, après qu’un demi-million de clients de la compagnie aérienne se soient fait aspirer leurs données personnelles en visitant le site web officiel.

L’un des points intéressants dans cette affaire est qu’elle illustre toute la difficulté (et la nécessité) de maintenir un niveau de visibilité adéquat sur les actifs web, et en particulier leur intégrité.

British Airways a été victime de MageCart, une série d’attaques qui a fait de très nombreuses victimes parmi les sites web de grands comptes (British Airways, mais aussi TicketMaster, Fila, et bien d’autres) comme de plus petits e-commerçants (vraiment beaucoup…)

L’approche des attaquants qui exploitent MageCart est souvent très futée, souvent personnalisée (une vague d’attaques automatiques vient d’être détectée, cependant) et en tout cas généralement très efficace. Mais toutes ces attaques ont un point commun : elles modifient les pages web de leur victime pour leur faire récupérer l’information nécessaire (quitte à ajouter des champs aux formulaires, par exemple pour demander des informations de paiement qui n’apparaissent pas sur le formulaire original – voir la capture ci-dessous, fournie par Malwarebytes) et les renvoyer vers un site contrôlé par l’attaquant. Celui-ci est le plus souvent hébergé sur un domaine proche de celui de la victime et enregistré pour l’occasion (dans le cas de British Airways il s’agissait du domaine baways.com, mais l’on a pu voir dans le cadre d’une autre affaire un compte Github créé au nom de la victime de manière à disposer d’une URL telle que victime.github.com).

Un formulaire web avant et après l'ajout du skimmer Javascript (source : Malwarebytes)

Cela est réalisé en injectant un code Javascript malveillant au code source légitime de la page (un « skimmer » Javascript, nommé d’après les outils destinés à voler les informations des pistes magnétiques sur les cartes bancaires).

Ce skimmer Javascript prend la forme de quelques lignes de code (22 exactement dans le cas de British Airways) qui sont le plus souvent ajoutées à une bibliothèque Javascript existante qui est, elle, intégrée à chaque appel de la page web légitime, souvent pour apporter des fonctionnalités tierces.

Le danger des dépendances web

Cette bibliothèque de code peut être hébergée localement, ou encore sur un autre serveur appartenant à la victime (il lui incombe alors de protéger ce dernier correctement afin d’éviter toute modification du code). Mais elle peut aussi, très souvent, être appelée depuis le réseau d’un fournisseur de contenu (un CDN par exemple) ou le site du fournisseur de la bibliothèque.

Et c’est là que le bât blesse : il peut s’agir alors d’un petit fournisseur, voire d’un développeur indépendant. Et à la manière d’un OpenSSL utilisé par le tout-internet et dont on a appris après une faille majeure que la Fondation peinait à financer un simple ETP supplémentaire, il peut se créer un delta important entre le profil du site client (British Airways, par exemple) et les moyens mis en oeuvre par un petit fournisseur pour sécuriser son infrastructure.

Bref, nous sommes dans le cas d’école d’une attaque de type « chaine de fournisseurs », sauf qu’ici le passage à l’acte est extrêmement simple et peu coûteux, et les victimes généralement aveugles.

Une solution simple ? Oui, mais…

Techniquement, la solution semble évidente : il suffirait, par exemple, de prendre une empreinte cryptographique des bibliothèques intégrées à ses pages web et de les appeler à intervalle régulier afin d’en identifier toute modification (et en se basant également sur les en-têtes « Last Modified« ). Un simple robot indexeur et quelques scripts suffisent probablement (je ne serais d’ailleurs pas étonné qu’un tel service existe déjà, et si ce n’est pas le cas, quelques lignes de Python ou de Go suffisent probablement ! Cela ferait même un très bon « projet perso » pour les weekends à venir…).

Seulement voilà : à l’échelle d’un British Airways, la tâche devient autrement plus complexe. Car pour bon nombre de grands acteurs, c’est faire l’inventaire même de leurs actifs web qui pose un problème ! Alors si l’on doit en plus en suivre les moindres modifications des bibliothèques tierces… (des bibliothèques qui n’apparaissent d’ailleurs que rarement dans l’inventaire, car leur intégration est jugée « standard » par les développeurs – souvent externalisés – et le client ne regarde de toute manière pas forcément sous le capot…). Et puis à qui remonter ces alertes ? Comment éviter les (probablement nombreux) faux positifs ? Comment organiser les circuits d’approbation des modifications ? Qui est responsable ?

Bref, pour un groupe international, déjà en situation de difficulté pour connaître tous ses actifs web, et dont les sites, landing pages et autres micro-sites sont développés par une armée de développeurs indépendants ou de studio plus marketing que techniques, c’est probablement mission impossible.

Alors que faire ? Je n’ai pas de solution miracle, mais un début de réponse passera certainement par de l’organisationnel avant la technique. Parmi les parades déjà mises en oeuvre par certains groupes, on peut citer « l’adoubement » d’un nombre restreint d’agences de développement web, après audit et instructions de développement sécurisé. Ou l’ajout aux conditions des contrats de développement d’une clause de visibilité sur les intégrations tierces. Voire l’hébergement en propre de toutes les bibliothèques Javascript standard, après revue de code, et le recourt à une politique de sécurité du contenu (Content Security Policy, ou CSP) pour garantir que seuls les serveurs officiels sont autorisés à servir celles-ci.

Et après, peut-être, parce que ça fait très envie, de développer un petit robot en Python (ou en Go ;)).  

Lire les articles précédents :
Vers une sécurité globale : sécurité économique, sûreté et cybersécurité

Une (longue) réflexion autours du rôle de la sécurité économique et de la sûreté dans un contexte de sécurité globale...

Fermer