Just a little FYI: Filtering doodad in Adblock Plus opens door to third-party malware injection

April 16, 2019

Just a little FYI: Filtering doodad in Adblock Plus opens door to third-party malware injection

Institute For Ethical Hacking Course and Ethical Hacking Training in Pune – India

Extreme Hacking | Sadik Shaikh | Cyber Suraksha Abhiyan

Credits: The Register

A feature introduced last year in Adblock Plus and a few other related content blocking browser extensions allows providers of filtering lists, under certain conditions, to execute arbitrary code on web pages.

Adblock Plus v3.2 for Chrome, Firefox and Opera, released in July 2018, includes support for the $rewrite filter option, which can alter filter rules governing whether or not content gets blocked. The rationale for doing so is that there may be times when it’s better to redirect a web request rather than blocking it.

The $rewrite filter provides a way to remove tracking data from URLs. One example might be avoiding Google Accelerated Mobile Pages (AMP). “We could redirect people to the non-AMP page as AMP is only meant to advertise and track not to actually make the web better,” suggested Adblock Plus developer Hubert Figuière last year.

Other content blocking extensions with confusingly similar names like AdBlock and uBlock (owned by AdBlock and not associated with uBlock Origin) are said to have also implemented the $rewrite option. With this directive, third-party maintained filter lists can selectively rewrite URL parameters.

According to Sebastian, web pages are vulnerable under specific conditions: if they load a JavaScript string via XMLHttpRequest or Fetchand execute the returned code; if they fail to limit the applicable domain origin fetched with Content Security Policy directives or URL validation; and if the origin of the fetched code has a server-side open redirect or allows the hosting of arbitrary user content.

In such a case, an untrustworthy provider of filer list data could include a malicious filter string that would execute arbitrary code.

In a blog post on Monday developer Armin Sebastian, who found the issue, said he has informed Google about the potential vulnerability but the company considers it intended behavior rather than a bug.

Adblock Plus, in a statement emailed to The Register said, “We are taking this very seriously and are currently investigating the actual risk for our users to determine the best countermeasure.”

In its statement, Adblock Plus said support for $rewrite “was added to allow filter list authors to effectively block circumvention attempts, where a website tries to force ads on visitors that use an ad blocker.”

“The new feature is a fundamental shift from how ad blockers are understood to work,” said Sebastian in a Twitter conversation with The Register.

“In the past the worst that could have happened was for a malicious filter list provider to block access to a site, which would have been a minor annoyance that is easy to spot. The $rewrite filter option, when chained with other security issues from web services, enables account takeovers and the exfiltration of private data. That is quite the leap from how users perceive ad blockers to work.”

Sebastian said he was unaware of whether anyone has been exploiting filtering lists thus, but said manipulation would be difficult to detect. “This method allows delivering payloads on a per request basis, you may be targeted, exploited and the evidence cleared from the extension storage, without needing to publish the payload as part of a public filter list,” he said.

Cause for concern

Raymond Hill, the creator of rival content blocking extension uBlock Origin, last year said he would not be implementing $rewrite because of security concerns. Specifically, he worried same-origin restrictions would not be enough because sites like GitHub can have the same origin (github.com) while giving different people control over content on different pages.

“Even with strictly same origin, a malicious filter list author could add bad stuff to a network request,” he wrote, noting that he preferred an option called querystrip that removes but does not rewrite URL query parameters.

In an email to The Register, Hill said, “The exploit requires that a filter list maintainer go rogue, an unlikely scenario, especially for prominent filter lists, i.e. those used by default by the affected blockers. Still, [Sebastian’s post] makes the case that the possibility exists and this needs to be taken into account by users according to how they personally choose to assign trust.”

Adblock Plus said $rewrite has been restricted to prevent it from executing any scripts but, despite Content Security Policy settings, “certain websites allow the interpretation of plaintext from a third party as code and execute it.”

The company said it considers exploitation unlikely (and hasn’t seen any exploitation attempts) because it vets authors who contribute to filter lists enabled in Adblock Plus by default and it examines filter lists regularly.

“Nevertheless, there are still websites where this option can be used to run malicious software and we know that it is our responsibility to protect our users from such attacks. We are working on fixing this exploit,” the company said.

In addition to further restrictions being considered for $rewrite, Adblock Plus says may restrict all filter lists to https, which is currently the case for default activated lists.

Sebastian said the risk can be mitigated by whitelisting known origins with the connect-src CSP header or by omitting server-side open redirects.

The Register asked Google to confirm that it doesn’t see this as a Chrome security problem, but we’ve not yet heard back.

One of the reasons Google cites for its controversial Manifest v3 plan to change the APIs available to Chrome extensions is security. The search biz is focused on issues other than filter trust, like replacing the webRequest API, which evaluates rules in the browser (where they can be changed) rather than in the JavaScript engine (where declared rules remain fixed).