We all know about the recent Dropbox bug which allowed users to login without correct password within the 4 hours period before the Dropbox team actually discovered the bug and fixed it. If you don’t down about this bug read this post on Official Dropbox blog. Derek Newton, a computer security expert, some months back discovered a serious security implication in Dropbox authentication design. He discovered this during his research on understanding the inner workings of several of the popular file synchronization tools with the purpose of finding useful forensics-related artifacts.
Derek Newton Discovered that –
“Under Windows, Dropbox stores configuration data, file/directory listings, hashes, etc in a number of SQLite database files located in %APPDATA%\Dropbox. We’re going to focus on the primary database relating to the client configuration: config.db. Opening config.db with your favorite SQLite DB tool will show you that there is only one table contained in the database (config) with a number of rows, which the Dropbox client references to get its settings. I’m going to focus on the following rows of interest:
- email: this is the account holder’s email address. Surprisingly, this does not appear to be used as part of the authentication process and can be changed to any value (formatted like an email address) without any ill-effects.
- dropbox_path: defines where the root of Dropbox’s synchronized folder is on the system that the client is running on.
- host_id: assigned to the system after initial authentication is performed, post-install. Does not appear to change over time.
After some testing (modification of data within the config table, etc) it became clear that the Dropbox client uses only the host_id to authenticate. Here’s the problem: the config.db file is completely portable and is *not* tied to the system in any way. This means that if you gain access to a person’s config.db file (or just the host_id), you gain complete access to the person’s Dropbox until such time that the person removes the host from the list of linked devices via the Dropbox web interface. Taking the config.db file, copying it onto another system (you may need to modify the dropbox_path, to a valid path), and then starting the Dropbox client immediately joins that system into the synchronization group without notifying the authorized user, prompting for credentials, or even getting added to the list of linked devices within your Dropbox account (even though the new system has a completely different name) – this appears to be by design. Additionally, the host_id is still valid even after the user changes their Dropbox password (thus a standard remediation step of changing credentials does not resolve this issue).”
Read the following article – Dropbox authentication: insecure by design by Derek Newton, to get more details on this and tips on How to keep you data protected in your Dropbox.
