Taking Over 20K DigitalOcean Domains via a Lax Domain Import System (2016)
thehackerblog.com
thehackerblog.com
It is absolutely bewildering that they wouldn't take this seriously. The owner of my takeover tried to add the domain to their panel and they couldn't. This adds a whole new level of customer service to their backlog which should essentially be mitigated by an automation of sorts via a txt record or cname confirmation. Seems to me that they are more interested in not fixing it but happy to waste hours of their agents trying to fix such takover problems.
I got what I wanted, but I fear not everyone knows what to ask for.
But, if anything, they did the work to collate a useful set of abandoned domains, and all DO needed to do was say "thanks, we've moved them to a special account we've set up and sinkholed on our own server".
Of course, then DO would be liable for the sinkholing, so maybe they thought it better to lock this guys account ("we did our best to prevent the hacker") and kick the actual issue into the long grass.
Their ex IT guy had half transferred their domain from namecheap to 123, changing the IPS tags to 123 but not accepting from 123's end. Then he got fired. The NS's were still pointing to Namechearp so everything continued to work, until the domain expired because neither company felt able to renew it, both referring me to nominet to resolve. Meanwhile the client was hard down.
After retiring to the bathroom to have a think I realised that 123 didn't really care who accepted the domain as long as the tags were right. So I created a new account, initiated a transfer and went through the steps, and the domain popped into my account, able to be renewed.
I did wonder if there would be a way to mass import domains that people hadn't accepted into their accounts yet but didn't actually try anything.
How should the system work?
I ask because I'm trying to understand how predators like Grubhub (the their proxies like Seamless) gobble up idle domains and phone numbers. And then try to figure out ways to mitigate, prevent, and more quickly resolve disputes.
FWIW, I found Nominet's Domain Dispute's explainer. https://www.nominet.uk/domain-support/uk-domain-disputes/ Next, I'll see what USA firms do. I'm especially interested in the legal framework (laws, rules, procedures).
Any pointers are greatly appreciated, thanks.
--
This Vice article is that one that got me spun up about this issue:
https://www.vice.com/en/article/akzz8z/nyc-is-cracking-down-...
This Smarter Everyday 3-parter gives example of impersonation happening on Instagram:
I wonder how effective that actually is? As far as I know there is nothing in the DNS protocol like the "Host" header of HTTP that allows the name server to tell what name the client knows the name server by. Two differently named name servers will actually be distinct only if they have different IP addresses.
The question then is how many IP addresses does Route 53 have for name servers?
Ideally, you'd want to have a separate IP address for each customer's name server. Do any of the big hosting companies do that?
I'd expect that they could do it without needing a lot of extra IP addresses by giving each customer who has a static IP address for the hosts an option to have traffic to port 53 of that IP address transparently sent to the hosting provider's name servers along with tagging to let the name servers identify what IP address it was for so it can serve the right name data.
That would allow each customer to have as many apparently dedicated name servers as they have hosts with static IP addresses.
You can create 100 delegation sets (until you reach a quota, which can be raised) per account. This would give you 100 possible combinations, rinse and repeat for more account and I'm sure you've exhausted all possible combinations rather quickly. You can also create more accounts programatically.
The mitigations does make it negligible harder for someone to swoop in and take control over domains that currently have misconfigured name servers. But at that point the domains won't be resolving anything, so either the user don't care or aren't even using the domain.
So of course, if you tell the world "These guys over there are responsible for resolving my domains" you shouldn't be surprised if they actually do this.
2. Someone can register your domain first and you won't even be able to migrate in (at least without customer support).
Also, strict proof may not be necessary, there's the Cloudflare/Route53 way with a pool of nameservers used for verification. Cloudflare has a blog post explaining that: https://blog.cloudflare.com/whats-the-story-behind-the-names... (Disclaimer: I'm not sure if account-specific combos are attacker-proof. Definitely better than generic ones though.)
Given the decentralized nature of DNS it's very simple to set things up before you change the nameservers, and this is widely considered to be the best practice. This also solves the "two accounts trying to claim a domain at the same time".
The way Amazon does it sure helps mitigate it. I'm just not sold on the idea that it's their responsibility to solve this. And I suspect they do this for other reasons as well, like spreading out across multiple TLDs.
Yes, apparently I didn't think this through. That leaves the nameserver combo method.
> Given the decentralized nature of DNS it's very simple to set things up before you change the nameservers, and this is widely considered to be the best practice. This also solves the "two accounts trying to claim a domain at the same time".
That only solves the someone trying to snatch your domain after they find out your nameservers have changed. They can still initiate the claim before you do for any other reason.
> I'm just not sold on the idea that it's their responsibility to solve this.
That's an opinion (flawed if you ask me), and has nothing to do with whether proof of ownership is technically possible. And if the pool of combos is large enough and uniquely assigned to each account it's certainly a technical solution to the problem.
And don't get me wrong, I think the solution that Amazon and CloudFlare use are better than nothing. Having safe guards against people misconfiguring things are always helpful, and I'm sure it would result in fewer support cases.
No, the problem is people can have their domains snatched even without misconfiguring things. You keep saying it's the users' fault, when the same could happen when users follow whatever you consider best practices.
Some TLDs check for this, they won't transfer a domain to new name servers unless they already respond as authoritative name servers for that domain.
The argument is that someone else could set up a zone before you. But there can't be duplicate zones, and the user should create this zone before changing the name servers. There are mitigation strategies that have already been discussed, but other than being a Nice Thing (tm) and likely lowering the volume of support tickets I don't see how this is the providers fault. You set the name servers before checking that you had control over said name servers, or forgot to change them when moving away.
One of two things happen:
1. Both are allowed to initiate the claim before verification comes through (Cloudflare allows this, not sure about DO); result: domain snatched by attacker;
2. Only one initiation is allowed, in which case the attacker denied you your setup until a support ticket, and even then, how do you prove you’re not the attacker in the support ticket?
Either case, disruption can be caused by an attacker.
You keep saying mitigation is just a nice thing and providers are not responsible. What a weird hill to die on. Are you a provider?
On Amazon you can request a delegation set, which means a combination of four name servers. Do that enough times and I'm sure you'll have all the possible variations that could exist. For every Amazon account you can request 100 delegation sets, but it's easy to scale this out over multiple accounts. I'm also willing to bet you can easily get that limit raised to thousands of delegation sets by just telling support you're going to use the account for hosting tons of zones. I don't know the specifics of how CloudFlare does it, but I assume you're more than welcome to do the same, programatically.
There's no hill to die on. I don't work for a provider, and how is that even relevant? Seems like a weird straw man argument or something.
The potential risks of this is blown way out of proportions. You're still in control over the domain, just not the zone. Do stupid things, win stupid prices? In this case, letting someone else control your zone because you failed to understand how DNS works.
Defunct registrars is a interesting problem. If they don't have functional name servers then it is also very likely that they don't have a functional portal and customer support in order to change the NS records. Defunct registrars are thus a pretty manual problem, so sacrificing security for easier process seems like a bad deal.
A best practice should make the common case easy but secure, and the uncommon case secure and possible.
Nobody seems to complain at that... If I point my domain at GitHub, but then don't complete the setup process in the GitHub UI, I can't really complain if someone else sets it up...
Yes. After blocking the usual suspects, the great majority of SSH brute force attempts I see in my server logs now come from Digital Ocean IP addresses.
If they’re not doing it, I suppose they feel that the reputation hit they take if someone misuses it is better than the lost dollars from a little bit more friction during setup.
How about Cloudflare? I always assumed no one gets the same combo of NS and they actively monitor / remove domains that don’t point to the expected NS.
lots of previous discussion: https://news.ycombinator.com/item?id=12364297
You can partially mitigate the issue the way Amazon does it. But even that isn't foolproof and I suspect they have other reasons than just this for their approach.
That seems to be what Cloudflare does (I’m not positive though), but with 2 NS per account.
That said, having some safe guards for a common pattern of misconfiguration is always good.
I go and look up the details for DigitalOcean or Amazon or whatever and I put them in, but I either don't tell the hosting provider I've done this, or I later delete the domain in DO/AWS, someone else can come along and tell DigitalOcean that they own it (AWS as well, though it's harder since they have a bigger pool of name servers).
Once DigitalOcean believes that the new user owns it they allow them to edit the DNS records. The attacker can then point the domain at whatever server they like and "takeover" the domain.
The original owner can get it back by changing the details in their registrar. But in the mean time a bunch of traffic might have been intercepted by the attacker (all kinds of bad).
NB: this was the case in 2016 when the article was written, I have not checked if it is still the case.