Ad Blockers, AdBlock, AdBlock Plus, Adblocker, browser security, eyeo GmbH, Google, Information Security, Security threats, Top News, uBlock, Vulnerability, Web Browsers

Ad blocker firms rush to fix security bug

If you’re using an ad blocker to filter out online commercials, then beware: You might be vulnerable to a new attack revealed on Monday that enables hackers to compromise your browser.

The vulnerability, discovered by security researcher Armin Sebastian, affects Adblock, Adblock Plus, and uBlock (but not uBlock Origin). It stems from a filtering option introduced into the ad blockers in July 2018. The option allowed the programs to rewrite web requests, cleaning them of tracking data.

The problem is that an attacker can exploit this rewrite function using XMLHttpRequest. This is a programming feature all modern browsers use to request data from a server after a page has loaded. They can also attack the server using an API called Fetch, which allows similar operations. An attacker can load a JavaScript string using either of these features and execute the returned code.

For the attack to work, the browser must visit another server after hitting a legitimate web page. Hackers can force that if the server allows open redirects. This is when the server takes a URL as input from the client and redirects to it, no matter what it is.

An attacker can also get their executable code into the browser via the $rewrite function if they can get it onto the legitimate web page. That’s possible if the server lets the user post their own content (such as in a comments section or social media timeline) and doesn’t use proper input validation to check the post for malicious commands.

Finally, for the attack to work, the server must not restrict where it can fetch content from. It must not validate the final request URL either, because the attacker will have tampered with it.

These conditions aren’t as rare as you’d think; Sebastian created an example of a malicious filter that would redirect requests to Google Maps to Google’s I’m Feeling Lucky. The filter then executes code that displays an alert box.

He explained:

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.

Website owners can fix the problem in two ways, he says. First, they can eliminate server-side open redirects. Second, they can use Content Security Policy (CSP), which is a World Wide Web Consortium (W3C) standard. The web server sends a CSP header when responding to a browser, and as long as the browser complies with it, it fetches content only from domains on the server’s white list.

Ad blockers might also want to rethink their use of the feature, he concluded:

Ad blocking extensions should consider dropping support for the $rewrite filter option. It’s always possible to abuse the feature to some degree, even if only images or style sheets are allowed to be redirected.

On Monday, eyeo GmbH, which makes Adblock Plus, did just that. It will release a version of the software without the $rewrite features “as soon as technically possible,” it said. However, it will leave in the ability to $rewrite to internal resources. This means allowing the filter to turn requests into local ones. They can substitute their own benign pixels for tracking pixels without alerting the server, for example.

Developers at AdBlock, which sells another product of the same name not connected to AdBlock Plus, are also working to rectify the problem. CEO Matthew Maier said:

We are aware of the vulnerability with the $rewrite filter option and we are preparing a release that will disable the potentially problematic functionality. We have not seen any attempt by a filter list maintainer to abuse this feature but we are removing the capability nonetheless as a precaution.

While Sebastian notified Google, Maier said that he didn’t get the same courtesy:

We did not hear from him first. We’ve been approached by ethical hackers in the past and we’ve paid bug bounties for folks that have surfaced issues to us. I don’t know that I would say I expected him to reach out, but it certainly would have been nice if he did. I don’t think we’re hard to find.

Source : Naked Security

Previous ArticleNext Article

Send this to a friend