#practical #dropbox #security #advice
How about checking your security settings?
Published 09:38, 08 April 11
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.
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.
So, given that Dropbox appears to utilize only the host_id for authentication by design, what can you do to protect yourself and/or your organization?
- Don't use Dropbox and/or allow your users to use Dropbox. This is the obvious remediating step, but is not always practical - I do think that Dropbox can be useful, if you take steps to protect your data
- Protect your data: use strong encryption to protect sensitive data stored in your Dropbox and protect your passphrase (do not store your passphrase in your Dropbox or on the same system/device).
- Be diligent about removing old systems from your list of authorized systems within Dropbox. Also, monitor the "Last Activity" time listed on the My Computers list within Dropbox. If you see a system checking in that shouldn't be, unlink it immediately.
...etc, etc; what he's basically saying is that there's a magic file on your Dropbox-enabled computer which - if copied - can be reused on another computer to gain access to your Dropbox. But they have to get the file, first.
I wouldn't panic about the overall approach; in fact commenter Dwayne Litzenberger has already pointed out that it's not much different to use of unpassworded SSH public key authentication, where you similarly set up a magic file which (if copied) permits unrestricted access into another machine. I've seen plenty of enterprises where that happens and is justified by the argument that it's safe to do this within a nice, secure corporate network - Ha! - whereas the simple truth is that sometimes unpassworded, statically authenticated access to compute resources and data is so desirable that people are willing to make it work within an acceptable framework of risk.
Plus, let's be honest: once somebody has gotten into your machine to retrieve Dropbox's magic file then you are already 0wned and it's game over, Dropbox or no Dropbox.
I would be worried if there was any hint that a Dropbox client could be persuaded to read or write in a filesystem anywhere outside its own little sandbox, or if there was some sort of buffer overflow, or if it was possible to forge credentials from a cold start; but I've not seen that yet. How Dropbox handles symlinks by dereferencing them even if they point to directories does absolutely terrify me - something like ln -s /etc ~/Dropbox/etc would be bad, and any Windows equivalent perhaps worse, but see the already 0wned point, above.
Certainly more research should be done because using any software like Dropbox (or SSH, or a browser, or a network) does introduce an element of risk. But you knew that, didn't you?
For now the Dropbox user is probably wisest to connect to their Dropbox website, check the Account > My Computers page, and "unlink" any devices that are listed but no longer used.