Dropbox Paid More Than $1 Million Via Its Bug Bounty Program
Nuri Baggett
I am using 1Password7 with stand-alone vaults that I synchronize myself using a private server. I would like to upgrade to 1Password8, but the online description of the process is not very clear (see -1password-account/).
Could someone here tell me if 1Password8 allows you to use private vaults that the user can synchronize using their own server (like Nextcloud, dropbox, icloud, ect...)? The instructions for migrating state that you first need to migrate your vault to a 1Password "account". I presume that this means that it is an online account where my data are stored on your servers. If I were to do this, could I later decide to use a stand-alone vault?
No, 1Password 8 does not support standalone vaults. 1Password 8 is our first membership only offering. Yes, there is a an online account portion with membership. No, 1Password 7 is the last version to support standalone vaults. This may help too. -future-of-local-standalone-vaults/p1
I have used 1Password for more than a decade and I have been very happy with it and have promoted it to many of my friends and colleagues. I was never happy that 1Password was a closed source black box, but given that I was able to store my own vaults on my own servers, I was satisfied that there were no real security concerns to worry about.
I understand that some people might appreciate the simplicity of having everything stored on the cloud. I also understand that 1Password does need to make a profit somehow. Unfortunately, for me though, the software as a service approach, closed source products, and the storing all information in the cloud is just too much for me swallow. If 1Password were to make the client open source, I would have been more than happy to pay a 1-time fee (or perhaps a subscription) to use your software.
As soon as 1Password7 stops working with web browsers (I received a warning today that the browser plugin is no longer supported and will stop working at some point), I will be transitioning to KeepassXC, which is free, open source, and allows you to store your own vaults on your own servers. It also imports the 1Password vault (with attachments) without any problems as far as I can tell. I don't blame you for your business decisions, but at the same time, I feel that you have abandoned your most ardent users that have been with you for over a decade. As much as I would like to blame you for this, it is my own fault: Whenever you use closed source software, there is a good chance that you will be burned at some point. In retrospect, I have been burned every time.
Thank you for using 1Password for so many years and for telling your friends and family about us so that they can also keep their data safe and secure. We really appreciate that you've been with us for so long. ?
I would encourage you to read through our security design. All of your information is end-to-end encrypted locally on your devices before being backed up to your 1Password account. 1Password account vaults are much more secure than older standalone vaults, your 1Password account data is protected and encrypted using a secret that is derived from both your account password and your Secret Key. Old standalone vaults didn't include the Secret Key nor did they include other modern security features such as two-factor authentication.
If you haven't already then please fill out the self-hosting survey as we're collecting data regarding demand for a version of 1Password.com that folks can host on their own server: Self-hosted 1Password kick-starter
That all being said, thank you again for being with us for so long and if you are moving on then I'm happy that you're still planning to use a password manager to keep yourself safe, even if that isn't 1Password.
The security audits that I mentioned in my previous post are one way to verify that 1Password does what it claims that it does. The audits are conducted by independent third-party organizations that are well known and respected in the industry. We open 1Password to their inspection and then we publish their findings publicly.
We also have a very high-paying bug bounty program to incentivize the community to test 1Password and to report security issues or vulnerabilities: Strengthening our investment in customer security with a $1 million bug bounty
You're right, 2FA wouldn't help there. That's where our dual-key architecture and cryptography comes into play. We take data security very seriously and we deliberately limit the information that we can access here on our end. As mentioned, all of your actual 1Password data is end-to-end encrypted using a private key derived from your account password and Secret Key so all that we see on our end are encrypted blobs of gibberish. If our servers were breached all that the attacker would be able to get is that encrypted gibberish, not your data.
Our Chief Technology Officer actually wrote a blog explaining how our security design protects your data even if our servers are breached: How 1Password Keeps Your Data Safe, Even In the Event of a Breach
Have you ever wanted to share a file via link but were afraid that anyone with the link would be able to access it? Dropbox Professional and Business customers are able to password protect their shared links via an option in Link Settings. This ensures that only users with the password for the link are able to access the file.
One of our top bug bounty reporters, detroitsmash, reported on December 25, 2018 that one of our endpoints responsible for performing document previews in Paper documents was ignoring passwords set on shared links. This would allow an attacker with a copy of a password protected shared link to be able to bypass the password requirement and view the document.
After validating the report, it was discovered that additional access control checks were missing on this endpoint. We immediately got to work on correcting this and pushed a fix out within a day. detroitsmash was awarded $10,648 for their finding and was later awarded an additional $2,744 as a bonus for being one of the best reports we received within that 6-month period.
Dropbox teams have access to a bulk user import feature that allows a Team Admin to import users listed in a CSV file. This feature is helpful for teams that have hundreds of licenses and the process of manually inviting each user one-by-one would be too cumbersome.
After some additional investigation, we discovered that it was possible to get this behavior to trigger on the Desktop client as well. Members from both the Product Security team as well as the bug bounty hunters spent some time trying to escalate this HTML injection into something more impactful. We concluded that the CSP rules used in the Desktop environment are too restrictive to allow for more interesting attacks.
Moving back to the web client, we realized that DOMPurify was allowing tags through in the default configuration. This means that an attacker could reapply styles on the page making it look however they want. Unfortunately, another big problem with exploitation was a limit on the number of characters allowed in the first and last name fields.
This functionality, however, can also come at a great cost. Improperly configured and mitigated, this feature can quickly turn into a vulnerability called Server-Side Request Forgery (SSRF). Server-Side Request Forgery occurs when an attacker has the ability to issue or redirect a request issued by the server into a sensitive location, often internal. The impact of SSRF ranges variably, but can lead to Remote Code Execution if unchecked.
Unfortunately for us, Dropbox often uses libcurl to make network requests which supports dozens of different protocols, not just HTTP and HTTPS. In the case of HackerOne report 139572, bug bounty participant Mark Litchfield discovered that by returning a 302 redirect to the request issued by Dropbox from our Saver API, that he was able to switch to an esoteric protocol called Gopher). Because Gopher is not HTTP-based, the request did not go to our configured proxies allowing him the ability to hit internal services.
Mitigation for this vulnerability was not as straight-forward as preventing redirects and disabling bad protocols at the app-layer. This could affect other places we make outbound requests in the future, too. To make our mitigation robust, we looked at all of the available protocols in libcurl and manually patched out all of the protocols we did not need to support. By approaching the mitigation this way, we have future-proofed ourselves from having this kind of problem in the future.
Making a secure platform to store, share, and collaborate on files is a deceptively hard problem. Dropbox has to handle any kind of file you can throw at it while ensuring the safety of everyone else using the platform. We also want to avoid compromising the experience of working with these files as much as possible, so sanitizing a file when a user fetches it is generally off-the-table to avoid manipulating the contents and integrity of the file.
One of our main mitigations to attacks like XSS) is origin isolation. That is, we use an entirely separate origin (dropboxusercontent.com) to serve file contents, which often includes when we render files via iframe in the web client. By separating out the origin that we serve our file contents, we avoid needing to do any sanitization of the content and are able to serve back the raw bytes of the file. Even if the file was a malicious XSS payload, the XSS would execute in a useless origin, protecting unsuspecting victims from potential compromise.
An App Cache Manifest is a file that describes what files a browser should cache locally for improved performance and experience. A webpage can mark itself as having an App Cache Manifest via an attribute, manifest, on the html tag at the top of the document. The browser will, based on the directives in the manifest, fetch and store any files necessary to comply with the manifest.
The attacker would then trick a victim into visiting or via a shared link so the user is viewing the file via our web client. The browser would then fetch the manifest marked by the manifest attribute in the payload.xml page. Then the browser fetches any of the assets marked in the manifest, including those under the FALLBACK directive. After these files are fetched, the browser would begin processing the javascript and filling up its cookie jar for the dl.dropboxusercontent.com domain.
7fc3f7cf58