This is an interesting article, but it keeps using the phrase "taking over domains", which isn't really what's happening.

It's really "squatting on the domain ONLY in the space of a specific provider".

And, this isn't new. For example, you can do this on most shared hosting plans...add a domain, and they don't ask for any kind of verification.

The only thing this seems to accomplish is lock you, the legitimate domain owner, from using a specific service until you open a support ticket and hash it out with them. You still control the domain, so it's fairly easy to prove control/ownership.

That's not good, of course, but it's not the same thing as "taking over a domain". Your WHOIS records still point at your DNS servers, which still return the correct records.

Edit: It could, I suppose, be used to take over a mostly "abandoned" domain, where the WHOIS records still point at a provider with this issue, but the underlying account is gone. Again, an issue, but if the domain is abandoned, it's not the same thing as taking over arbitrary, in-use domains.

Author here, you do have a point, that distinction should have been made. This is merely taking control over the DNS for a domain and doesn't speak to actual ownership of the domain at the registry (which would be "ground truth" for ownership of a domain).

The main idea of this post is to be informational/raise awareness since I'd argue a large majority of users don't expect this behavior to occur.

Were you able to forge HTTPS certificates?

You wouldn't really need to "forge" SSL certificates, since you have control of the domain's DNS you can just request a long-term certificate and use DNS/HTTP as a validation method. Many/most CA's support this already.

To be clear though, you only have control of the domain's DNS in the specific case that:

- The original owner made that specific service the authoritative server for the domain with their registrar

- They then either never added the domain to the service, or added it, and later removed it...or killed the entire account.

As I mentioned, this is certainly an issue. But, the domain is basically abandoned. It's very similar to letting it expire. Something that should be fixed, for sure, but not a way to take over an actually functioning website.

Of course. I'm a bit confused on this emphasis... Does the post make it seem as though you can take over an active site? The point of this attack is merely to take control of many domain names and doesn't make any point about taking over live websites (at least, this was not my intention). You are taking over control of the DNS of these domains, just because they are not actively hosting something doesn't make this less true.

The idea would be that a user has simply deleted/released the zone for a specific domain under their account. This could have happened because they plan on moving it later or because a lack of payment/service termination has occurred. This allows an attacker to obtain thousands of fresh domains easily with very little effort and likely no payment at all which can be used in malware campaigns/etc. Some common things I saw were indeed older unused domains, domain portfolio's of domain resellers/squatters, and even domains in restricted TLD spaces such as .gov, .edu, etc. These would certainly have value despite no longer being used.

Let me know if I've been unclear or am missing something here.

The author specified that his source for finding the domains in the first place was the .com and .net zone files. This means that the domains were actively pointing to Google/DO/Rackspace's nameservers.

The author would therefore have complete control over the orphaned domains after the takeover.

The reason for the emphasis is that the article isn't clear on two points.

- By definition, his method of finding domains only finds domains that aren't in active use. (domain servers in the ns records return fail/refused).

- It uses the terminology "taking over", and you're saying "complete control". However, if the real owner of the domain wanted control back, they would simply log into their registrar and change the NS records...very low effort.

As a first thought, it should be possible to.

a) With control of a domain's name servers you can set up working mail handling for a domain.

b) At least some HTTPS cert providers allow verification of domain ownership using email. eg click on a link in a mail they send to (say) [email protected]

With those two in place, you can generate HTTPS certs for the domain. I'm not yet familiar with LetsEncrypt, but if they allow domain verification through email then this would even be a cost free exercise.

LetsEncrypt only supports their certbot client, so no email support.

Imagine Foo, Inc., a hot new startup disrupting $industry. DNS for foo.com (which was paid up for several more years) is hosted on Route 53.

One day, they run out of money and close up shop. Their Amazon AWS accounts get shut down. The domain gets wiped from Route 53.

You come along and add foo.com as a hosted zone in Route 53. You point MX RRs towards a machine you control and begin reading the mail sent to [email protected] that will continue to arrive for the next several years. Perhaps you even use your new access to all @foo.com addresses to do some password resets on long forgotten accounts.

The same thing can happen if the domain expires and you re-register it, right?

Correct. The only difference is that the behavior is expected when you register the domain yourself.

The combination of this being fairly unlikely to be attempted, along with Foo Inc no longer existing, I really don't think this is a significant issue.

I manage some mail servers for an ISP. There have been times when I've came across domains that we still have control over but the companies are long gone. Many times I'll "recycle" domains (old ones of mine, "donated" domains, or some of these "forgotten" domains) and use them for spam traps.

Typically, I wait until a domain hasn't been used legitimately for e-mail for at least one year (i.e. I'll set "null" MX records or point them to a non-existent host) before I repurpose them. You might be surprised at the types of e-mails that start flowing right back in after pointing the MX RR back to a real host: lots of it is crap (spam), but I've received travel itineraries, notifications from AmEx, appointment reminders from medical facilities, and all kinds of good stuff.

This would be valid for bug bounties on things like HackerOne. I wonder if this attack is in any writeups.

I mostly agree with you. This has been an issue with multiple free DNS providers for many many years (and one I personally reported to DigialOcean years ago).

Unfortunately we now live in a world where control of DNS is proof of ownership. Look at the entire mess that is Domain Validated SSL certs and how CloudFlare has abused this to get certs for domains that have never pushed SSL traffic over their network.

> Unfortunately we now live in a world where control of DNS is proof of ownership.

We have never lived in a world where "control" of the Domain Name System was not equivalent to control of the domain name.

I'm not sure if you have used Google Apps before, but from memory it has DNS and website verification, so I can only assume it'd be vulnerable to this sort of attack.

Let's face it, being able to serve content on a website at all is enough to prove you own it these days.

You are misunderstanding how DNS works. Just because I can get a google cloud name server to point example.com at my server does not mean I own the domain. The gcloud nameservers are not the authoritative nameservers for the zone unless the root .com registry points at them.

Google apps verification only asks the nameservers designated by the registrar for the domain.

A variant of this technique was briefly popular for "underground" sites around a decade ago --- someone would setup a site on virtual hosting with an unregistered (or registered, but pointing somewhere else) domain name, then disseminate that name along with the IP of the "hidden" host to those authorised for manual addition to HOSTS files; it was by no means secure, but quite effective at keeping out most of the population who don't know how these things work.

This. Plus, it's probably forgotten domains fron past projects, no one cares about.

yes, but it can be used as an exploit see the uber sso vuln

and furthermore, any domains that are affected are clearly not in use, so it's not exactly like you can do a MitM on any real users.

This should be fairly obvious to anyone who has ever moved DNS from one provider to another. Or even from one account to another. Anybody can stand up a server that's "authoritative" for a domain. It doesn't matter until the registrar points the domain's NS there. In fact, how else would you move from your registrar's nameserver to something like route53? Nobody is going to point their NS at an empty zone and populate it after the fact.

Indeed, "Taking Over.." is a misleading, click-baity heading. "Resuming Abandoned..." would be a better title.

> "Rackspace (~44K Domains Affected, Won’t Fix)"

Remember when Rackspace was a premium host that you happily paid more money to because they handled things the right way?

So what did Google do