En février 2018, plus de 4 000 sites web, y compris des organismes gouvernementaux de premier plan comme le Bureau du Commissaire à l'information (ICO) du Royaume-Uni, ont été victimes de l'attaque BrowseAloud. Il ne s'agissait pas simplement d'une autre violation de cybersécurité ; c'était un rappel puissant des dangers cachés des scripts tiers dans nos écosystèmes numériques de plus en plus interconnectés.
Que s'est-il passé lors de l'attaque BrowseAloud ?
Un service tiers apparemment inoffensif appelé BrowseAloud, qui aide les sites web à améliorer l'accessibilité en convertissant le texte en parole, a été compromis. Des acteurs malveillants ont injecté le script de minage de cryptomonnaie CoinHive dans le code de BrowseAloud. Ce script a ensuite été exécuté involontairement par les navigateurs de milliers de visiteurs sur divers sites web, utilisant leurs appareils pour miner de la cryptomonnaie sans consentement.
Le minage de cryptomonnaie implique le processus de résolution de problèmes mathématiques complexes pour valider les transactions sur la blockchain, une tâche qui nécessite traditionnellement des ressources informatiques substantielles. Cependant, avec l'avènement de scripts comme CoinHive, ce processus a été introduit dans les navigateurs d'utilisateurs sans méfiance. Voici comment cela fonctionne :
- Exécution JavaScript : CoinHive et les scripts similaires sont écrits en JavaScript, qui peut être exécuté dans n'importe quel navigateur web standard. Cela rend leur déploiement à grande échelle incroyablement facile. C'est probablement l'aspect le plus important des attaques de la chaîne d'approvisionnement web et ce que cside sécurise.
- Utilisation non consensuelle des ressources : Contrairement au minage typique qui nécessite un consentement explicite et du matériel dédié, le minage basé sur le navigateur utilise les ressources CPU de tout visiteur d'un site infecté. Le script s'exécute tant que la page web est ouverte, le rendant moins perceptible mais potentiellement nuisible aux appareils des utilisateurs en raison d'une consommation d'énergie accrue et de l'usure.
- Rentabilité pour les attaquants : Chaque appareil détourné contribue une petite quantité de puissance de minage. Cependant, lorsqu'elle est mise à l'échelle sur des milliers d'appareils, cela peut générer une quantité significative de cryptomonnaie pour les attaquants.
L'impact de cette attaque
Cette attaque a touché plus de 4 000 sites web, y compris des sites gouvernementaux et éducatifs, exposant des milliers d'utilisateurs au cryptojacking à leur insu. Aucune donnée personnelle n'a été volée, mais les implications étaient néanmoins significatives. Les sites web ont dû être mis hors ligne, causant des interruptions de service et des dommages à la réputation. Les attaquants ont exploité une pratique courante mais risquée : l'acceptation automatique des mises à jour de scripts tiers. Cet incident a mis en évidence le besoin d'une surveillance et d'une gestion rigoureuses des composants tiers, que de nombreuses organisations avaient négligées.
C'est ce contre quoi cside protège, à la fois en surveillant le changement et la possibilité de prendre des mesures de manière autonome pour empêcher le code malveillant d'être chargé dans le navigateur de l'utilisateur.
En d'autres termes, cela ne se serait très probablement pas produit si cside avait existé et été déployé à l'époque. Vous pouvez commencer avec cside pour vous protéger contre tout type d'attaque de script tiers gratuitement.
Qu'est-il arrivé à BrowseAloud après ?
Après l'attaque de cryptojacking, la société mère de BrowseAloud, Texthelp, a pris des mesures immédiates en mettant temporairement le service hors ligne pour atténuer le problème et effectuer un examen de sécurité approfondi. L'incident a conduit à une sensibilisation accrue concernant la sécurité des services tiers et la nécessité d'une vigilance continue et d'audits de sécurité réguliers.
BrowseAloud est revenu en ligne avec des mesures de sécurité renforcées et un engagement à prévenir de tels incidents à l'avenir. L'attaque a également déclenché une discussion plus large parmi les fournisseurs de services web sur l'importance de sécuriser et de surveiller rigoureusement les scripts tiers.
Le destin de CoinHive
CoinHive, en revanche, a connu une trajectoire différente. Initialement lancé comme un outil légitime pour monétiser le contenu des sites web sans publicités en utilisant la puissance CPU des visiteurs pour miner de la cryptomonnaie, CoinHive est rapidement devenu associé au cryptojacking non autorisé. La connotation négative et l'utilisation abusive du script dans diverses attaques malveillantes ont conduit à un examen minutieux important.
La viabilité du service a été davantage remise en question par la baisse de la valeur du Monero et la difficulté croissante à le miner de manière rentable. Par conséquent, CoinHive a annoncé sa fermeture en mars 2019, citant l'inviabilité économique comme raison principale de sa fermeture.
Le domaine CoinHive.com appartient maintenant à l'expert du secteur Troy Hunt. Il est sûr et héberge son point de vue sur la protection contre des attaques similaires et le cryptojacking en général.
Similaire à la façon dont nous possédons maintenant le domaine Baways.com et l'avons transformé en un site web éducatif.
L'utilisation d'anciens domaines précédemment utilisés comme ceux-ci peut causer d'autres problèmes, comme Troy Hunt l'a récemment expérimenté.
Email amusant / stupide / idiot du jour :
gère un service pour suivre les instances d'images protégées par le droit d'auteur utilisées sans licence. En mars, ils m'ont envoyé plusieurs emails exigeant de l'argent pour violation du droit d'auteur. Aujourd'hui, j'en ai reçu un autre demandant plusieurs centaines d'euros :
— Troy Hunt (@troyhunt)
Maintenant, revenons à ses recommandations sur le sujet, son approche implique l'utilisation de CSP pour faire en sorte que les navigateurs ignorent toute commande provenant de tout domaine qui n'est pas explicitement autorisé. Dans son cas, après avoir sécurisé le domaine CoinHive, il a mis en œuvre une CSP qui garantit que même si des scripts malveillants sont injectés, ils ne seraient pas exécutés car ils ne proviendraient pas d'une liste de domaines autorisés.
À notre avis, cette approche est bonne, mais pas suffisante. En bref, les CSP ne devraient pas être la seule mesure de sécurité contre les attaques JavaScript tierces. Notre page de comparaison donne un excellent aperçu des fonctionnalités que nous avons mises en œuvre en plus des CSP pour fournir la meilleure sécurité possible concernant les violations de scripts tiers.
Nous pensons que la clé réside dans l'analyse de l'intégralité du script avant qu'il n'atteigne le navigateur de l'utilisateur. Naturellement, cela présente quelques défis, pour lesquels nous avons conçu des solutions. Vous pouvez en savoir plus sur ce point de vue et sur la façon dont nous sécurisons les scripts tiers ici.
