Responsible Disclosure: CloudFlare - more interested in tracking than security
Bug Bounty cloudflare NaBloPoMo security · 2 comments · 450 words · read ~552 times.
CloudFlare claim they want to secure the web - but they seem more interested in tracking their customers than giving them decent security.
Upon registering with the Internet giant, users are encouraged to confirm their email addresses. So far, so standard. This is the confirmation message CloudFlare sends out:
Looks good! Hey! I wonder where that garish orange button goes?
WHAT!?! An http URl? Surely some mistake. Every baby-in-a-basket knows that we should use https everywhere.
No matter, I'll click on the raw link underneath. That's got an https at the start, right? WRONG!
Yup, the clumsy clowns at CloudFlare have managed to turn a secure URl into an insecure one. Bless.
Why do they do this? Because they want to track every click on their emails. Their statistics are more important than your security.
Why is this bad?
Links to http sites are not secure. That means your visit to that URl can be seen by your ISP and anyone else between you and your destination.
A user clicking on that insecure URl risks having their request intercepted. While an attacker can't log in using the data they've captured, they would be able to redirect the user and phish their details.
It gets worse!
Hey, at least email.cloudflare.com belongs to Cloudflare, right?
Well... Not quite. Visit it, and you'll find that it is run by Customer.io's edge event collection service.
Visit an incorrect URl like email.cloudflare.com/example and you'll be taken to Customer.io's site.
Basically, if Customer.io gets hacked, or goes rogue, they can start phishing all of Cloudflare's customers. Nice...
How to solve it?
STOP TRACKING EVERY LINK IN YOUR EMAILS!
Or, if you really have to - make sure your tracking server supports https and is controlled by you.
Disclosure timeline
I went through HackerOne in the vague hope of getting a tiny bug bounty.
- 2018-10-19 - Disclosed
- 2018-10-26 - Response from HackerOne asking for clarification
- 2018-10-27 - "We were able to validate your report, and we have submitted it to the appropriate remediation team for review."
- 2018-11-05 - Informed them that I indented to publish on the 19th. Received no objection.
- 2018-11-19 - Response from HackerOne "It looks like the problem has been solved and future emails will provide https:// verification links."
- 2018-11-20 - Published
All this has happened before...
This is an identical bug to the one I disclosed to Udacity who were kind enough to say thanks and send me some merchandising.
€100 Bug Bounty from Intigriti - please stop tracking your confirmation emails!
Andrew McGlashan says:
I get you when it comes to https vs http and I also get you when it comes to tracking.
But..... there are email service providers, like it or not, that muddy the waters badly.
I agree that Cloudfare should be 100% responsible for everything with their domain name and services, but they seem to use gmail for the mx servers (not themselves), they /seem/ to use Google for captcha as well, which I hate and they won't change. They outsource sending other emails with the sub-domain to customer.io (without any SPF records to support that, they so have SPF on their "main" domain name though[1]) -- do I like that at all, absolutely not. People use mailchimp and all sorts of other "services" to send and track emails. I REALLY HATE THAT. I wish we could convince ALL major providers to NOT do tracking and also to do as much as possible in house and not rely on third parties for services such that it makes their service seem non-trustable by someone who cares about these things -- granted probably 99+% of people are not technical enough to even care, let alone understand what may or may not be going on behind the scenes.
[1] Now, their SPF is likely, although it looks okay right now, going to cause real problems with all those DNS lookups due to the includes! However there are quite a few service providers than are allowed to send emails as @cloudflare.com -- this includes mcsv.net, Google, Mandrill, Zendesk, CustomerIO and stspg-customer (whomever that is) ... 🙁 What a dog's breakfast indeed.
Šime Vidas says:
They use a third-party service for their frickin’ login tokens? Is that also why I have to keep logging in every time I visit cloudflare.com? Is that handled by a third party, too? (I have strict tracking protection in my browser, incl. cookies.)
I hope this is not as bad as it sounds.