Cloudflare Bug - My blog got redirected to this illegal site

:wave: @Xaq,

Cloudflare does authenticate Eve. It provided her a pair of nameservers to configure at the registrar. She will not be able to do that because I own the example.com domain. As such she will never be able to get an SSL cert issued or orange cloud a record she creates. The zone will never move beyond pending nameserver updates and will ultimately be deleted and purged from Cloudflare.

Ok, so my Italian loafer example didn’t resonate. How about this… lets say you have a website running on a virtual server 192.0.2.1 and you point your website www.coolsite.com to that IP using an A record. You then stop paying your bill for the virtual server, the service deletes your virtual machine. I use the same service and they reuse the IP 192.0.2.1 and I stand up a website on that host which accepts any host header. Have I hijacked your website or have you misconfigured your system? Where is the hosting company’s culpability?

No it’s not bypassed. In your example OG introduced a security issue that is being exploited by pointing his domain to a service he is not using.


Here try this… go to freenom and register a domain. Set it’s nameserver pair to ian.ns.Cloudflare.com and amy.ns.Cloudflare.com at freenom. Then add the zone to your Cloudflare account. The nameserver pair doesn’t match, the zone will never activate. The misconfiguration at your registrar is not Cloudflare’s issue, that is 100% under your control.

-OG

I registered nameserverCloudflare.cf.

Nameservers:

ian.ns.Cloudflare.com
lola.ns.Cloudflare.com

(my account does not currently receive these nameserver pairs)

Now, when I add it to CF, it asks me to change the nameservers:

image

I then add two non-proxied records:

Now,.imagine the server IP is a server set to always redirect to a porn/illegal/etc. website.

Even though the domain is not activated in CF, due to how CF will return DNS records before zones are active (to not break websites during the CF transition), the DNS will return this account’s DNS records.

$ dig nameserverCloudflare.cf @1.1.1.1 +short
192.0.2.1

No, this domain won’t get SSL (and I don’t think the proxy will work, maybe) but it doesn’t need that. Non-HTTPS and non-proxied DNS is all attackers need to take advantage of domain owners that set their nameservers to CF without adding the site to their account.

2 Likes

That works and CF is not responsible for such hijack. But this is not the case. Among all cases I have seen here all were claiming IP was changed. Unfortunately neither of them revealed the domain name. The last report shed light on that even NS pairs were not changed. Say alice and bob were on the registrar and user has an A record to 1.2.3.4 but at the time of hijack report CF resolved domain through john and kate to 5.6.7.8.
Whatever the hack is, it is more complicated than finding a unused domain pointed to an IP and acquiring that IP or brute forcing CF to generate the same pair of names.

:wave: @Xaq,

Forget Cloudflare. Is the hosting provider responsible? They provided the IP I pointed my A record to. Someone has “hijacked” my website, whose fault is it?

Yes, my example doesn’t involve Cloudflare, it involves pointing something you manage to a service you aren’t using. It was an attempt to demonstrate that the security issue here is not whatever the service is, it’s someone pointing to it when they don’t use it. PEBCAK

I gave you the steps to repro with freenom using a free domain. It’s not complicated at all. Add an A record to the zone you register in the inactive zone on Cloudflare and point it to a server you control. It will resolve.

-OG

I don’t get your point. You have passed authentication:

dig NS nameserverCloudflare.cf @1.1.1.1

nameserverCloudflare.cf. 86400|IN|NS|deb.ns.Cloudflare.com.
nameserverCloudflare.cf. 86400|IN|NS|gabe.ns.Cloudflare.com.

You mean you have set registrar to ian.ns.Cloudflare.com and lola.ns.Cloudflare.com (didn’t change to deb and gabe) and I get deb and gabe through dig query?

Uh… this is odd

$ dig nameserverCloudflare.cf @1.1.1.1 NS
nameserverCloudflare.cf. 10629  IN      NS      gabe.ns.Cloudflare.com.
nameserverCloudflare.cf. 10629  IN      NS      deb.ns.Cloudflare.com.

Same for Google DNS:

$ dig nameserverCloudflare.cf @8.8.8.8 NS
nameserverCloudflare.cf. 21599  IN      NS      deb.ns.Cloudflare.com.
nameserverCloudflare.cf. 21599  IN      NS      gabe.ns.Cloudflare.com.

but using the root cf to look it up:

$ dig nameserverCloudflare.cf @d.ns.cf NS
nameserverCloudflare.cf. 300    IN      NS      ian.ns.Cloudflare.com.
nameserverCloudflare.cf. 300    IN      NS      lola.ns.Cloudflare.com.

