Q&A uBlock, I exfiltrate: exploiting ad blockers with CSS

F

ForgottenSeer 92963

@Jan Willy

This is a test page to promote the author's own extension. The test just fetches and imports first and third-party style sheets with the vulnerability and when the image appears your browser allowed it. So the test-page has nothing to do with the vulnerability Tavis Ormandy (of Google) and Gareth Hayes

Short answer: no it is not enough

Long answer


Imagine a three staged attack. Stage 1 hide code in a adblock filter list. Stage 2 pull in the malicious code which does all the bad things. Stage 3 execute the code. Let me help to explain by quoting parts of the article


Stage 1

Gareth Hayes said:
Ad blockers like uBlock Origin are extremely popular, and typically have access to every page a user visits. Behind the scenes, they're powered by community-provided filter lists - CSS selectors that dictate which elements to block. These lists are not entirely trusted, so they're constrained to prevent malicious rules from stealing user data. .....A while ago one of my heroes, Tavis Ormandy mentioned on Twitter that uBlock Origin was vulnerable to CSS injection in their filter rules.
Because of the ongoing struggle between advertising publishers and adblockers the advertising links are randomized and obfuscated everywhere in and on a website. To match these advertising tactics Adblockers need to dig deeper into a webpage and offer more powerful means to block advertisements.

To prevent misuse of these powers, the Adblockers put constraints and limitations on what input they accept. Because this is complex, not all combinations and input situations are tested, so a unforseen combination of inputs might slip through the adBlocker's rule sanitizing mechanism.

The most important thing to remember the larger a community sourced blocklist is and more people contribute to this list, the harder it is to test all rules to prevent someone adding rules to find holes in the input check of an dblocker. It is even better when a more closed group of trusted people write the rules like Brave and AdGuard who have their own versions of community sourced lists (Easy List).

This is the rational behind my advice to use blocklist of AdGuard in stead of EasyList (reduce source risk)

Gareth Hayes said:
uBlock Origin also has cosmetic filters that allow more powerful CSS selectors they even let you define your own CSS rules but are restricted (limiting the use of URL requests), so I thought this would be a good place to look for another bypass.
This is the rational behind my advice to disable cosmetic filters system wide and enable it only on the websites you often visit (reduce target risk)

Gareth Hayes said:
Next Gareth Hayes used an external font to pull code in (stage 2) and create a keylogger. can't show the original text
1638978844354.png


Stage 2
An external font file also contains data which can be used import code. There are many ways to import code as shown by this reply of GorHill
1638980136575.png
Because Gareth used an external fonts file, blocking external fonts helps to close one door. This is the reason why GorHill offers to block fonts in the popup screen. It helps to block third-party fonts, but most websites use third-party fonts, so this also could prevent websites to display stuff correctly. Websites can set with Content Security Policies from which websites third-party content is allowed to be used. Well developed websites use this to reduce the attack surface (only allow stuff from trusted parties to minimize breeches).
This is the rational behind my advice to remove all Content Security Policies set in any filter (with the My Filter rule: @@||*$CSP). It does not make a badly secured website stronger, but it prevents an attacker to change a website's content security policies by sneaking in a CSP modifier in a static filter to make the security of that website weaker.

Stage 3
After malicious code is imported it has to be executed. One of the most abused javascript commands is the EVAL which executes dynamically pulled in code. This is the rational to block eval with *##+js(noeval) rule. This enforcement could potentially break a website, but I would not visit a website which relies on dynamically executing code from other sources.

Sum up
None of the above advices complete rules out misuse of an Adblocker powerful website manipulation capabilities (at least until Manifest V3 is implemented), but they make it harder to craft a staged misuse of errors in the internal 'rules checker' of an adblocker.
 
Last edited by a moderator:

Jan Willy

Level 7
Verified
Well-known
Jul 5, 2019
338
@Kees1958
You've explained the CSS-issue very clear and have given very usefull tips. Many thanks. Is it wise to whitelist all CSS Instead of disabling all cosmetic filtering (and enabling it only on the websites you often visit)?
 
  • Like
Reactions: Nevi and oldschool
F

ForgottenSeer 92963

@Jan Willy

Selectively enabling cosmetic filtering and using well known filters is sufficient IMO.

The attention and air-time for layest breeches, vulnerabilities and threats is immense on security forums and magazines.

My chance of being hit by a bus is still much bigger than being hit by one of the many exotic pocs and vulnerabilities mentioned in MT.

So unless you are wearing a tin foil hat, I would not worry much on these breaking news alerts (although I enjoy reading and chatting about them in MT).
 
Last edited by a moderator:

oldschool

Level 66
Verified
Top poster
Well-known
Mar 29, 2018
5,589
@Jan Willy

The attention and air-time for layest breeches, vulnerabilities and threats is immense on security forums and magazines.

My chance of being hit by a bus is still much bigger than being hit by one of the many exotic pocs and vulnerabilities mentioned in MT.

So unless you are wearing a tin foil hat, I would not worry much on these breaking news alerts (although I enjoy reading and chatting about them in MT).
I agree wholeheartedly!(y)(y)
 
F

