Cloudbleed: Cloudflare CDNs, does it impact 1Password? [no; see blog.agilebits.com]
Google vulnerability researcher Tavis Ormandy has discovered a major security bug, now known as "Cloudbleed", in Cloudflare's CDN that has caused Cloudflare to "have been leaking customer HTTPS sessions for months. Uber, 1Password, FitBit, OKCupid, etc." --
Ormandy's full bug report mentions that the leaked sensitive data included, "even plaintext API requests from a popular password manager that were sent over https (!!)" -- https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
Security researcher Thomas H. Ptacek commented, "If you run a cloud-based password manager, don’t put it behind a CDN in a way that exposes the CDN to secrets." --
Cloudflare's initial technical response explains that "The earliest date memory could have leaked is 2016-09-22." -- https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/
Could 1Password explain what sensitive customer data, if any, has been exposed by Cloudflare's bug? Which of our secrets have actually been exposed to the Cloudflare CDN, and thus, potentially, the entire world?
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Seconded, I'm wondering the same thing. In particular wondering if this affects me even though I don't use 1password.com to access my passwords? I don't have a 1Password account; I use the native apps and sync my vault with Dropbox.
0 -
Thirded; also, I would appreciate guidance on how to proceed from here to initiate damage control. Do I need to force reset all my passwords for example? What about "Notes" and other stuff saved into my 1Password account?
0 -
Hi all!
We are aware of the reported data breach at Cloudflare.
1Password data was NOT exposed as a result of this breach. This means that users of 1Password do not need to change their Master Passwords.
1Password does not rely on HTTPS to ensure that customer's 1Password data is not at risk. Our security recipe starts with AES-256 bit encryption and uses multiple layers to protect your data both at rest and in transit.
To read further about our approach to security and how we protect our 1Password data you can read our security whitepaper here
We also have a blog post up here
Kyle
0 -
Curious to know what was getting leaked.
0 -
We'll provide a full run down as soon as we can.
Rick
0 -
Do see our blog post: Three layers of encryption keeps you safe when SSL/TLS fails , which sums things up.
As Kyle pointed out any data captured through a failure of HTTPS is encrypted with keys that would never be in CloudFlare's memory. (Indeed, some never ever leave your own devices). Furthermore, the sign in process doesn't involve sending any secrets; so even if someone were to capture every bit of a sign in they would have nothing that would help then attack 1Password data,
So @tommyent, I, too, would love to know what data Tavis and his team saw (and purged), but it wouldn't be anything that would put anyone at risk if exposed.
0 -
Just a heads up. I modified the title of the post to be a little less scary and more inviting for people to come join in without being worried when simply looking at the title.
0 -
Will you guys be updating Watchtower security audit with services affected by the Cloudbleed leak? This type of leak is quite similar to Heartbleed which was the driver for your (very much appreciated) rapid deployment of the Watchtower service.
Edit: something like integrating this list of affected sites to easily determine which sites' passwords need an update.
0 -
That is a tricky question. We would need to find some mechanism to distinguish services like ours, hosted by CloudFlare during some of the relevant time span, does not require people to change their passwords from services that do. We will certainly be considering this, but I don't think we are going to make a decision tonight.
0 -
For those wondering which of their 1password sites might be affected, I created a nodeJS script that checks your 1password URLs to see which are affected.
https://github.com/weltan/cloudbleed-1password
Cheers.
0 -
@weltan: Wow! Thank you for sharing that! I think that jpgoldberg 's point still stands: It's difficult to simply tag all of these sites as being affected when perhaps, like 1Password.com, some may not be due to their security architecture. We'll see what we can come up with.
0 -
It's difficult to simply tag all of these sites as being affected when perhaps, like 1Password.com, some may not be due to their security architecture.
I don't think this is the case but this statement makes it sound like you're more worried about making 1Password look bad by having it show up on such a list rather than protecting your users. Realistically, if there's any chance whatsoever that a website was affected by this issue then that website's users should be advised to change their credentials immediately. I realise that that probably means a lot of websites will be tagged, but it's better to err on the side of caution on this particular issue.
0 -
@jpgoldberg I would second (third?) the proposal to add this to the Watchtower audit:
- It is totally impractical for users to go through the complete list of 4,287,625 websites that were potentially affected by the bug to see which ones affect them.
- This is exactly the sort of issue that Watchtower was designed to assist with
I can understand that you may be concerned about declaring a site as vulnerable when it may not actually have been affected, but I think it's far safer to initially include all the sites that haven't already been confirmed as unaffected, even if you later remove a site from the list if it's confirmed that it was secure.
0 -
Greetings -
1Password accounts are protected by 3 layers of encryption. The Cloudbleed vulnerability is similar to other vulnerabilities which have involved SSL/TLS, where the encryption in that layer failed. As @jpgoldberg mentioned, there are still two more layers protecting the secrets and this vulnerability doesn't affect either of those layers. The secrecy of the APIs, including the parameters in the HTTP requests, is not part of the security model.
We use Bugcrowd for our penetration testing and Bugcrowd researchers are provided with API documentation, on a best-effort basis. If a pentester asked for the documentation for an API they suspected was vulnerable, someone on the security team -- me, Jeff, Kyle -- or one of the developers -- Rick, et alia -- would update the secure vault where researcher tools are stored with that API.
But more to the point of the Cloudbleed vulnerability, we also provide UUID values for specific vaults and items, and Bugcrowd makes use of MitM proxies (Burp Suite, in particular) in their pentesting. The Cloudbleed vulnerability can best be thought of as a really ugly MitM proxy that everyone gets to access, not just the person(s) who set it up. Even with pentesters using Burp Suite, there have been no unauthorized data disclosures of unencrypted data. There have been access control vulnerabilities which allowed users to access encrypted data belonging to others members within the same account, but no vulnerabilities to date have resulted in data being decrypted. It isn't for lack of trying, either. The bug bounty award for the disclosure of cleartext data is $25,000, which is about $24,990 more than the value of the t-shirt Cloudflare is offering.
As an aside, there is nothing preventing Tavis from submitting a vulnerability against 1Password.
0 -
If any web crawler has been dumping memory from CF for a while now, then let's assume any password to any website using cloudflare is compromised. (except 1p passwords).
When will watchtower be updated to show me which URLs/Domains point to cloudflare so I can change my passwords?
0 -
I don't think this is the case but this statement makes it sound like you're more worried about making 1Password look bad by having it show up on such a list rather than protecting your users. Realistically, if there's any chance whatsoever that a website was affected by this issue then that website's users should be advised to change their credentials immediately. I realise that that probably means a lot of websites will be tagged, but it's better to err on the side of caution on this particular issue.
@bogdanp: That sounds like you're suggesting we add 1Password.com to Watchtower even though login information wasn't compromised, and I fail to see how that benefits anyone. As mentioned previously, we're evaluating the best approach here.
I can understand that you may be concerned about declaring a site as vulnerable when it may not actually have been affected, but I think it's far safer to initially include all the sites that haven't already been confirmed as unaffected, even if you later remove a site from the list if it's confirmed that it was secure.
@davidgeary: I think you're right that caution needs to be exercised, but also in a different sense. There may be a legal issue in telling users that a site has been compromised if it hasn't. I'm sure that even Tavis doesn't announce every lead he has, not only because it can be beneficial to conduct research secretly, but also in case it doesn't pan out, since an erroneous security announcement can have a very real impact on a company's business.
When will watchtower be updated to show me which URLs/Domains point to cloudflare so I can change my passwords?
@jondb: Information is still coming in, and we're working to determine the best approach. We'll update this thread with the results.
I love that you guys provide this whitepaper. Will there be an update that fills in some of the incomplete sections?
@wxkeith: Absolutely. There have been some revisions already, and there's more in the works. :)
0 -
@jpgoldberg this is something I would want and expect 1P to do for me --- to flag potentially vulnerable passwords in a situation like today's, so I can focus my thoughts on just those sites even if it's as simple as going to that site's blog to determine whether they have it under control. For instance if it flagged 1Password as potentially vulnerable I would know to check your forums for any comments about it. This is a lot more practical than me trying to manually look through the list of 4.3 million potentially affected sites and compare it to the list of my 1500 or so 1P entries!!
0 -
Thanks for that, Weltan.
Found ~40 possible URLs out of 617 logins and I've changed nearly all of them.
1Password made this so easy. I love this app and hope you folks continue to stay a step ahead of the bad guys.0 -
-
@hesspaul: Understood. But at the same time it's important that we treat this as what it is: yet another unfortunate series of potential account breaches. We add these to Watchtower once we're able to confirm. This is no different. Thanks for your patience, and for being so passionate about this.
0 -
I'm glad @rickfillion has indicated some sites will be added to Watchtower*. In reading Agilebits responses here, and in past threads, I think Agilebits' stance has been too cautious on the side of avoiding false positives, waiting for absolute confirmation that a site has been compromised. I think this is the wrong approach, as for example, in this case, there are far too many potentially compromised sites to obtain such assurances.
Watchtower should take a Better Safe Than Sorry stance. Changing a password is usually trivial; missing a compromised change can be catastrophic. Watchtower is advisory, and being so deeply hidden within the UI, there is almost no downside to it suggesting or advising users change a few passwords - its good practice anyway.
* As an tangential note, it seems curiously inconsistent to me that Agilebits takes an absolutely hard stance against users, for example, printing out their passwords, but side-steps using their owe Watchtower service to advise users about publicly disclosed, widely-known potential threats. The risk threat for the former is deemed Terror Level 5, while the later doesn't even register at Terror Level 0, despite no certainty of exploits in either case. I get that the former risks all passwords, while the later just a few. But its not the number of passwords that should be the sole metric, rather the site. Users who were caught using certain online dating services via password / username breaches had their lives ruined. I'm sure they would prefer a Watchtower-like notification if, say, okcupid dot com was potentially breached (oh, and look at that, its on the list of potentially exploited sites!). And since Agilebits cannot know a site's personal risk-metric to any given individual, its just better to be safe than sorry. Watchtower was supposed to be a helping tool, but instead seems little more than an add-on wart that occasionally flares up.
0 -
For people like me who've already changed passwords on the affected sites. Will watchtower realize that or will it give me a false positive?
0 -
@jd4840 : Watchtower should be smart enough to see you've changed your password after the date of the issue and not bug you to do it again.
0 -
@MrC : definitely there are different ways of looking at this. I'm not sure that I agree with the comparison you've made with regards to export/print, but I see where you're coming from in general.
0 -
@rickfillion - it's a stretch of a comparison, I agree. But the point is a simple one, and I think you've heard it loud and clear - Watchtower is sufficiently silent as to be basically insignificant.
0 -
@MrC : loud and clear, yup. :)
0 -
I don't know that it matters. Wasn't the CloudFlare breach going for months before it was discovered/reported? Watchtower does not possess the requisite supernatural ability to identify malfeasance before it become news. Although it might behoove agilebits and other password managers to gin up a relationship with Top 500 popular sites (or sites with a higher aforementioned "personal-risk-metric") to come up with a protocol to act on things quicker.
0 -
@jd4840 : it would certainly be cool if such a standard existed so that we could reduce the delay between breach disclosure and watchtower notifications.
0 -
@brenty @rickfillion I know this isn't an immediately implementable suggestion, but why can't watchtower be red/yellow/green. Red = your current very cautious level that watchtower uses to declare a problem, yellow = suspected/potential concern with a link to some article about the event, green = not flagged by watchtower. The red bar at the top which just says alert could open into a paragraph/link that you create when you enter those sites in your database.
0
