Hello Cloudflare team,
My domain downloadrootexplorer.com got redirected to this illegal streaming site - {redacted}
After doing a little bit research, I found out that thousands of domains are redirected to this illegal streaming site. Here’s a list of those sites:
{redacted}
Please fix this bug. According to me, this is happening:
He finds out domains which are deleted from Cloudflare account after getting expired. Once they are renewed, then they are deleted from CF database after 7 days or something like that. (That’s what happened to me).
This guy created huge amount of Cloudflare accounts (to get almost every nameservers combination).
He adds this deleted Cloudflare domain in his Cloudflare account (with matching nameserver) & uses it to send traffic/backlinks to his site.
I hope Cloudflare will fix it very soon & will reward me
Hi @downloadrootexplorer, sorry your domain was hijacked. I’ve removed the urls from your post, no one on Community can assist with the issue you’re facing and we’d rather not have links to what you identify as illegal sites posted here. But, if you share the information with our Trust & Safety team, they can work with you and legal authorities to take appropriate action, https://www.cloudflare.com/abuse/form.
It is highly unlikely to be a Cloudflare bug, but if a domain is pointed to Cloudflare nameservers, but is not added to an account then this is possible. This is why it is never recommended to leave the nameservers pointing to Cloudflare without adding it to your account.
It should not. There should be security mechanisms (which exist and are bypassed sometimes). Since the behavior is unexpected it is a bug. I remember discussing this issue from two years ago.
It is possible in very specific circumstances and I wouldn’t really call it a bug. The domain expiring is not really related to Cloudflare, nor is it when a user doesn’t follow the correct procedures when adding a domain to the account.
It’s not necessary for the guy to add more than even a single account to Cloudflare, as nameservers on Cloudflare are a virtual as the linked article above states. He cannot however activate the zone on Cloudflare or proxy traffic through Cloudflare because Cloudflare will not reissue the same nameserver pair you had.
The serious security issue is that you pointed your nameservers to a service you were no longer using. When you renewed your domain you should have either added the zone back to Cloudflare or pointed your nameservers to a different service.
First, since you let your domain expire the issue would be all your fault, but I am gonna explain why it won’t happen. It’s explained in the article above as well.
He would need a ton of them, really. There are at least 2550 combinations, but now probably even more. In addition to that the NS assigned are per domain, not per account. While most often they will remain the same for every domain for simplicity they will change if conditions dictate it.
I really don’t see how he could do it. The only thing he could have done would be to add the zone to Cloudflare, keep it inactive since it wouldn’t have control of the actual NS at the registrar, and let it reply for people who query Cloudflare’s NS directly, which is no one since they aren’t recursive. They are not 1.1.1.1, but the actual woz.ns.Cloudflare.com and similar.
The issue here would have been if he renews the domain himself, but then it would be allowed for him to add his domain to Cloudflare and the problem was yours since you lost control of it.
Cloudflare’s NS are virtually the same, but are different for a reason: they are used to indicate ownership.
So it is not possible to hijack a domain pointing to CF without NS records?
Either one of these is correct:
If a domain is pointed to Cloudflare nameservers, but is not added to an account then this [hijacking] is possible.
Without taking control of victim CF or registrar account (client hacking) or registering domain after expiration (legal ownership) it is not possible to control a domain pointing to CF.
If the second is the expected behavior (which should be), then how to explain hijacking reports?
I would need to actually see the setup during an hijacking and I would guess the Cloudflare Security and Abuse team would be the best group of people to chat to.
That statement would be true if the domain owner weren’t point their domain to a service they don’t use. But they are. That is the security issue and it is an issue with the zone owner, not Cloudflare.
Imagine I order a pair of beautiful Italian loafers and I have them shipped to the mailing address in my profile, but I moved 2 months ago. If it a security flaw on the part of the e-commerce site I ordered from that the loafers are shipped to someone else? Of course not.
This is correct.
Why would this be the expected behavior? Let’s say example.com is currently using ns1 and ns2.digitalocean.com for it’s nameservers. I add that zone to Cloudflare.
In this initial state I am exactly as @matteo described in my first quote of him above. The fact I have added a zone to Cloudflare, but not updated my nameservers means nothing because no one is asking Cloudflare for resolution since my registrar has ns1 and ns1.digitalocean.com listed as authoritative.
At that point I can query individual records to confirm Cloudflare DNS is working as expected before I update my nameservers by querying it directly. (e.g. dig example.comMX@ian.ns.Cloudflare.com). Once I am confident that Cloudflare’s DNS is working I then update my nameservers at my registrar.
The zone owner here was not using Cloudflare (whether they were in the past or not is not relevant…the zone had been removed from Cloudflare). Declaring a service/thing/address you don’t use as accurate/authoritative is absolutely a security issue… but that declaration is done at the registrar level which is 100% under the control and 100% the responsibility of the OP.
In that I believe he actually was, it was removed from his account since the domain was expired (hence the NS changed to the registrar’s defaults). I sincerely can’t understand how the hijacking happened if the registrar, after the expiration (before it would have been in the OP’s account → the wiki above), removed the custom NS like usual.
Same as above, but I would guess (no assurances on my part obviously, @cloonan would have to ask the team and report back) that they wouldn’t issue the same NS as the ones already on the domain.
Most registrars restore the previous nameservers when you renew and expired domain automatically.
Sorry probably a language issue on my part. He was not using Cloudflare when he renewed his domain as it had been purged. He may have used it in the past, but that changed and the user failed to verify. If his zone had be active on Cloudflare it would have continued to work as expected… however it wasn’t.
This has been confirmed in the past, the same nameservers would not have been reissued by the Cloudflare system.
Agreed, but the hijacker never actually renewed the domain himself, he has took control during the time that the domain was expired.
In normal cases yes, but I don’t have confirmation of the system actually issuing different NS that the ones that are on the domain itself. I know it doesn’t use the same as another account. I presume having had the domain on another account it would count. Maybe the issue could arise (still doubt it, but don’t know) if the domain has never been active on Cloudflare.
Because CF needs to somehow make sure who controls the domain.
Let’s say we both create account on CF for controlling example.com
We would have a unique id on CF system:
cfAccountId=1 // OG
cfAccountId=2 // Xaq
We both add example.com to our accounts and set different A records.
1 => 123.123.123.123 // OG
2 => 456.456.456.456 // Xaq
Here CF needs to know who is the owner of example.com
Usually a random token would be created and provided to both of us to place in the root of domain.
1 => zahfooc7Aip4aeteiyigheicerooshei // OG
2 => Jook7theesh7ahye9eikeeyiequeezuj // Xaq
So when CF crawler checks example.com/token.txt if it contains the token CF assigned to Xaq then he is in charge and his A Record would be resolved and if example.com/token.txt contains the token assigned to OG he is the owner and his A Record would be propagated.
By CF does the authentication with less pain.
Providing two random NS names like bob and alice to Xaq and eric and kate to OG CF bot checks for NS records on example.com and the query result shows who is in control of the domain.
Consider in this scenario one of us owns example.com but after this challenge we both delete A reccords and forget about this.
Now Eve who is not the owner of example.com (say OG is the real owner) finds out OG has set NS servers to CF but doesn’t use the domain. If somehow Eve can use CF to point example.com to her desired IP address that’s a problem. Usually if I try to do so with a domain pointing to CF but without NS records I will be challenged to set CF tokens (the NS pairs) on the domain but according to hijack reports somehow this authentication mechanism is bypassed.
We can blame OG for pointing example.com to CF without setting records but still CF should authenticate Eve upon claiming that domain.
At the point at which the OP renewed the domain with their registrar, but was no longer using Cloudflare for their authoritative DNS they introduced a security issue. The issue is pointing your domain to a service you aren’t using is bad and people can exploit that. The root cause is user error.
The attacker likely added the zone to Cloudflare after noticing that there was a configuration issue… e.g. the zone pointed to Cloudflare for DNS but was not configured to use Cloudflare for DNS. Where the zone points and the configuration of DNS on that service is the responsibility of the zone owner, not Cloudflare. The zone owner misconfigured their zone allowing someone else to exploit that misconfiguration.