ForgottenSeer 92963

@Jan Willy

Do you mean with " Is it wise to whitelist all CSS" removing all CSP modifiers set in filterlists?

The $CSP modifier is a static filter (which AdGuard says only to be used by specialists, which hackers/malware writers usually are), so besides selectively enabling cosmetic filtering, removing CSP changes set by any filter is recommended (this means the content security policies set by a website self are applicable): @@||*$csp
1639039098475.png

Browsers do not perform a CSP check on extensions: How Browser Extensions Routinely Bypass a CSP (Content Security Policy)
 

Jan Willy

Level 7
Verified
Well-known
Jul 5, 2019
338
Do you mean with " Is it wise to whitelist all CSS" removing all CSP modifiers set in filterlists?
For the record: in daily life I use on my laptop only Adguard for Windows. For experimenting I use now and then uBlock Origin. On the occasion of your question, I have (also as experiment) added the next whitelist-rule to Adguard: @@||*^$stylesheet.
The advantage is that other kinds of cosmetic filtering remain intact. An example from Adguard-log:

css whitelist example.jpg

Edit: In the past I've used the extension Policy Control. For CSS was the default setting Allow all.
 
Last edited:
F

ForgottenSeer 92963

@Jan Willy

By disabling cosmetic rules in uBO you disable the cosmetic modifiers which are imported and applied by the blacklists you have enabled. You don't disable the CSS-formatting of the websites themselves. An allow can be overruled with the IMPORTANT option in a rule, so for security it is less effective than disabling cosmetic filtering.

Because I always have disabled cosmetic filtering globally and enabled it on a handful websites to removed a few white space banners (with the element picker) and one looping GIF (by blocking the link source of the blob), I have no idea which cosmetic filters are still applied when globally allowing style sheets. For my education could you explain what you have achieved by "other kinds of cosmetic filtering remain intact (which style elements are still hidden)" ?

Regards Kees
 
Last edited by a moderator:

Jan Willy

Level 7
Verified
Well-known
Jul 5, 2019
338
@Kees1958
When I read your post # 26 I had already nearly forgotten the whole thing. First I had a simple whitelist-rule in mind (@@||*^$stylesheet). After reading your post # 26 I added this rule to Adguard to experiment. Now I realize that it's in fact a networkrule. So it has no effect on (possible vulnerable) cosmetic CSS-rules. I accepted already your solution to disable cosmetic filtering in uBlock (which isn't possible in Adguard for Windows) and now I confirm it. An example of another kind of cosmetic filtering regards EasyList Cookie (which I don't use).
 
F

ForgottenSeer 92963

@Jan Willy

When you use AdGuard with AG own blocklists, you are good to go IMO because these blocklists are maintained by AdGuard. On top of that AG extension V4 has a new rules engine and the code has been scrutinized and optimized (JasonUK mentioned the rules are different also: link).
 
Last edited by a moderator:

South Park

Level 8
Verified
Jun 23, 2018
393
@Jan Willy

When you use AdGuard with AG own blocklists, you are good to go IMO because these blocklists are maintained by AdGuard. On top of that AG extension V4 has a new rules engine and the code has been scrutinized and optimized (JasonUK mentioned the rules are different also: link).
On the strength of your recommendations, I switched from Easy List/Easy Privacy to AdGuard optimized lists in uBO (Base+EL and EP optimized) to reduce the chance of malicious rules getting in. I remember when the one-man uBO fork Nano Blocker and its powerful rules lists were sold to a rogue maintainer and abused for social media spam about a year ago. AdGuard seems to be a much more stable and reliable company.
 
F

ForgottenSeer 92963

@South Park, good choice

Raymond Hill (the programmer of uBo)will never turn roque. I know never say never, but ...

With the installs uBlock has, he could have received a small fortune on donations. Gorhill might be as flexible* as a lead door, but he is also as solid as a lead door, so I trust he will never sell out for profit.

* I have had a discussion with Gorhill on the uselessness of his malware and phising blocklists (long ago) with the default (low interval) update blocklist cycle of uBlock**. When the man is convinced of something even 10 horses can't make him move an inch in opinion.

**Ask our resident MT tester @Evjl's Rain whether it makes sense to use malware and phising URL blocklist with low update interval frequency (like uBo has).
 
Last edited by a moderator:

iam-py-test

New Member
Dec 10, 2021
3
@wat0114

Thanks and in addition to Jan Willy's tip, you can stil enable cosmetic filtering for websites you visit a lot.
It is recommended you enable cosmetic filtering on _all_ websites, as it is part of how uBlock Origin blocks ads. Disabling it leaves you vulnerable to ads and malware
I also have added two rules in My Filters (which are good security practice rules to add anyway), note that the *## does not triggers uBlock's DOM inspector so this rule is processed even when you have enabled the "ignore generic cosmetic filters" option Filter lists.
Code:
! Remove any Content Security Policies set by filters on all websites (by setting a CSP exception with no values)
@@||*$csp
[/QUOTE]
Why?
[QUOTE="Kees1958, post: 967499, member: 92963"]


