AdBlock, AdBlock Plus and uBlock Exploitable in a Trivial Attack
NEWS

AdBlock, AdBlock Plus and uBlock Exploitable in a Trivial Attack

AdBlock Plus image

If you use AdBlock, AdBlock Plus or uBlock, you should be aware that a security researcher discovered a vulnerability in their filter systems.




The loophole may allow remote attackers to inject arbitrary code into web pages. The discovery was made by security researcher Armin Sebastian.

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, explained Sebastian.

AdBlock, AdBlock Plus or uBlock Exploit Explained

What is the vulnerability about? The vulnerability is found in version 3.2 of the Adblock Plus software which last year introduced a new filter option for rewriting requests. It appears that, under specific conditions, the $rewrite filter option enables filter list maintainers to inject arbitrary code in web pages. The problem is not only that the extensions have more than 100 million active users but also that the issue is trivial to exploit.

As explained by the researcher himself, 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.

Furthermore, because extensions periodically update filters at intervals determined by filter list operators, attacks can be difficult to detect. The operator may set a short expiration time for the malicious filter list, which will then replaced with a benign one. In addition, both organizations and individuals can be targeted based on the IP addresses from which the updates are requested.

Related:
Microsoft has declined to patch a zero-day vulnerability in Internet Explorer for which a security researcher published details and proof-of-concept.
Microsoft Refuses to Patch Zero-Day Exploit in Internet Explorer.

There are several conditions that should be met for a web service to be exploited via the vulnerability in AdBlock. For example, the page must load a JS string using XMLHttpRequest or Fetch and execute the returned code. Furthermore, the page shouldn’t restrict origins that it can fetch using Content Security Policy directives, or it must not validate the final request URL before executing the downloaded code.

And lastly, the origin of the fetched code must have a server-side open redirect or it must host arbitrary user content. If these are met, an attack is possible.

To test the vulnerability and see how it can be exploited, the researcher used Google Maps. Because the service met the criteria explained above, Sebastian successfully wrote exploit code.

The steps he utilized are the following:

– 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 respond to the conditions and are exploitable via the vulnerability.

The researcher contacted Google to notify them about the exploit, but the report was closed as “Intended Behavior”. It turns out that Google considers that the vulnerability is present solely in the 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,” the researcher noted, adding that Google’s services are not the only ones that can be affected.

What about AdBlock? According to AdBlock Plus’ official statement, despite the actual risk being very low, the company has decided to remove the rewrite option and will accordingly release an updated version of Adblock Plus as soon as technically possible. The company also said they’re doing this as a measure of precaution.

The good news is that there has not been any attempt of abusing the rewrite option. As for mitigation, whitelisting known origins using the connect-src CSP header, or eliminating server-side open redirects should do the work.

Milena Dimitrova

An inspired writer and content manager who has been with SensorsTechForum for 4 years. Enjoys ‘Mr. Robot’ and fears ‘1984’. Focused on user privacy and malware development, she strongly believes in a world where cybersecurity plays a central role. If common sense makes no sense, she will be there to take notes. Those notes may later turn into articles!

More Posts

Leave a Comment

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

Time limit is exhausted. Please reload CAPTCHA.

Share on Facebook Share
Loading...
Share on Twitter Tweet
Loading...
Share on Google Plus Share
Loading...
Share on Linkedin Share
Loading...
Share on Digg Share
Share on Reddit Share
Loading...
Share on Stumbleupon Share
Loading...