I confess—my digital space is not always the most tidy that it could be. Sometimes I leave unread tabs open in a rush out the door, or half-written text docs piled on top of half-written text docs. When I’m being generous to myself, I see it as the chaos from which my creativity is born. When I’m not quite so generous, I see it as just sloppy (and usually that leads to a purge).
Out of all such digital spaces, I have to admit that my DNS zone is usually pretty low on the list of spots I think about when I’m cleaning out clutter. But it’s actually extremely important that you do, because a cluttered zone file with DNS zone records you’re not using can actually be a serious threat.
What’s the worst that could happen?
The popular ride share company Uber created a subdomain on their domain name—saostatic.uber.com. They used Amazon Cloudfront, a content delivery network, with this subdomain while it was in use.
At some point, Uber stopped using the subdomain saostatic.uber.com and they removed the endpoint from their Amazon Cloudfront.
However, no one ever removed the ‘saostatic’ CNAME pointing to Cloudfront. That stayed in place.
Then one day, a bug bounty hunter discovered the saostatic subdomain, and saw that it still pointed to Cloudfront, even though he got a “Bad Request” error from Cloudfront when he tried to navigate there.
From there, all he had to do was add saostatic.uber.com as an endpoint from his own Cloudfront account and he was able to take full control over saostatic.uber.com.
What’s worse, because Uber’s then newly implemented single sign-on system issued a session cookie for *.uber.com, in a hypothetical attack scenario, getting an authenticated user to navigate to saostatic.uber.com could allow the hypothetical attacker to hijack that user’s session and access a user’s account on a variety of Uber’s services.
Obviously I’m not trying to pick on Uber here. Bugs happen. The point is that what seems like such a small thing—forgetting to remove a CNAME from your DNS zone, could potentially be a major security headache if it’s discovered by someone looking to do harm to you or your users.
What’s worse, because nothing is changing on your end and there’s no compromise of any of your networks, this kind of attack is virtually impossible to detect!
Likewise, free SSL services can make it easy for an attacker to get an SSL certificate for the subdomain so it can be hard for your customers to notice too.
What else could they do?
In the Uber example, the bug bounty hunter described using cookies to exploit this issue. However, some technologies, like Oauth, have subdomain allow-listing mechanics that let developers indicate callback URIs to accept. If an allow-listed subdomain can be hijacked, then a user’s Oauth token could be leaked.
There are a few other ways that attackers could utilize allow lists with subdomain takeovers.
Some password managers save passwords based on subdomains as well, so a phishing site could cull user logins from password managers.
How can this happen?
What we described above is an example and Amazon Cloudfront is a common service, but it’s certainly not the only service that this could work on.
But you don’t have to have a super successful ride share app for this to happen to you.
Let’s take a hypothetical example and say that your website is structured so that shop.example.com goes to your e-commerce site. Now let’s say that you move your shop to example.com/shop and remove shop.example.com from your hosting. If you don’t also remove the CNAME record pointing shop.example.com to your hosting provider, someone else could potentially create the host for shop.example.com and hijack your subdomain.
You should consider that any hosting service could potentially allow the creation of a new host on a subdomain you point to them via a CNAME record and act accordingly.
The bug bounty hunter who found Uber’s old CNAME record was likely using a tool that scans for subdomains, or they could have just Googled the domain and found a subdomain indexed somewhere. So don’t assume just because it’s not an obvious subdomain like admin.example.com or mail.example.com that you’re not vulnerable.
How can you prevent subdomain takeovers?
Really the only way to prevent a subdomain takeover is to keep your DNS zone clean. That doesn’t just meant that when you discontinue using a hosting service—for sales, for email, for support ticketing, etc.—remove the CNAME record that corresponds to it from your DNS zone.
Your best bet is to set up web forwarding on the subdomain either to your home page or to the service that’s replacing the one you’re discontinuing.
But, obviously, that’s not how the workflow works in some organizations and that’s okay. Which is why independently of discontinuing any particular services, you should periodically check the DNS zone and make sure that there aren’t any old CNAMEs floating around in there.
Just like any type of good hygiene, it can be a chore, especially if your domain is linked to a lot of different services, but in the end it’s worth it.
Tagged in DNSNom de domaineSecurity