! Block the use of the much abused EVAL javascript command bij using uBO's no-eval scriptlet on all websites
*##+js(noeval)
This breaks many websites
I have read a little more about it and my take is that when you stick to ublock's own filterlists in combination with AdGuard's filterlists, you essentially use only closed group maintainer lists, with near zero chance of misuse of abuse.
There are two problems with this:
- uBlock Origin's own filterlists and the AdGuard filters were _never_ designed to be used on their own; they should be used with EasyList and EasyPrivacy
- Fewer developers does not mean more secure, and only trusted developers are allowed to directly edit _any_ of those filters. For all of these, every commit is logged and any abuse would be detected.
an open community (like easylist)
Easylist is not an 'open community' - only the Easylist maintainers can edit the filters, and in terms of Pull Requests, there is pretty much the same policy.
 

oldschool

Level 66
Verified
Top poster
Well-known
Mar 29, 2018
5,589
It is recommended you enable cosmetic filtering on _all_ websites, as it is part of how uBlock Origin blocks ads. Disabling it leaves you vulnerable to ads and malware
From µBO Wiki:
Tips

It is often suggested adding a custom static filter such as @@||example.com^$elemhide or @@||example.com^$generichide to prevent "adblock" detection by specific sites (example, example). You can accomplish the same goal more simply by just toggling off cosmetic filtering using this switch while on the problematic site.

This switch can help uBO to further lower its CPU-cycle footprint, which might be beneficial on devices with limited CPU-cycle resources -- and thus helping extend battery life and speed up page load times. The idea is to disable cosmetic filtering everywhere by default, and to enable it only for those sites which really benefit from it.
 
F

ForgottenSeer 92963

It is recommended you enable cosmetic filtering on _all_ websites, as it is part of how uBlock Origin blocks ads. Disabling it leaves you vulnerable to ads and malware
Cosmetic filtering hides stuff it does not block, things. As @oldschool pointed out read in the past Gorhill recommended it.

Also do you really think Raymond Hill would offer options which would decrease security?
This breaks many websites
Like which websites?
There are two problems with this:
- uBlock Origin's own filterlists and the AdGuard filters were _never_ designed to be used on their own; they should be used with EasyList and EasyPrivacy
- Fewer developers does not mean more secure, and only trusted developers are allowed to directly edit _any_ of those filters. For all of these, every commit is logged and any abuse would be detected
My advice was to enable the AG versions of Easylist and Privacy. Click on the links added in my post.
 

iam-py-test

New Member
Dec 10, 2021
3
Cosmetic filtering hides stuff it does not block, things. As @oldschool pointed out read in the past Gorhill recommended it.

Also do you really think Raymond Hill would offer options which would decrease security?
Because the whole purpose of uBlock Origin is to offer user choice - besides, it does not completely disable uBo, it just means that elements won't be hidden (so the page looks bad & some ads will get through)
Like which websites?
Anything using Cloudfare - also, injecting a scriptlet into all websites (even any scriptlet) has many problems & is recommended against by @gorhill
My advice was to enable the AG versions of Easylist and Privacy. Click on the links added in my post.
Not equivalent - those versions main advantage is used on uBo/AG specific syntax, which EL doesn't. They are designed to work together. Feel free to ask Gorhill and see if he agrees
 
F

ForgottenSeer 92963

Because the whole purpose of uBlock Origin is to offer user choice - besides, it does not completely disable uBo, it just means that elements won't be hidden (so the page looks bad & some ads will get through)
Still telling not hiding something leaves you vulnerable to malware is sheer nonsense

Anything using Cloudfare - also, injecting a scriptlet into all websites (even any scriptlet) has many problems & is recommended against by @gorhill
Name 5 websites
Not equivalent - those versions main advantage is used on uBo/AG specific syntax, which EL doesn't. They are designed to work together. Feel free to ask Gorhill
Both AG and uBo proces ABP format. Just look at the links of AG's EL and EP blocklists provided.
 
  • Like
Reactions: wat0114

wat0114

Level 6
Verified
Well-known
Apr 5, 2021
264
Interesting. I don't have any custom cosmetic filters made for APnews.com, but there is a difference between having cosmetic filtering enabled and disabled on the site. It does appear, if I understand correctly, with it disabled the ad is blocked but the containers remain.

APNew with cosmetic.png

APNew without cosmetic.png
 
F

ForgottenSeer 92963

Interesting. I don't have any custom cosmetic filters made for APnews.com, but there is a difference between having cosmetic filtering enabled and disabled on the site. It does appear, if I understand correctly, with it disabled the ad is blocked but the containers remain.
That is what i posted (handfull websites I visit a lot, have white space placeholder). You can always selectively enable cosmetic filtering.
 
  • Like
Reactions: wat0114

wat0114

Level 6
Verified
Well-known
Apr 5, 2021
264
That is what i posted (handfull websites I visit a lot, have white space placeholder). You can always selectively enable cosmetic filtering.

Makes sense. And when I hover over the placeholder, nothing happens, so the ad - at least in my very limited technical understanding - seems to be blocked.

EDIT

I do agree the page looks kinda bad with a smattering of grey placeholders :D
 
Last edited: