I did the same to Shopify about 12 months ago or less and their response was , first please remove the takeover from your panel and then second we are aware but wont fix.
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.
As someone who was recently pitched the role for running a bug bounty program I insisted on a resource commitment from all other stakeholders. Otherwise it’s effectively hush money.
I got what I wanted, but I fear not everyone knows what to ask for.
I'm not sure that the researcher did any actual damage? I guess they could have taken over one domain to show the vulnerability rather than all of them.
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.
Aye, adding a random sample of 10, or probably even just one of those domains which you have manually checked to see it wasn't in legitimate use, would have accomplished the same goal.
I did similar on 123 Reg a few years ago to rescue a client.
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.
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.
The article says that Route 53 uses randomly generated name server names, so if at your registrar you are pointing your domain to Route 53 name servers, and then you remove the records for your domain at Route 53 but leave the record at your registrar pointing to Route 53, it is unlikely that another Route 53 customer could add your domain and get your traffic. Their randomly generated Route 53 name server names would probably not match yours.
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.
When you create a hosted zone in Route53 you have two options, either let them pick a delegation set for you at random, or request a delegation set upfront, which can be used when creating a hosted zone.
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.
Maybe I'm missing something here, but isn't this only a problem if you migrate your domain DNS away from DO and forget to also change the nameserver with your registrar?
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.
1. The guys over there responsible for resolving my domains should probably verify that they're actually my domains. You want to offer an authoritative nameserver service you better take it serious.
2. Someone can register your domain first and you won't even be able to migrate in (at least without customer support).
I'm not sure how you imagine that you could prove that you owned the domain, on a technical level. You're updating the NS-records for your domain at the top level domain, being able to do that should provide enough proof that you in fact own this domain.
Of course there are ways to prove you own a domain, e.g. one way Google verifies domain ownership is through a TXT record, the content of which is only known to you until you set it. (Well, that doesn't work if the registrar doesn't offer any DNS service other than submitting NS records to a zone file.) The NS records updated to generic, known values shows that someone who owns that domain intends to use your nameserver, but that someone doesn't have to be the one claiming the domain. If two accounts try to claim a domain at the same time, and the NS records have been set, which account do you award the domain to?
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.)
When you're changing NS-records you're actually updating the TLD, so at that point any other records should be considered moot, like the suggested TXT record. How do you imagine people migrate if the current name servers aren't responding any more?
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.
> any other records should be considered moot, like the suggested TXT record
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.
They can claim the domain before you, but like you mentioned used in combination with a matrix of name servers this should quite easily be mitigated. Another solution is to time box new zones.
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.
> Having safe guards against people misconfiguring things are always helpful
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.
No, they can't. The user has either failed to complete setting things up, or forgot to change the name servers to something else after removing it. It's a configuration issue created by the user.
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.
> But there can't be duplicate zones, and the user should create this zone before changing the name servers.
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?
The owner of the domain is responsible to make sure they are in control of the zone where they've decided to point the name servers. Failure to do so means that anyone able to create zones on these name servers can do so.
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.
For the vast majority of registrars you would find it hard to find one that do not offer DNS. For defunct registrars it does get more tricky but you can have better security than what is provided here. Have the customer first create an account and link the domain to the account and then change NS rather than the other way around. This solves the issue of people discovering domains that point to DO but has no linked account.
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.
Does anyone know whether this issue was fixed by Digital ocean after 4 years ? or you can still add anyone else's Domain name in your account in digital ocean, even after so much outrage back then ?
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...
This was posted in 2016, but their process hasn't changed. I'm not sure if it's actually caused any real damage yet (usually you'd add your domain fairly quickly), but it seems crazy that in between declaring DO as your DNS provider and importing the domain on DO, it can be stolen.
DigitalOcean have a HackerOne programme which... is a much better way of getting an issue like this flagged in a reasonable manner. I'm not surprised the account got banned. https://hackerone.com/digitalocean
> I wish Digital Ocean would do something about the amount of abuse from their network.
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.
I blocked their entire IP range from my network. Cloudflare WAF shows the amount of nonsense coming from their network. Bots and a lot of hits in the fail2ban logs.
Clearly this an issue, and clearly AWS has at least mitigated it. How hard is it for other probiders to do the same?
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.
Really? Do you mean you’ll eventually get 4 matching NS or just overlap 1?
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.
Not every decision is based on a rational weighting of risks and benefits. More likely scenario is that this simply hit the desk of someone who doesn't care.
I don't think there are any solutions to this on a technical level. There's no way for you to prove that you own the domain, besides setting the NS-records.
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.
It's a smart way to at least make it a lot harder to take over a misconfigured domain this way, but like I said in another thread, I'm not sold on the idea that this is their responsibility.
That said, having some safe guards for a common pattern of misconfiguration is always good.
Say I register a domain with Namecheap. Namecheap will ask me who I want to resolve the domain (or offer to do it themselves).
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.
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:
https://www.youtube.com/watch?v=1PGm8LslEb4
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.