Cloudbleed: Cloudflare CDNs, does it impact 1Password? [no; see blog.agilebits.com]

AGAlumB

@MrC: This is really cool! Thanks (again) for all the scripts! :chuffed: :+1:

jd4840

For grins, I did a 'git pull' (to get the latest version) and re-ran the Node script on my Linux box, then I ran the Perl script on my Mac. Thanks again to these two very helpful folks who took time to write these scripts.
Here are my results:

The Perl script didn't flag: lovesac.com, polymail.io, kik.com, nytimes.com, plex.tv, propellerheads.se
This time, the Node script didn't flag: typepad.com and yelp.com.
The Perl script found softwareforscreenprinters.zendesk.com so I have one more password to change.

MrC

@jd4840,

I've updated the zip package this morning to include the latest suspects list. One domain from your list above was added:

$ git log | egrep 'lovesac.com|polymail.io|kik.com|nytimes.com|plex.tv|propellerheads.se'
    Add nytimes.com
    Add nytimes.com

I'm don't know anything about the others, but you could check their sites for any information, such as this post for plex.tv (on your list):

https://www.plex.tv/blog/plex-cloudflare-important-security-update/

I've added myself to be notified when there are changes to the list, and will push a new version of the zip file to Dropbox when I receive update notifications.

tinywzrd

@MrC Thanks again for this! I wish I could favorite this post or follow your user somehow~!

MrC

@tinywzrd,

You're welcome, glad to help out.

DanielP

An official thank you to @MrC from me too :) The script works great, thank you so much for taking the time to do that.

danco

Yes indeed, thanks to MrC for all his work on this and other things.

DanielP

Also, @MrC, if you replace line 41 in your current version of the script with this:

say "Suspect URLs (" . scalar @found . " found)";

It will also print out the number of potentially affected URLs. Just a very minor change, but maybe some users will find it useful to see this at a glance.

MrC

@DanielP,

I like the idea - done! Thanks.

Want to help my optimize the script more by creating additional levels of domain component hashes? :-)

DanielP

@MrC,

Although I would honestly love to, I must admit that Perl is not my bread and butter, so I am not sure how much help I can offer :P How were you thinking of using multiple-level hashes in the script though?

MrC

@DanielP,

I was (almost entirely) kidding, and I get it - Perl is a bit arcane.

Initially the script tested leading matches for each URL against the suspects list. This of course is slow, and wasteful. So, I split the host/domain names into components, reversed them, and populate a hash by root domain component. This greatly increased performance. The next optimization would be to create a second level hash for the second component of the domain.

DanielP

@MrC,

Got it, that makes sense. My experience with Perl so far has stopped at using hashes, anything over single-level hashes is still outside of my comfort zone :P And yeah, arcane is a fit adjective I think :)

Superfandominatrix

Hi, I saw the update today indicating the CloudBleed domains were going to be included in 1PW Watchtower security audit feature. Thanks! This is why I have my entire family on 1PW.

https://blog.agilebits.com/2017/02/28/watchtower-keeps-you-safe-on-cloudy-days/

I've looked at Watchtower this morning after this update and it doesn't seem to be working. I have accounts with nytimes.com and glassdoor.com and per this next link, they both should be coming up as a potential vulnerability.

https://github.com/pirate/sites-using-cloudflare

So far I have manually refreshed Watchtower via ctrl + > Watchtower > Update now, but still nothing is listed in Watchtower.

What is the source for affected domains in Watchtower? If I store the log in URL like "https://myaccount.nytimes.com/auth/login?URI=http://", will Watchtower correctly identify this style URL as the affected "myaccount.nytimes.com"?

Ben

Hi @Superfandominatrix

Thanks for writing in.

Just because a website uses Cloudflare does not mean that they were affected by this. For example we use Cloudflare for some things, but because we do not rely on SSL as the only layer of protection we were not affected.

We'll only add a site to Watchtower after a 1st party confirmation that some or all of their services were affected. We do not flag sites simply based on 3rd party speculation. The exception to this is when we can test a site, such as we could with Heartbleed. Then, even when we do not have 1st party confirmation, we may list a site based on evidence we're able to gather ourselves.

Watchtower checks sites based on the domain name portion of the URL (e.x. nytimes.com).

Does that address your questions? Please let me know.

Ben

Superfandominatrix

Thanks Ben... the reason I pointed out nytimes and glassdoor is that I found them both in the github.com link I provided above. I found this online checker and glassdoor is showing vulnerable while nytimes is not.

https://cloudbleedcheck.com/?domain=glassdoor.com

For some reason Watchtower isn't returning Glassdoor as a vulnerability despite a "last modified date" of May 23, 2016. Based on everything I've found, at minimum Glassdoor should be returned as a possible problem. Why is this site excluded from Watchtower?

