Solved What's CNAME of your game? This DNS-based tracking defies your browser privacy defenses

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Wallace_n_Gromit

Senior Member
I'm still reading, watching podcasts, videos trying to wrap my mind around this issue.




Ultimately what caught my eye about this issue is that 3rd parties (advertising/analytics and by extension even malware vendors--some good guys can go bad) can with the cooperation/collusion of the website (isn't that what they do now anyway to monetize your visit?), in effect plant cookies as first parties thus effectively negating any 3rd party cookie blocking and under the radar of adblocking, analytics blocking software (that rely upon 3rd party "fixed hostname-based block lists").

The researchers found this technique currently in use on a total of 10,474 websites. And of the top 10,000 websites overall, 9.98% — 1 in 10 — of those top 10,000 are currently employing this form of CNAME tracking, cloaking, subdomain collusion.
BUT THERE'S MORE!

But perhaps an unintended consequence of this feature can, additionally, due to it's nature, in the hands of bad actors, effectively authenticate/login/impersonate YOU. Since their cookies are part of the hosting websites domain/subdomain and if there exists a still-valid authentication cookie (you haven't explicitly logged off); that same 3rd party now has access to ALL COOKIES, including the authenticating cookies, from that website you visit.

[Subject is discussed 1:26:40 into Podcast]

The Podcast Notes about CNAME Collusion issue begin on page 7
Security Now! #808 - 03-02-21 - CNAME Collusion (grc.com)

