Une vulnérabilité dans les filtres AdBlock et uBlock permet d'exécuter du code arbitraire côté utilisateur

Dans un certain nombre de conditions, l'option de filtre $rewrite , implémentée dans AdBlock, AdBlock Plus et uBlock avec la mise à jour 3.2 du 17 juillet 2018 , permet l'exécution de code arbitraire sur une page Web affichée à un utilisateur, rapporte le blog armin.dev .

Voici comment la fonction problème est décrite dans le correctif AdBlock lui-même:
Ce correctif implémente la nouvelle option de filtre $rewrite , qui permet aux auteurs de listes de filtres d'empêcher l'affichage (principalement vidéo) de publicités qui auparavant ne pouvaient pas être bloquées sur un certain nombre de sites Web.
La vulnérabilité décrite affecte les trois bloqueurs de publicités mentionnés, dont l'audience totale dépasse 100 millions d'utilisateurs. Vous pouvez l'utiliser pour attaquer n'importe quel service Web, y compris, mais sans s'y limiter, par exemple, n'importe laquelle des ressources de Google. Le problème est répandu, c'est-à-dire qu'une attaque avec le même succès peut être effectuée sur n'importe quel navigateur populaire et ne dépend pas de sa version.

La vulnérabilité a duré près de 9 mois et n'a été trouvée que maintenant.

Essence de l'attaque


Le blogueur source explique que l'option $rewrite est utilisée par AdBlock et les autres bloqueurs mentionnés pour éviter de suivre l'utilisateur et de bloquer les publicités en redirigeant les demandes depuis la page Web visitée. Ainsi, $rewrite vous permet de rediriger et non de traiter des requêtes comme SCRIPT , SUBDOCUMENT , OBJECT et OBJECT_SUBREQUEST .

Une attaque peut se produire si le site Web utilise XMLHttpRequest ou Fetch pour télécharger et exécuter des extraits de code, tout en autorisant des requêtes arbitraires.

Autrement dit, pour mener une attaque, trois conditions doivent être remplies:

  1. La page Web doit charger la chaîne JS à l'aide de XMLHttpRequest ou Fetch et exécuter le code renvoyé.
  2. La page Web ne doit pas utiliser les directives de validation de la politique de sécurité du contenu et ne doit pas vérifier l'URL finale avant d'exécuter le code téléchargé.
  3. La source du code extrait doit prendre en charge une redirection côté serveur ou contenir du contenu généré par l'utilisateur arbitraire.

Il semblerait qu'il y ait beaucoup de conditions, et CSP est loin d'être une nouveauté dans le monde du développement web. Cependant, la principale menace à la vulnérabilité trouvée n'est pas la façon dont elle fonctionne, mais la façon dont elle se propage.

Étant donné que les systèmes de filtrage AdBlock, AdBlock Plus et uBlock sont vulnérables, le moyen d '«infecter» la victime finale est extrêmement simple - grâce au système de mise à jour automatique des filtres. Ce n'est un secret pour personne qu'une grande partie des utilisateurs utilisent des filtres prêts à l'emploi, mais ne les configurent pas eux-mêmes. Dans ce cas, l'auteur du package de filtrage peut déployer une mise à jour malveillante, effectuer une attaque, puis «rouler» le package et ainsi «balayer les pistes».

Façons de se battre


Le moyen le plus simple de vous protéger contre la vulnérabilité mentionnée est de passer à uBlock Origin. Ce bloqueur de publicités ne prend pas en charge la fonction $rewrite , c'est-à-dire qu'il est impossible de mettre en œuvre l'attaque décrite par son intermédiaire.

Sinon, à vos risques et périls, vous devez attendre la prochaine mise à jour d'AdBlock. Littéralement quelques heures après la publication sur le blog armin.dev, cette entrée de blog est apparue dans le blog de blocage officiel en réponse à la vulnérabilité de $rewrite .

Dans ce document, l'administration AdBlock assure que même si la vulnérabilité est spécifique, ils sont extrêmement prudents quant à la sécurité de leur public et dans la prochaine mise à jour, la fonction $rewrite sera supprimée d'AdBlock.

De plus, selon les assurances de l'administration, ils vérifient toutes les listes de filtres et les revérifient maintenant. Sur la base des résultats de l'audit, l'administration indique qu'aucune des listes de filtres existantes ne décrit la méthode d'attaque de l'utilisateur contenue. Étant donné que seulement quatre heures environ se sont écoulées entre le moment où le message d'origine a été publié et la réponse au blog AdBlock, nous ne nous réjouissons que de la réactivité de l'équipe de bloqueurs.

Dans le même temps, la suppression de la fonction $rewrite rewrite du projet est un pas en arrière pour AbBlock, car il a été créé à l'origine pour lutter contre les publicités vidéo contextuelles. Maintenant, elle reviendra pour la sécurité universelle. De plus, la vitesse avec laquelle il a été décidé de supprimer complètement $rewrite du projet montre que bien que l'attaque soit spécifique, les conséquences de sa conduite de masse sont trop étranges.

Source: https://habr.com/ru/post/fr448302/


All Articles