Don’t let your domain name become a sitting duck
krebsonsecurity.com
krebsonsecurity.com
Update: CF claims to have closed this loophole: https://github.com/indianajson/can-i-take-over-dns/issues/10
Also, when reading through the thread I shared it doesn't seem like CF or the researchers recognized the extent of the initial problem when they initially classified as "edge case". My client who was targeted was small and insignificant which caused me to doubt this an "edge case". Just my speculation.
2. CF assigns "semi permanent" nameservers like: bob.cloudflare.com
3. Attacker creates CF account and somehow gets assigned the same nameserver.
4. Once the domain expires, CF allows it to be assigned to a new CF account.
5. Domain comes back online with same nameservers.
6. Attacker adds domain to their CF account and now controls DNS because the nameservers stayed the same but CF allowed a new controlling entity.]
I butchered that explanation but whether that's a loophole, exploit or just an "issue" I'm glad it's solved.
CF says they now no longer allow previously used nameservers to be used again. The only problem with this is if someone swaps CF accounts hundreds/thousands of times and "runs out" of custom names.
1. Attacker registers hundreds/thousands of free CF accounts.
2. Each account gets assigned random CG nameservers (some dupes obviously)
3. Attacker than loads the assigned nameservers into a tool that looks for domains using those nameservers.
4. Attacker monitors those domains for accidental expirations.
5. Once expired, attacker adds domain in the CF account that matches the existing nameservers.
6. Once renewed domain comes back online, attacker controls DNS at Cloudflare.
If the domain is expired, someone else can buy it. This is normal. I don't understand where the attack is.
It’s not necessary for Cloudflare to remember or to reject all previously assigned name servers: Cloudflare can simply fetch the domain’s cached NS records before DNS enrollment and refuse to assign them again.
I don't see why Cloudflare would do this. If you stop paying for a paid tier, I figure your account and the domains associated with it would still exist in the free tier. I can see how this could happen if you manually remove the domain from your account but don't change the nameservers (at least before they fixed it so the previous nameservers will never be assigned to the same domain in the future), but when would Cloudflare automatically expire the domains from an account or automatically expire an account itself?
(I can potentially see this happening for providers that don't have free tiers.)
Basically yes. When you have a domain in setup in CF (free tier), and the domain expires CF will inform you "nameservers no longer point to CF" and then if you do nothing, CF will remove that domain from your account. This process might have been altered, I'm sure someone will correct me if I'm wrong.
registered a bunch of domain names, had my registar auto set to make all new registered domains auto point to cloudflare..
some months later I found that a domain was pulling up some shady site..
So I never went into my cloudflare account and added the domains there, but the dns from uniregistry was pointing to alex.cloudflare.. and so sneaky perps I assume created a CF account and added my domain name there and then pointed it to their server..
I reported this - never heard back. found the issue with another domain, reported it, never heard back.. got busy.. found another domain name that had the same 'exploit', running through CF... didn't bother reporting it.
No longer auto-pointing to cloudflare for new domains.
Actually no longer pointing any new domains to CF but that's other reasons.
Neat to see how people find ways of exploiting wierd misconfigs, I gave them major props for pulling it off, and gave CF non-props for not responding with 'we found person X who was pointing your domain without permission, and found all associated..' whatever.
To me this indicates it may have been a widespread problem. Really calls into question this hypothesis and the categorization of it being an "edge case":
>At this point, it would take upwards of 450 Cloudflare accounts to get an account that matches one of your specific vulnerable domain's nameservers. Additionally, in my experience, there is only around a 10% chance of success even if the nameservers assigned to your account match the domain. While this is a far cry from the theoretical 200,000 accounts previously believed necessary, that's still a lot of work to perform a targeted takeover. *https://github.com/indianajson/can-i-take-over-dns/issues/10
> There is a frequently updated list published on GitHub called “Can I take over DNS,” which has been documenting exploitability by DNS provider over the past several years.
https://github.com/indianajson/can-i-take-over-dns
Whoa, names like Digital Ocean, Google Cloud, Linode, Hurricane Electric - all classified as fully vulnerable.
This doesn’t feel any different than letting your domain expire.
What happens is Alice creates some DNS records for example.com which is registered elsewhere. Everything is fine.
At some point (maybe Alice forgets to pay the bill) the DNS records expire.
A bit later Bob makes an account at the same DNS provider and makes DNS records for example.com. This is possible because Alice's records have been deleted. Bob has now effectively taken over example.com
The due diligence missing is that the provider could have kept a record that the DNS records were owned by Alice. They should have been asking questions (or doing additional validation) when Bob tried to create new ones for example.com.
So as sibling says it's a case of changing the ns to some other provider, or else I suppose a support case to somehow prove you do own the domain, so please assign control back to your account.
Isn’t that this covered by e.g. OVH that sends you at least a dozen of emails before your domain expires?
In this "attack" the domain is not expired.
A dns company that goes into commercial relationship with a customer should try to prevent themselves from being used in a crime. DNS registrars are already very much used to this since fraudulent registrations are common place, and top registries generally demand some minimum standards when dealing with it. It is not a major leap to demand something similar from dns services.
The issue is kind of similar to account creation bugs, where a user name ALICE (all caps) can masquerader as user Alice. If the new user claims to be alice, they either have to log in with the old account (alt using an account restoration process), or they have to validate that they are in control of the domain name. Validating a sub domain is fairly easy, but even a bare domain is doable using unique ns records, alternatively using any third-party validations (e-id, company registrations, etc.) that other part of society is already using for validation.
I see this as a purely dns industry problem that can be solved using existing tools and expectations.
You just shouldn't point your domain into DNS providers that aren't providing DNS for you. If you go and add them to your domain, it's reasonable for the provider to decide that what they are doing is correct.
Anything you add here (are people thinking about some hard to write TXT record? It surely looks like so) will break more things than it fixes.
This is generally the level of diligence (i.e. emailed verification link) that registrars are held to. DNS providers should be held to the same when the requesting account isn't the same account that created the 'earlier' zone file for a given domain at the very same provider.
Maybe we should add a requirement that the zone register sends some notification on behalf of the DNS provider. That could work, at least on the TLD level.
Point being that, short of transfer Auth-Codes[5], a verification link sent to the registrant's email address by the DNS provider is the functional equivalent of nearly the most that a registrar may be required to do in order to contact and/or verify a registrant.
[1] https://www.icann.org/resources/pages/ra-agreement-2009-05-2...
[2] https://www.icann.org/resources/pages/ra-agreement-2009-05-2...
[3] https://www.icann.org/resources/pages/benefits-2013-09-16-en
[4] https://www.icann.org/resources/pages/registration-data-accu...
[5] https://www.icann.org/resources/pages/auth-2013-05-03-en
So the only way the DNS service can get a notification to the domain owner is if it's forwarded by the registar.
The DNS provider absolutely can send a notification to the registrant without having to 'go through' (meanining interact with) the registrar. Even a third-party privacy service merely exists as a notification broker. Any notification sent by the DNS provider would simply pass through onto the registrant directly.
[1] https://www.icann.org/resources/pages/governance/bylaws-en/#...
In the case of a large-scale, multi-domain authoritative nameservers assignment change, only the DNS provider would be able to facilitate the process programmatically. And at that kind of scale (i.e. hundreds of domains), one would hope verification would not only be obtained through, but require some form of human-to-human contact coupled with thoroughly documented scope.
It seems like the vulnerable providers either respond from or assign prior NS hosts, sometimes with randomized lottery thrown in, which only reduces the takeover probability.
Krebs's article also mentions it:
>What did DNS providers that have struggled with this issue in the past do to address these authentication challenges? The security firms said that to claim a domain name, the best practice providers gave the account holder random name servers that required a change at the registrar before the domains could go live. They also found the best practice providers used various mechanisms to ensure that the newly assigned name server hosts did not match previous name server assignments.
- Enable 2FA
- Check that your domain is set to auto renew
- Lock your domain from transfer
- Check your payment details
- Use a reputable domain registrar
- Be sure you actually own your domain
- Extend your domain registration
- Be aware of any TLD-specific rules around renewals
from: https://onlineornot.com/guidelines-to-help-avoid-losing-your...
If society fails planning likely won’t help.
Sometimes luck is all one should relay on.
I have told my kids but who knows if there listening. I’m in process of buying a sailboat and wondering how important a domain name is.
> I registered a new domain at one registrar and immediately asked they change the IPS tag to another. A coworker [saw] ... the tag change, but then I got distracted looking for cake/looking over their shoulder. They set up a new account at the second registrar and claimed the domain, using no secret information and without either registrar or Nominet gaining my consent.
To be clear, the IPS was (is?) publicly visible. So you could poll a list of domains looking for it.
It's worth noting that even if you registered .co.uk with e.g. Gandi, you still get a separate Nominet account with it's own authentication. It doesn't matter if you add 2FA etc - after such a transfer, the domain was registered to a different nominet account.
1. I register a domain name -- example.com -- with a registrar like NameCheap. They tell Network Solutions (the .com registry) to add records on my behalf like below, which means the rest of the internet asks NameCheap's nameservers when they want to look up my domain.
example.com. 172800 IN NS ns1.namecheaphosting.com
example.com. 172800 IN NS ns2.namecheaphosting.com
example.com. 172800 IN NS ns1.he.net
example.com. 172800 IN NS ns2.he.net
4. Now this HE customer has control over my domain... because I told my registrar to change the NS records to HE's nameservers. Why would I ever do that?
My understanding is this should never happen, I have no reason why I'd want to make such a change. ICANN have a policy on domain transfer between registrars: https://www.icann.org/resources/pages/transfer-policy-2016-0... -- and transferring a domain should only be done with the gaining registrar (HE in my example) putting an explicit request to the losing registar (NameCheap in my example), and the losing registrar getting to decide yes or no to the transfer.
So... how are there a million or more domains at risk this way? Is it old practises that haven't been corrected? How would this work?
The issue would be more like:
1. Register your domain with namecheap, and you want to have digital ocean run your DNS, so you point the domain to use their name servers.
2. A few months later, you decide to stop using digital ocean DNS, so you delete all your records… but you forget to change your NS record at namecheap, so now someone else can now add that DNS name to their digital ocean account.
This would only happen if your aren’t actively using the DNS name, which would allow you to have it point to a NS you aren’t controlling.
It is not a huge security hole, but just something that will cause issues for some people.
What users would do is, add DNS records to their DNS Manager to point their custom domain to Gitlab Pages, later will delete the Gitlab pages when not wanted any more. Scammer will simply point that same domain to his fake repository, thus hijacking customer domain.
Gitlab then made customer add a Txt Record for verification of domain. Scammer's txt record value is different from customer txt record, scammer can't modify DNS records.
This is unlikely to be an issue on their primary domain but could be for e.g. subdomains or some marketing domains that aren't really in use anymore. Or cases where domain is just be squatted.
However, other posters have given a more plausible example: you have server hosting with someone who isn't also a registrar, so for simplified management, you get your registrar to point your domain's nameserver at the server hosting company's nameservers, delegating it all to them... now you just need one customer portal to update all your hosting and DNS entries... and then you leave the hosting company (maybe the bill's too much), and you also forget to clean up the NS records, pointing them back to the real registrar's nameservers, so they're still pointing at this server hosting company you're no longer a customer of.
The hosting company isn't a registrar and is under no obligation to follow ICANN policies, so they can give the domain to some other customer of theirs without doing any verification. (I'm not sure they can do domain ownership validation, if they're not a registrar themselves)
(I would also never maintain a registration nor a zone file with a web/cloud hosting service.)
I want my domains at dynadot or namecheap or hexonet, but want CloudFlare to manage all DNS. CF doesn't support al ccTLDs.
Hosting company can not "give" the domain to anybody. If domain is still pointing to Hosting with NS records, anybody could make an account at Hosting, and add that domain. Now that scammer controls whats visible at Domain, but he is not yet the owner of domain.
Owner is who control and can change NS records. Scammer can change all other records, but not NS. NS is at original domain registrar. Original owner can very easily change the NS and cut the scammer out of everything (& should).
Gitlab used to be like this. You add a domain to Gitlab. You add an A record to your domain registrar or NS Manager. Now your domain shows your Gitlab Page. After few months, you don't want the pages anymore. You delete the project from Gitlab. You ignore to delete the A Record. Scammer adds that domain to his Gitlab, and shows his content at your domain.
Now Gitlab asks you to add a verification TXT record when adding any domain. Scammer's veri record is different. He can't prove that he owns the domain.
> Gitlab used to be like this
That's what I'm saying. Hosters can "give" a domain (i.e. control of that domain's records on their nameserver only) to someone else, because they're not registrars and aren't _required_ by some painful business contract with ICANN to have to take change of ownership seriously.
They should require a domain validation challenge to add a new domain, like your Gitlab example, but it doesn't seem like anyone can make them.
So therefore the onus is currently on the domain owner not to leave their domains' NS records pointing at nameservers they don't control!
That's exactly right. That is how this "attack" happens. Bad actor exploits registrant's abandoned yet still authoritative third-party nameservers assignment.
Discussion elsewhere in this thread[1] of how some of that responsibility/risk could be spread/shifted onto the DNS provider.
Its like you put a lock (NS) on your box (Domain). After few months you don't care about that box anymore and leave that key in the wild. Anybody can pick that key and use the box. The box holder (domain registrar) can't make you verify that you are the original owner 'by' asking you to open the box, because by default, anybody who has key, can open the box. The correct way & responsible way is to destroy the box (delete the domain) or at least destroy the key (unpoint the third party NS records).
The only provider I know who does this correctly is AWS Route 53. Your zone gets assigned 4 unique authoritative servers from a set of namespaced shards. eg ns-2048.awsdns-64.com
Someone else can create a zone for the same domain but will map to different shard so no real world effect.
Always surprising to me that hardly any providers do it.
The Route 53 technique of assigning random server names looks a bit like the technique of creating virtual hosts in a nginx server, but it looks like this is a custom AWS implementation and not something that comes out of the box in any DNS server software I know.
I would just recommend cleansing the domain from any systems you may have used it on and ensuring that you have no other technical ties the domain. Treat it just like any other domain you do not own.
If the account is validated on large platforms, it should be a good idea to remove those from the account as a way to signal the platform that it is no longer validated on that site.
I've done this with zones I've had for a while - it sucks since you want to be a good net citizen and not let the zones be used for spam/attacks. You end up paying for a domain for years after you stopped needing it.
The best defense is to set up the delegation at the host first, then set up the delegation information at the registrar. A stub zone is could be run indefinitely (as long as there were no name collisions) before a formal delegation from a TLD is set up. Gives you time to set things up the way you want before it is reachable from global DNS tree.
> DNSMadeEasy founder and senior vice president Steve Job
That name surprised me. I thought it couldn't possibly be real. I looked it up and apparently that's actually his name; presumably no relation to the plural one who ran Apple. Most articles seem to write his first name with an N to make it more believable.
As I posted on Krebs' article:
This is neither news nor new. There have been prior panics around this “water is wet” type issue going back at least a decade.
(Search up “Floating Domains – Taking Over 20K DigitalOcean Domains via a Lax Domain Import System” – and others).
I also wrote about this on CircleID from the DNS operator’s perspective (“Nameserver Operators Need the Ability to “Disavow” Domains”) – after this same issue was used to DDoS attack another DNS provider by delegating a domain to their DNS servers without having setup an account there, and then doing a DNS reflection attack on that domain. That was over ten years ago.
The fact that people can delegate their own domains to somebody else’s nameservers without ever properly setting up a zone on those nameservers, or ever keeping track of where THEIR OWN DOMAINS point is 100% the responsibility of the domain owner – and to varying degrees a function of their REGISTRAR – who is the only entity that has any control over it.
It’s a weird flex for corporate registrars who purport to be “high touch” and exclusive, to simply shrug their shoulders and turn a blind eye to their own clients’ obviously broken and vulnerable nameserver delegations.
For our part this is specifically one of things we actively monitor and alert our clients about.