I got a bit waylaid with how Dropbox performs host-level authentication while I was researching and documenting forensic artifacts that Dropbox leaves lying around, but finally have gotten the chance to come back around to finish my research/documentation. Here’s a summary of my observations:

Dropbox binaries are installed into %AppData%\Dropbox\bin instead of the standard %PROGRAMFILES%. During the install, a number of registry keys were added (13), although they contained no forensically useful data.

The Dropbox configuration and state is stored in SQLite files found in %AppData%\Dropbox

config.db: contains baseline configuration settings that the Dropbox client references in order to run in a table named config. Records of interest include:

host_id: the authentication hash used by the Dropbox client to authenticate into the Dropbox “cloud.” This hash is assigned upon initial install/authentication and does not change unless revoked from the Dropbox web interface.

email: account holder’s email address. Can be changed to any value without consequence – set at install/authentication.

dropbox_path: actual path to the user’s Dropbox on the local system.

recently_changed3: lists the path/filename for the five most recently changed files- this includes files removed/deleted from the Dropbox. This is probably the only truly useful forensic artifact produced by Dropbox (other than the usual filesystem related artifacts). The BLOB for this record is text-based and is consistently formatted:

text begins with “lp1”, ends with “a.”

entries are in order of most recent to least recent and each entry the filename/path is followed by “I00” and “tp#” (replace # with the order that the file is in + 1, i.e. first entry is followed by “tp2”), separate by line breaks.

if the file has been removed/deleted from the Dropbox, the “I00” text is removed and a “N” is placed in front of the “tp#”. So, an example of a removed/deleted file is would be:(V41725479:/new file.txt Ntp2

root_ns: appears to be used throughout the Dropbox DBs to reference the base Dropbox path/location.

filecache.db: contains a number of tables, but the primary focus is to describe all files actively in the Dropbox (deleted/removed files are removed from this table upon deletion/removal). Tables and records of interest:

file_journal: includes the filename, path, size (in Bytes), mtime (file modified time, in Unix/POSIX format), ctime (file created time, in Unix/POSIX format), local_dir (flag indicating whether the entry is a directory), and more (mainly unpopulated).

block_cache: hash id (id) and hash. Hash is of an unknown format and did not match up with anything I could generate using standard tools.

mount_table: appears to list folders that are shared with other Dropbox users.

host.db: actually not a SQLite database but contains what looks to be a hash of some sort (possibly SHA-1?) and the dropbox path (dropbox_path in config.db) encoded in base-64. The entire file may be encoded in base-64 (basing this on a few Dropbox forum postings I read), but the first part of the file does not decode into anything human readable or match any other fields that I observed in the other DBs.

sigstore.db: stores hash values which correspond to the values found in the block_cache table in filecache.db.

unlink.db: appears to be a binary file and is not a SQLite database. Format and purpose is unknown.

Honestly, short of the recently_changed3 record in the config database, there really isn’t a significant number of useful forensic artifacts generated by Dropbox. Given Dropbox writes to the local filesystem, your standard filesystem analysis steps will encompass files stored/synced into a subject’s Dropbox; but perhaps, under certain circumstances, the recently_changed3 record and/or the Dropbox ctime/mtime entries for files could come in handy…

For the past several days I have been focused on understanding the inner workings of several of the popular file synchronization tools with the purpose of finding useful forensics-related artifacts that may be left on a system as a result of using these tools. Given the prevalence of Dropbox, I decided that it would be one of the first synchronization tools that I would analyze, and while working to better understand it I came across some interesting security related findings. The basis for this finding has actually been briefly discussed in a number of forum posts in Dropbox’s official forum (here and here), but it doesn’t quite seem that people understand the significance of the way Dropbox is handling authentication. So, I’m taking a brief break in my forensics-artifacts research, to try to shed some light about what appears to be going on from an authentication standpoint and the significant security implications that the present implementation of Dropbox brings to the table.

To fully understand the security implications, you need to understand how Dropbox works (for those of you that aren’t familiar with what Dropbox is – a brief feature primer can be found on their official website). Dropbox’s primary feature is the ability to sync files across systems and devices that you own, automatically. In order to support this syncing process, a client (the Dropbox client) is installed on a system that you wish to participate in this synchronization. At the end of the installation process the user is prompted to enter their Dropbox credentials (or create a new account) and then the Dropbox folder on your local system syncs up with the Dropbox “cloud.” The client runs constantly looking for new changes locally in your designated Dropbox folder and/or in the cloud and syncs as required; there are versions that support a number of operating systems (Windows, Mac, and Linux) as well as a number of portable devices (iOS, Android, etc). However, given my research is focusing on the use of Dropbox on a Windows system, the information I’ll be providing is Windows specific (but should be applicable on any platform).

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).

Of course, if an attacker has access to the config.db file (assuming that it wasn’t sent by the user as part of social engineering attack), the assumption is that the attacker most likely also has access to all of the files stored in your Dropbox, so what’s the big deal? Well, there are a few significant security implications that come to mind:

Relatively simple targeted malware could be designed with the specific purpose of exfiltrating the Dropbox config.db files to “interested” parties who then could use the host_id to retrieve files, infect files, etc.

If the attacker/malware is detected in the system post-compromise, normal remediation steps (malware removal, system re-image, credential rotation, etc) will not prevent continued access to the user’s Dropbox. The user would have to remember to purposefully remove the system from the list of authorized devices on the Dropbox website. This means that access could be maintained without continued access/compromise of a system.

Transmitting the host_id/config.db file is most likely much smaller than exfiltrating all data found within a Dropbox folder and thus most likely not set off any detective alarms. Review/theft/etc of the data contained within the Dropbox could be done at the attackers leisure from an external attacker-owned system.

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.

Hopefully, Dropbox will recognize the need for additional security and add in protection mechanisms that will make it less trivial to gain long-term unauthorized access to a user’s Dropbox as well as provide better means to mitigate and detect an exposure. Until such time, I’m hoping that this write-up helps brings to light how the authentication method used by Dropbox may not be as secure as previously assumed and that, as always, it is important to take steps to protect your data from compromise.

Update (10/31/2011): Dropbox has release version 1.2.48 that utilizes an encrypted local database and reportedly puts in place security enhancements to prevent theft of the machine credentials. I have not personally re-tested this release – feel free to comment if you’ve validated that the new protection mechanisms operate as described.