A new version of Adblock Plus was released on July 17, 2018. Version 3.2 introduced a new filter option for rewriting requests. A day later AdBlock followed suit and released support for the new filter option. uBlock, being owned by AdBlock, also implemented the feature.
Under certain conditions the $rewrite filter option enables filter list maintainers to inject arbitrary code in web pages.
The affected extensions have more than 100 million active users, and the feature is trivial to exploit in order to attack any sufficiently complex web service, including Google services, while attacks are difficult to detect and are deployable in all major browsers.
Considering the nature and implications of the uncovered vulnerabilities, and given that filter lists have been employed in the past for politically motivated attacks, details of the exploit chain are publicly disclosed to ensure the fastest possible propagation of upcoming mitigations in the affected browser extensions and web services.
The $rewrite filter option is used by some ad blockers to remove tracking data and block ads by redirecting requests. The option allows rewrites only within the same origin, and requests of SCRIPT, SUBDOCUMENT, OBJECT and OBJECT_SUBREQUEST types are not processed.
However, web services can be exploited with the help of this filter option when they use XMLHttpRequest or Fetch to download code snippets for execution, while allowing requests to arbitrary origins and hosting a server-side open redirect.
Extensions periodically update filters at intervals determined by filter list operators. Attacks are difficult to detect because the operator may set a short expiration time for the malicious filter list, which is then replaced with a benign one. Organizations and individuals may be targeted based on the IP addresses from which the updates are requested.
The following criteria must be met for a web service to be exploitable using this method:
The page must load a JS string using XMLHttpRequest or Fetch and execute the returned code
The page must not restrict origins from which it can fetch using Content Security Policy directives, or it must not validate the final request URL before executing the downloaded code
The origin of the fetched code must have a server-side open redirect or it must host arbitrary user content
Filter list operators may deliver a rule update such as this:
The above rule redirects the target request to Google’s I’m Feeling Lucky search service, which then redirects to a page with the payload: alert(document.domain).
Steps for running arbitrary code on Google Maps:
Install either Adblock Plus, AdBlock or uBlock in a new browser profile
Visit the options of the extension and add the example filter list, this step is meant to simulate a malicious update to a default filter list
Navigate to Google Maps
An alert with “www.google.com” should pop up after a couple of seconds
Gmail and Google Images also meet the listed conditions to be exploitable.
Google has been notified about the exploit, but the report was closed as “Intended Behavior”, since they consider the potential security issue to be present solely in the mentioned browser extensions. This is an unfortunate conclusion, because the exploit is composed of a set of browser extension and web service vulnerabilities that have been chained together.
Please note that the vulnerability is not limited to Google services, other web services could be affected as well.
Apr 15, 2019
We have received a reply from AdBlock Plus.
We are already working on eliminating any risk for our users – find our full statement here: https://t.co/Kcl0sIbPV4
— Adblock Plus (@AdblockPlus) April 15, 2019
We will keep you updated on any new releases on https://twitter.com/zxer197
Support ls /blog