Les listes de filtres Adblock Plus peuvent exécuter du code arbitraire dans les pages Web

L'éditeur retire l'option de filtre $rewrite par précaution

Les listes de filtres Adblock Plus peuvent exécuter du code arbitraire dans les pages Web,
l'éditeur décide de retirer l'option de filtre $rewrite par précaution

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.


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:
[LIST][*]Installez soit Adblock Plus, AdBlock ou uBlock dans un nouveau profil de navigateur[*]Visitez les options de l[/*]...