A vulnerability in Adblock Plus lists allows malicious code to be executed

browser

Recientemente a vulnerability has been discovered which could allow maintainers to block filter lists for Adblock Plus, AdBlock and uBlocker browser extensions to create filters that inject remote scripts into websites.

With a user base that has crossed the 10 million mark, if malicious scripts were injected into ad blockers, this would have a considerable impact Because they could perform unwanted activities, such as theft of cookies, connection information, causing page redirects or other unwanted behavior.

For those who are not familiar with ad blockers, they basically use URL lists related to malicious ads and behavior.

Generally, They are run by a small team of people or even a single person.

When these lists are loaded with an ad blocking extension such as Adblock Plus, this extension will prevent the browser from connecting to the URLs put in the list and thus this prevents connection to malicious ads or scripts.

The $ rewrite filter option is causing the problem

When AdblockerPlus 3.2 launched in 2018, it added a new filter list option, called $ rewrite.

This option allowed to a list maintainer replace a web request that matches a regular expression in particular with another URL.

Hubert Figuiere, who introduced this function, explained that:

“Since Adblock Plus 3.2 for Chrome, Firefox and Opera (and development versions of 3.1.0.2053), a new filter option $ rewrite allows you to rewrite the URL of a resource instead of blocking it.

When Adblock Plus assigns a request URL to a filter with the $ rewrite option, it transforms the URL based on the provided rule and tells the browser to load the resource at the same time.

The syntax of the $ rule rewrite specifies a string that serves as a template for the new URL.

$ n is replaced by the filter's regular expression n-th sub-match. This is the same syntax as the JavaScript String.prototype.replace () function.

If the resulting URL is relative (i.e. you don't have a host), the origin of the original query will be used as the basis. In either case, if the new URL does not share the origin, the rewrite will be considered as failed and the initial request will pass.

Also, $ rewrite filters are ignored for SCRIPT, SUBDOCUMENT, OBJECT and OBJECT_SUBREQUEST queries for security reasons. This option is convenient for modifying or eliminating query parameters ».

The only downside is that the replacement string must be a relative URL, which means that it does not contain a hostname and, when rewritten, it must belong to the same originating domain as the request.

Code execution is even done on google maps

A security researcher explained that:

Under certain conditions, it is possible for an unauthorized malicious filter maintainer to create a rule that injects a remote script into a particular site.

To do this, just look for a site that loads scripts from any domain that contains an open redirect and use XMLHttpRequest or Fetch to download the scripts to run.

It wasn't too hard to find because to do this alone just use Google Maps as proof of concept.

The researcher explained that the following criteria must be met so that a web service can be exploited with this method:

  • The page must load a JS string using XMLHttpRequest or Fetch and execute the return code.
  • The page should not restrict the sources from which it can be retrieved using content security policy guidelines, or validate the final request URL before running the downloaded code.
  • The source of the retrieved code must have an open server-side redirect or arbitrary user content from the host.

Using XMLHttpRequest or Fetch to download scripts and open the redirect are the two keys to the problem.

To mitigate this problem, it is recommended that websites use the content security policy header and connect-src option to specify a whitelist of sites from which scripts can be loaded.


Be the first to comment

Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.