What's In A CNAME

With the rise of ad and content blockers (think Ghostery and uBlock Origin), as well as browser tracking protections (see www.cookiestatus.com), marketing technology vendors have their work cut out for them. And when I refer to “their work”, I mean they have to proactively identify and exploit any loopholes they can find to keep on collecting their precious data.

In this article, I’ll take a look at one such exploit vector, the Canonical Name (CNAME) DNS record, in particular.

The phenomenon of mapping subdomains to third-party services isn’t confined to just advertising and marketing technology industries, though. In this article, I’ll also introduce you to the extensive body of research collected by Zach Edwards.

This research shows how countless subdomains of high value and importance (think government, education) have been compromised and primed for stealing credentials written in first-party cookies.

It’s important to raise awareness of the risks involved with mapping subdomains to third party servers. Even though much of Zach’s research concerns scenarios where subdomains have been taken over by attackers, the end result is the same: the third party has access to data beyond what the site owner or business might have considered.

But before we dig into the risks themselves, it’s important to understand how we got to the point of surrendering our own domain namespace to third-party vendors and services.

X

The Simmer Newsletter

Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!

The perils of the third-party

The fact is that storage access in third-party context, colloquially referred to as “third-party cookies”, has become unstable and unreliable as the foundation for any data collection scheme, regardless of browser vendor:

• Safari blocks all third-party cookies. Sites and services can request access to third-party storage from the browser user with the Storage Access API.
• Brave blocks all third-party cookies.
• Firefox blocks third-party cookies on domains that are in their blocklist.
• Edge blocks third-party cookies on domains that are in their blocklist, with some mitigations.
• Chrome is planning to phase out support for third-party cookies by 2022. They are also rolling out a change to how browser cookies are processed in the browser, by defaulting all cookies to SameSite=Lax unless the cookie is manually updated with the appropriate flag when set.

SameSite=Lax is an attribute that specifies the cookie can only be accessed in first-party context. While not a tracking protection per se, it’s still a fairly significant move in helping auditors identify which cookies have been flagged for potential cross-site access.

What’s the solution for vendors that want to continue with their cross-site tracking shenanigans? Well, if third-party context is too unreliable to build any business logic for, it’s time to take a look at first-party context.

The bliss of the first-party

When a vendor decides to move from third-party to first-party context, it typically means one or more of the following.

They start decorating incoming links to the site from the vendor’s platform where the user has been identified e.g. via a login.

This is how Facebook works, for example, as every single link you click in Facebook will be appended with the fbclid parameter. After that, any Facebook (or partner) script running on the site can take that parameter from the URL and send it back to the vendor. Thus Facebook will know that the person for whom the hash was created visited your site.

They start utilizing browser fingerprints to identify the user from one HTTP request to the next. Fingerprinting is dangerous because it is completely stateless - there’s no need to persist any information in the browser.

The user is disarmed of options to actively prevent this. This has led fingerprinting to become one of the rare areas where there is practically universal consensus among browser vendors that it is a Bad Thing and must be prevented.

They request the site owner to run their scripts locally or to use local routers. This way they can circumvent ad blockers targeting the vendor domains.

They request the site owners to reserve a subdomain in their domain namespace, which is configured to point to the vendor’s servers.

All of these approaches have been designed to avoid the heuristics in browsers and browser extensions that target third-party trackers. The reliability of these workarounds depends on how easy the site owner is to hoodwink into actively participating in setting them up.

Link decoration, for example, doesn’t require the site owner to do anything but add the vendor JavaScript to the site. However, it’s not the most reliable exploit since blockers are most likely already preventing access to the most popular CDNs owned by the tracking vendors.

The last option in the list ends up being the most robust one because it requires the site owner to actively and knowingly collude with the third party to improve the quality of the data collection. This is the exploit we’ll be discussing in the rest of the article, as it has the biggest ramifications for end-user privacy and data security.

Subdomain mappings

This article shows you how some vendors in the advertising and marketing technology space are approaching the restrictions to third-party context. They are directly contacting their customers and asking for their help in keeping the service alive.

The gist is typically that the site needs to reserve a subdomain (e.g. tracking.domain.com), which is then set to point to a vendor domain name (e.g. identity.vendor.com) using a Canonical Name (CNAME) DNS record.

Alternatively, the site can set up A/AAAA records that point directly to the vendor server IP address, but this is rare. With a CNAME, the vendor has the liberty of shuffling around the IP ranges of their servers without breaking the link to the mapped domain names.

Once the DNS record resolves, all requests to tracking.domain.com are received by the vendor server behind identity.vendor.com.

So, why go through all this trouble? Well, there are a couple of reasons:

1. The site doesn’t have to relax its Content Security Policies to allow third-party domains to load and run their scripts on the site. This reduces the friction in deploying the third-party service on the site.

2. It’s so easy to setup a CNAME record. There’s no need to configure complicated reverse proxies or to create multiple A/AAAA records. It’s (typically) just a single DNS change that anyone with adequate access can do.

3. While identity.vendor.com is most likely in most of the blocklists for browsers and browser extensions, tracking.domain.com most likely isn’t. This is a pretty solid way to circumvent ad blockers.

4. Since the service is now running in first-party context with the rest of the site, the service can leverage first-party cookies, even those set with the HttpOnly flag.

First-party cookies and data leaks

When the browser sends an HTTP request to a target address, that request will include all the cookies written on the target domain and any domains “higher” in the hierarchy, all the way to the top-most privately controlled domain name.

For example, when owned.domain sends an HTTP request to sub.sub.owned.domain, that request will include all the cookies written on sub.sub.owned.domain, sub.owned.domain, and owned.domain.

If the source and target of the request are same-site (i.e. they share the top-most privately controlled domain name), the request happens in first-party context, which is largely unrestricted by browsers and plugins today.

