AdGuard names 6,000+ web trackers that use CNAME chicanery: Feel free to feed them into your browser's filter AdGuard on Thursday published a list of more than 6,000 CNAME-based trackers so they can be incorporated into content-blocking filters. CNAME tracking is a way to configure DNS records to erase the distinction between code and assets from a publisher's (first-party) domain and tracking scripts on that site that call a server …
If a webpage has a link to https://deviouscname.firstparty.tld and that is actually a CNAME for adserver.devious.tld, won't my system make 2 dns reqeusts: the first for deviouscname.firstparty.tld which returns adserver.devious.tld, and a 2nd that resolves adserver.devious.tld to 8.8.9.9, which will be blocked because of 1) devious.tld or 8.8.0.0/16?
> Perhaps I don't appreciate how difficult this is for a web browser but if I ping a CNAME address the real address gets shown.
You mean if you have
foo.bar IN CNAME adtech.foo
adtech.foo IN A 1.2.3.4
When you do ping foo.bar you'll get
64 bytes from adtech.foo (1.2.3.4)
?
That's reliant on there being a valid PTR record for 1.2.3.4 naming it adtech.foo. That's not a given, and checking the PTR for every IP you connect to gets quite expensive (but would sometimes yield results).
True, but it's still additional latency per-FQDN, and the benefit from it is fairly limited, as ad companies just won't bother adding reverse records for their IPs, where they even own their ads.
A stonking number of ad/tracker services uses AWS/Azure/GCP too, so the PTR already won't yield much useful information in terms of identifying that it's a tracker service.
> won't my system make 2 dns reqeusts: the first for deviouscname.firstparty.tld which returns adserver.devious.tld, and a 2nd that resolves adserver.devious.tld to 8.8.9.9, which will be blocked because of 1) devious.tld or 8.8.0.0/16?
Assuming you've an even semi-standard setup on your OS, no.
- Your OS will send a query to your configured recursor (lets say google, 8.8.8.8) for deviouscname.firstparty.tld
- Google will go and find the authoritatives for firstparty.tld and query deviouscname
- The authoritatives will reply with CNAME adserver.devious.tld
- Google will then go find the authoritatives for devious.tld and query adserver
- Those authoritatives will return a response (lets say 1 A record)
- Google will then reply to you with the two records
- Your browser will connect out to the IP in the A record
The response you get will be something like
deviouscname.firstparty.tld IN CNAME adserver.devious.ltd
adserver.devious.ltd IN A 8.8.9.9
Only one DNS query ever leaves your system - for deviouscname.firstparty.tld - it's the recursor that follows the CNAME (hence recursor).
Of course, you *might* be running a recursor on your own machine, which changes things, but most users aren't, or are but have configured forwarding, so the query still goes out to another recursor which does all the work (doesn't stop their local recursor inspecting the response and blocking, of course).
> and a 2nd that resolves adserver.devious.tld to 8.8.9.9, which will be blocked because of 1) devious.tld or 8.8.0.0/16?
As above no, but this is how the adblocker extensions that support CNAME blocking achieve this. They resolve deviouscname.firstparty.tld and inspect the response. When it sees the CNAME, it checks whether the target is in the block list.
Even at the DNS blocking level, being able to inspect CNAME targets is relatively new.
In Unbound it used to be that if you had
local-data: "adserver.devious.ltd A 127.0.0.1"
Then you'd get inconsistent looking behaviour depending on whether you were directly querying that name, or it was a CNAME target (
curl http://adserver.devious.ltd # Connects to loopback
curl http://cnamedtoadserver.foo.ltd # Resolves correctly and connects to adserver
Pihole itself also only relatively recently got the ability to block CNAME targets.
Seriously, the solution to this isn't a browser plugin, it's to control your DNS. It is also going to protect you from other horrors. And if you blackhole the DNS requests it will also wipe out some of the hit tracking data your ISP has been selling them thanks to Idjit Pai. Filtering DNS servers are the new firewall.
And don't worry about "what will they think of next", they have already moved on to A records instead of CNAMES (which you can also block by IP btw).
And if a webpage refuses to load without JavaScript I simply move on.
Well, yeah. But how many sites actually work without Javascript nowadays? Ironically, Google search seems to be one of the few things that still runs in old fast browsers like links or dillo. It gives you links (sort of -- it actually hijacks them so it can file away information on what you clicked on). But they rarely work well. Blocking JS would seem to seriously decrease the utility of the internet for most users.
Doesn't think come from the bad old days where you accepted plaint text email on port 25 and assumed that sender would never lie about their address? Is there really a use for them given that you can update A and AAAA records automagially? And while I am whining why not take the axe to the PTR records. Nobody cares what IP they connect to, as machines and address no longer have any real meaning due to network mangling and manipulation.
Really disappointing that nobody took the bait. Where are the CNAME apologists that say I NEED to call something by something else in my domains, usually to some other thirdparty over which I have no control. And nobody going to say that if I cannot do a reverse look up on the SSH server I connected to I wont really know who it is, because since v2 of the protocol, I still don't trust the key it presents me?
So as a novice Firefox with uBlockOrigin user I wondered if I could add a CNAME filter list, clicked on the article links, and came across this dublious looking address on a place called GitHub. +++https://bananamovies.net/gangbang-stars-vol-3/ (nsfw) - popup+++ .
Blimey! I won't be clicking on that thanks, but is this the same scary place I should be looking for a legit' filter list please?
Does uBlock work automatically or do I need to add a CNAME filter myself?
Many thanks.
This is a security shit show waiting to happen. If your CNAMEd advertiser has the same FQDN as your website, it is treated as a trusted part of the web site. Think a minute and let the full implications of that sink in. Its scripts can change the JavaScript runtime by binding to events or changing the prototypes of key objects. It can manipulate any data, exfiltrate any data (remember, same FQDN so those requests automatically get allowed). Intercept any browser tokens and masquerade as any logged in user. The attacks would be indistinguishable because they could be launched from the same browser the victim user is using.
Even if you fully trust your advertiser, still do not do this. If your advertiser gets compromised, the miscreants potentially own every website that has aliased their CDN records to them. This completely breaks and renders useless all browser defenses against cross site abuse of JavaScript and http requests.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