Edit: and uber.com as well. Why is uber.com excluded?

pervel

@Superfandominatrix, that site also displays 1password.com as vulnerable:

https://cloudbleedcheck.com/?domain=1password.com

It seems to just list everything and the kitchen sink.

Superfandominatrix

Thanks pervel... I guess my question still stands, which sites are included as a vulnerability in Watchtower and which are not? I'd like transparency on the problem list 1PW is using to improve my confidence levels that Watchtower is working correctly. Trust but verify and all that...

DanielP

@Superfandominatrix

Ben summed this up pretty nicely in his previous post, specifically in this paragraph:

We'll only add a site to Watchtower after a 1st party confirmation that some or all of their services were affected. We do not flag sites simply based on 3rd party speculation. The exception to this is when we can test a site, such as we could with Heartbleed. Then, even when we do not have 1st party confirmation, we may list a site based on evidence we're able to gather ourselves.

Looking at Glassdoor specifically, since you mentioned it, it's not in Watchtower because the company communicated on Twitter that there was no impact after Cloudbleed.

hesspaul

@DanielP can you clarify a little more? Ben's quote says you need first party confirmation of a problem to list a site, but then you mention that the reason Glassdoor is not listed is because the company claimed there was no impact, which is a very different and more powerful standard.

The first standard would mean you will only ever list a potentially compromised site during a situation like Cloudbleed if the company confirms they have a problem, and the second strandard means you will list a site as suspicious unless the company confirms they have no impact.

What do you do to a silent company? Does watchtower consider it as clean, or include it as a potential cloudbleed concern?

Cc @Superfandominatrix

DanielP

Absolutely @hesspaul, I should probably have clarified this better. What Ben said stands, i.e. we need confirmation that there was an impact before we add that website to Watchtower, we do not just add websites there based on speculation.

My mention of Glassdoor was just meant as an example since it was specifically mentioned in this discussion. It was meant more as an "in addition to not having reported any vulnerability, Glassdoor also specifically stated that they are not impacted by this" sort of thing. It was just meant to make the point for this specific decision stronger, in response to @Superfandominatrix wondering why this website wasn't showing up in Watchtover.

I hope this clarifies things a little!

Superfandominatrix

DanielP, Ben... thank you for the clarification. Your approach sounds hellishly labor intensive, tracking down statements from each website operator. What is your estimate for completing the manual assessment work on the 4+ million affected websites?

MrC

@Superfandominatrix ,

There's a lot of very soft language being used to describe this issue, and words like "speculation" are a bit equivocal and perhaps dismissive.

The list of 4.2 millions sites are only a list of sites that have used Cloudflare's CDS or DNS services. It is not a list of affected sites. And the list is not a speculative list of vulnerabilities. Rather, it is a first pass forensics list of possible sites. It is up to each vendor to supply a response statement, if their site is on that list. In the absence of such a statement, or other proof assuring no comprise occurred, the vast majority of the sites on the list will remain unknown or unverified one way or the other. This is typical, and this is just the way it is. So you have two choices: 1) await for vendors like Agilebits to place items on their vulnerability lists, one by one, or you can 2) take more drastic action yourself and just change all of the passwords for sites that appear on that candidates list. Given that the later is likely to take < 30 minutes, I think that option (2) is a no-brainer.

For end users like us, it has been grossly estimated that there might be a breach in 1 or fewer per 10 million hits per month during the window of vulnerability.

DanielP

@Superfandominatrix

I don't think I could have said this better than @MrC did :)

Ultimately, that list is a list of potentially affected sites, and adding them all just based on speculation is not the way we have chosen to address these. Having said this, we are definitely adding the ones that are indeed affected, and you always have the option to update your password for those sites anyway with the help of the script MrC did, for example. I have used it myself and it worked great ;)

hesspaul

A lot of us who are comfortable enough with the technology have used @MrC script --- and as he said so well himself "option (2) is a no-brainer."

I wish Agilebits would provide this capability within 1Password's watchtower feature instead of having to download a script, export all my vaults (I have a LOT more vaults since migrating to the Teams product), etc.

AGAlumB

@MrC: Indeed, we prefer to reserve harsh language for the xenomorphs. ;)

@Superfandominatrix: But in all due seriousness, MrC is right. It's a messy situation, and ultimately the full truth may never emerge. We're focused on staying on top of known breaches, and that's a non-trivial pursuit (as you suggested), even under the "best" of circumstances. It likely won't be possible for us to determine the full impact of the CloudFlare issue, since in many cases no information is forthcoming. So using his awesome script to automate checking the full CloudFlare list is an extremely thorough way of determining if any of your logins could be affected.