When you surrender, either willingly by mapping the domain yourself or inadvertently via a takeover, a subdomain to a third party, you open your business for potentially horrendous data and credential leaks.

Since the web server at the end of an HTTP request is privy to a large subset of first-party cookies set on any given site, things like state and authentication tokens are automatically logged by the web server owned by the vendor. This is because many sites still set them on owned.domain, making them available to all subdomains of the domain name.

Gaining control of a subdomain also opens up possibilities for a number of different, very dangerous exploits, ranging from cross-site scripting attacks to intentional brand defamation.

Sometimes these cookies contain personally identifiable information such as email addresses and user names, allowing vendors to enhance the user’s cross-site tracking profile without them being able to do anything about it.

Typically, there are privacy policies and lots of red tape in place, where the vendors offer complicated promises that they will not misuse the information logged by their web servers. But these practices vary wildly.

Furthermore, because everything happens behind the curtains of server-to-server communications, it’s practically impossible for independent auditors to know what’s going on.

And this is the main warning of this article:

When you map your subdomain to a third-party service, you are sending much more data to the third party than you might have bargained for.

Compare this with sending the request directly to the vendor-specific domain. By default, these requests would only include (third-party) cookies written on the vendor domain. Any other information would need to be encoded with JavaScript, which can be parsed and audited by anyone visiting the site.

But with a subdomain mapping, all first-party cookies available on that domain will be sent, including those flagged as HttpOnly. These HttpOnly cookies can’t be accessed with client-side script at all, which might lull site owners to a false sense of security.

Zach Edwards’ research on the PickAFlick.com crew

Zach Edwards is one of those people on Twitter you simply must follow. He’s been conducting exhaustive research into many areas intersecting internet security and digital marketing and analytics. One of his pet peeves at the moment is something he’s dubbed the PickaFlick.com attacks.

In these scenarios, an attacker takes control of subdomains (usually DNS records left dangling), and then starts stuffing search engine results with bogus links, hoping the visitor will click one of them.

If the visitor does click such a link, that HTTP request will include all the first-party cookies available on that particular subdomain. See the previous chapter for examples of what type of information can be encoded in these cookies.

The screenshot above is from thehousepartyapp.com, which Zach quite elaborately reported to Epic Games as having been compromised by subdomain takeovers. This was initially in response to Epic Games’ ludicrous $1,000,000 bounty for proof of a smear campaign related to a possible hacking incident.

I recommend you read Zach’s article, as it shows how widespread and long-standing the PickaFlick.com attacks (and similar) are. It’s also shocking how oblivious so many site and service owners are to trouble brewing in their own backyards.

Go through your site’s search results with a search query like site:mydomain.com "free ebook" and see if bogus results turn up. If they do, it’s time for a DNS record audit. Make sure to eliminate any that you don’t recognize or control the endpoint for anymore.

This diversion to Zach’s research isn’t necessarily an indictment of CNAME exploits themselves, but they do exemplify how perilous and fragile this aspect of the HTTP protocol is.

Prevention measures

To avoid subdomain mappings from harming your business, there are some mitigations you can act upon.

1. Follow the instructions in the previous chapter to see if you have compromised subdomains. If so, make sure you remove these subdomains from your DNS registry. It would be a good idea to report this to the service you use for your DNS, so that they can take appropriate action with their other customers as well.

2. Make sure all state and authentication tokens, and really anything that can be used to impersonate a user, are written on a subdomain that you have control over. Make sure they are not written directly on the top-most privately controlled domain name. Make sure they are httpOnly and secure. Make sure they are SameSite=Strict, unless you need them in a third-party context.

3. Make sure your Content Security Policy doesn’t just wildcard all your subdomains (*.owned.domain). Allow only those domains that you have vetted and have governance over.

4. Periodically audit cookies accessed in both first- and third-party contexts across your sites.

It really boils down to the trust you place in the vendors to whom you are mapping subdomains, the governance you have over the data flows, assets, and storage access across your sites, and processes you have in place for periodically auditing these perilous gateways to potentially brand-decimating leaks.

Closing thoughts

Why go through the trouble of ranting about CNAME redirects, when they’ve been so eloquently covered by this incredible article by Romain Cointepas? Why discuss subdomain takeover attacks when Zach Edwards has already done all the legwork?

Well, this is an insidious attack vector because it can be orchestrated with the best of intentions. It needs more exposure. More and more vendors are requesting subdomain mappings, and it’s important that site owners know what they’re subscribing to.

Moving vendor services to first-party context isn’t necessarily a universally bad thing. As a site owner, you are actively participating in vetting the services integrated on your site, and by mapping DNS records to third parties, you are proactively taking responsibility for the data streams and flows to and from your site. At least, in theory.

The problem isn’t necessarily related to the contracts and terms of services you sign with the vendors, which promise to restrict the types of data accessed in these requests. No, the problem is with this aspect of the HTTP protocol in general.

Allowing cookies to pass unchecked through CNAME redirects to possible tracking domains is where the problem lies. Browsers don’t (yet) have the capability to detect hazardous CNAME chains, but it is a feature set I wouldn’t be surprised to see in their roadmaps.

In the European Union, the ePrivacy Directive guides businesses to be aware and audit all keys and values stored in all browser storage at all times. Having an up-to-date audit of first-party cookies, for example, reduces the risk of leaking this information to third parties.

If you need to manage state, authentication, and/or personally identifiable information in cookies, make sure they’re not set in the root of the domain namespace you control. That way you mitigate the risk of this information leaking to server endpoints you have no control over.

Just be vigilant and map those data flows. That’s a good way to reduce a huge amount of risk embedded in how your site, app, or service persists and processes user data.