And in freenom:

1 Like

My guess is the existing NS (ian, lola) are broadcasting the NS deb and gabe as authoritative.

If the domain was already on CF, this wouldn’t be a problem as then they would broadcast themselves (since this is the issue we have with .de domains when moving domains between CF accounts, as it requires the nameservers advertise themselves as authoritative).

2 Likes

Then problem solved. Cannot believe this :face_with_head_bandage:

:wave: @xaq,

No you haven’t. Is the zone active? No. You’ve introduced a security issue by pointing a domain you own nameserverCloudflare.cf to a service you aren’t using.

Now an attacker (also you in this instance) has signed the zone up to Cloudflare and gotten an alternate nameserver pair. The attacker can add records in that zone and Cloudflare will resolve them. Eventually the zone will be removed from Cloudflare, but as long as your configuration error at the registrar exists, you are vulnerable to being exploited.

-OG

2 Likes

:wave: @Judge,

In the link @matteo shared early in the thread Cloudflare nameservers are described as virtual constructs. Hence asking any Cloudflare nameserver a query will return a result for a zone on Cloudflare (usual issues with zones pending multiple times not withstanding).

Security issue is still the misconfiguration at the registrar.

-OG

Correct, it is ultimately a configuration issue.

I’m not sure about the turnaround time, but I believe a source of the problem is generally bots that look for newly registered domains with CF nameservers, test to see if any CF nameservers advertise themselves for that domain, then use the API to add them to their account if it hasn’t been added to CF yet by the owner.

1 Like

Domain hijacking 101

Exactly!

I have to admit I am a bit lost in this conversation.

I generally agree with @OliverGrant that the initial mistake was to keep the nameservers pointed to a service which the OP no longer used. That being said, I’d argue that fact should still not serve as reason for Cloudflare to authenticate that domain on another account, respectively give that account control over the domain’s records. I understand this is the argument you are making however, @OliverGrant. Is that right?

I believe it should be pretty simple, as long as a domain does not have the assigned nameservers set, none of the DNS settings in that account should be effective.

Maybe I am missing something, as I said initially, I am a lost at this point :smile:.

:wave: @sandro,

It doesn’t.

Absolutely not. My argument is OP’s failure to properly his own system/settings is the cause of this issue. Full :stop_sign:.

What happens when Cloudflare’s NS validation algorithm is in a 2 hour backoff window and I update my nameservers at my registrar? My properly configured Cloudflare account returns NXDOMAIN for my :grey: records until the algorithm finally validates my nameservers are set correctly? :see_no_evil:

-OG

Is that not what happened in this case? Another Cloudflare managed to control DNS records even though the domain was never specifically pointed to the nameservers issued to that account?

I am afraid I am not sure what scenario you are describing here. Could you elaborate please? What exactly do you mean by “backoff window” in this context?

Cloudflare never authenticated the domain in the new account. The OP introduced a security issue in their configuration of their domain at their registrar and it was exploited. Steps to repro are above, if you can do it in a manner where the domain in question becomes active in your account without you changing the nameservers at your registrar then you have found a :logo: bug. But that isn’t what happened here and in all of the threads like this it has never turned out to be what happened.

Register a new domain at Freenom. Add the domain to your account in Cloudflare, but don’t update your nameservers. Cloudflare will check quickly at first but eventually wait longer an longer between checks for nameserver configuration. In a week change your nameservers at your registrar and see how long it takes for the zone to go active on it’s own (can’t assume the whois propagated to whatever Cloudflare uses to check because clearly that doesn’t always match up and it won’t allow you to recheck more than once an hour).

With your described implementation my production domain won’t answer until it has been validated by Cloudflare that the nameservers match?

-OG

Yet, that account controlled the DNS records.

I am not arguing the OP did not contribute to this situation. What I am saying is Cloudflare did so too by allowing it to be exploited. And this is my point. That should not have happened.

Precisely, and this is how it should be. The point of the validation is to validate, and Cloudflare should not respond before that validation passed.

I’m so wishing I could get my Editing privileges back to I can re-title this thread:
Cloudflare Bug - My Post got redirected to this long-winded debate
:rofl::rofl::rofl::hugs:

5 Likes

:wave: @sandro

Can you point to another major DNS provider that doesn’t answer DNS queries until the nameservers match at the registrar? I’m not aware of another one which has the validation mechanism you say Cloudflare should have.

And the domain hasn’t been validated… not sure how many times you’ll ignore that.

-OG