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.
I too saw this and even tho its not exactly new, I want to place a few comments as well.
Interesting… There are alot of people saying that having access to a users files means the battle is lost already.
There are a number of ways to access files on a windows host without the users knowledge, through a number of vulnerabilities … some not even being vulnerabilities.
However grabbing one file on a known path may be easy, but it is not the same thing as:
a) Having access to all files on the system
b) Being able to query the system in various ways, and perform complicated operations on the system under administrative privileges.
Simple measures at least on a Windows system would seriously hamper an attackers possibilities to exploit a vulnerability like this, for example:
a) Dropbox client runs as service, under a specific set of credentials, and default access to the config.db file are only allowed for those credentials and SYSTEM. This will eliminate the possibility of stealing the file by simple means, even if the process in question runs under administrative privileges, as it involves changing file permissions – something you’ll need a pretty high level of system access to do.
b) If same ID is active simultaneously flag an alert and re-authenticate (and I don’t care about those complaining that they can no longer exploit this to ease their own life’s when deploying large number of identical machines in a test environment, as I dont believe thei’re the major part of users 🙂 )
c) Using hardware profiling – again grabbing the hardware profile requires a higher level of system access than most simple methods of acquiring a single file. (at least on windows).
d) Many more…
To keep it simple – my point is:
A malicious 3rd party, does not neccessarily have the level of control over a machine, to defy many of the suggestions delivered in all the previous comments, just because he/she is able to grab this one file. So it would be worth incorporating some of those, to narrow the possible exploitation scenarios.
This includes most types of social engineering, including the “please let me use your pc to fire off a quick mail” issue, along with shipping the file for “support needs” etc.
It would be quite easy to implement, and it would make a difference regardless of what many thinks – again – at least on windows.
All that being said – of course everybody who claims that if your system is fully compromised, then you’re screwed anyway – is absolutely right.
And almost forgot… for option a) above:
Removing all access rights to the file, except for a randomly created dropbox account, for which credentials are randomly set at install time, and denying administrators the right to change permissions, would eliminate the risk of anyone gaining access to the file unnoticed.
Dropbox service could then monitor the file for changes to permissions and should they occur, ask for re-authentication. Even if the malicious user tries – it would be impossible to restore original permissions, as he would have to take ownership of the file (because admins have been denied the change permission right).
The only way this could ever be circumvented unnoticed, would be to impersonate as the dropbox account, which would not be possible without a brute force on the locally saved hash – if the dropbox service changes its own password randomly, it would be next to impossible to circumvent this method undetected.
All this is for Windows only.
Looks like they just addressed this issue in latest RC:
http://forums.dropbox.com/topic.php?id=45535
Hardly a shocking exploit. Basically if an attacker has access to your file system, they can use it to get rights to your file system . . . wooooo
what about authentication via mac address?
Regarding your last suggestion to watch for systems checking in that shouldn’t be and removing them – wouldn’t that leave a copy of all your files on the phantom system? I think it would be better to move or delete your files so that Dropbox syncs the deletions, then remove that system.
Interesting article, balancing security with usability is always fun.
The “magic ticket” people are referring to in the comments is equivalent to SSH key based authentication that is common place in IT, and is accepted as a secure mechanism for unattended operations.
The security of the key is based on file system ACL’s and hopefully an encrypted file system or a encrypted storage device.
This is what the article refers to as a HOST ID.
As ARash (DropBox) mentioned this method is comparable to a cookie/session based token, but without (as others have pointed out) IP session based info or an expiration.
The fact is there is no universal way to identify the hardware/virtual host with a WWN/UUID e.g. a MAC address is easily faked as is an IMEI number or a CPU ID. Worse even if they exist, they vary between platforms/standards/technologies.
Of course you can use a combination of hardware factors to ID a device but this gets quite “grey” and annoying to the user e.g. replace a failed graphics card and you have to re-authenticate etc…
However DropBox can apply some smarts on the back end, assuming the standard use case is to re-authenticate when setting up a new host and not manually move the config.db.
For example:
1) Is a HOST ID (“Magic Ticket”) being used by multiple hosts simultaneously? This should not occur at all e.g. -1,000 points
2) Is the source IP on a commonly used address e.g. home. If so its more likely to be ok e.g. +200 points
3) Is the source IP in the same network (e.g. ISP) and geolocation as usual e.g. Wellington, New Zealand
4) Has the HOST ID appeared in New Zealand at 8pm UTC, and then Turkey at 9pm UTC. If so it is not possible (without a worm hole). -1,000 points at 9pm UTC, -600 points at 10am UTC and -200 points at 6pm UTC.
5) Has the HOST ID moved operating systems e.g. from Linux to Mac/Windows? -300 points
6) You get the idea…. This is all based on easily accessible data from any HTTP/S or fat client based TCP/IP connection.
Other improvements that should be made:
7) Pop up a notification on all hosts connected to the account when a device changes or something odd, but not definitive happens. For example hey you are normally in New Zealand but are now in Thailand.
8) Regularly (weekly?) change every device’s HOST ID automatically using something like Diffie-Hellman key negotiation. Make this optional
9) Allow the users to expire connections after a period, expiration can occur on the next new request (once processing existing requests has completed). e.g. User has a desktop at home that is left on, they should be able to choose that the connection remain authenticated for xx days after which they are re-authenticated.
10) Offer multi-factor authentication, preferably using TOTP.
These ideas are all about testing integrity, in other words no one factor is relied upon to authenticate a client. Knowing the HOST_ID is not enough, even knowing the username/password combo and having the TOTP device should not be considered enough if other factors are screaming NO!.
@Geoff Baysinger: Your items (2) and (3) exist. (2) in the DropBox settings on the web site and (3) at https://www.dropbox.com/events. However for (3) to be effective DropBox need to expose the origin of the change and its connection info e.g. OS, IP address etc…
Nice website, thanks for sharing all the info on Dropbox. I was looking for some input.
I believe they have fixed that long ago already (mentioned it somewhere).
http://rud.is/b/2011/04/28/dropbox-1-2-0-experimental-build-fixes-security-issue/
The experimental build is already pushed to the stable build.