L'URL ne fait pas le site

Le 5 décembre 2022, jscrambler, entreprise spécialisée dans la sécurité des applications javascript, a publié un article concernant une vulnérabilité sur une librairie : Cockpit. Offrant un service gratuit de marketing et d’analyse de données destiné aux sites e-commerce, cette librairie pourtant dépréciée depuis 2014, était encore utilisée par plusieurs sites. Or, son utilisation a permis à des hackers de faire du skimming, c’est-à-dire faire exécuter des scripts pour récupérer les coordonnées bancaires des utilisateurs.

Vulnérabilité

Regardons d'abord comment fonctionne cette librairie. 

La photo ci-dessous est un extrait du code :

• on commence par créer un élément script dans la page web qui inclut la librairie

• on ajoute un attribut src à cet élément qui va pointer vers l’URL de Cockpit, d’où il récupère un script qui enregistre des cookies afin de permettre de faire de l’analyse de données,

• on insère ensuite l’élément cockpit dans notre page.

Code d’intégration de la librairie cockpit sur son application

La librairie Cockpit a été dépréciée en 2014, et depuis, l’URL tracker.web-cockpit.jp n’était plus utilisée.

💡 Explication

Les hackers ont remarqué que l’URL de la librairie cockpit ne renvoyait plus rien,  pas même de code d’erreur. Ils ont alors découvert que ce nom de domaine était disponible en vente. Les attaquants l'ont donc réservé afin de renvoyer leur propre script et ainsi récupérer les informations des utilisateurs.

Afin d’avoir le script le plus adapté possible à la page web, les hackers souhaitent se baser sur l’URL du site e-commerce utilisant leur script. Pour cela, ils renvoient une réponse adaptée en fonction de la valeur dans l’en-tête referer.

Lorsque l’on essaie d’accéder à un site, on envoie une requête HTTP ou HTTPS à l’URL du site avec des en-têtes (headers) qui donnent des informations supplémentaires sur la ressource qu’on essaie de récupérer ou sur le client lui-même.

Lorsqu’on accède à un site depuis un autre site, que ce soit depuis un script ou en appuyant sur un lien sur la page web, un en-tête appelé referer est ajouté afin de donner une idée sur l’origine de la requête. Ceci permet de faire de l’analyse de données, de la journalisation etc.

En envoyant la requête à l’URL : tracker.web-cockpit.jp site e-commerce utilisant cette librairie, on a l’URL du site dans l’en-tête. Les hackers se basent sur cet en-tête pour renvoyer le code malicieux :

• pas d’en-tête referer: aucun script n'est envoyé
• referer existant mais inconnu : on reçoit un script de skimming par défaut
• referer existant et connu : on reçoit un script de skimming spécifique

Afin d’inspecter le script, on peut ouvrir la console du navigateur et taper l’URL de la librairie dépréciée. Comme on accède au site directement, et pas en cliquant sur un lien depuis un autre site, l’en-tête referer est vide (on peut le vérifier avec l’onglet "Réseau" de la console).

Cependant, on peut voir le script dans la réponse à une autre requête qui est envoyée automatiquement par le navigateur pour récupérer la favicon (l'icône affichée sur l'onglet du navigateur). Dans ce cas l’en-tête n’est pas vide, mais contient l’URL http://tracker.web-cockpit.jp/, d’où provient la requête.

Script par défaut

Dans la plupart des cas, l’URL de l’origine n’est pas reconnue. On reçoit alors un code malicieux qui vérifie si on est dans une page de paiement, récupère tout champ d’entrée utilisateur (texte, sélection etc…), puis encode et envoie les données à un serveur en Russie.

De plus, le script injecte un formulaire d’entrée de coordonnées bancaires qui renvoie les informations écrites aux hackers :

Script spécifique

Afin de rendre la détection du code malicieux plus difficile, les hackers renvoient dans quelques cas un script qui ressemble au code d’intégration de google analytics dans son application.

Cette version du script peut changer en fonction du site e-commerce. D’après jscrambler, il y aurait au moins 3 versions, avec des différences mineures. Comme le script par défaut, ces versions enregistrent toujours les informations de la carte bancaire dans un cookie qui est alors encodé puis envoyé au même serveur.

Sites impactés

Les équipes de Jscrambler ont contacté 40 sites e-commerce concernés, la plupart ont supprimé cette dépendance vulnérable rapidement. Cependant, certains n’ont toujours pas fait cette mise à jour.

Les administrateurs d’un site e-commerce ont mis une notice afin d’alerter les utilisateurs que le site est vulnérable sans supprimer la libraire.

Il est possible que leur site soit généré depuis un CMS que les administrateurs n’ont pas pu modifier.

Comment se protéger

• Prendre en compte les conséquences de la dépréciation possible d'une librairie au moment de choisir de l'utiliser
• Être notamment vigilant quand une librairie va récupérer du script sur un domaine qu'on ne contrôle pas : rien ne garantit que ce domaine existera pour toujours
• En plus de l'attribut "src", les balises "script" possèdent un attribut integrity, qui permet d'indiquer le hash attendu du code. Si le code est modifié, le hash ne correspond plus, et le navigateur refuse d'exécuter le script. Dans l'attaque ici, le code renvoyé par les attaquants ne serait donc jamais exécuté.

Pour aller plus loin

• L'article original de jscrambler

Nous avons pour ambition de sécuriser le web, et pour atteindre cet objectif, nous avons besoin de vous ! Si vous avez des questions, des suggestions ou le moindre doute, n'hésitez pas à contacter notre équipe sécurité security@theodo.fr.