So you point your nameservers at a third party, let your account with that third party expire, then someone later on can create an account at third party and resume control of the DNS zone? I mean yeah, but you mustn't care much about the domain and any credibility it has will evaporate quickly.
I had something similar happen to a client using Cloudflare. The attacker somehow was able to establish a new account(s) at CF that used the same free nameservers as my client. When my client's domain expired the attackers added the domain in their CF account, and were then able to control DNS. I reported it to CF security but I'm not sure if the loophole was closed. What I don't know is how the attacker was able to get an account with the same nameservers which are seemingly assigned at random (maybe not?). Maybe they just own/operate thousands of CF accounts?
Hate to admit it, but I had several domains get semi-hijacked using a cloudflare(esq?) technique, it went like this...
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.
> 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
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
How exactly does this happen in practice? When you add a domain to a Cloudflare account, can that domain actually "expire" and no longer be attached to the account? Or can the account itself and all the domains in it expire?
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.)
> How exactly does this happen in practice? When you add a domain to a Cloudflare account, can that domain actually "expire" and no longer be attached to the account?
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.
Not sure if you're emphasizing "claims" because you find it dubious so perhaps it's worth noting that the statement is coming from someone who claims (heh) to be an engineer at CF rather than someone working in PR/marketing. In case that affects the reader's view of the statement.
I don't necessarily find it dubious. I emphasized because I have not verified personally that the exploit is closed nor would that even be feasible (for me or anyone outside CF). I also previously reported this issue to multiple people at CF, offered more information and it was seemingly ignored/buried until this project called them out.
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.
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.
> 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.
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.