Countermeasures
In response to a report that a tracker was using CNAMEs to circumvent privacy blocklists, uBlock Origin released an update for its Firefox version that thwarts CNAME cloaking. The extension blocks requests to CNAME trackers by resolving the domain names using the [browser's own] browser.dns.resolve API method to obtain the last CNAME record (if any) before each request is sent. Subsequently, the extension checks whether the domain name matches any of the rules in its blocklists, and blocks requests with matching domains while adding the outcome to a local cache. Although uBlock Origin also has a version for Chromium-based browsers, the same defense cannot be applied because Chromium-based browser extensions do not have access to an API to perform DNS queries. As such, at the time of this writing, it is technically impossible for these extensions to block requests to trackers that leverage CNAME records to avoid detection. uBlock Origin for Chrome, which does not have an explicit defense for CNAME-based tracking, still manages to block several trackers. This is because the requests to the trackers matched an entry of the blocklist with a URL pattern that did not consider the hostname. Unfortunately, it is fairly straightforward for the tracker to circumvent such a fixed rule-based measure, e.g.by randomizing the path of the tracking script and analytics endpoint, as is evidenced by the various trackers that could only be blocked by the uBlock Origin version on Firefox

On page 10 of the show notes a chart does show that uBlock Origin and the NextDNS CNAME blocklist are partially able to mitigate this behavior.
 

Attachments

  • CNAME CHART.pdf
    276.2 KB · Views: 23
Last edited:

Treadler

Very Senior Member
I'm still reading, watching podcasts, videos trying to wrap my mind around this issue.


Ultimately what caught my eye about this issue is that 3rd parties (advertising/analytics and by extension even malware vendors--some good guys can go bad) can with the cooperation/collusion of the website (isn't that what they do now anyway to monetize your visit?), in effect plant cookies as first parties thus effectively negating any 3rd party cookie blocking and under the radar of adblocking, analytics blocking software (that rely upon 3rd party "fixed hostname-based block lists").


BUT THERE'S MORE!

But perhaps an unintended consequence of this feature can, additionally, due to it's nature, in the hands of bad actors, effectively authenticate/login/impersonate YOU. Since their cookies are part of the hosting websites domain/subdomain and if there exists a still-valid authentication cookie (you haven't explicitly logged off); that same 3rd party now has access to ALL COOKIES, including the authenticating cookies, from that website you visit.

[Subject is discussed 1:26:40 into Podcast]

The Podcast Notes about CNAME Collusion issue begin on page 7
Security Now! #808 - 03-02-21 - CNAME Collusion (grc.com)




On page 10 of the show notes a chart does show that uBlock Origin and the NextDNS CNAME blocklist are partially able to mitigate this behavior.

This may be relevant.......

 

Wallace_n_Gromit

Senior Member
Anyone wishing to add the list to their blocker of choice, be it Diversion, Unbound or Pi-Hole, here is the link:

https://raw.githubusercontent.com/A...r/combined_disguised_trackers_justdomains.txt
Just copy and paste the list into the Diversion BlackList? i.e.:

Code:
nano /opt/share/diversion/list/blacklist

EDIT: My blacklist on Diversion went from 0 entries to 6143! Hope it don't slow things down too much. Is there a way to prove (proof of concept) that the blacklisted items are actually being filtered?

Also just went to https://github.com/AdguardTeam/cname-trackers. I see that the list has been updated 6 days ago.

So that begs the question: wouldn't a dynamically updated list be more beneficial than a static list? How is that done? Is it possible to have diversion do it automatically and how?

2nd EDIT: Removed the blacklist entries and updated the "add hosts list" . Guess I'm pretty naïve about the power/operation of Diversion. But a quick study when things are explained. :D
 
Last edited:

Make WiFi Great Again

Regular Contributor
I think you are not doing that the way it was intended.

you want to add it to nano /opt/share/diversion/list/hostslist not blacklist but i think you are suppose to do it through the diversion text based gui by pressing b then 1 then 2 and finally 1 again which is "add hosts list". this will setup diversion to automatically update its own list by pulling down the list you just made ever so often. mine is set with option "92" which updates the list tuesday and friday. blah someone else can explain it better.
 

bluzfanmr1

Senior Member
Also just went to https://github.com/AdguardTeam/cname-trackers. I see that the list has been updated 6 days ago.

So that begs the question: wouldn't a dynamically updated list be more beneficial than a static list?
They have indicated the list will be updated on a regular basis. Your chosen ad blocker will pull the list each time it updates your chosen blocking lists.

https://github.com/AdguardTeam/cname-trackers

The Solution​

Thanks to AdGuard DNS that does block CNAME-cloaked trackers, we actually know what domain names they are hidden behind.

This is the most complete auto-updating repository of actively used hidden trackers. The list is to be updated on a regular basis to add new hidden trackers as they’re detected.

We're going to block those trackers in AdGuard Tracking Protection list so now even the users of Chrome and Safari extensions will be protected from CNAME abuse.

We hope that other filter lists makers (EasyPrivacy in particular) will also use this repository. This way we'll cover most of the content blockers and finally get rid of CNAME abuse.
 

Wallace_n_Gromit

Senior Member
I think you are not doing that the way it was intended.

you want to add it to nano /opt/share/diversion/list/hostslist not blacklist but i think you are suppose to do it through the diversion text based gui by pressing b then 1 then 2 and finally 1 again which is "add hosts list". this will setup diversion to automatically update its own list by pulling down the list you just made ever so often. mine is set with option "92" which updates the list tuesday and friday. blah someone else can explain it better.
1. Add hosts list
2. Remove hosts list
3. Disable hosts list
4. Enable hosts list

Enter selection [1-2 e=Exit] 1

i Hosts list can be in "IP domain" pair or
domain only format.

Paste web address and press [Enter]

Enter hosts list [q=Quit] https://raw.githubusercontent.com/A...r/combined_disguised_trackers_justdomains.txt
____________________________________________________

Customizable hosts list:

1: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
2: https://raw.githubusercontent.com/A...r/combined_disguised_trackers_justdomains.txt
____________________________________________________

1. Add hosts list
2. Remove hosts list
3. Disable hosts list
4. Enable hosts list

Enter selection [1-2 e=Exit]
I Think that's it, right @bluzfanmr1?

EDIT:
Sooooo...,
not sure if the "Customizable hosts list:" should have:
https://raw.githubusercontent.com/A...r/combined_disguised_trackers_justdomains.txt
Or:
Or:
https://github.com/AdguardTeam/cname-trackers

Only the first one is a Text file with an actual list. When I go to my original default diversion host list:
I do see that it is also presents an actual list like https://raw.githubusercontent.com/A...r/combined_disguised_trackers_justdomains.txt

So I think I answered my question: The actual "Customizable hosts lists" URL's must actually point to a list of items.

This is so cool, nevertheless. I'm learning so much about the power of Diversion (I've run it in it's default configuration for 1 1/2 years).
 
Last edited:

Wallace_n_Gromit

Senior Member

bluzfanmr1

Senior Member
I Think that's it, right @bluzfanmr1?

EDIT:
Sooooo...,
not sure if the "Customizable hosts list:" should have:
https://raw.githubusercontent.com/A...r/combined_disguised_trackers_justdomains.txt
Or:
Or:
https://github.com/AdguardTeam/cname-trackers

Only the first one is a Text file with an actual list. When I go to my original default diversion host list:
I do see that it is also presents an actual list like https://raw.githubusercontent.com/A...r/combined_disguised_trackers_justdomains.txt

So I think I answered my question: The actual "Customizable hosts lists" URL's must actually point to a list of items.

This is so cool, nevertheless. I'm learning so much about the power of Diversion (I've run it in it's default configuration for 1 1/2 years).

Lists come in different formats and so yes, you want the .txt list as its just the domains. The other lists have different formats that are used by other types of ad blockers i.e. AdGuard, etc.
 

Wallace_n_Gromit

Senior Member
Lists come in different formats and so yes, you want the .txt list as its just the domains. The other lists have different formats that are used by other types of ad blockers i.e. AdGuard, etc.
Yes, Thank you. I see/understand [I'm GROKing it] now that DIVERSION accepts both.

Hosts list can be in "IP domain" pair or domain only format
 
Last edited:

Wallace_n_Gromit

Senior Member
Last edited:

redpaw.rider

Occasional Visitor
Couldn’t this be mitigated using a recursive dns server on something like pi hole and use of dns servers like the 1.x for a lot of that
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top